* This article assumes that the reader already has a basic understanding of the Bitcoin protocol and how nodes, users and miners interact within it.
Bitcoin is extremely secure, but it did so with a compromise initially: it’s slow. At the basic level, there is no getting around the immense computing power and the average block time of 10 minutes – and that’s what it’s all about. Bitcoin’s maximum number of transactions per second (TPS) is around five, which immediately raises concerns about the scalability that enables millions of users to leverage its use case: a permissionless peer-to-peer currency.
Enter the Lightning Network. Lightning was suggested in a 2016 whitepaper by Joseph Poon and Thaddeus Dryja. At 59 pages, it’s serious read, but nothing short of awesome. It overcomes this scalability problem without sacrificing security or trust, while increasing anonymity.
There are often discussions about protocols based on Bitcoin and whether or not its users interact with “real” Bitcoin. This is a valid question in this context, as it is not immediately apparent how Lightning users interact with “real” Bitcoin while having near-instant transaction times and almost no fees.
The Lightning Network itself is made up of two things: nodes and the channels between them. These nodes must also serve as nodes for the base layer of Bitcon as this is how they open and close channels between nodes.
Bitcoin can only be added to the Lightning Network by creating a channel between two nodes. The bitcoin is placed in an unsent transaction that both nodes verify and sign. This channel can be funded by one or both nodes. This means that
1. This bitcoin cannot be used for anything else until this transaction is sent to the network.
2. Both nodes have the option to “redeem” this transaction at any time in order to get their original channel funding back.
The operation of a Lightning node involves a lot of effort and nuances. Not least because of the incurring routing fees, node operators are encouraged to set up many channels. However, the fees must be competitive in order for transactions to be routed through their node. It is also suggested that operators have multiple channels to increase network connectivity and make channel matching easier.
A natural side effect of running the Lightning Network is the pooling of funds on one channel or another. This restricts liquidity in certain neighborhoods and therefore requires “realignment” of the channels in order to achieve a more even liquidity gradient across the network. The maximum transaction size was – at least in the past – limited by the smallest channel balance. Interestingly, Rene Pickhardt and Stefan Richter are working on this. Operators are also encouraged to open large channels – usually at least a million satoshis – to facilitate larger transactions through their channels. Operators are also encouraged to keep their channels open for as long as possible, as closing them will require falling back on the base layer, which potentially incurs high transaction fees.
Canal operators have an incentive to cooperate with one another. The main concern is that some channel constituent will close the channel itself and send an incorrect transaction (ie, a channel state that indicates the channel balance per side at a given point in time) back to the base layer. But they cannot access these bitcoins for a period of time. If during this time the other channel component can have a more recent channel state, the malicious channel component will lose all of its bitcoins. Watchtower nodes can also enforce this.
The smooth operation of Lightning nodes and channels can be very time consuming. Fortunately, there are large communities devoted to education that bring everyone, including your grandma, into Lightning.
Lightning enhancements are currently being made by several organizations, including Lightning Labs, Blockstream, and ACINQ. Although they are separate groups, they keep their products interoperable by applying agreed development rules.
With Lightning still in the works, security issues and vulnerabilities will inevitably arise. As I said, it has come a long way in just a few years. At the time of writing, it has a capacity of over 20,000 public nodes, 60,000 channels, and 2,000 bitcoin.
Since Lightning makes it unnecessary to confirm every transaction on the base-layer blockchain, the possible upper limit of TPS tends steadily towards infinity. This also pushes transaction fees down to near zero.
Interacting with Lightning isn’t that different from interacting at the base level. You can still use your own node or someone else’s node through a depot or non-depot wallet. Instead of trading addresses, we are now exchanging bills that encode, among other things, where the Bitcoin is going and how much is going there. These transactions are sent via onion routing, ie no node between the sender and receiver knows who is sending and who is receiving. In this way, lightning increases the fungibility dramatically. With the introduction of Taproot, it becomes difficult to even determine whether or not Bitcoin is trading on the Lightning Network.
In order to remove Bitcoin from Lightning back to the base layer, a channel must be closed, a loop-out performed, or a sub-boot swap performed. You can do this yourself using your own Lightning Node, or you can have someone else do it through a wallet mentioned above.
Fortunately, there is a flurry of activity around onboarding and developing Lightning. Worldwide acceptance is in sight and within reach and requires all hands on deck.
This is a guest post by Nameless. The opinions expressed are solely their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine.