bitcoin-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 blog post addresses the issue of ensuring that a preimage is revealed in a timely manner within the context of blockchain transactions.

It highlights a specific problem where an entity, referred to as Carol, could potentially prevent another party, Bob, from learning about the preimage on time while still allowing Carol the opportunity to use it herself. The solution to this problem rests in a mechanism called OP_Expire, which guarantees that the preimage is either made public on the blockchain promptly or rendered useless.

Further discussion brings up the concept of v3 package relay and its potential problems when compared to the Replace-by-Fee (RBF) protocol. The critique centers on situations where the commitment transaction may not be mined, thus presenting an "obvious problem." The proposed alternative advocates for the use of RBF without anchor outputs, coupled with all outputs being made unspendable through one CheckSequenceVerify (CSV). This approach limits any attacker's freedom to only increasing fees or broadcasting a revoked commitment, which carries the risk of punishment for fraud.

However, a practical challenge arises from the need to sign a set of refund transactions for each fee variant. While signing multiple transactions might be currently manageable, future solutions might involve the use of SIGHASH_NOINPUT or the replacement of the pre-signed refund mechanism with a covenant structure. The author argues that using RBF is more efficient than Child Pays for Parent (CPFP) with package relay, as it doesn't require block space for anchor outputs or their consuming transactions. Special cases where CPFP might be cheaper due to BIP125 rules can be addressed by modifying the replacement relay fee or implementing delta-encoding for transaction updates.

The post concludes by suggesting a soft fork that includes both SIGHASH_NOINPUT and OP_Expire, considering the benefits they could bring to Lightning Network symmetry. For further engagement or queries, readers are directed to reach out to the author, Peter Todd, through his email available on his website petertodd.org.