Published on: 2022-09-26T20:46:37+00:00
The Lightning Network is facing the risk of being mempool-pinned by "ancestor bulking" and "junk pinning" attacks. These attacks can lead to griefing attacks and loss of funds for HTLCs. While anchor outputs were introduced to mitigate junk pinning, splice transactions are still susceptible to both attacks. To address this, a proposed mitigation requires reliable access to the UTXO set.However, this may be problematic for mobile LN clients relying on lightweight validation backends. To address this issue, every tx_add_input proposed by a peer must be included in the UTXO set, and every output included directly in a splice transaction must be a v0 P2SH witness script with a minimum of 1 CSV relative timelock.There are two side effects to consider when implementing these changes. First, splice transactions cannot be CPFP'd (Child-Pays-for-Parent). Second, arbitrary third-party scriptPubKeys are not permissible directly into the splice transaction. For arbitrary splice out funds, they can be included in a "fan-out" transaction.Additionally, new channel outpoints' v0 witness script should start with [OP_1, OP_CHECKSEQUENCEVERIFY]. This modification ensures easy validation and prevents the script from being hidden in a false conditional. Splice-in transactions will not require any fan-out children as long as all change goes into the channel outpoint.The interactive tx protocol mandates that splice transactions are RBF-enabled (Replace-By-Fee), meaning that broadcast splice proposals can be replaced by the original commitment transaction at any time. This, combined with every other output in the tree being locked behind a 1 CSV, ensures that force close will always have top mempool priority, mitigating the risk of "output junk" style pin.Dustin Dettmer and his team have proposed several changes to address the issue of splice pinning in the Lightning Network. These changes include modifying the v0 witness script and verifying the presence of proposed inputs before adding them to the splicing transaction. However, it is noted that this proposal may be problematic for mobile LN clients relying on lightweight validation backends.The conversation also discusses the issue of feerate/total fee pinning and the behavior implemented by Bitcoin Core. The ancestor bulking variant of pinning is mentioned, along with its relevance in different scenarios. Enabling the commit tx bit is noted to be tricky, but an attacker can make a junk tree using the anchor output if the new funding output is not encumbered. However, it can be replaced using RBF since there is one's own commit tx (with anchor) to broadcast.The conversation also mentions a function in bitcoind called PaysMoreThanConflicts, which checks if a transaction pays a higher feerate than the replaced tx. It is clarified that this function is not a BIP125 rule and may lead to issues with high feerate splice transactions at the bottom of the mempool.Overall, the discussion provides insights into various aspects of the Lightning Network, including the risks of mempool pinning, proposed mitigations, and technical details related to Bitcoin transactions. Interested individuals can sign up for updates and participate in discussions through the Lightning-dev mailing list.In summary, the implementation of fan-out transactions using P2WSH outputs is explained, along with the modifications required for new channel outpoints. The changes in the interactive tx protocol, such as including the witness script in the TLV and enabling RBF for splice transactions, are highlighted. The use of anchor outputs and force close scenarios are also explained to ensure effective fee management and prevent issues like "output junk" style pin.
Updated on: 2023-08-01T00:39:07.489334+00:00