Thunder, Lightning and Interledger
Fixing Bitcoin’s speed issues may be the key to using it with Interledger
It’s still very early to tell, but on first appraisal, it looks like Blockchain has taken a great stride in fixing a major limiting factor of Bitcoin and one that made it very difficult to use Bitcoin with Interledger; transaction speed.
“it makes me excited about bitcoin all over again.”
What is Thunder?
Thunder is an implementation of a Lightning network, a theoretical peer-to-peer network of nodes that establish “payment channels” between one another. A payment channel is a pre-funded Bitcoin float (setup through complex multi-sig transactions on the Bitcoin blockchain) that the two parties can then exchange using a very lightweight payments protocol to facilitate movement of Bitcoin between them.
You can think of payment channels as ad-hoc clearing houses in a traditional payments ecosystem, however they only clear transactions between two participants and the netting and settlement (on the Bitcoin blockchain) is also done on an ad-hoc basis.
Payment channels can be chained together and the alpha implementation includes a crude routing mechanism to allow payments to move between nodes that do not have a direct payment channel established between them.
The effect of Thunder is to create a real-time Bitcoin clearing network on top of the Blockchain.
How does this relate to Interledger?
So you may be asking what the difference is between Thunder and Interledger or why the Interledger community is so interested in Thunder at all. The fact is, the Interledger community has been keeping an eye on Lightning since the original white paper was published earlier this year and is very excited to finally see a working implementation.
Thunder is a payment network. It is efficient, fast and has very low fees but it is still a network just like any other payment network in that to use it you need to connect to it directly, and in the case of Thunder you only transact in bitcoin. On the other hand Interledger is a protocol that is ledger- and network-agnostic, it is neither a ledger nor a network itself; as Stefan Thomas and Evan Schwartz explain in a recent interview with EpicenterBitcoin:
If you think of the theoretical Internet of Value as a network of payment networks (much like the Internet is a network of networks), Thunder is one of the subnets and Interledger is like TCP/IP. Payments within the Thunder network don’t require Interledger (although there are some good arguments for Thunder to re-use some Interledger primitives like crypto-conditions) but any Interledger connector that connects into the Thunder network enables routes through Thunder for payments from any ledger to any other in any currency.
Previously it would have been very difficult to route Interledger payments through a Bitcoin ledger (due to the slow time to clear) so a working implementation of Lightning is a big deal. Because Interledger is neutral, it gives no preference to any ledger or network. That means that payments will route through ledgers or networks that offer the best capabilities such as speed, cost and trustworthiness.
Bitcoin excels in many of these areas except speed and so it has been difficult for anyone to realistically build a ledger adapter for Bitcoin to support Interledger. It has always been technically possible, but why would anyone ever have routed payments via Bitcoin if that link in the chain delayed the whole payment from completing?
The promise of Thunder is a new high-speed low-cost route for payments, that are settled via Bitcoin and that could form a very competitive link in a chain of Interledger payments.
There are still some changes required to the Blockchain before Thunder can operate without special trusted nodes but the alpha release gives us an opportunity to kick the tires and experiment more effectively with Interledger over the Bitcoin network.
The transaction signing mechanism used within payment channels could be implemented slightly differently using crypto-conditions which would make it easy for a Thunder wallet to be the terminating ledger (sender or receiver) for an Interledger payment rather than simply using Thunder as an intermediary rail.
The core team will be reaching out to Blockchain and the Thunder team and hopefully we’ll see them at our workshop in London on 6 July.
For more info on the upcoming London workshop visit the registration page at interledger.org/workshop