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.
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 valuesxK_ein a transaction are unique." However, by itself, unique values ofxK_ewithin 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:This is possible since Mallory sent only two plain enotes in that transaction, so they shared the same
xK_eand destination, and thus the sameDHE_1/2/3, and thus the sameK_o. As @tevador noted, there are two ways to prevent this burning bug: 1) Binds^sr_1to 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_ewithin a transaction is not enough to ensure uniqueness ofK_owithin said transaction, and therefore is not enough by itself to mitigate the burning bug.