TumbleBit vs CoinJoin


Jul 22, 2017 · 11 min read

I have been working on TumbleBit for quite a long time now. While CoinJoin is an old, well-understood, production tested technique with multiple implementations such as JoinMarket, ShufflePuff, DarkWallet, and SharedCoin, modifications and/or improvements like CoinShuffle, CoinShuffle++, none of that can be said about TumbleBit. It is a new technique, with a single protocol implementation, NTumbleBit, and its precursor proof of concept implementation, BUSEC/TumbleBit. In fact, so far my work concentrated around grasping the basic concepts and explaining them to wider audience, Understanding TumbleBit 1, 2, 3, 4, 5, building TumbleBit enabling technologies such as HBitcoin, DotNetTor, HiddenWallet, BreezeWallet, and procrastinating on smaller issues. I was not quite sure about the practical limitations of the concept. Now that I am in the middle of integrating TumbleBit into HiddenWallet, this has just changed and I am now able to properly write this long article about Bitcoins’ two biggest and/or most hyped hopes of achieving privacy on-chain: TumbleBit and CoinJoin.

On-chain Privacy

I will talk about Confidential Transactions and Schnorr Signatures, because they are complementary technologies to both TumbleBit and CoinJoin, and I will tell you which one benefits more from them and how.

The Basics

Bitcoin transaction

This is how a simple Bitcoin transaction looks like. You send some coins from one address to another address, and you get back the change to the same address. Of course, this model provides terrible Bitcoin privacy, therefore change addresses were introduced.

Change addresses

The concept is the same, however instead of getting the change to the same address, your wallet software internally generates a third address where you receive the change. This highlighted another problem, with how you store so many addresses in a wallet. Hierarchical Deterministic wallets solved this issue, however this is outside the scope of this article.

What happens if your wallet does not have enough money on one address? If it has enough on another one, it will join together more addresses to add up the transaction input:

Actually, my explanation is not entirely correct. The inputs are not address-balance pairs, rather address-amount pairs, or more correctly signature-amount-index trios, however let us not concern ourselves with such details.

Almost all of Bitcoin wallets today uses this model. Of course, it still has many privacy problems.
Would not it be great if people could just join together their inputs with other people and make one big transaction?


It is a great concept, because it further hardens the job of blockchain analysis companies, however, simple amount analysis, CoinJoin Sudoku, can tell a lot about who sent money where.

It was a terrible service, because somehow the general public was under the impression “SharedCoin is good enough” and we did not even talk about the fact that Blockchain.info itself was able to simply reestablish the links. Blockchain analysis was not the whole story here.

Since then the company stopped providing this service, I suppose for legal reasons. However I can guarantee you, when Schnorr signatures are introduced they will start providing this service again, because that will dramatically lower the fees of these kind of transactions. In fact, every wallet with decent liquidity will start doing this in order to offer cheap transactions, although I am getting ahead of myself.



Here comes the idea of JoinMarket (JM) in. In the transaction I inserted there are three outputs with 2.32386728 BTC. Even if you can figure out which inputs corresponds to which change outputs you cannot figure out the destination. Note, your anonymity set in this case is three.
So how did JM solve the liquidity issue of CoinJoin? It introduced the maker-taker concept, where market makers are waiting until a taker wants to execute a CJ transaction and asks market-makers to provide liquidity for his CJ for a small fee. Now you must realize if a normal Bitcoin transaction is $1, then if you want to send money through JM with three makers, then you must pay $3 transaction fees. What if you want 100 as your anonymity set? Then you must pay $100.

CoinShuffle, CoinShuffle++, ShufflePuff

TumbleBit: Classic Tumbler mode

The workflow is:
1. Open a payment channel to the Tumbler with your Alice identity and Bob identity.
2. Crypto magic.
3. Close the two payment channels.

For now, note that those are two payment channels: four transactions.
What happens under the crypto magic stuff is that many other users, who additionally opened channels tells the Tumbler to tunnel through money to their desired output, however in a way the Tumbler cannot tell who sends money to whom. Seems impossible, huh? You either trust me with this or read more about it.

