bitcoin-dev

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

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

Original Postby ZmnSCPxj

Posted on: January 30, 2024 04:12 UTC

The email from ZmnSCPxj addresses the current and future challenges associated with fee rates in Lightning Network's commitment transactions.

In the existing Poon-Dryja model, each commitment transaction is locked to a specific fee rate, which becomes problematic when there's a divergence between the market fee rate and the last signed fee rate, particularly if one party goes offline for an extended period. This issue persists with the proposed Decker-Russell-Osuntokun model, where update and state transactions also commit to a specific fee rate.

To overcome this challenge, "anchor outputs" have been introduced in what are known as anchor commitments. These allow parties to use Child Pays For Parent (CPFP) transactions to adjust fees. However, anchor outputs increase blockspace usage, presenting a trade-off. An alternative solution by Peter Todd suggests signing multiple versions of offchain transactions at varying fee rates to accommodate fee fluctuations. But this approach could be exploited by parties not responsible for onchain fees, who may prefer using or storing only the highest-fee version, resulting in increased costs for the other party.

Todd's proposal might be more viable if both parties were responsible for onchain fees, possibly requiring joint funding of channels, but fairness in fee distribution remains undefined. Whether fees should be split equally or proportionally to channel balances is unclear. Moreover, the proposal does not account for the complexities of hosting Hashed Time-Locked Contracts (HTLCs), which are nested within channel contracts. The HTLC resolution might necessitate separate transactions and additional multi-feerate considerations, potentially leading to a quadratic increase in the number of required transactions for N different fee rates.