risks: need to add that payers of ecash tokens are vulnerable to payees in current design

[bipreview]

As I understand from the current design documentation, when a payer uses eCash to pay a payee, the payer passes the information necessary to spend the eCash to the payee. This sensitive information transfer, from payer to payee, is necessary as a spend in this model is defined by a mint successfully accepting an eCash token submission, validating that it was not previously spent, logging the identifier as spent, and disbursing the value in some form, usually as new tokens (which necessarily uses information that is secret to the payee in order to make the generation process blind to the mint).

It appears that the payer is fully vulnerable to the payee during the time period when both parties know the sensitive token information, but the tokens have not yet been settled at a mint. Even if you assume that the payee is an honest actor, the payee's system could be compromised by another party.

But, what prevents Bob from synchronously passing Alice's eCash tokens to Cindy for settlement of a concurrent transaction that Bob has with Cindy? Bob could even impersonate Alice, if he has Alice's personally identifiable information (PII) that Cindy may require for the transaction.

For example:

1. Alice places an order with Bob and submits payment for the order to Bob via eCash tokens.
2. Bob's system receives Alice's eCash tokens and places an order with Cindy's system. Bob submits Alice's eCash tokens to Cindy's system for payment along with Alice's PII, if necessary. Cindy's honest system successfully submits the eCash tokens to the mint for settlement and fulfills Bob's order (e.g.- perhaps it was an order to pegout to a fresh BTC address on-chain that is not associated with Bob).
3. Bob attempts to double spend Alice's eCash tokens at the mint and receives a valid rejection notice. Bob returns the valid rejection notice to Alice. Alice can further validate the rejection notice.

Thus, Bob successfully stole from Alice and can validly repudiate her payment. It is not provable that Bob committed fraud. In fact, if Bob was honest, then perhaps it was Hal Hacker that performed these shenanigans via Bob's compromised system. Cindy thinks Alice (at best -- and only if her system required PII) performed the swap of eCash tokens for on-chain sats. Alice is out the value and has no recourse at the mint as the tokens were validly spent. If Alice goes to the mint and attempts to trace who received the tokens, the mint can only say that Cindy received the value (assuming that the mint stored that information -- it can know, but it may not, depending on how much info it requires and logs).

---

EDIT: added some thoughts

Another possible process, having different, but possibly favorable vulnerabilities is:

1. Instead of having Alice send her eCash directly to Bob, have her request blinded serial numbers from Bob. The metaphorical equivalent of this step is having Bob create a new enveloped note that will be signed at the mint with the denomination that he is requesting from Alice. At this point, the new note is not signed by the mint, but it is blinded and ready for signing by the mint. Only Bob will be able to later unblind/unenvelope the new note, and Alice does not learn the identifier of the new note which remains private to Bob.
2. Alice sends the blinded serial numbers from Bob to the mint and has the mint generate signed blinded serial numbers using her mint account balance. These are equivalent now to new mint notes that only Bob can unblind and use (i.e.- are signed and still enclosed in their envelope).
3. Alice takes the newly signed enveloped mint note from the mint and returns it to Bob. Bob can remove the new note from its envelope and validate that he effectively has a new note that only he can spend. Thus, Alice has paid Bob.

Alice would have some vulnerability to Bob if the process fails. For example, if Bob's system dies between steps 2 and 3 and does not come back, then she could have been made to essentially burn some of her funds.

If the blinded serial numbers from step 1 were signed by Bob, then he'd be less able to repudiate having sent them to Alice. That could provide her a little more support if Bob's system were compromised. At least she'd be able to provide that his system caused her to create a note that was ultimately only usable by Hal Hacker. It's arguable whether this solution is better. But, I think the original discussed vulnerabilities are still problematic and worthy of consideration for re-design.

[bipreview]

I read through some code at https://github.com/fedimint/fedimint.

In the code I found:

1. Users create secret keys, known as "spend keys". The spend keys are used to generate corresponding public keys (elliptic curve points). To create an e-cash note, a user takes the X coordinate of a generated public point and uses it as a nonce (aka a "serial number" in typical e-cash terminology). The user blinds the nonce and sends it to the mint for signing. Then, the typical e-cash note creation process continues.

2. The nonce of an e-cash note is a compressed public key that can be used to validate a signature generated by the associated spend key. A paying user can create a transaction message that spends an e-cash note to a payee's blinded nonce, sign a hash of the transaction message with the spend key, send the transaction message + signature to the mint, and have the mint validate the signature with the nonce of the payer's e-cash note before reissuing new notes. This allows proving that the paying party (holding the spend key) committed to a specific transactional transfer (hopefully as agreed to with a payee). This is known as the "pay to blind nonces" flow. This flow can be used to reduce vulnerability to payee fraud, especially in cases where a payee provides a signature associated with a reputational key that commits to the blinded nonces being paid to. From the code, this is "a standard way to facilitate a payment between users of a mint" that allows a payee to "receive e-cash directly from another user when online" by "creating notes provided (and most probably controlled) by the recipient". This process is similar to the process that I described above in my edit. It still has vulnerability to the payee failing late in the process, but that is a lesser risk than the otherwise possible general payee fraud.

3. There is also a concept of offline payments and SpendableNotes. Offline payments do leave a payer vulnerable to general payee fraud as originally described above. A spendable note is the information of a note plus the spend key and is transferred from payer to payee. Again, general payee fraud is not distinguishable from the payee's system being compromised. So, it is not enough to simply state that the payer can know that the payee committed fraud. The payer can not prove fraud by a particular party.