Author: Anony
In the second article of this series, we have pointed out that the construction method and final effect of lightning channels can be improved with the improvement of Bitcoin protocol. However, in fact, in an area that has received less attention but is closely related to the construction of channels, lightning channels have been continuously optimized without upgrading the consensus rules of Bitcoin protocol, that is, transaction fee payment.
In a lightning channel, the channel state is expressed in commitment transactions, and each commitment transaction may be sent to the chain, so the handling fee must be considered for these transactions. In turn, the method of paying the handling fee will also affect the available balance in the channel and the possibility of batch processing transactions, which in turn affects the user experience.
In this article, we will review how the fee payment design of the lightning channel has been gradually optimized, and how these optimizations have improved the user experience. Readers need to first understand the working principle and security requirements of the lightning network.
Before we begin, please think about a "simple" question: a channel is jointly owned by two parties, and both parties may hold a balance in it. So, when the transaction needs to be submitted to the chain, who should pay the handling fee? In Bitcoin transactions, how can this be achieved?
Okay, let’s start with the method of paying Bitcoin transaction fees.
Payment and Addition of Handling Fees
When a Bitcoin transaction is confirmed by a block, the difference between the sum of its input funds and the sum of its output funds can be collected by the miner who mined the block. This difference is called the "handling fee" and is the main incentive for the miner to include the transaction in the block.
When constructing a transaction, the user selects the input and output for the transaction, which also determines the size of the fee. However, the fee market may change dramatically, and the fee size selected by the user may later prove to be insufficient for the transaction to be confirmed within the time the user desires. Therefore, we need to consider "adding" fees. This is necessary to improve the user experience.
RBF
One of the methods is called "Replace-by-fee", which is based on using part or all of the input of the original transaction to initiate a new transaction, and let the new transaction (replacement transaction) carry a higher fee than the original transaction, thereby attracting miners to package the replacement transaction. As shown in the figure below (note the amount):
graph LR U1(UTXO #0, 500 sats) --> T0[Tx #0] T0 -.-> P0(Payment #0, 300 sats) T0 -.-> C0(Change #0, 150 sats) T0 -.-> F0{{Fee #0, 50 sats}} U1 --> T1[Tx #1] T1 -.-> P1(Payment #1, 300 sats) T1 -.-> C1(Change #1, 100 sats) T1 -.-> F1{{Fee #1, 100 sats}}You can also think that Tx #1 is trying to double-spend UTXO #0, and the two transactions are "racing". But because Tx #1 offers a higher fee, miners will obviously prefer this transaction. This has the effect of what we call "adding fees" and attracting miners to package transactions first.
CPFP
Another method is to use the output of the original transaction to initiate a new transaction and let the new transaction carry a higher fee, so that if the miner wants to package the new transaction, he must package the original transaction (in other words, the old transaction and the new transaction will be a whole - "transaction package" - to compete with other transactions in the transaction pool); this is called "Child Pays for the Father (CPFP)". As shown in the following figure:
graph LR U1(UTXO #0, 500 sats) --> T0[Tx #0] T0 -.-> P0(Payment #0, 300 sats) T0 -.-> C0(Change #0, 150 sats) T0 -.-> F0{{Fee #0, 50 sats}} C0 --> T1[Tx #1] T1 -.-> C1(Change #1, 50 sats) T1 -.-> F1{{Fee #1, 100 sats}}Compared with RBF, CPFP has a disadvantage: new transactions need to occupy additional block space (which means that part of the handling fee carried by the new transaction will be used to confirm itself, rather than adding to the original transaction), while RBF basically does not need it. This means that in situations where both methods can be used, RBF is more efficient and more economical.
With these basic concepts, let’s take a look at the design of the lightning channel.
Legacy Channels
graph LR Channel(The Chennel, 2-of-2 Multi-sig) --> TC1[Commit #1] TC1 -.-> TR(To Remote) TC1 -.-> TC(To Local) TC1 -.-> OH(An Offered HTLC) TC1 -.-> RH(A Received HTLC) OH --> HT[HTLC-Timeout tx] RH --> HS[HTLC-Success tx]The figure above shows the transactions related to a channel state for a participant in the channel: Offered HTLC and Received HTLC represent the HTLC provided by the participant to the other party and the HTLC received from the other party, respectively. In order to consistently apply the penalty-based lightning channel security rules (LN-Penalty), both types of outputs must be pre-signed transactions (and place a penalty branch in the transaction output, which is not drawn in the figure above) [2] . Both types of transactions outlined in the figure above (commitment transactions, HTLC-related transactions) must consider the issue of fee payment and addition.
The original Lightning Network specification made the following designs for fee payment: (1) The channel initiator always pays the fee for the commitment transaction (this is highly tied to the " one-way funding " design mentioned in the fifth article of this series); (2) In HTLC transactions, the beneficiary of the transaction pays the fee. In addition, although the special nature of commitment transactions makes RBF almost unusable (imagine a forced closure scenario where one party wants to put a commitment transaction on the chain, but the other party does not cooperate, and they cannot form a new transaction to replace the previously signed commitment transaction), commitment transactions are not designed to facilitate the use of CPFP - although the To Local output is given to the transaction broadcaster himself, this output has a time lock and cannot be used immediately, so it cannot be used immediately to initiate a sub-transaction; the HTLC transaction itself also requires the signature of the other party, and its output also has a time lock branch.
This design affects the user experience in the following aspects:
- Always asking one party to pay the handling fee is unfair;
- Commitment transactions cannot use RBF and are not designed for CPFP, so they must be guaranteed to have a high enough fee to be confirmed during the construction phase. However, since the time when commitment transactions will be put on the chain in the future is uncertain, this becomes an almost unsolvable problem. The only practical solution is to overestimate the fee very conservatively [3] . However, these fees will occupy a part of the channel funds, reducing the usefulness of the channel.
- In addition, the fee market will also fluctuate, and the resulting fluctuations in estimated fees will also cause fluctuations in the available balances of channel participants, which will cause confusion for users; moreover, during periods of high on-chain fees (which is also the period when people most want to use the Lightning Network to save fees), this will greatly compress the available channel capacity and weaken the utility of the Lightning Network [4] .
So, how to optimize it?
Anchor Channel
The idea of "Anchor Channels" is to arrange an additional low-value but immediately available output for each party in the commitment transaction (while adding a relative time lock of up to 1 block for all other outputs), so that each party can use the anchor output to initiate CPFP after broadcasting the commitment transaction. Of course, since the anchor output itself has a low value, the user must inject additional funds into the sub-transaction in order to successfully add the handling fee.
In addition, anchor channels apply a bold trick to HTLC transactions: when one party signs the other party's HTLC transaction, it uses the hash tag "SIGHASH_SINGLE | ANYONECANPAY" [5] ; this tag makes the signature cover only a pair of inputs (i.e., the target HTLC) and outputs, and allows this pair of inputs and outputs to be combined into other valid transactions. This allows users to combine multiple pre-signed HTLC transactions into one transaction. Moreover, the Lightning Network specification also specifically stipulates that the HTLC transaction of the anchor channel itself should not carry any handling fees; that is, users should combine (batch) all the HTLC transactions they deserve into one transaction, and then pay the handling fee by adding inputs and change outputs to it.
With the combination of these two designs, the implementation of lightning channels has been simplified, and the problem of transaction fees occupying balances has been optimized:
- In a commitment transaction, it is not necessary to rely entirely on the commitment transaction itself to pay the handling fee. Instead, a relatively stable handling fee can be set, and the issue of additional handling fees can be left to the sub-transactions initiated based on the anchor output; in this way, the problem of handling fees occupying the available balance of the channel is alleviated;
- Please note that this does not completely solve the problem of needing to estimate the handling fee. Due to fluctuations in the handling fee market, the threshold value of the fee rate for a transaction to be forwarded by a node will also fluctuate. Although a committed transaction no longer needs to guarantee that it can be confirmed at any time, it still needs to ensure that its fee rate is high enough to attract node propagation; if it cannot be propagated, the CPFP method will not work. But the difficulty has been reduced.
- In HTLC transactions, the transaction fee is no longer paid by the transaction input (i.e., HTLC), so there is no need to consider how the fee level affects the construction and desirability of HTLC transactions.
The cost is that when using an anchor channel, users must ensure that they have available on-chain funds in their wallets to pay for transaction fees.
Complex facts
You might think that, given the structure of Bitcoin transactions and the method of adding handling fees, applying the above improvements should be natural and simple. However, the fact is that, although it can be said to be logical, it is not that easy. Because the order relationship (topology) that can be formed by multiple transactions is diverse. Whether RBF or CPFP, allowing this behavior is equivalent to allowing the initiator of the transaction to occupy part of the resources of the node that propagates the transaction. This occupation must be constrained, otherwise the attacker can launch a DoS attack on the node that propagates the transaction by replacing the transaction and constructing the transaction package. But on the other hand, these rules used to constrain behavior may also be used to launch attacks.
For example, to constrain CPFP behavior, Bitcoin Core's transaction pool rules require that an unconfirmed transaction can only have 24 descendant transactions. Well, in the commitment transaction of the above anchor channel, since both parties have anchor outputs, one party can use its own anchor output to add 24 child transactions to the commitment transaction, thereby preventing the other party from initiating CPFP. Due to the existence of this attack risk (which is called "transaction nailing attack"), the above Bitcoin Core rules allow an exception: when a child transaction has a weight less than 1000 vB and has only one unconfirmed ancestor transaction, it can become the 25th descendant transaction of the unconfirmed ancestor transaction. This exception rule (called "Carve Out") allows the above anchor channel to operate safely (but still cannot eliminate the risk of being affected by the adversary) [6] .
Ultimately, the network of Bitcoin full nodes and the transaction pool rules applied by each node constitute the security reliance of contractual protocols such as lightning channels (they often require transactions to be confirmed instantly to ensure the security of users' funds), but these transaction pool rules may not be perfect. It is not easy to design reliable and abuse-resistant transaction pool rules.
Since 2022, Bitcoin developers have begun to form new ideas about transaction pool rules, among which the most famous are "v3 transactions [7] " and "tribal transaction pools [8] "; the former supports the design of more sophisticated rules by constraining the topology between transactions, while the latter hopes to redesign the internal ordering of the transaction pool to support better RBF rules. Interestingly, since the tribal transaction pool does not allow CPFP-Carve Out, v3 transactions (now renamed "TRUC transactions") will be our bridge to the tribal transaction pool.
In the next section, we will introduce the implementation of these ideas in Bitcoin Core 28.0 (see this guide [9] for details) and how Lightning channels can use them to improve the user experience.
A new paradigm based on 1P1C transaction package
First, Bitcoin Core 28.0 introduces a new transaction pool unit called "1P1C transaction package". As the name suggests, it is a transaction package consisting of only two parent-child transactions. They will compete with other transaction pool units (such as transaction units or other 1P1C transaction packages) for block confirmation as a whole. Among them, the handling fee rate of the parent transaction only needs to meet the lower limit of 1 satoshi/vB, and there is no need to consider the handling fee rate threshold for nodes to enter the transaction pool, which fluctuates at any time.
Secondly, based on the 1P1C transaction package, if all transactions therein use the version number "3", then they will be subject to the rules of "TRUC transactions": the volume of the transaction unit shall not exceed 10 kvB, and the volume of the sub-transaction shall not exceed 1kvB; there are no longer any requirements for the parent transaction rate (it can be zero rate); most importantly, when another sub-transaction is added to the same parent transaction, regardless of whether it uses the same input as the original sub-transaction, it will be regarded as a conflict between the two and the RBF substitution rule will be applied.
That is to say, although 28.0 allows the forwarding of transaction packages, it limits the form of transaction packages to only two transactions, and direct conflicts and competitions at the sub-transaction level cannot destroy this form. This constraint greatly reduces the difficulty of analyzing and designing alternative rules.
Back to the lightning channel:
- When the commitment transaction of a lightning channel adopts v3 transaction, it does not need to carry any transaction fee itself, which completely solves the problem of needing to estimate transaction fees and transaction fees occupying channel capacity!
- No more fee changes to consider, no more fee negotiations, and no more annoying channel closures due to fee disagreements!
- Since we no longer rely on Carve-Out, we no longer need to set up an anchor for each party. We only need to set up an anchor output that both parties can use. This can reduce the size of the commitment transaction and slightly improve economics. We can even use anchor outputs that can be spent without a key [10] .
Conclusion
Back to the question at the beginning of the article: Who should pay the fee for the commitment transaction? Ideally, of course, whoever wants to put a transaction on the chain should pay the fee. Today, with the support of 1P1C transaction package and TRUC transaction, we can finally realize this ideal.
footnote
1. https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#channel-establishment-v1 ↩
2. https://ellemouton.com/posts/htlc-deep-dive/ ↩
3. There is an interesting idea from Peter Todd, which is to let channel participants sign multiple commitment transactions for the same channel state at different fee levels when updating the status, so that participants can broadcast commitment transactions with appropriate fees according to the specific circumstances when going on the chain, including initiating RBF at that time. But it is conceivable that this version may not be suitable for all types of channel participants. For details, see: https://www.btcstudy.org/2024/01/07/v3-transactions-review-by-peter-todd/#%E6%89%8B%E7%BB%AD%E8%B4%B9%E6%9B%BF%E6%8D%A2 ↩
4. https://www.btcstudy.org/2024/01/12/rethinking-lightning-by-benthecarman/ ↩
5. When generating a signature for the input of a Bitcoin transaction, a tag called "sighash" can be used to indicate the part of the transaction covered by the signature (that is, the usage of the funds agreed to by the owner of the funds); only changes to the part covered by the signature will invalidate the signature (and fail the Bitcoin script verification procedure). A common tag is "SIGHASH_ALL", which means that the signature covers all transaction inputs and outputs - adding, deleting, or changing any part of the transaction input and output will invalidate the signature. For details, see: https://www.btcstudy.org/2021/11/09/bitcoin-signature-types-sighash/ ↩
6. https://www.btcstudy.org/2022/08/08/anchor-outputs/ ↩
7. https://bitcoinops.org/en/topics/version-3-transaction-relay/ ↩
8. https://www.btcstudy.org/2024/01/16/an-overview-of-the-cluster-mempool-proposal/ ↩
9. https://www.btcstudy.org/2025/01/07/bitcoin-core-28-wallet-integration-guide/ ↩
10. https://delvingbitcoin.org/t/which-ephemeral-anchor-script-should-lightning-use/1412 ↩
