Published on: 2014-08-08T18:42:35+00:00
During a discussion on the Bitcoin-development mailing list in 2014, several proposals were made to address various issues related to transaction expiration and the use of nLockTime. One suggestion was to add a new IsStandard rule that rejects transactions with an nLockTime more than N blocks behind the current tip. However, it was pointed out that transaction creation time and transaction publish-to-outside-world time are not always the same, so this rule may not be effective in all cases.Another proposal involved setting nLockTime to the current height by default in newly created transactions. This would discourage fee-sniping and help in case of reorg. There was also discussion about implementing a janitor mechanism to purge mempool of transactions more than N blocks behind the current height.In a separate email exchange, there was a debate about whether the transmission of merkle data in transactions is necessary or if it can be derived from the transaction data itself. One participant argued that validators need to know certain information, such as expiry, which is hidden behind the merkle root in the transaction. They questioned how validators could make decisions without this information.The developers also discussed the possibility of creating a new field or parallel transaction format to deal with pre-consensus mempool behavior without requiring a fork or protocol revision. Various ideas were proposed, including creating a "network TX" with digitally signed information that is discarded before reaching miners, and using a merkle radix tree to commit fields in an extensible and provable way. The goal was to avoid changing the existing transaction format in a hard-fork, which was seen as disruptive.There were also discussions about the potential impact of adding an nExpiry field to the transaction format. Some participants argued that it should be included with the transaction as part of the network and on-disk data structures for proper validation, while others suggested packaging it in some sort of envelope container. The efficiency and compatibility of different approaches were debated.Overall, the discussions focused on finding solutions to improve transaction expiration and mempool behavior without causing disruptions or breaking existing functionality. Different ideas and perspectives were presented, highlighting the complexity of implementing changes in the Bitcoin network.The lack of transaction lifetime management in the network's mempools is hindering some mempool exchange. To address this issue, a proposal has been made to add finite and predictable lifespans to transactions in mempools using nLockTime and a new standardness rule. This proposal can be implemented in stages and would not necessarily require a soft fork, avoiding problems with reorgs.The first stage of the proposal involves setting nLockTime to the current height by default in newly created transactions. Once users have upgraded to clients that set nLockTime, transactions without nLockTime will be discouraged, and a slightly higher fee may be required for relay. Relay of transactions without an nLockTime will then be rate-limited, which alone may achieve discouragement.In the next stage, a new IsStandard rule will be added, rejecting transactions with an nLockTime more than N blocks behind the current tip. This means that transactions will stop being relayed and drop out of mempools a fixed number of blocks from their creation. Once that window has passed, the sender's wallet could begin to expect that the transaction will not be confirmed.Despite concerns that someone may circumvent this IsStandard() rule by submitting "expired" transactions directly to miners with suitable policies, a user who needs to get their original "expired" transaction confirmed could still do so by submitting it directly to a miner with suitable policies.Overall, the proposal aims to add transaction lifetime management to the network's mempools to improve mempool exchange. By implementing stages such as setting nLockTime by default, discouraging transactions without nLockTime, rate-limiting relay of such transactions, and adding an IsStandard rule, the proposed solution provides a way to ensure finite and predictable lifespans for transactions.
Updated on: 2023-08-01T10:10:05.905319+00:00