We are not that concerned about how it works, since the purpose of this article is a comparison and not an introduction. Let us take a look at its parameters:
How fast is it?
Two channel opening transactions, two channel closing transactions, those are two blocks: twenty minutes. Great!
What are the costs?
Four transactions. They are bigger than normal ones, then maybe at $1 bitcoin fees you would pay $10. Plus, Tumbler fees. Let us say 1%. That is a little problematic, however considering huge the anonymity set, it is probably feasible.
What is the achievable anonymity set?
The sky is the limit. Well, the white paper’s proof of concept implementation achieved 800 anonymity sets, therefore let us go with that.

This was the theory, let us see the practice.

  • Unfortunately, there is a great and terrible property of payment hubs. It must hold a lot of bitcoins in order to cover the mixes. It is great because this pushes the Bitcoin price to the roof, and it is bad because it is exposed to the possibilities of different attacks.
  • Sadly, TumbleBit needs fixed denominations just like CoinJoin, consequently the same set of problems applies here.
  • Regrettably, some timing attacks are possible by the Tumbler in order to deanonymize the users.

Fortunately, all these problems are solved in TumbleBit, therefore you do not need to worry about them. Unfortunately, all these solutions made a tumbling cycle longer, which ended up at the very best around two hours, often times even half a day. Recently a one day long standard cycle was proposed, just to be sure.

Of course, I was aware of these extremely long mixing times, however all this just did not make sense for me and I was hoping that when I get there I can come up with something and make it as fast as possible. Now I am there and I cannot make it fast, no matter what I do, it just ruins something else. I am still not convinced if optimization cannot make it considerably faster, although now I know it is not as easy as I initially thought.
This made me question what is the anonymity set we are hoping to achieve if the cycles takes so long?

I do not have an answer, however I would guess ten to fifty. Initial liquidity has to be gained in the first place, the later we launch the higher the Bitcoin fees will be, which as I detailed above, a ten times multiplier applies to TumbleBit transactions. The worst thing is that you do not even send the amount you want to send. Wait, I did not mention what our is solution for that.

For comparison see my brief explanation of what JoinMarket’s solution was for that, the maker-taker concept. Of course, we cannot use the same, because that multiplies the fees by your anonymity set, and in TumbleBit the fees are high in the first place.

We figured you can mix to yourself. If you want to send 8.3 BTC and the Tumbler denomination is 1 BTC, then you must do 8 rounds of TumbleBit cycles and you will not be able to mix out the remaining 0.3 BTC.
These 8 rounds although multiply the fees, $80, considering $1 bitcoin fees. Luckily you do not need to wait for the completion of every round, because the rounds can overlap.

Authors’ note: I did not and I do not think anyone else ever thought through TumbleBit’s Classic Tumbler’s economics as I did now, in a high Bitcoin fee environment where we are inevitably going towards. In fact, $1 Bitcoin fee, which I was assuming all along is today’s reality and can be hardly considered to be high fee environment.
To be completely honest, after I wrote all these down I became pretty disillusioned.

CoinJoin vs TumbleBit

While I am using rough estimates, I think I got it right.

Conclusion? If CoinJoin as envisioned existed it would be the winner. However, it does not exist and therefore it is better to use TumbleBit for high anonymity transactions, and JoinMarket for the low ones.

Now let us try to figure out the future, shall we?

Confidential Transactions

As you can see CT both in TB and CJ would lower the cost of mixing out bigger amounts and it would increase the costs of mixing out smaller ones.

Schnorr Signatures

The red ones are the input, the green ones are the output and Trump signs the inputs. Schnorr enables us to use only one signature for every transaction. This cannot be significantly utilized in TumbleBit however, it can be in JoinMarket and CoinJoin as envisioned.
How much do they gain? I will go with a rough estimation here, using this Bitcoin Stackexchange answer as my data source:

71 bytes signatures on average
Size of P2SH/P2PKH Transaction = in * 146 + out * 33 + 10

The most frequent transaction we are concerned about has one input and two outputs, which are about 233 bytes. The signature data is about 30% of the transaction. Assuming Schnorr signatures are about the same size (they are not) Schnorr saves at least 30% of every CJ transaction fees. However, there is one signature that needs to be added to the transaction, so a two participant CJ costs at least 15% less, a three participant CJ costs at least 22% and as the numbers grow higher they reach close 30%.


The questions of the future are:
Will TumbleBit in production find the liquidity it needs to achieve huge anonymity sets? Can CoinJoin solve its coordination issues and achieve huge anonymity sets?


Written by