deterministic transaction expiration



Summary:

The current lack of transaction lifetime management in the network's mempools has been identified as a major factor blocking some mempool exchange. Kaz Wesley proposed a way to add finite and predictable lifespans to transactions in mempools. This can be done by using nLockTime and a new standardness rule, which would not necessarily require even a soft fork, and does not cause problems with reorgs like other proposals. The proposal includes 4 stages: setting nLockTime to the current height by default in newly created transactions, discouraging transactions without nLockTime, rate-limiting relay of transactions without an nLockTime, and adding a new IsStandard rule rejecting transactions with an nLockTime more than N blocks behind the current tip. Transactions would stop being relayed and drop out of mempools a fixed number of blocks from their creation. Once that window had passed, the sender's wallet could begin to expect the transaction would not be confirmed. A miner can still put it back in the blockchain if a reorg displaces a transaction until after its expiry height. A user who needed to get their original "expired" transaction confirmed could still do so by submitting it directly to a miner with suitable policies. It is suggested that introducing a new script opcode that pushes the current block height onto the operand stack would make more sense for implementing arbitrary logic about which blocks the transaction can be valid in. However, this would require that the client revalidate all transactions in its mempool whenever the chain tip changes, but only those making use of this opcode.


Updated on: 2023-06-09T01:45:35.319426+00:00