Input-triggered transaction expiry

The proposal for modifying consensus and policy regarding the handling of timelocks in transactions has prompted a reevaluation of existing Blockchain Improvement Proposals (BIPs), specifically BIP68. The discussion involves two main alternative framings aimed at simplifying the understanding and implementation of these changes.

The first alternative framing proposes an ultra-short explanation that emphasizes the primacy of absolute timelocks as the last to expire, ensuring transactions are deemed invalid if any relative timelock does not activate in time. This proposition narrows the focus to height-based timelocks only and excludes Modified Median Time Past (MTP) based timelocks to prevent potential manipulation by miners concerning timestamps. This approach also suggests a change from the original proposal by removing the 100-block minimum delay and applying the revised rules exclusively to inputs that opt-in using a specific bit, thus minimizing the risk of unintended confiscation while losing cross-input enforcement.

The second framing shifts the focus to transaction confirmations, portraying an inverse measure of time where confirmations for each input are counted backward starting from nLockTime. This method avoids using BIP68 language and does not accommodate time-based relative timelocks, aligning closely with the functionality described in the previous framework but with a stronger emphasis on user intuition concerning transaction progression rather than technical timelock specifications.

Both frameworks share concerns regarding the potential for zero-confirmation inputs to disrupt free relay policies. Proposed solutions include enforcing a minimum one-block delay in consensus or adjusting policy to ensure that fees from parent transactions cover their child transactions, which might otherwise expire due to zero confirmations.

Additionally, a broader perspective was introduced discussing transaction expiry in offline contexts, which could aid users like Alice in understanding transaction conditions better, particularly when approvals are signed without network connectivity.

Conclusively, revising the language used to describe these consensus changes, such as adopting terms like "coin-heights" or "coin-height ceilings," is advocated as a means to make the protocol's temporal aspects more accessible, especially for newcomers. This linguistic adjustment could serve as a third viable approach to refining the consensus mechanism in blockchain protocols.