Expiring HTLCs without free relay

The introduction of a mechanism that allows for the expiry of such contracts without the need to publish preimages is a central feature of these changes. This development could significantly reduce the need for local-mempool monitoring, which is particularly advantageous in environments with restricted bandwidth or where mempool availability is limited, such as on devices like home routers running Utreexo.

A notable proposed change includes assigning a specific meaning to bit 21 of nSequence in transaction entries. This adjustment would enforce a minimum nLockTime based on the BIP68 inclusion height, ensuring transactions cannot be included in a block until a predetermined number of blocks have passed since the last confirmation of the transaction inputs. Additionally, the enforcement of bit 21 in OP_CSV and the introduction of a new opcode, OP_LOCKTIME, which is exclusive to tapscript and pushes the nLockTime onto the stack, are suggested. These modifications aim to create a more robust framework for HTLCs by enabling refunds if the necessary preimage is not published at least 100 blocks before the contract's expiry. The structure proposed for these HTLCs involves a two-stage process, where initially the funds are moved to a staging output through a preimage-gated, presigned transaction, followed by defined spending paths for both the receiver and the offerer, contingent on specific conditions set within the BIP68 constraints and the functionalities of the new opcode.

Moreover, these changes address vulnerabilities such as the replacement cycling attack, an issue highlighted in Peter Todd’s OP_EXPIRE proposal. While the proposed solution does not completely prevent such attacks, it reduces the economic incentives for executing them by assuring guaranteed refunds in scenarios where timely preimage publication does not occur. However, this approach also introduces trade-offs including limitations on the minimum length of HTLCs, potential liquidity constraints for receivers, and heightened transaction costs due to the necessity for multiple transactions. Despite these drawbacks, the security benefits from eliminating dependence on local mempool states for preimage monitoring are considered significant.

In addition to these technical enhancements, the proposals reconsider previous mechanisms such as grinding and rebroadcasting, aiming to phase them out in favor of relay-safe expiry methods to mitigate the time-sensitive replacement cycling attacks. Interestingly, a conservative approach has been maintained by incorporating a 100 block delay as per existing protocols, though further reductions in this delay are contemplated to maintain stability in consensus and relay operations. Further insights into these considerations can be found in a discussion by @ajtowns available here.

Overall, these advancements represent a significant shift towards improving the framework governing blockchain transactions, specifically in the context of decentralized financial transactions and smart contracts. By moving away from mempool-based to chainstate-based monitoring, the proposals offer substantial improvements in security and operational robustness, potentially accelerating the broader adoption and utility of blockchain technology in various applications.