A practitioner’s guide to Bitcoin scaling solutions

Exploring the design and trade-offs between Lightning and Liquid networks

Intro

It is widely accepted that Bitcoin requires new solutions for use cases that are infeasible to scale on-chain. Operating as the most secure and decentralized proof-of-work (PoW) network comes with its own set of trade-offs: lack of innate scalability, as embodied by transaction costs and time to first confirmation. With these downsides in mind, researchers have designed novel solutions which leverage different aspects of the base layer to solve for speed and cost. Two emerging solutions are Lightning (payment channel) and Liquid (sidechain) networks. In this article we will explore the design of each system and their trade-offs.

No free lunch; or why we need scaling solutions

A theorem applied to general optimization problems is the no free lunch theorem: for discrete problems, a candidate solution which demonstrates elevated performance in one class of problems pays for it in performance over another class. This theorem provides a logical framework to produce related theorems in specified classes of problems such as distributed data access systems (CAP) and more recently in blockchain protocol networks (scalability trilemma). (Note: these theorems are not universal and come with several caveats, but they summarize, rather intuitively, that there is no winner-take-all solution to many complex problems.)

It is intentional that Bitcoin sacrifices relative scalability to optimize for a combination of other features aligned with the design of PoW. Exploring the economics of PoW is outside the scope of this post but others have argued why PoW is efficient. In summary, the cost of PoW is a feature, not a bug, and provides economic incentives for the value propositions of Bitcoin (ie. incentivized immutability) enforced by the expenditure of an expensive physical resource (energy). We can see that altering solutions for PoW to optimize for scalability, such as reducing PoW difficulty and/or blocktime, in turn negatively affects Bitcoin’s PoW incentive structure. Due to this selection of trade-offs, Bitcoin adds immutability incentive faster than any competing network.

Since Bitcoin design goals do not optimize for scalability or speed, we must look to off-chain solutions. Two nascent architectures are routed payment channels, as implemented in the Lightning Network, and federated sidechains, as implemented by the Liquid Network. (Note: there has been recent discussion around narrowing the definition of “Layer2” to solutions which do not compromise on the security of the base layer. Under this definition Lightning is a Layer2 solution; however, Liquid is not.)

Lightning Network overview

The concepts underpinning the Lightning Network date back to the initial release of Bitcoin Core, which included sample code to allow users to update a transaction in-memory before it was included in a block (Nakamoto high-frequency transactions), allowing for functionality akin to a payment channel. However, this design did not persist at scale as it can be trivially abused to bloat the network mempool alongside other consistency issues.

A payment channel is a set of cryptographic techniques to allow users to make many transactions between them without writing intermediate state to the blockchain; when parties are done transacting, the channel is “closed” and final state is enforced on-chain. Over the years, there have been many iterations of payment channel designs leading up to the Lightning Network whitepaper (2015) which outlines techniques for structuring payment channels together to create a routed payment channel network. Since then, stakeholders have come together to agree on an evolving Basis Of Lightning Technology (BOLT) specification resulting in many client implementations including Lightning Network Daemon, Eclair, C-Lightning, and Ptarmigan. Each client implementation maintains relative freedom for architecture design and solutions to the unique problem set posed in Lightning.

Entering

Joining the Lightning Network involves opening a payment channel with another node (running a BOLT-compatible client) on the network. To open a channel, two parties cooperate to create a multisig, agree which party will fund the multisig, exchange signed transactions that allow either party to spend the respective channel balances to themselves, and finally fund the multisig with an on-chain transaction. After a few confirmations of the multisig funding transaction, which serves to anchor the channel to the blockchain, subsequent payments in the channel happen off-chain. Participants cooperatively change the channel balance by exchanging data to update the state of the channel, and simultaneously updating how the multisig outputs can be spent.

Transacting

Lightning extends on the channel architecture described above to enable payments between nodes that are not directly connected by a channel. Distant nodes in the network graph can transact by constructing atomic payments that route across multiple nodes, and without requiring intermediate nodes to take custody of funds. A routed payment is established by a payer finding one or more intermediate nodes to the payee who are willing to change two channel balances such that they net a neutral or positive (with fee) balance. Routes are secured using chained Hashed Timelock Contracts (HTLCs) acting as a conditional escrow, where the payee reveals the preimage to unlock the Hashlock chain and receive payment. Routed payments are constructed with onion routing, meaning an intermediate node only knows about its local channels to route a payment and nothing about the payer or payee. Onion routing provides privacy and censorship resistance to routed payments.

Exiting

Closing a payment channel can be done collaboratively or unilaterally by either party at any time via an on-chain transaction. A collaborative close involves both parties signing off on final channel state, allowing for the multisig outputs to be immediately spendable. In contrast, a unilateral close involves one party broadcasting a final channel state and waiting for multisig outputs to become spendable. The wait time is a dispute period during which the broadcast channel state can be challenged. This period is agreed upon by the channel parties ahead of time and might be anywhere from a few hours to a few weeks. If the broadcast state is the newest channel state, it is allowed to stand and the parties receive their share of the channel funds on-chain; if the broadcast state is not the newest channel state, this “breach-attempt” can be challenged by broadcasting a more recent valid channel state. If a channel party is caught attempting channel breach fraud, their funds in the channel are automatically forfeited to the other party.

Failure modes

A failure mode is defined as a condition where a network participant is subject to cost or friction due to an undesirable state. A routed payment channel network like the Lightning Network has several possible failure modes, many of which have mitigations that will be mentioned later:

• Unable to send or receive payments due to network conditions: Routed payments require changes to the allocation of existing balances within the channels along a route. While the total capacity of a public channel is gossiped and verified by other nodes, the exact allocation of funds between parties is not. A payer attempts to construct a route from their local knowledge of the network, so it is not possible to know beforehand whether a payment of certain size will succeed on a particular route. If the allocation change of any channel leaves either party with a negative balance, the payment cannot be made and another route must be attempted.
• Unable to secure dust transactions: If a node’s channel balance is less than the cost to close that channel to enforce the respective balance on-chain, this channel’s balance is not economically secure. This is due to all payments being secured by HTLCs which are only enforceable as an output, and transactions creating outputs below the dust limit are non-compliant and will be rejected by miners.
• Disputable breach-attempt: A channel participant can close a channel with a breach-attempt; if the corresponding party does not challenge the attempt during the dispute period, for instance because the node is running on hardware with poor uptime such as a mobile device, there is potential for the honest party to lose funds.
• Indisputable breach-attempt: Each active channel requires persisting of local data for breach-attempt remedy and state updates. If this data is lost or corrupted, a breach-attempt cannot be successfully disputed.

Features

• Key value propositions: final, private, fast, conditional, and cheap payments.
• Each node on the network can be identified using a persistent public key over the lifetime of the node. This allows for nodes to carry a reputation on the network. For instance, a node which maintains properly balanced channels is a desirable routing target and this can be gossiped to other nodes on the network. Conversely, a node that is poorly routed or performs breach-attempts can be avoided.
• Conditional payment structure allows for new payment flows, opening the door for revamping existing flows with trustlessness or new novel use cases:
  - A payee could withhold a preimage from being revealed until some other condition is met.
  - A payer could generate a payment hash and withhold the preimage until the payee meets some condition before receiving payment.
• Uses Bitcoin’s censorship-resistant immutability incentive and security features as an arbiter for any channel disputes.
• Localized failures: As a payment channel is only between two parties, any errors or failures within the channel only impact channel participants and not the global network.

Open issues

