Bitcoin and its most popular off-chain scaling solution, the Lightning network, have ushered in a new digital payment era, allowing users worldwide to make almost instantaneous, cost-effective payments. Once you’re in the Lightning Network, you’re free of the timing of adding blocks and competition block space.
You can send and receive payments as long as you have the capacity in your channel, and you only ever need to touch the chain if you want to call it quits with Lightning if a peer goes down, if you’re rebalancing your channels or you’re looking to bring online even more liquidity by adding more channels.
Today dance between the Bitcoin base chain and Lightning Network isn’t too much of a pain. The Lightning Network has pulled millions of transactions off-chain, leaving plenty of block space for those who wish to use Bitcoin on-chain.
But this won’t always be the case; the more users coming online in both the Bitcoin mainchain and Lightning means block space will see more competition, and those who use Lightning in a non-custodial manner will need to be smarter in the ways they touch the chain.
If Lightning is going to scale, there needs to be more efficient ways of moving capital between the base layer when it is needed to give Lightning node operators more optionality.
The standard channel opens and close are fine for now, but in the future, options like dual-funded channels, Lightning CoinJoin, CoinPools co-ordinated channels opens, Splicing, Liquid Network-funded channels, and channel factories might all have a part to play in a node runners arsenal.
Another option making the rounds is the idea of Hierarchical Lightning channels.
What are hierarchical channels?
In a standard Lightning channel, a Lightning network node would broadcast a UTXO announcing that they will be locking up these funds, creating a corresponding HTLC on Lightning tied to a peer in a 2 of 2 multi-sig on-chain agreement.
A hierarchical channel is a 2-party channel with two main outputs, one per party, plus zero or more HTLC outputs. Each output from a hierarchical channel that pays to a multi-user party fund another potentially hierarchical channel.
As a result, each output in a hierarchical channel (including an HTLC output once it has been resolved) can be viewed as the root of an off-chain tree of outputs where the leaves are owned by single users.
In order to update a hierarchical channel, funds are offered by one party to the other party in an HTLC. One user within the party offering the HTLC is designated as the payer, and one user within the party offering the HTLC is designated as the payee.
Updating and rebalancing hierarchical channels.
All of the funds for the HTLC are provided by the payer, and if the HTLC succeeds, the bulk of the funds go to the payee (but users within the offered party other than the payee can also get routing fees).
Before a channel state is updated to include a new HTLC output, all of the users in the channel sign new transactions that spend the new channel state’s main outputs. Then its existing HTLC outputs are rebalanced with the new HTLC output.
The users then sign transactions implementing the new channel state (including the new HTLC output) and revoking the previous channel state.
Once the HTLC is resolved, the channel state is updated to include the HTLC’s funds in the offered party’s main output (if the HTLC succeeded) or in the offering party’s main output (if the HTLC failed).
Payments between hierarchical channels.
Because the two parties within a hierarchical channel can use an HTLC to exchange bitcoin, they can link their HTLC to HTLCs in other potentially hierarchical channels, thus making payments over the Lightning Network.
In particular, each party in a (potentially hierarchical) channel appears as a separate node in the Lightning channel graph. Each (potentially hierarchical) channel appears as a pair of unidirectional edges linking the channel’s two parties.
Payments would remain the same as in the current Lightning Network, where a payment consists of a path where the node that’s offered an HTLC in one hop offers an HTLC in the next hop (and the user that is the payee in one hop is the payer in the next hop) along with collecting a routing fee in the process.
What are the benefits of hierarchical channels?
First, as long as Lightning channels are created within hierarchical channels, resizing them flexibly, nearly instantly, and off-chain is possible. This makes Lightning node management cheaper and more effective by moving liquidity around and deploying it where it is needed without the “big reset” that is touching the chain to close and open new channels. The less need for updating HTLCs by broadcasting a UTXO means capital already in Lightning is the first point of order, and only when additional capital is needed do we look to pull in funds from the base chain.
Lightning node runners will need to touch the chain far less, saving on bidding up block space or waiting for blocks to confirm to unlock or close down channels.
Another benefit of hierarchical channels is that they can be created by a casual user and a pair of power users such that the casual user can send and receive bitcoin in a watchtower-free manner, while the dedicated users can use the total of their channel capacity to route payments even while the casual user is inactive.
As a result, casual users can operate watchtower-free without stranding any capital, while liquidity is used more effectively across the network, with power users able to pull that static channel capacity online whenever it is needed to route a payment.
Lightning requires protocol changes to support HLCs.
Each main output (or resolved HTLC output) from a hierarchical channel must be able to pay to a tree of transactions that distribute the output’s funds to individual users at the leaves. This can be achieved by requiring the users in the hierarchical channel to exchange signatures for the tree of transactions that spend each output of a given Commitment transaction before signing that Commitment transaction.
Updated channel announcements
A Lightning channel is currently announced with a channel_announcement message that references the on-chain UTXO funding the channel, and the channel’s capacity is static. These channel_announcement messages won’t work for hierarchical channels that are funded by off-chain UTXOs and have dynamic capacities.
Another proposal (Lightning gossip alternative) for channel_update_v2 messages is well-suited to hierarchical channels as it merges the concepts of channel announcements and channel updates, and it includes the channel’s capacity, thus supporting dynamic capacities.
In addition, it supports channels that are funded off-chain by allowing on-chain UTXOs to be cited when announcing channels with capacities that are, at most, a fixed multiple of the on-chain UTXOs’ value.
Adding support for multiple channel peers.
Hierarchical channels need to support more than two users per channel. The current Lightning channel protocol only works for 2-user channels, as it penalizes a user that puts an old Commitment transaction on-chain by allowing the other user to obtain all of the channel’s funds. Such an approach doesn’t work if there are more than two users in the channel, where at least two are dishonest.
In such a case, a dishonest user could put an old Commitment transaction on-chain, and another dishonest user could “punish” that user by claiming all of the channel funds, including those from the honest users.
Even if dishonest users can’t guarantee that they’ll take the channel’s funds, the expected value obtained by dishonest behaviour could exceed the expected value from honest behaviour.
Do your own research.
If you want to learn more about Hierarchical Lightning Channels, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research, check out their official resources below or review other articles and videos tackling the topic.
Are you a Bitcoin and Lightning fan?
Have you been using Lightning to make micro-payments? Stream sats or engage with apps? Which app is your favourite? Do you run a Lightning node? How do you handle channel rebalancing? Have you tried all the forms of Lightning payments? Which one do you prefer?
Let us know in the comments down below.
