TumbleBit is a second layer payments proposal for bitcoin that has mostly gained attention due to its ability to improve privacy for users, but this enhancement is about much more than that. With TumbleBit, there may be the potential to exponentially increase bitcoin’s user base without making any alterations at the consensus layer, although Segregated Witness activation would help.
For the developers working on TumbleBit, the creation of trustless bitcoin banks is the ultimate end goal. In a recent conversation with CoinJournal, Ethan Heilman, who is a co-author of the original TumbleBit white paper, shared his own aspirations for this sort of system.
TumbleBit essentially builds the anonymous digital cash systems of the past on top of the censorship-resistant base of bitcoin. With TumbleBit, bitcoin could provide the sorts of features that are often wrongly attributed to it (e.g. anonymity, instant transactions, nearly free transactions).
TumbleBit Hubs Envisioned as Trustless Bitcoin Banks
In TumbleBit, payment channels are centered around a centralized hub that essentially acts as a trustless payment processor. “A payment hub is basically a bank that can’t steal from you,” Heilman told CoinJournal.
“Someone like Coinbase could become a payment hub, enabling off-blockchain payments,” added Heilman. “They already do this, Coinbase to Coinbase payments are just a database row update, but they are trusted. So [a TumbleBit hub] is an untrusted Coinbase with privacy.”
Payment channel hubs are already possible today, but TumbleBit adds a layer of privacy to the equation: The hub does not know where payments are being sent. These sort of second layer bitcoin protocols would also be much more elegant and efficient if the Segregated Witness (SegWit) improvement were activated on the network.
With TumbleBit, bitcoins are essentially deposited into a bitcoin bank in a manner where they cannot be stolen by the bank and the bank is unable to track its users’ transactions. The “bank” benefits by collecting fees for processing transactions.
Since payment channels are used in TumbleBit, none of the transactions between users of the same hub need to be broadcasted on the blockchain. However, on-chain transactions are required for what essentially amounts to opening an account. On-chain transactions are also necessary when something goes wrong and are needed more often if SegWit is not available.
“The end goal is private, bidirectional payment channels, but that requires more research to figure out how to do it with bitcoin,” said Heilman.
The Tradeoffs with TumbleBit
Of course, TumbleBit is not perfect — at least not yet. Tradeoffs are made in terms of security when using a TumbleBit hub. The most worrisome scenario with TumbleBit is the possibility of lost funds. “For a user to lose bitcoins, he must not get his transactions into the blockchain and the hub must try to cheat him,” explained Heilman.
If the hub attempts to cheat a user, the user has a certain amount of time to broadcast a transaction that proves the hub is trying to cheat. If the user’s transaction is broadcasted in time, the hub fails in their attempt to cheat the user. Otherwise, the user would lose out on the entire amount they had received through the hub up to that point.
“This is an issue with all current layer two protocols, although I believe it can be overcome,” said Heilman. “If a user can’t post to the blockchain during the window of time in which they are supposed to (say one week), they forfeit those funds.”
This situation is similar to a problem with the Lightning Network. Much like TumbleBit, funds can be stolen if a user is unable to get a transaction broadcasted to the blockchain within a certain time period. “One challenge is to make the cashout window large enough that this will never happen,” said Heilman. “How big should that window be?”
This problem is obviously much worse in the era of full blocks. If blocks are full, then it will be more difficult to get a specific transaction into the chain under certain time constraints.
In theory, this issue is less problematic with TumbleBit than it is with the Lightning Network. ”In the Lightning Network, your counterparty is some random node; in TumbleBit your counterparty is a known entity,” explained Heilman.
In other words, these TumbleBit hubs will essentially be running their servers as businesses and providing a service to their users. This sort of entity is generally less likely to act in bad faith than a random node on the Lightning Network. Having said that, it’s still critical for the system to work in a trustless manner.
Various solutions to the issues related to coin theft in layer-two protocols like TumbleBit have been proposed. An adaptive block size limit would allow miners to increase capacity in scenarios where users are in desperate need of broadcasting transactions. Users may also be able to reserve block space in the future as a form of insurance that they’ll be able to get their transaction broadcasted by a certain time.
What may be the most promising solution, which is now included in the Lightning Network white paper, comes from Blockstream CTO Greg Maxwell. Called a “timestop” the idea is to allow miners to pause the countdown on the amount of time users have to get their necessary transactions broadcast when blocks are full. “[This turns] the security risk into more hold-up delay in the event of a DoS attack,” Maxwell wrote on Reddit.
In addition to the possibility of stolen funds, a TumbleBit server could simply disappear. In this situation, users would be left with the annoying process of waiting for the locktime on their “deposited” coins to expire. “With SegWit this locktime can be hours; without SegWit, the locktime would be a few days to maybe two weeks,” said Heilman.
Even with these tradeoffs in terms of security, it’s clear many bitcoin users would prefer a TumbleBit hub over on-blockchain transactions in certain scenarios. After all, payments are much faster, cheaper, and more private when TumbleBit is used.