Published on: 2022-11-07T08:56:17+00:00
In a discussion about the lightning network transaction format, concerns were raised about the challenges introduced by anchor outputs, which require nodes to maintain a reserve of available UTXOs for fee-bumping. This management is complex and requires dynamic risk assessment, as nodes may need to fee-bump thousands of HTLC transactions in a short period of time. One proposed solution is for each node to sign multiple versions of the HTLC transactions at various feerates, allowing pre-signed transactions that match the required feerate, reducing the requirements on the on-chain wallet and simplifying transaction management logic.Bastien Teinturier, the person who raised these concerns, has sent an email to the Lightning-dev mailing list regarding the implementation that needs to be provided. He has also shared three links related to the same on Github. The first link is for a pull request numbered 688, the second link is for an issue numbered 845, and the third link is for another pull request numbered 1036.The updated Lightning Network transaction format leverages CPFP carve-out and anchor outputs, which allow nodes to set fees at broadcast time. However, this change introduces new challenges as it requires nodes to maintain a reserve of available UTXOs for fee-bumping. Managing this fee-bumping reserve involves complex decisions and dynamic risk assessment, as nodes may need to fee-bump thousands of HTLC transactions in worst-case scenarios. Each node can sign multiple versions of the HTLC transactions at different feerates, reducing the need for inputs from their fee bumping reserve. This simplifies transaction management logic and reduces the requirements on the on-chain wallet.While this solution is a pragmatic approach to increase fund safety for existing node operators and wallets, there are limitations to its ability to tackle attacks such as dusty HTLCs. It also introduces complexity. The proposal made by Bastien is currently seeking concept ACKs through a spec PR. It is worth noting that implementations that have already rolled out anchors by default and have a satisfactory policy for ensuring fee bumping UTXOs are available may not need to implement this solution. It is seen as another option defined in the spec, prescribing a more restrictive approach compared to the existing ability to dynamically fee bump commitment transactions and aggregate second level spends.
Updated on: 2023-08-01T00:48:07.937505+00:00