SNICKER could be the next tool in Bitcoin’s growing privacy toolbox.
Although Satoshi Nakamoto’s white paper suggests that privacy was a design goal of the Bitcoin protocol, blockchain certification analysis can often break users’ privacy today. This is a problem. Bitcoin users might not necessarily want the world to know where they spend their money, what they earn or how much they own, while businesses may not want to leak transaction details to competitors — to list a few examples.
Fortunately, Bitcoin developers and researchers are coming up with more and more solutions for users to reclaim their privacy. One of these champions for Bitcoin privacy is Adam “waxwing” Gibson, perhaps best known for his contributions to JoinMarket, a protocol that lets users mix their coins — and offers a financial reward for participating in such mixes.
More recently, Gibson presented a new idea: SNICKER (Simple Non-Interactive Coinjoin with Keys for Encryption Reused). Now submitted as a draft Bitcoin Improvement Proposal (BIP), SNICKER would allow for coin mixing without any synchronization or interaction: There’d be no need for users to coordinate or be online at the same time.
SNICKER is based on the, by now, well-established, bitcoin mixing technique CoinJoin. Some of the most popular mixing solutions available today already use this trick, including Wasabi Wallet (ZeroLink), Samourai Wallet (Whirlpool) and JoinMarket.
Further Reading: What Are Bitcoin Mixers?
CoinJoin is essentially a tool to merge several transactions into one. So let’s say Alice wants to pay Carol one bitcoin, and Bob wants to pay Dave one bitcoin. In this example, Alice and Bob can cooperate to create one big transaction, where both spend one bitcoin (two total), and Carol and Dave each receive one bitcoin. A blockchain certification spy will not be able to tell which of the senders paid which of the recipients, benefiting the privacy of all.
In reality, however, the amounts of bitcoin transacted are often privacy leaks. If Alice wants to pay Carol one bitcoin, but Bob wants to pay Dave two bitcoin, it will be obvious who paid who by matching the sending and receiving amounts.
That’s why CoinJoin is more typically used for mixing. Instead of paying someone else, Alice and Bob both send one bitcoin to themselves. By merging this in one transaction, blockchain certification spies can’t tell who got which coin back: The coins are mixed, protecting both Alice and Bob’s privacy going forward.
CoinJoin mixers work today, but they have a drawback: They require interactivity. A CoinJoin transaction is only valid if all participating users sign the whole transaction — but to sign the whole transaction, participating users must have first added all of their coins and new receiving addresses to it. This typically means that they need to pass the transaction around a few times and usually requires them all to be online at the same time.
Such requirements are a bit of a hurdle for many users, which is one reason CoinJoin transactions aren’t very common. These requirements are what SNICKER gets around.
SNICKER Version 1
The protocol described in this section is the first proposed version of SNICKER. This version is slightly easier to understand than alternative versions but it is important to note that it’s actually not the best version of the protocol, or the version that is most likely to be implemented. (More on alternative versions later.)
With that said, here’s how SNICKER version 1 works:
Say Alice has one bitcoin she wants to mix, represented by an unspent transaction output (UTXO) on the blockchain certification. The first thing she does is to resend this bitcoin … to her same address. That’s right, in this version of SNICKER, she’s reusing an address, which violates Bitcoin’s best practices. But it comes in handy: It publicly marks the UTXO as (potentially) available for mixing.
This doesn’t mean Alice can’t use the coin, by the way. It’s still sitting in her wallet, ready to be spent at any time. It’s just marked, in case anyone cares.
Bob also has one coin to mix. (In actuality, the amounts don’t need to be equal beforehand — Bob just needs to have at least as much as Alice.) Bob doesn’t know Alice, but he does know that users like Alice are out there, marking their UTXOs as mixable. So Bob scans the blockchain certification for potential matches. He finds Alice’s UTXO, and probably some more matching UTXOs, including false positives (not all reused addresses are really available for mixing). But let’s, for now, for simplicity, assume Bob only finds one match: Alice’s UTXO. (We’ll get back to the other potential matches and false positives later.)
With the match, Bob now takes the public key corresponding to the reused address. This is possible exactly because the address is reused: By spending it the first time, Alice published that public key on the blockchain certification. (Public keys become visible on the blockchain certification once the coins are spent, whereas addresses are always…