Heard of TumbleBit but never really understood what it was?
This part 3 of the series will explain the way TumbleBit solves the problem of trust. In part 1 of the series I explained what traditional Tumblers are, their shortcomings, and why you need to watch the Stratis Breeze Wallet (beta is released) to keep up with the developments of privacy within Bitcoin. In part 2 I discussed how TumbleBit tackles the privacy problem- one of the two main problems for traditional Tumblers posed in part 1.
Problem of Trust
What still remains is how Tumblebit can be prevented from stealing if malicious? This second main problem - the issue of trust - is what will be discussed in this part. First we have to have more info on TumbleBit as a payment hub. Still, only the basic idea of how a trustless payment hub works is explained. The complexity of TumbleBit is way beyond this, it however helps to understand how TumbleBit works.
The Payment Hub
To be able to explain how TumbleBit solves the trust issue, we first have to look at how a unidirectional payment hub works. It sounds more complex than it is, so just bear (or bull) with me. As an example we think about Alice wanting to send 1btc to Bob via the Hub.
As you can see, the set transactions are escrow transactions. That way the transactions must be signed by both Alice (or Bob) and the Hub.
If the Payment Hub doesn’t sign, the 1btc is refunded to Alice after 1 month. Giving us this picture:
So Alice wants to pay Bob 1btc with this setup. Alice creates a transaction claim, as does the Payment Hub (transaction Claim2).
To authorize the transaction, Alice signs Claim 1 and the Payment Hub similarly signs Claim 2.
When the Payment Hub signs Claim 1 – like illustrated below - and Bob signs Claim 2….
… a full transaction from Alice to Bob via the Payment Hub can be illustrated:
So what’s the problem?
Well.. what if the Payment Hub is malicious? How can we trust the Payment Hub not to take Alice’s bitcoin by not signing the claim transaction from Bob? Obviously there is a problem when Alice signs Claim1 before the Hub signs Claim2.
If the Hub signs Claim2 before Alice signs Claim1 the same problem is presented. Bob can claim his 1btc from the Hub while Alice refuses to sign Claim 1 - resulting in a refund of her 1btc.
Solution
One way to prevent theft from the Payment Hub is to make Claim1 and Claim2 happen atomically. That way they either both happen or don’t happen at all.
It is possible to do this with Hash locks.
Due to this hash lock, we can agree on the Payment Hub having to share ‘X’ with Alice in order to claim the 1btc. Bob also needs the same value ‘X’ in order to get his 1btc from the Hub. At the moment Alice receives X from the Hub, she shares it with Bob in order for him to conclude the transaction (and get his 1btc).
The result is a trustless system in which no one has to be afraid of malicious players.
A new occuring problem however is that when you have a bunch of people using this, the payment hub can link the hash locks that are used.
Solving the problem of trust therefore does not solve the problem of privacy. The main idea behind TumbleBit is a protocol which provides atomicity but is also unlinkable. Luckily we already discussed how to solve that problem in Making Bitcoin truly anonymous – Part 2.
In the next and final part (4) TumbleBit will be compared to privacy-centric coins such as Monero and Zcash. Why do we need TumbleBit when we have privacy-centric coins?
Something not clear in this part? Check out this presentation by Ethan Heilman and Leen AlShenibr
For more information on TumbleBit go to:
TumbleBit scientific paper
For more information on the Breeze Wallet from Stratis go to:
Stratis Website
Stratis Blog
Stratis Reddit
Thank you for reading