From Nic's blog,
https://medium.com/@nicolasdorier/tumblebit-tumbler-mode-ea44e9a2a2ec#.ecxv3ebemTumbleBit: Tumbler Mode
As I am currently developing a hopefully production ready tumbler server and client implementation called NTumbleBit, I attempted to find the easiest way to model interactions in TumbleBit as easily as I could.
A tumbler is basically a service to remove any link between two addresses that you own. You send some coins to an address, tumbling happens, and you get some other coins, minus fees, back to another address.
Tumblers like Helix are costly (around 3%), and users need to trust Helix to not scam them by confiscating the coins sent to it. Not mentioning that such Tumbler might keep records of the mapping of the coins it tumbles.
TumbleBit solves this issue, by making the tumbler itself unaware of how to match input coin to output coin, it also prevents any theft from a malicious tumbler.
In Tumbler Mode, TumbleBit asks two time-locked escrow coin to be setup.
First coin will be escrowed by Client and can be spent under one of the two conditions:
Client and Tumbler sign,
Client signs and block height is above X
Second coin will be escrowed by Tumbler and can be spent under one of the two conditions:
Client and Tumbler sign,
Tumbler signs and block height is above X + Y
It means that the Tumbler need Bitcoins in reserve to escrow.
Since bitcoins are limited, the Tumbler need to ensure there is some cost into making it escrow some coins.
Keep also in mind that Tumbler must not be able to know which Client’s coins (the input) belongs to which Tumbler’s coin (the output).
Here is how to solve those problems in the escrow phase:
Client asks an unsigned voucher to Tumbler,
Client create its escrow coin, and wait a confirmation,
Client blind the voucher and asks Tumbler to sign,
Later, Client unblind the voucher, and show the signature to Tumbler,
Tumbler can now escrow a coin, because it knows Client escrowed one of its coin, but does not know which one,
In other word, the voucher constitutes a “proof of escrow”.
Now here is the trick: The tumbler can ask to the Client to escrow a coin whose value is “Amount + TumblerFee + DoSPrevention”.
However, Client would only send “Amount + TumblerFee” to the Tumbler, and get back DoSPrevention to one of his address.
By doing so, the Tumbler can impose a temporary cost to the Client for the privilege of escrowing one of his own coin.
In other word, if a Client wants to send 1 BTC to the Tumbler, the tumbler can ask to the Client to escrow 2 BTC. But the Tumbler would only escrow 1 BTC.
When the escrowed coins have been confirmed, the Client can sends money to the Tumbler in the Payment Phase. After the Payment phase, thanks to the Puzzle solver/promise protocols, the Client knows for sure that he will be able to cashout later.
After payment, the Tumbler cashouts.
Then the client cashouts out.
If for some reason the payment could not go through, the Tumbler and Client can cash out the coins they escrowed by waiting for the time-lock to expire.
All Tumbler’s Clients pass through these phases at the same time (in blocks) so the Tumbler can’t infer the new address of the Client by measuring timing.
Here is a summary:
