I will show you how the Tumbler forwards your bitcoins without the ability of exit scamming on you.
“Meh, this is already boring, I stop reading there.” — Do not make that immature decision just yet. What if I tell you, by the end of this article you will have all the knowledge to build a trustless ShapeShift?
In Part 1: Making The Case, I described why TumbleBit is important, in Part 2: The Endgame I described how far this idea can take us and in Part 3: Not Even The Tumbler Can Breach Your Privacy I finally described how the first key attribute of TumbleBit can be achieved: anonymity. In this article I define the missing piece, the second key attribute of it: trustlessness. What I express here is not only the basic concept what TumbleBit is built on but the basic concept of payment channels, payment hubs and lightning network. If you are interested in any of those, stick around!
State of Development
I cannot avoid first addressing the question you guys are most interested about. When can I use it?While the TumbleBit core protocol is pretty much ready and you can use it in an extremely impractical way through a CLI interface and Bitcoin Core, TumbleBit needs liquidity and this will not achieve it.On the other hand integrating TumbleBit into an existing Bitcoin wallet is a no-go as well. The problem is that if the wallets that your peers are using in the mix are screwed up from a privacy point of view, even if you are using TumbleBit in the correct way, with a fullnode, your anonymity is screwed up because of your peers. The solution is to build a Bitcoin wallet that does not ruin full node level privacy and not as cumbersome as a full node. This is where HiddenWallet and BreezeWallet comes in. We are both working on a dedicated TumbleBit wallet independently.Without going into much details I just drop a part of the road map of my HiddenWallet here:
- Full Block Downloading SPV — Ready, unstable
- TumbleBit integration, Classic Tumbler Mode — I am currently working on it.
- Transaction Filtered Block Downloading — 10–100x performance increase.
- Release stable version.
The Cool Crypto Stuff
Note: I only describe here the basic idea of how trustless coin exchange works and of course not the full TumbleBit protocol.
More specifically I am describing how a unidirectional payment hub works.
The above illustration shows how a unidirection payment hub works. If you already understand it then sorry, I just wasted two minutes of your life by making you read the introduction and asking you to stop reading here. If not, stick around and you will see the magic.
First imagine Alice wants to send Bob 1 BTC. How does she do that? Well she sends 1 BTC to Bob. I hope you can follow.
Next introduce the Hub.
Now Alice wants to send 1 BTC to Bob through the Hub. I know that is pretty pointless, however it will make sense. How does she do that? First Alice sends 1 BTC to the Hub, then the Hub sends 1 BTC to Bob. So far so good, we just introduced a second pointless transaction, so we can pay twice as much network fee and we can wait twice as much time as we would usually do. However, it gets even worse. What if the Hub decides to steal Alice’s money and it does not forward the coins to Bob. Let us try to solve that issue, shall we?
Let us say Alice and the Tumbler are sending some special transactions instead of regular transactions, which will not solve the issue for now, although it will bring us closer to the solution.
As you can see the transactions we introduced are escrow transactions.
What does this really mean? Let us examine Alice’s transaction to the Hub. The transaction says: “Hey, I am a transaction and I can talk. I am coming from Alice’s wallet and going to Hub’s wallet, however, I am not quite there yet, just somewhere in between. The thing is, Hub cannot spend me alone. It can only spend me with Alice together. If the transaction that is attempting to spend me is not signed by both Alice and the Hub that transaction will be rejected by the Bitcoin network. However, there is more. If I will not be spent within one month I will let Alice spend me without Hub’s signature.“
Similarly the transaction from the Hub to Bob:
I decided not to write it down what this transaction exactly said, because it was apparently Chinese, and I am too lazy to translate it. You must figure out from the box above.
What do we have now?
We just made four transactions in order to transfer 1 BTC from Alice to Bob through the Hub. That is four times a normal transaction fee. In fact, it is even more, because the escrow transactions are bigger than the normal transactions, not in money but in actual size, in bytes, which is what actually matters when you pay the transaction fee in Bitcoin. What did we solve? Nothing, the Hub can still steal our coins. Wait, why four transactions? Think about it, the escrow transaction is not a transaction from Alice to Hub. It is a special transaction somewhere in the middle. Therefore there must be another transaction that spends that transaction to the Hub’s wallet. We will call this a claim transaction.
Do you remember what the Escrow1 transaction said? Did it not feel a little strange? It did not talk much about itself, rather it was talking about the transaction that wants to spend it, the claim transaction.Now, I have a question. Do you know how do we call it when Alice signs the Claim1 transaction, however the Hub not yet?
It is called opening a payment channel. Then the Hub can steal your coins, can it not? Yes, it can, however, that is the last problem we will solve. For now, let us close the payment channel:
Exactly the same things happen in the payment channel between Hub and Bob.
Pretty neat, huh? You just mastered a super complicated illustration.Now let us get back to the problem we just discovered.
The Hub will be able to steal Alice’s money if Alice signs the Claim1 transaction before the Hub signs Claim2 transaction to Bob. If Hub signs Claim2 transaction first, then Alice can just refuse to sign Claim1, wait until Escrow1 expires and she can refund it back to herself and Bob can take Claim2 transaction. I think the proper cryptographic terminology of this situation is Catch-22.Is there something we can do to escape this situation?If only we could just say that Alice signing Claim1 and Hub signing Claim2 must happen at the same time then all our problems would be solved.
Fortunately, there are a couple of ways to do this. For example, with hash locks:
Only Hub knows X.
If we say Claim2 cannot happen without X, then Hub can sign Claim2 without being worried that it will be defrauded by Bob:
If Bob wants the claim transaction to happen it must learn X.
How does Alice learn X? Claim1 transaction must include the hash lock that uses the same X.
Notice that Alice signed Claim1 as well, and when she signed Claim1 the Hub was able to steal her money without paying Bob. This time it should be the same, since only the Hub knows X, right? Hub can just spend Claim1 transaction by signing it and providing the X. In that very moment when the Hub provided X, Alice learnt X and told Bob, who is now able to spend Claim2 transaction. Yes, this is the time for your first “aha moment”, because you just mastered atomicity.
Time for your second “aha moment” because you just realized that now you fully understand this super complicated illustration I bothered you with in the beginning of my explanation.
What did we achieve? We figured out how we can send money from one place to another through a third party, using payment channels. That is stupid, why would anyone want to do this complicated shame, when you can just directly send bitcoins? Well, what if Bob would rather receive Litecoin, instead of Bitcoins, what would change? Absolutely nothing. It does not matter if Escrow2 and Claim2 happens on Litecoin or Bitcoin. Now that is how a decentralized crypto exchange could work.
Still do not get it? Do not worry, watch the first four minutes in this video where Ethan Heilman, the creator of TumbleBit explains this concept for you:
I happened to write one more part of this series, check it out: Understanding TumbleBit Part 5: Try It Out!