Understanding The TumbleBit WhitePaper: II. Bitcoin Scripts And Smart Contracts

I already wrote a series of blog posts, called: Understanding TumbleBit, where I explained the basic concepts of TumbleBit in layman’s terms.
This article series are different. What you are about to read, or not read is probably the most useless, uninteresting article you’ve ever read in your life. Its target audience is one, maybe two people in the whole world and I did not even write it to you, but to myself: in order to make sure I don’t skip any important details I forced myself to create some output and not only concentrate on the inputs.
I actually wrote this a while ago, now that I am revisiting the updated whitepaper, I decided to revise “my understanding on it”, too. And I thought I’d publish it this time, who knows maybe someone cares?
Ok, I stop overselling it.

Image for post
Image for post
Illustration: The TumbleBit WhitePaper

Random interesting remark

People on Reddit were saying calling TumbleBit “untrusted” leads to wrong associations, it’s better to call it: “trustless”, which if you noticed I did call it that way in all my previous articles. But lately I had a converstaion with Ethan and he enlightened me that “untrusted” is the correct cryptographic term. Altough I’m still struggling to verify it with my google searches.

Dismissing the big picture

Section one is the introduction, this is “not that hard” to understand so I skip it. In any case I insert the abstract here.

Image for post
Image for post

Bitcoin Scripts And Smart Contracts

Image for post
Image for post

Oh what a coincidence, I accidentally inserted a part where my name is cited. Jokes aside, nothing too difficult to understand so far, but I have some notes.

  • Cross chain atomic swaps (trustless coin exchange between altcoins) with TumbleBit will only be possible with alts those support a couple of things TumbleBit needs. (Ethan told Monero would need timelock, so it’d be difficult (impossible?) to do it, but zcash would probably work.)
  • Why the “non-Turing-complete” attribute had to be even mentioned here? So far the only turing complete cryptocurrency: Ethereum backpedalled from that claim and instead use “rich statefulness”, whatever that means.

Yes, I said jokes aside, I failed.

Image for post
Image for post

So far it’s only an explanation on how Bitcoin transactions work.
This is a good time to start implementing a proof of concept of the paper. I will use .NET Core, Nicolas Dorier’s NBitcoin and QBitNinja.
First for refreshing my knowledge, I start with implementing a basic transaction on the testnet:

At this point, I sent 1 testnet btc to the _fundingAddress, which is mkvRuHAv3qek4mP3ipjqFnaFXj4d2kKit3, as you can see here:

Image for post
Image for post

Or in a block explorer: f1e0865d087e3aeee1124e07c32b5cd7dda342c3d8dc691e54b9094f1f939df8
As you can see I, the first output of the transaction belongs to my fundingAddress. And then I build another transaction using this txout. The console output is:

fundingAddress: mkvRuHAv3qek4mP3ipjqFnaFXj4d2kKit3
destinationAddress: mk1soVb7Se1t99v7APGqiXofr2pKVS7hN5
txThatSpends:{
"hash": "c59b60dab2587617097f87b3589b153c5390085dd3f554712a831dc745e624d5",
"ver": 1,
"vin_sz": 1,
"vout_sz": 1,
"lock_time": 0,
"size": 192,
"in": [
{
"prev_out": {
"hash": "f1e0865d087e3aeee1124e07c32b5cd7dda342c3d8dc691e54b9094f1f939df
8",
"n": 0
},
"scriptSig": "3045022100e0b725ed91e09637cb1df70a2ec9fa7d1446a92474ac11aff8
4fb7cd20cb1d3402202cd656d28ab15e86ec4b6ce8c2ff00c9b882dceebb8006b7c99933743e0013
ba01 03a97dabf1315edda7ba0fa8972fc59f2496eee4c54f3191163987d9a663cd6d24"
}
],
"out": [
{
"value": "0.99900000",
"scriptPubKey": "OP_DUP OP_HASH160 3158d0e1bbbc464a1fd137ca7a9f4b838a2f706
b OP_EQUALVERIFY OP_CHECKSIG"
}
]
}

Now let’s progress further with the whitepaper.

Image for post
Image for post

Now I start drawing, not only writing the code:

Image for post
Image for post

At this point I don’t know what the condition is, so there is nothing much to change in my code, except that I simply rename my created transaction, txThatSpends to tOffer.

Image for post
Image for post
Image for post
Image for post

So there is another transaction that spends tOffer, called tFullFill. Let’s add it.

Image for post
Image for post
Image for post
Image for post

It’s actually not clear at this point, but it’s important:

Image for post
Image for post

First let’s examine the hashing condition:

Image for post
Image for post
Image for post
Image for post

Approaching the wtf zone, nevermind, read further.

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

To make it more understandable, it is not a bad idea to go through Davide De Rosa’s The Bitcoin Script Language (pt. 1 and pt. 2) tutorials.

Now let’s see the signing condition:

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

This is a fancy way to describe this, but it’s actually simple, I just realized this and I’m already mad at the cryptographers who wrote these lines down.
If you send 1btc to Bob, then when Bob wants to spend that transaction it has to sign with his corresponding private key.
It only differs in that Toffer adds the hashing condition that Bob must have x, too, his private key is not enough.
Now when Bob acquires x, he can spend Toffer with Tfulfill to himself.

Image for post
Image for post
Image for post
Image for post

Crypto blabla..

Image for post
Image for post

More crypto blabla…
Ok, I think the reason it is included here is simply informational, to show why the authors’ previous work is not compatible with Bitcoin: Blindly Signed Contracts: Anonymous On-Blockchain and Off-Blockchain Bitcoin Transactions
As they noted:

Image for post
Image for post

[27] is the work, I just linked above.

Image for post
Image for post
Image for post
Image for post

Ahha, there’s another condition!

Image for post
Image for post

Is this really correct? Shouldn’t Tfulfill be propagated within the timewindow otherwise Toffer can be reclaimed by the party funded the transaction?
I wuld continue to complete my transaction drawings, but I’m getting confused here. Anyway, read further.

Image for post
Image for post

Our previous drawings now looks like this:

Image for post
Image for post

Plus you have to imagine the timewindow magic, which I wasn’t able to include, because I got confused by the possible mistake?

Image for post
Image for post

So far simple renaming, I follow this renaming my code, but I don’t construct the transactions just yet, only in my drawings:

Image for post
Image for post
Image for post
Image for post

Yes, I knew it was a mistake:

Image for post
Image for post

The End

I covered half of the 4th and half of the 5th page of the WhitePaper. There are 35 altogether.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store