6

Transactions with low fees may remain in the mempool for as long as 14 days. This indeterminism is a source of confusion for users and wallets. It's not possible to cause a transaction in the mempool to expire (become invalid) at a certain time in the future, if not yet mined.

Allowing a transaction to specify a block height after which it cannot be mined would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent. This would allow a payment to be re-attempted without having to wait up to 14 days and without having to satisfy the BIP125 rules or submitting a CPFP transaction. This would also have the advantage of optimizing mempool performance by removing transactions that are no longer desired or that may not be mined.

Adding this functionality today would probably require a hard fork, but why didn't the protocol initially provide this feature?

1 Answer 1

9

This question was answered by Satoshi. My attempt to paraphrase: Suppose a transaction T specified an expiration height, X, and was mined in block X. Then its outputs were spent, possibly many times over through multiple generations (the original transaction had, for example, great-great-grandchildren). Now a reorg occurs and there's a new version of the block at height X that doesn't include T.

Most (now unconfirmed) transactions are simply re-mined in the new branch, possibly at different block heights than before. But T can't be re-mined, since it is now invalid (it has expired), as are all of its descendants. As Satoshi puts it,

This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.

It's true that any reorg can cause previously-mined transactions to never be mined. But such double-spending would likely require malicious intent -- a 51% attack by miners, rather than, say, an innocuous temporary network partition.

It would be bad if this scenario (a previously-mined transaction is un-mined and then expires) could happen routinely because it would make payments less certain and would give payment receivers an incentive to verify the provenance of the coins they're being paid with, lest they be from a recent-expiring transaction. This is similar to the motivation for the 100 block coinbase maturation consensus rule.

1
  • 4
    And, importantly, this type of scenario where there's confusion about the final state of a transaction is precisely what this change would be intended to prevent. And, worse, this would be confusion about a transaction that some parties thought was confirmed. If a fix creates a worse version of the very problem it's intended to fix, it's not a very good fix. Jan 27 at 1:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.