Input-triggered transaction expiry

In a recent discussion on Bitcoin development, an alternative to coin-height introspection was proposed. Coin-height introspection, while offering a method to control input confirmation heights, is seen as overly powerful for the needs of most applications and brings significant complexity to implementation. This approach requires more extensive changes in the script interpreter, potentially affecting the kernel and other related projects. By contrast, using nSequence and nLockTime allows for enforcing maximum height-caps in a simpler, more streamlined manner. This method aligns with existing time-based validation mechanisms, leveraging transaction identifiers to enforce minimum input heights while scripts can set upper limits.

The proposal also highlights the use of bit 21, which avoids the need for cross-input introspection by enabling expiry or height cap enforcement on any input without additional scripting. This simplifies enforcement and supports uses like presigned key-path spends or commitments via TEMPLATEHASH / CTV. Furthermore, there's a suggestion to reconsider the necessity and length of consensus-enforced delays—currently set at a minimum of 100 blocks—arguing that such requirements might be excessive compared to the actual risk posed by reorgs and double-spends. The idea is put forward that enforcing minimum delays through policy rather than consensus could provide sufficient protection against abuse while allowing flexibility based on network conditions.

Additionally, the discussion touches on the potential for simplifying contract and swap transactions using Hash Time Locked Contracts (HTLCs) with reduced maturity rules. This could lead to contracts that complete in fewer transactions, a particularly advantageous adaptation in environments where transaction fees are high. However, careful design is required to prevent issues like replacement cycling, ensuring security and reliability in these simplified transaction formats. For further insights on designing secure HTLCs that mitigate specific risks, the conversation references a detailed exploration available here.