lightning-dev

OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

Original Postby Peter Todd

Posted on: November 8, 2023 00:51 UTC

The discussion in the email revolves around a specific technical issue within the realm of blockchain technology, particularly concerning Bitcoin transactions and the challenges associated with them.

The primary focus is on OP_Expire, a proposed solution aimed at preventing scenarios where one party could delay another from learning a crucial piece of transaction information (preimage) while still retaining the ability to use it themselves. OP_Expire addresses this by ensuring that the preimage must be broadcast on the blockchain promptly or it becomes invalid.

The conversation further critiques the v3 package relay system, highlighting its shortcomings compared to alternative methods such as Replace-by-Fee (RBF). The author argues that the v3 package relay with anchors has flaws and suggests that a more robust approach would be to pre-sign RBF replacements. This method involves creating replacement transactions without anchor outputs and making all outputs unspendable with a 1 CSV (CheckSequenceVerify) condition. By doing so, it significantly limits an attacker's options, effectively reducing their capabilities to either increasing the fee or broadcasting a revoked commitment, with the latter risking retribution for fraud.

An additional practical consideration mentioned is the need to sign a set of refund transactions for each variant of the fee, which could potentially be streamlined in the future using solutions like SIGHASH_NOINPUT or covenants to replace the current pre-signed refund transaction mechanism.

Furthermore, the email discusses the efficiency advantages of utilizing RBF over Child Pays for Parent (CPFP) in conjunction with package relay, highlighting that RBF does not require block space for anchor outputs or their spending transactions. Potential improvements to CPFP are also suggested, such as reducing the replacement relay fee or applying delta-encoding to transaction updates.

Lastly, the potential for a soft fork that includes both SIGHASH_NOINPUT and OP_Expire is deemed beneficial, especially as SIGHASH_NOINPUT aligns with the needs of Lightning Network symmetry. For those interested in further details or correspondence, the author can be contacted via the provided email link to Peter Todd's website.