SKALEing 20% of ETHParis Submissions – SKALE – Medium

Ádám “nopara73” Ficsór, HiddenWallet developer and TumbleBit contributor, and “TDevD,” the pseudonymous Samourai wallet developer, are joining forces on a new privacy project: ZeroLink. ZeroLink is set to realize a trustless mixing scheme first proposed by Bitcoin Core contributor Gregory Maxwell years ago — but one that hasn’t been realized thus far.

According Ficsór, the ZeroLink framework, which utilizes a scheme known as “Chaumian CoinJoin,” is actually more straightforward than many of the alternatives that have been proposed.

“Back in 2013, there was this sort of obsession with decentralization. ‘Everything that can be decentralized will be decentralized’ was the slogan,” the developer recalls. “By now we realize that decentralization is actually not always that useful. As long as a mixer cannot steal funds or link transactions, that’s enough.”

CoinJoin

Each bitcoin transaction essentially sends bitcoins from one or several bitcoin addresses (really: “inputs”) to one or several bitcoin addresses (really: “outputs”). That’s how bitcoins “move” over the blockchain.

The problem, from a privacy perspective, is that the blockchain is completely public, which means that anyone can see which addresses are paying which addresses. If these addresses can be linked to real-world identities, it can reveal a lot about who transacted with whom, and perhaps for what.

CoinJoin, the well-known coin-mixing scheme first proposed by Maxwell in 2013, is a potential solution to this problem. A CoinJoin transaction is basically a combination of several transactions merged into one big transaction. In other words, it includes inputs from several different users, and the bitcoins move to outputs controlled by several different users. As such, it’s not clear which bitcoins moved where. All users effectively paid all users.

While that’s great, the next problem is that whomever or whatever combines the different transactions into one CoinJoin transaction can be a central point of failure from a privacy perspective. That person (or that server, or whatever it is) still knows which bitcoins moved where. So if that individual is either corrupt or corruptible, the problem isn’t really solved.

“For CoinJoin to live up to its promise, even the entity that creates the transaction must not learn which addresses are paying which addresses,” Ficsór noted.

ZeroLink

ZeroLink provides a privacy framework for wallets that can be used for different mixing schemes. And it defines its own mixing technique as well: an implementation of CoinJoin referred to as “Chaumian CoinJoin.”

With Chaumian CoinJoin, users both send and receive equal amounts of bitcoin from a CoinJoin transaction, so everyone receives each other’s coins. This obfuscates the trails for all of these coins.

In practice, ZeroLink users will require two types of wallets: a pre-mix wallet and a post-mix wallet. As the names suggest, the first type holds coins that are to be mixed, while the latter is where the mixed coins end up.

Users then connect their pre-mix wallets to the ZeroLink tumbler and provide an input (“from” address) and an output (“to” address), which they both control. But importantly, the outputs are disguised (“blinded”) using a mathematical trick. So while the tumbler knows where all bitcoins are sent from, it does not yet know where bitcoins are sent to.

At the heart of the trick, the tumbler then cryptographically signs all blinded outputs, using a type of cryptographic signature introduced by David Chaum: a “blind signature.” This allows data to be cryptographically signed even if it is disguised. And importantly, these signatures can be checked against the original, unblinded data as well to see if the blinded data and the unblinded data match.

Next, all users connect to the tumbler again, but this time through some type of anonymity network, like Tor. They will then provide the tumbler with the unblinded versions of the outputs. Using the cryptographic signatures it just created, the tumbler can check that all revealed outputs match all blinded outputs. If they do match, the tumbler knows that all the outputs it received are legitimate, and thus were provided by the same users that also provided the inputs to send funds.

The tumbler then adds the revealed outputs to the CoinJoin transaction. And it sends this transaction back to all users, for these users to sign with their bitcoin private keys. Doing so validates the transaction. (The users should of course double check that the amounts and their outputs check out, to be sure they receive as much as they send.)

Finally, the tumbler broadcasts the CoinJoin transaction to be included in a bitcoin block. As a result, all users end up with different bitcoins than they started with: all bitcoins were mixed, and the blockchain trails broken.

While all this is actually relatively straightforward compared to some alternative schemes, and to a large extent already suggested by Maxwell back in 2013, the process has never been realized. This is probably because it was long thought to be too vulnerable to attacks, Ficsór thinks.

“When Maxwell first published the proposal, bitcoin transaction fees were practically non-existent. Because of this, it would be relatively easy and cheap to launch denial of service attacks against a CoinJoin mixing system. An attacker can just keep providing valid inputs, but refuse to sign when he should. That invalidates the whole transaction, and wastes everyone’s time.”

Interestingly, this attack vector is now to some extent resolved simply because it would be too expensive to keep it going. In order to maintain the attack in a way that it’s not easily countered, an attacker must provide new inputs for each round, meaning he must be able to keep moving bitcoins to new addresses to do so. “Assuming $1 transaction fees, that could cost up to $1,000 a day,” Ficsór pointed out. “In this particular context, high fees are a blessing in disguise.”

Development

Ficsór is currently about to help wrap up the development of another highly anticipated privacy tool, TumbleBit, for Stratis’s Breeze Wallet. This is expected to take another three months.

After that, he plans to focus on realizing ZeroLink, while TDevD may even start working on the framework sooner. Concretely, three new codebases need to be developed: the pre-mix wallet, the tumbler and the post-mix wallet.

“The tumbler needs to be developed from scratch. But it should be relatively easy to add the pre-mix wallets to any existing open source wallet. The same is true for the post-mix wallet implementations, though for privacy reasons not all wallets are a good fit,” Ficsór said.

His own HiddenWallet as well as Samourai Wallet are “fully committed” to implementing and deploying ZeroLink into production, Ficsór said, while Breeze Wallet may be interested as well.

Optimistically, an initial implementation of ZeroLink could be live before the end of this year.

For more information on ZeroLink, see Ficsór’s blog post on the project (which also includes a donation address) or ZeroLink’s specification.