Drawbacks and Limitations
Payment channel hubs have already started to form using two-way payment channels in the Lightning Testnet for Bitcoin. The current off-chain scalability solutions, however, ensure correct operations by arming all participants with the means to economically penalize each other in case of misbehavior. This fashion of design is somewhat akin to having assurance of mutual destruction, which is far from providing graceful fail-safe termination.
The purpose of this blog post is to outline and highlight the limitations of two-party payment channels when used to form hubs, signaling the need for a more elegant and practical hub solution.
What is a 2-party payment channel?
A 2-party payment-channels allows two peers to jointly manage an onchain escrow account that they both have made a deposit into. The management takes place through directly exchanging messages off-chain, which allows the peers of the channel to make payments to each other at a higher throughput than that of the underlying blockchain.
More information: https://en.bitcoin.it/wiki/Payment_channels
What is a payment-channel network?
As a 2-party channel is just between 2-parties, the funds deposited into the channel escrow account are transferable only between the two peers. A payment-channel network utilizes the concept of connecting 2- party channels together such that they can be used to route payments, off-chain, between two peers who may not have established a channel to directly connect them.
This section discusses a few drawbacks of using payment channels to
enact off-chain payments.
Two-way lock-up of funds
The stake in the funds deposited into a payment channel may only be securely renegotiated between the two main channel parties. This means that the funds deposited into a channel by a party are restricted from general use in order to ensure the solvency of payments made in the channel. This frozen collateral cost becomes amplified if the channel is not frequently used.
Linked-payment routing costs
When utilizing payment channels as intermediate links for cross-channel payments, a complex routing problem has to be solved, and the collateral costs associated with ensuring solvency are even more amplified.
Channel termination may be triggered at any time by either channel owner. This means that channel participants must remain connected to the underlying blockchain in order to listen for the termination trigger and react accordingly if the counterparty attempts to terminate the channel with an outdated state.
This is the section that discusses the main issues with trying to run a hub that opens payment channels with each of its users in order to facilitate an off-chain payment routing service.
We had previously written a dedicated blog post on this point. The collateral required to be locked up by a payment processor would have to be quite substantial, actually equal to the amount being transacted by the entire set of users in a given time period, which is not trivial to forecast.
Payment channel termination has a challenge period during which the termination conditions can be contested. One of the channel owners may attempt to close a channel using outdated information that would finalize the channel with more funds in their favor than agreed upon. During the challenge period, the counterparty is given the chance to correct the termination conditions by publishing the most up to date agreed upon channel data.
Blockchains have limited bandwidth for transactions per a given period of time, depending on the design and operational parameters in use such as block size, and average block generation time. If a large enough number of payment channels were triggered to terminate simultaneously, or if the blockchain experienced congestion during a long enough period of time for any reason, payment channels can be terminated using outdated information.
This issue is particularly problematic for the hub-like intermediaries established using payment channels. A hub, or collection thereof, operating a large enough number of payment channels can choose to spam the blockchain with channel terminations, effectively congesting the blockchain and giving very little chance for channel counterparties to contest the channel termination conditions.
Extending the termination challenge period comes at the explicit cost of extending the amount of time the frozen collateral is inaccessible. The more payment channels there are at stake, the longer the timeout period has to be. This creates an implicit upper bound on how large a hub can grow before it becomes too much of a liability.
Enforcing strong penalties on the losing side of a channel termination challenge also significantly increases the risk associated with operating a payment hub. For “honest-but-compromised” parties, the damage can be catastrophic in case channel finalization were intentionally forged using leaked private keys.
Payment channels are a useful construct for two parties to co-manage an escrow account, and payment channel networks leverage these channels to route payments between two indirectly connected parties. The formation of hubs that maintain a significant number of channels, however, is impractical using existing channel solutions, due to business challenges, security concerns, and usability issues. Subscribe to our blog for more short articles on blockchain solutions, and the latest news about the Liquidity.Network project!
DISCLAIMER: Timelines and roadmap details mentioned are subject to change. Please look for our official communication on liquidity.network and subscribe to our update emailers. There is a lag on uploads. This message is not an endorsement or recommendation for Liquidity Network, any cryptocurrency, or investment product. Neither the information, nor any opinion contained in this message constitutes a solicitation or offer by the creators or participants to buy or sell any securities or other financial instruments or provide any investment advice or service.