On Twitter I recently shared an announcement blog post about Umbra, a new stealth address implementation written in Solidity for Ethereum-compatible blockchains (currently running on the Ropsten test network).
NuCypher cryptography engineer and generally rad person @__tux replied:
If the Payee withdraws from “stealth addresses” (these aren’t stealth addresses) to a mixer, it’s relatively trivial to learn the Payee’s “stealth addresses”.
The Payer should, instead, deposit into a mixer where they Payee is only capable of withdrawing. Umbra doesn’t do this.
This wouldn’t fix everything though. There’s a lot of ways to deanonymize payments between these steps, like when withdrawing from a mixer.
I started writing out an answer on Twitter and realized it got way too long, so I decided to move my reply over to a blog post.
To the comment “these aren’t stealth addresses”, I do think Umbra enables stealth addresses.
Some background info
Stealth addresses are a category of cryptocurrency technology that enables Payees to publish a static, re-usable address that Payers can then use to generate unique, one-time addresses. This can make it harder/ nearly impossible for observers who only know the static “stealth address” to know when the Payee has received payments, who is paying them, and what the amounts of the payments are. I will let the Umbra blog post explain technically how it implements this functionality.
The post-withdrawal problem I highlight in my thread arises from the fact that once the Payee has received a bunch of payments to their one-time addresses, they have to do something with those funds. Most likely, the Payee will want to consolidate those funds somehow, so they can make larger payments with them.
This consolidation is where linkages between the one-time addresses occurs and it becomes possible for, at a minimum, previous Payers to learn the amounts and sources of other possible payments to the stealth address. (I say “possible” because they do not know 100% those payments were sent via Umbra, they just know that the funds are controlled by a common party; this is also known as the “mystery shopper payments” vulnerability).
A mixer like Tornado can help here by allowing the Payee to consolidate funds a little at a time in different addresses, deposit the funds into a mixer, and later withdraw to a common address that is de-linked from the pre-mix addresses. Instead of 100% of the funds being linked together in a common consolidation address (as would occur if no mixer is used) only some of the funds are linked pre-mix. After funds are withdrawn from the mixer, there’s no way to conclusively link the pre-mix addresses to the post-mix address.
Imagine Alice has received four Umbra payments of 0.051 ETH at one-time addresses A1, A2, A3, and A4. She consolidates A1 + A2 into address C1, and A3 + A4 into C2. The addresses that were consolidated together are now linked, but C1 and C2 are still unlinked.
The reason for consolidating pre-mix is because Tornado only supports specific denominations of ETH in each pool, so she needs to combine enough ETH to meet the denomination threshold she wants to mix into (0.1 ETH being the smallest ETH Tornado pool currently). If the Umbra payments are by themselves large enough to go into a Tornado pool, then no consolidation is needed pre-mix and even more privacy is possible.
Alice deposits the funds from C1 into Tornado, waits some time, then also deposits the funds from C2 into Tornado. C1 and C2 are still not linked together.
After a couple of weeks, she withdraws her Tornado funds to withdrawal address W1, which has no links to either her Umbra address or to her one-time addresses. Tornado has successfully helped her privately consolidate 0.2 ETH from C1 and C2 into a single new address.
Of course, as tux points out, there are ways that Alice can de-anonymize herself post-mix. Maybe she sends some funds from one of her pre-mix addresses to W1. Or maybe she sends some other funds from W1 to an address publicly linked to her. Post-mix behavior is as important for maintaining privacy as pre-mix behavior. This is the main reason why privacy on transparent blockchains is so fragile, and why I advocate for fully shielded, end-to-end encrypted transactions as the ideal standard for on-chain payment privacy.
Email is probably the most popular decentralized messaging protocol, and I expect it to be around for a while. Add yourself to my email contacts if you would like to stay in touch!