Input-triggered transaction expiry

In the discussion surrounding Bitcoin transaction protocols, a nuanced differentiation is brought up between traditional expiry proposals and an innovative approach concerning transaction validation relative to confirmation times. Traditional methods deem a transaction invalid post a specific event, whereas the new methodology suggests a transaction path becomes invalid if confirmed after a certain time threshold. This novel perspective aligns with previously discussed concepts in the OP_TX thread on bitcoindev, where the ability to introspect the confirmation height of a coin was proposed approximately eight months ago.

Introspecting the commit height could be achieved simply by scripting 'OP_TX LESSTHANOREQUAL VERIFY', which presents a straightforward method to replicate much of the functionality proposed by combining nSequence and nLockTime. Furthermore, this feature facilitates parent height introspection, ensuring transactions comply with historical mining data—specifically confirming that a parent transaction was mined before a predetermined block height.

The debate extends to the necessity and rationale behind setting a consensus-enforced minimum delay for transactions, notably in non-coinbase outputs. While a 100-block delay might be justifiable for coinbase transactions due to their direct payment to miners—who influence blockchain reorganizations—the same cannot be said with certainty for standard transactions. The argument posits that imposing such delays on regular transactions does not substantially mitigate risks associated with blockchain reorganizations compared to the risks posed by possible double-spending activities. Here, varying opinions emerge on whether shorter delays like 50, 20, 10, or even as low as 6 blocks might suffice, questioning the balance between security against reorgs and transaction fluidity.