• Availability constraint: The network necessitates a liveness constraint to: open a channel; make, route, or receive a payment; collaboratively close a channel; or dispute a malicious unilateral close. This makes up-to-date channel and network state data critical for safe usage. Failure to dispute a breach-attempt results in loss of funds, thus watchtower designs have emerged to incentivize keepers to watch for and remedy breach-attempts. This constraint also comes with a trade-off gain described in CAP theorem: predictable consistency. A payment, when executed, updates impacted network channels (state) atomically with a known upper bound on time being the HTLC timelock. When a timelock is expired, either the payment route is complete and all parties to the route are consistent with the new state, or all parties remain in the original state. (Note: a theoretical caveat exists where an intermediate node receives a preimage but does not settle upstream HTLCs to the intended payer, however in practice the intermediate node has no incentive to net a negative balance by not completing the route.)
• Liquidity management: The liquidity architecture of routed payment channels can be reduced to a specialized flow network. While flow network semantics and algorithms are not new, Lightning poses some nuances to be worked around due to the opacity of channels. Currently, the maximum possible payment for a node is capped at an upper bound of a node’s largest local channel balance, however, atomic multi-path payments (AMPs) will move this upper bound to adhere to the max-flow min-cut theorem. Along the same lines, to route across the network involves intermediary nodes willing to change the balance of two channels, so to be a reliable routing target, a node would need to monitor and maintain a channel balance conducive to routing under ever-changing network conditions. Several cost-incurring techniques are being developed to aid in channel balancing strategies, including circular rebalancing and submarine swaps, leading to service provider nodes specialized in routing.

Liquid Network overview

The Liquid Network is an implementation of a federated pegged sidechain whose architecture was first proposed by founding members of Blockstream and others in a whitepaper (2014). The authors come to similar conclusions as above for the need of off-chain solutions to supplement the intended design of Bitcoin, and propose a system which trades off decentralization for scalability (cost and speed). Liquid operates similar to the Bitcoin blockchain, even including a block explorer, but with a different trust model and additional features. A sidechain validates data from other blockchains, therefore a pegged sidechain allows assets to be moved on and off the sidechain maintaining a two-way peg on each network. The Elements Project develops pegged sidechain clients; one of which is the Liquid client.

To avoid expensive mining requirements or variable blocktimes, a trusted federation is selected to manage the intended operation of the network. Ideally, federation members are also major users of the network so operational incentives are aligned. Each new block is agreed upon by a majority of the federation (11 out of 15 members establish consensus) to eliminate chain reorganizations (reorgs), which are common in Bitcoin, resulting in consistent and final one-minute blocktimes. Additionally, Liquid provides features to users including asset issuance and confidential transactions.

Entering

Anyone can enter the network by running a Liquid client and depositing BTC (peg-in) into a federation-controlled multisig wallet to mint transferable Liquid-bitcoin (L-BTC). To maintain solvency of the two-way peg, the federation must defend against reorgs, and therefore waits for 102 block confirmations (confirmation period) before considering a Bitcoin simplified payment verification (SPV) proof that mints L-BTC onto the network.

A peg-in transaction works by a user cryptographically altering the federation public keys (still spendable by the federation private keys) and spending to the newly generated public key. Sometime after the confirmation period, the user can inform the federation what alterations it made to generate a new public key which the federation confirms along with the SPV proof to mint L-BTC. This mechanism affords users privacy from miners and even the federation itself, who do not know a peg-in is available until after the confirmation period. This also allows the user to tie other conditions to their L-BTC at this time.

Transacting

Transacting on the Liquid Network is semantically similar to Bitcoin since they use the same transaction model such that a transaction is constructed, signed, and submitted to the federation for inclusion in a block. There are other major additional features in Liquid such as confidential transactions and issued assets covered below, however these do not materially change the way transactions are signed or submitted.

Exiting

Withdrawing requires a request to the federation who approves a burning of L-BTC (peg-out) and spends an output with the corresponding amount of BTC from the federation multisig. (Note: as detailed in this blog post, for security reasons peg-out transactions can only be made to supported exchanges.)

Failure modes

• Censorship potential: the federation could, in theory, reject all signed transactions from a particular address forbidding transfer or withdrawal.
• Malicious federation: since a majority of the federation reaching consensus is required to append new blocks or spend from the multisig, the same majority is required to unilaterally change the operating rules of Liquid. For example, in the worst cases the federation could collude to drain the multisig or reorg Liquid to an arbitrary depth with no recourse.
• Consensus failure: if the federation stops producing blocks all funds are frozen within Liquid. After 28 days of consensus failure, any combination of Blockstream and other emergency key holders (two out of three) can trigger an emergency shutdown allowing users to withdraw funds.

