Expiring HTLCs without free relay

One significant modification is the introduction of a mechanism that allows HTLCs to expire without the need for preimage publication, shifting away from local-mempool monitoring. This change is especially beneficial for setups with limited resources, such as home routers running Utreexo, where mempool data might not be readily available.

A key aspect of these proposals is the enforcement of bit 21 of nSequence in transaction inputs to assign consensus meaning. This enforcement would set a minimum nLockTime based on the BIP68 inclusion height, meaning a transaction could not be included in a block until after a specified number of blocks post-confirmation of its inputs. Furthermore, two additional changes include the enforcement of bit 21 in OP_CSV and the introduction of OP_LOCKTIME. The latter is a tapscript-only opcode that pushes nLockTime onto the stack, aiding in the creation of more secure HTLCs by ensuring refunds if the preimage is not revealed at least 100 blocks before the contract's expiration.

The proposed structure of HTLC involves a two-stage process. Initially, the receiver moves the funds to a staging output using a preimage-gated presigned transaction. Subsequently, spending paths for both the receiver and the offerer are defined, contingent on specific conditions being met within the constraints of BIP68 and the functionalities of the new opcodes. These adjustments aim to address vulnerabilities like the replacement cycling attack, a concern highlighted in Peter Todd’s OP_EXPIRE proposal. Although the new approach does not fully prevent such attacks, it significantly reduces the economic incentives to execute them by assuring guaranteed refunds in scenarios where the preimage is not timely published.

However, this novel approach introduces certain trade-offs, such as limitations on the minimum length of HTLCs, potential liquidity constraints for receivers, and increased transaction costs due to the necessity for multiple transactions. Despite these challenges, the benefits, including reduced vulnerability to specific network attacks and enhanced robustness of node operations in constrained environments, are substantial. These improvements could be pivotal for the broader adoption and functionality of blockchain technology in decentralized financial transactions and smart contracts, thereby enhancing the overall security framework of HTLCs by moving from reliance on mempool-based to chainstate-based monitoring systems.