search

UkoeHB / Seraphis

Privacy-focused tx protocol
52 stars 2 forks source link

Impl clarification: burning bug not prevented by `xK_e` uniqueness when using shared `xK_e` #5

Open jeffro256 opened 1 year ago

jeffro256 commented 1 year ago

In section 8.2.2 of Implementing Seraphis, "Secret uniqueness: input_context", the paper states "To further ensure uniqueness within a transaction, transaction verifiers must mandate that all values xK_e in a transaction are unique." However, by itself, unique values of xK_e within a transaction don't guarantee uniqueness of the other components when a sender doesn't follow the Jamtis rule of having at least one self-send type enote, where each self-send enote type within a transaction is unique. Consider the following situation, which was brought up by @tevador on the jamtis gist:

Mallory registers at an exchange and is provided with a deposit address. She crafts a 2-output transaction without change, sending both outputs to the deposit address, each output worth 1000 XMR. In order to do this, she needs to provide inputs with a total sum of exactly 2000 XMR + fee, but that should not be hard to do.

Unless the exchange has a wallet that is aware of the burning bug, Mallory will be credited with 2000 XMR and can proceed to withdraw the funds back to her custody. However, the exchange will later realize that only one of the 1000 XMR outputs can be spent. This scam can be repeated until the wallet of the exchange is completely drained. It only costs some tx fees.

This is possible since Mallory sent only two plain enotes in that transaction, so they shared the same xK_e and destination, and thus the same DHE_1/2/3, and thus the same K_o. As @tevador noted, there are two ways to prevent this burning bug: 1) Bind s^sr_1 to the tx output index, or 2) (what is already done by the Seraphis consensus rules) have transaction validators check uniqueness of the enote components manually.

Either way, this passage of the specification should be clarified to note that uniqueness of xK_e within a transaction is not enough to ensure uniqueness of K_o within said transaction, and therefore is not enough by itself to mitigate the burning bug.

UkoeHB commented 1 year ago

This is possible since Mallory sent only two plain enotes in that transaction, so they shared the same xK_e and destination, and thus the same DHE_1/2/3, and thus the same K_o

A transaction is invalid if it has duplicate K_o, so this is a non-issue.

jeffro256 commented 1 year ago

That's exactly my point, that's what actually prevents the burning bug: validators checking if the enote components (mainly K_o) are unique. So it should say that in the spec.

UkoeHB commented 1 year ago

I believe this may be a typo on my part.

jeffro256 commented 1 year ago

I just don't want people to interpret this passage to mean that ensuring that xK_e is unique will thereby guarantee that enote components are unique / prevent the burning bug.

UkoeHB commented 1 year ago

Actually the burning bug is prevented by completely ignoring duplicates. See section 8.3.2.

Using input contexts and requiring uniqueness of K_e just reduce the vectors for burning funds, they don't eliminate burning.

UkoeHB commented 1 year ago

However, I will update the document in the next version to clarify section 8.2.2.