TokenShuffle - A protocol for anonymizing BCH transactions

tokenshuffle.md

TokenShuffle

TokenShuffle is a protocol for anonymizing Bitcoin Cash (BCH) and improving its fungability.

The purpose of this Gist is to solicit feedback on possible shortcomings or improvements to the protocol described here. This Gist will also be updated based on this feedback. Once these ideas receive sufficient community review, an open source project will be created to transparently develop the ideas laid out here.

This protocol is loosely based on the ideas in CoinJoin and CoinShuffle, and is intended to be implemented as a light-weight web app that people can anonymously interact with. It leverages new token protocols built on top of Bitcoin Cash like Wormhole, though other token protocols could be used.

The User

• Sends BCH to the public input address of the app and receives a 1:1 token match.
• To redeem tokens, they visit a single page web app (SPA) in their web browser, where they are presented with a unique public address and a form. In the form, they enter the output address redeemed BCH should be sent to, and also specify a random time to send BCH after the tokens have been received by the app.
  • On the user interface (UI), the user can click a button to randomize a time between 0 and 60 minutes, or manually specify the time up to 24 hours.

The Public Input Address

• All token exchanges use the same public input address.
• The wallet periodically combines all UTXOs into a single UTXO.
• It sends BCH for redeemed tokens to the specified output address

The Web Form (and API)

• Allows user to specify an output address.
• Allows users to specify a time delay before sending BCH to the output address.
• Provides a unique public address for 30 days for users to send tokens to.
• Token redemption must be sent with enough BCH to cover a second transaction (300 satoshis), which the app uses to send the tokens to a burn address.

Security Implications

• Because the public input address periodically combines all UTXOs, the information associated with every transaction is unseperably mixed with all the others.

• While the output BCH amount could be correlated to token transactions, users are encouraged to send in standardized amounts of tokens, like quantities of 1, 0.1, 0.01, or 0.001 tokens at a time. This breaks the ability to correlate inputs to outputs. Bootstrap Bots will be described later to help bootstrap sufficient volume of standardized quantities of tokens.

• Because the output address is arranged privately between the user and app, the address is single use, and the tokens are burned, there is no direct connection between the token redeemer and the output address. The app will be programmed to delete any knowledge of the transaction after 30 days.

• Output BCH is randomized in time, which is also important to obscuring the connection between inputs and outputs.

Bootstrap Bots

An extension to this idea uses an automated web app to bootstrap sufficient transaction volume to make this app pragmatic for the occasional early adopter to use. The Bootstrap Bot is a totally separate application, and typically many instances of it would be ran in parallel.

Distributed, independent users would be encouraged to fire up their own Bootstrap Bot to support the community of users of the TokenShuffle app.

Fixed quantities of tokens would be redeemed and sent to N addresses. For this example, we'll use 0.01 BCH as the standardized amount. An HD wallet (Wallet 1) is created with N addresses.

• The N addresses from Wallet 1 are submitted to the TokenShuffle app, with a randomized time set for each address to receive their BCH. The tokens come from a common address, and the amount of BCH received by each address in Wallet 1 is 0.01 BCH.

• After the last address has received its BCH, an N multi-signature transaction is created by Wallet 1, sending randomized amounts of BCH to N matching addresses in Wallet 2. The total amount of BCH from Wallet 1 is sent to Wallet 2, but the individual amounts sent to each address in Wallet 2 are randomized.

• After one confirmation, Wallet 2 begins sending the amounts of BCH in each address back to the public input address of the TokenShuffle app. The entire balance of each address is sent sequentially, but randomly in time.

• Tokens are pooled to a common address, and the process begins again, using new wallets. (There may be future improvements to pooling tokens.)

The effect of the above protocol ensures there is sufficient volume of standardized amounts of BCH traveling through the TokenShuffle app to mask the transactions of early users. The Bootstrap Bots would not be needed once natural volume increases to an adequate level.

Instances of this Bootstrap Bot improve security by creating shuffled transactions with random amounts, randomized in time. It also introduces circular paths to further confuse malicious deanonymizing software.

Some early feedback I've gotten:

• It's centralized and trusted.
• It's just another mixer

The above statements are true. I'd love it if they weren't, and if anyone has suggestions on how to reduce the trust/centralization, I'd love to hear them.

The 'theme' behind this idea is simplicity. I believe the diagram and explanation are conceptually much easier to understand than other obfuscation algorithms that I've read. Everything described here can be implemented very quickly in JavaScript with existing tools.

If there is a problem with the logic or privacy implications, I'd like to know about it as soon as possible. That's why I'm soliciting this idea to the community for feedback. After that, I plan to code up a reference implementation, Dockerize it, and publish it for anyone to use and replicate. I don't know if it's possible to get away from centralized trust, but it can be made transparent, easy to implement, and easy to replicate.

I'm also having a hard time comparing this protocol to the ones used by other mixers. I have yet to find an existing mixer that publishes their mixing algorithm. I would be wary of using one without this transparency, otherwise, how do you know it worked?

On the purpose and value of the token in this protocol:
By burning the token and arranging the output address privately between the user and app, it breaks any direct connection between input and output. The connection can still be inferred from correlation, but standardized amounts and randomized times break that correlation.

It's not clear what role do tokens play here. Also hard to tell anything about the token part without knowing the exact specifics of the token system that will be used and how it will work.

You say: "By burning the token and arranging the output address privately between the user and app, it breaks any direct connection between input and output. The connection can still be inferred from correlation, but standardized amounts and randomized times break that correlation."

but that's not true. You send BCH to a single address and your destination receives BCH from the same address. There is a simple, direct connection linking the money, tokens or no tokens.

From what I can tell, the main idea is to combine UTXO's into a single address. This is a weak protection compared to a mixer with multiple random addresses, because the attacker can see ALL in and out transactions conveniently in a single address. Standardized amounts limit usability and if you are willing to use them, you're better off using CoinShuffle. Time delays also hurt usability and provide very little protection, as tools can be developed to find correlations.

So it does look like simply another centralized mixer with weaker algorithm and no additional benefits, unless I am missing something.

Thanks for the feedback @NxtChg. By combining all the UTXOs, every users transaction is mixed with every other users transaction. At the output, there is no way know what input generated it.

The role of the token is to essentially be a 'sin eater'. Any uniquely identifiable taint associated with the inputs are passed onto the token, and those tokens are burned after being redeemed. For specifics on the token, check out the 'managed tokens' examples in the BITBOX Wormhole SDK.

After having spent more time thinking about this idea, I've reached a couple conclusions:

• It seems to me that it would be fairly easy for malicious deanonymizing software to isolate the Bootstrap Bots from actual users. The above protocol should work, but any attempt to bootstrap transaction volume needs to obfuscate people from bots, or bootstrap transaction volume some other way.

• An idea implied here is the concept that consolidating UTXOs is equivalent to CoinJoin when using a trusted, central wallet-app. I expand on this idea, here.