0

https://github.com/monero-project/monero/issues/1673#issuecomment-312968452

Were there solutions to this Monero EABE attack since this was posted in 2017 and it is now 2020?

The EABE attack defined It's been pointed out to me that many people only following this discussion on GitHub and not on IRC are so far unaware of the "EABE attack". I'll explain it here for those new to the concept.

To avoid exchange rate risk, it's common for Alice (A) to withdraw XMR from an exchange (E), and then use that XMR to make a purchase from Bob (B). At some point in the future, Bob will cash out at the exchange (E).

Hence, "E->A->B->E".

This pattern of purchasing cryptocurrency from an exchange immediately prior to making a purchase from a vendor, in order to avoid exchange rate risk, was described by a merchant on Reddit as the almost universal practice of his customers.

If E->A->B happens only once, then the exchange cannot tell Alice has been sending money to Bob.

But if E->A->B happens multiple times, then when Bob cashes out with the exchange, the exchange can look at the set of outputs referenced in the ring signature of the transaction B->E. For each of those outputs referenced, the exchange can go backwards by several more transactions, to determine the set of outputs that each of those outputs must have originated from. The set of possible originating outputs grows dramatically as we travel backwards.

If the exchange only has to go backwards by one or two transactions in order to discover multiple outputs it knows it had sent to Alice, then this is extremely strong evidence that Alice was sending money to Bob.

For Alice to have been implicated incorrectly by chance, the person that sent money to Bob would have had to have chosen one of Alice's outputs as a decoy not only once, but on several occasions. Given that there are over 21 million outputs to have chosen from, the chances of choosing decoy outputs owned by Alice (or multiple outputs owned by any other Monero user) on multiple occasions is vanishingly small.

This means that a KYC exchange will know of large numbers of interactions between customers that the customers had incorrectly assumed would be private.

This is a serious problem for a cryptocurrency that prides itself on delivering private transactions.

The solution is for Alice to put distance between the outputs she receives from the exchange and the outputs she sends to Bob. She does this by churning, i.e. sending outputs to herself before then sending to Bob. Each time she churns, the size of the anonymity set will increase because the exchange will have to go back backwards many more transactions to eventually see the outputs that the exchange knows were previously given to Alice by the exchange.

The goal is for Alice to increase her anonymity set such that it is large enough that it will include not just multiple outputs owned by her, but multiple outputs owned by other Monero users or customers of the exchange. This gives Alice back her plausible deniability, because many other people could have, by chance, had more than one of their owned outputs caught up in the anonymity set.

Churning can deliver enormous anonymity sets, because each churn will multiply the anonymity set by the ring size of the transaction used to churn (as long as most other people's outputs referenced as decoys in her churn transaction had themselves used the same or larger ring size as Alice).

Increasing the mandatory ring size therefore requires drastically fewer churn operations by Alice in order to generate the anonymity set required to hide her activity with Bob from an exchange.

The ability of Alice to increase her anonymity set when sending funds to Bob can be implemented as a "high privacy" transaction option that automatically takes care of queuing up the intermediate churn transactions prior to funds ultimately being sent to Bob.

To avoid having to wait for churns to happen when sending to Bob, Alice may choose to ask her wallet to churn incoming funds in advance, so when it's time for her to make a purchase with Bob the anonymity set of the funds she intends to spend with Bob has already been enlarged. Without the need for local storage, a wallet can automatically determine whether funds have been pre-churned or not, to avoid Alice wasting time and money by churning inputs that have already been churned.

2

...since this was posted in 2017

Well, apart from a host of other changes since 2017, specific changes that have helped mitigate the risks of an EABE attack are ring size increases and selection algorithm changes. Some of these things were even discussed and agreed upon in the link you reference.

And whilst the attack is a weakness, it is somewhat overblown; very specific spending patterns need observing. There has been much discussion and research already.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.