Features

• Private, high-volume, and high-velocity transfers between semi-trusted actors: We observe the trust model of the federation to infer the relative risk of other actors. The trust of the system is reliant on the honest operation of the federation, and falling back on emergency key holders in the event of a consensus halt. It follows that Blockstream and other emergency key holders have the least amount of downside risk, followed by other federation members, and finally non-federation users incur the highest risk. For users willing to accept this model, the risk incurred is less than that of solutions that take full custody of funds such as exchanges. This makes Liquid a strong network solution for users, and in particular federation members such as exchanges, over-the-counter (OTC) trading desks, and other high-volume traders to perform transactions and atomic swaps more cheaply, quickly, discreetly, and with a higher certainty of finality than the existing Bitcoin network.
• Confidential transactions make use of Pedersen commitments to obfuscate transaction amounts from other network participants, ensuring financial privacy while still guaranteeing valid transaction amounts. A user may optionally reveal their blinding key to another party to decrypt transaction amounts.
• Users have access to a feature called Issued Assets (IA), enabling the creation of new, user-managed assets within Liquid. Recently, Tether issued USDt on Liquid enabling users to perform private and fast transfers or atomic swaps between L-BTC and USDt.
• Due to Liquid using the same protocol as Bitcoin, parties can construct the same routed payment channels used in Lightning on top of Liquid. This would allow users to derive the same off-chain benefits of Lightning with fast and private channel creation, but falling back on the federation trust model of Liquid.

Open issues

• Emergency key holder liability: Blockstream and other’s control of Liquid emergency keys could infer some liability as a network operator. If Liquid consensus fails and two of three key holders are conflicted out of executing the emergency shutdown transaction, users have no native recourse in the system.

Network comparison and trade-offs

• Both networks’ security is predicated on the security of the Bitcoin network in different ways: Lightning falls back on the Bitcoin network as an anchor and arbiter during dispute, while Liquid relies on high-depth SPV proofs to secure the L-BTC peg.
• Both networks allow for rapid experimentation of nascent payment technology (i.e. conditional payments) and cryptographic features too risky or expensive to support directly on Bitcoin (i.e. confidential transactions).

Safe network operation:

• Lightning safety is predicated on a node’s ability to manage (or outsource) local state data.
• Liquid operates as intended so long as the federation operates as expected.

Trust dependency:

• Lightning’s trust model falls back to the security of the Bitcoin network.
• Liquid requires multi-party trust of the federation, falling back to emergency key holders.

Pain points:

• Lightning’s trust-minimized nature comes at the cost of added complexity. Local liquidity is bilaterally managed by channel parties, creating additional economic and coordination costs to perform network-critical tasks such as routing.
• Liquid’s utility is a function of reliable operation of federation members and their respective liquidity in the network. It therefore faces a problem if key target stakeholders (exchanges, OTC desks, etc) do not on-board, and a chicken-and-egg problem such that liquidity is unlikely to show up until liquidity is in the network.

Which is better for your use case?

While both networks offer similar value propositions, each comes at the cost of vastly different trade-offs. Liquid makes the classic trade-off in centralized network operation to gain feature flexibility and fast finality, and therefore is likely unsuitable for users who value trustlessness. For federation members who are already dealing with high-volume custodian risk at exchange or OTC venues, Liquid can provide cost savings in operational expenses without the additional overhead of Lightning channel management. Lightning, on the other hand, maintains decentralization and the security characteristics of Bitcoin making it an ideal choice for fast, high frequency, and trust-minimized payments at the cost of increased local operational overhead. When selecting an off-chain solution users should consider the trade-off set as it relates to their current operation and problem being solved.

If you are exploring these networks you can find related topics on the wiki and stay updated with ION Twitter.

Special thanks to Brandon Curtis, Beatrice Leung, and James Prestwich for feedback on this post.