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

6 min readJun 5, 2017

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.

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.

Bitcoin Scripts And Smart Contracts

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.

Transactions

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:

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: mk1soVb7Se1t99v7APGqiXofr2pKVS7hN5txThatSpends:{
  "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.

Now I start drawing, not only writing the code:

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.

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

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

First let’s examine the hashing condition:

Approaching the wtf zone, nevermind, read further.

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:

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.

Crypto blabla..

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:

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

Ahha, there’s another condition!

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.