What are the reasons to avoid spend-paths that become invalid over time (without a transaction)?

Question

I have been told that a spend-path that expires is something bitcoin designers have explicitly avoided, and that it would cause bad reorg behavior (eg here).

To be clear about what I mean by an expiring spend-path, imagine a script opcode that require that a particular spend-path be executed before a timelock has expired (rather than the usual timelock where the spend-path is only valid after the timelock expires).

Satoshi mentioned this kind of thing here saying that:

"In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block. The OP_BLOCKNUMBER transaction and all its dependants would become invalid. This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction."

However, if you wait for 6 confirmations, no transactions should be happening that expect to have actually received the coins if, say, a transaction is sent with only one or two confirmations. If that happened, a reorg after 3 confirmations would invalidate those transactions too. And a reorg after more than 6 confirmations is statistically impossible unless a 51% attack is underway. So I don't understand satoshi's point here.

I was also told that during a reorg, nodes don't have to re-evaluate transactions that have already been validated, but if an expiring spend-path then you would have to re-evaluate transactions. However, don't' nodes have to re-evaluate transactions in a reorg anyways currently? Since the re-org could have introduced double-spending transactions, all transactions need to be rechecked in the new UTXO context, don't they?

I was further told that there are "a whole bunch of other reasons". I'm curious what they are, but I haven't been able to find much discussion of these things by searching for "bitcoin monotonic" and "bitcoin context free". I would very much appreciate links to more information about these issues.

Answer 1

It seems the objections are primarily:

• Potential spam risk, where a spammer might be able to broadcast a transaction that expires soon (as soon as 1 block) with a fee too low to be included in the next block, wait until it expires, then broadcasts again.
• Mempool complexity. Since transactions can expire, additional logic would be needed to keep track of this and evaluate transactions for eviction from the mempool and whether they're worth rebroadcasting at all.
• Reorg safety issues, where a transaction confirmed just before it expires might be excluded in a reorg that orphans that block, and the transaction would be unable to be included in that alternate chain that becomes the main chain.
  • There is a risk that this could be abused by a malicious actor who pays victims who accept single-confirmation transactions as payment, with transactions that expire soon in the hopes that a reorg will reverse the transaction after they receive whatever they bought with the payment.
  • There is also the risk that child transactions are created using the expiring-soon UTXO, and that a reorg invalidates those transactions as well.

These seem like solvable issues, but regardless, these are the risks / potential issues I've come across.