bitcoin-dev

Combined summary - CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment

Combined summary - CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment

The current discussions among developers are addressing the fee payment structure within the Lightning Network (LN), focusing on commitment transactions, fairness in fee distribution, and incentives.

It is observed that the channel initiator might not necessarily pay most of the fees, challenging the expectation of 'initiator pays.' Real-world examples have shown that cooperative close failures can occur due to low initial fee rates, necessitating the recipient to use Child Pays for Parent (CPFP) to expedite their transaction.

Proposals such as BIP 118 and BIP 143 seek to modify digital signature hashing, influencing how fees get distributed in LN transactions. The concept of 'initiator pays' is under scrutiny, especially with regard to potential fee-related attacks where an attacker could drain a channel at a low fee-rate time, leaving the victim with high transaction fees. Debates also touch upon the security implications of fee-rate-dependent timelocks (FDTs) which rely on miner honesty, and whether anchor outputs and CPFP are less efficient than Replace-by-Fee (RBF) due to additional block space required for CPFP transactions.

Peter Todd has proposed signing multiple offchain transaction versions with different fee rates to address these issues, although concerns about incentives and party responsibilities for fee payments persist. There is consideration for shared burden in fee payments, potentially requiring contributions from all parties during channel openings, diverging from single-sided funding models.

Moreover, there is an ongoing debate regarding the fair allocation of on-chain fees within channels and the practicality of multiple fee-rate-version transactions in protocols like Poon-Dryja or Decker-Russell-Osuntokun. Discussions cover the management of Hash Time-Locked Contracts (HTLCs), user balance protocols, and CTV-based solutions for exit fees. Proposed ideas include using in-protocol balances to cover fees, ephemeral anchors for exiting users, dual UTXO commitments for incoming users, and fee insurance to facilitate multiple exits through one UTXO. These concepts aim to decrease trust requirements and scale the network effectively.

Michael Folkson discusses the comparison between CTV and RBF, particularly in high fee scenarios, highlighting the limitations of CPFP compared to the efficiency of RBF. He also addresses the implications for LN symmetry and suggests that APO-based LN-Symmetry could enable fee adjustments with channel updates. For further in-depth discussions, individuals can visit the Lightning Development Mailing List and Michael Folkson's YouTube channel.

Critiques of CTV highlight the contradiction of its goal to simplify UTXO management with the possible requirement of additional UTXOs for fee payments. Suggestions include pausing CTV development in favor of new covenant schemes that integrate RBF features to avoid extra UTXOs and enhance on-chain efficiency. Resources related to these topics are available in the Bitcoin Improvement Proposals on GitHub and Peter Todd's review on v3 transactions. Peter Todd's contact information is provided, excluding the last character for security purposes.

Discussion History

0
Peter ToddOriginal Post
January 24, 2024 19:31 UTC
1
January 25, 2024 12:57 UTC
2
January 25, 2024 17:49 UTC
3
January 27, 2024 06:28 UTC
4
January 30, 2024 04:12 UTC
5
January 30, 2024 04:38 UTC
6
January 30, 2024 04:41 UTC
7
January 30, 2024 04:46 UTC
8
January 30, 2024 04:49 UTC
9
January 30, 2024 05:07 UTC
10
January 30, 2024 05:17 UTC
11
January 30, 2024 05:55 UTC
12
January 30, 2024 08:40 UTC