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.
-
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.
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.
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.