Input-triggered transaction expiry

[josh]

@ajtowns

I think it’s worth comparing this to a generic ability to introspect the confirmation height of the coin being spent; I proposed that in the OP_TX thread on bitcoindev 8 months or so ago.

Thanks for sharing - I missed your post on the mailing list.

Agreed. Coin-height introspection enables similar behavior and is a good comparison.

Here are a few reasons why I think coin-height introspection is less-than-ideal:

• More powerful than needed: The fundamental capability we care about is an absolute cap on an input’s confirmation height. Coin-height introspection enables other behavior, like a minimum or exact confirmation height.

• Non-trivial implementation: Whereas the described approach requires a single if-statement in tx_verify.cpp, coin-height introspection would be a much more involved change, which exposes new context to the script interpreter, with downstream implications for the kernel and kernel-dependent projects.

  • Comment: I’d emphasize that the described approach uses the same design pattern as existing time-based validation. With an absolute timelock, the txid enforces a transaction min-height, and script enforces a minimum min-height. The analogy here is that the txid enforces an input height-cap. Using nSequence and nLockTime introspection, script can then enforce a maximum height-cap.

• No cross-input introspection: Bit 21 can enforce an expiry / height cap on any input, without introducing cross-input introspection in the script interpreter. Replicating this capability purely in script would require cross-input introspection.

• Scriptless enforcement: With bit 21, we get scriptless enforcement, allowing usage in a presigned key-path spend or a TEMPLATEHASH / CTV commitment.

@ajtowns

You can somewhat do parent height introspection with this feature, in that 100 CSV 900100 CLTV will verify that the parent was mined prior to block 900000, if nSequence bit 21 is also set.

(Edited) That’s correct, provided nSequence bit 21 is committed to outside of CSV.

@ajtowns

I don’t see a strong argument for why the consensus-enforced minimum delay here should be 100 blocks rather than 50, 20, 10, 6 or even 1 – for coinbase outputs that makes some sense; coinbases pay directly to miners who are ultimately responsible for whether we see extensive reorgs or not, but for individual transactions, I don’t think this creates a significantly bigger risk in regards to reorgs than regular double-spends.

I’m open to removing the consensus-enforced minimum delay and enforcing a minimum delay in policy. Policy-only enforcement is sufficient to prevent free relay and can be adjusted if needed, depending on network conditions.

The only reason I see to set a minimum delay in consensus is to proactively protect users from double spends. But it’s not clear to me if that responsibility lies with the receiving user or with the protocol. I believe it lies with the user, since they are responsible for waiting for confirmations.

@cmp_ancp

An use case i find interesting is to cut steps on contracts and swaps.

If a contract uses HTLCs and end up with a privkey handover, then the other party already have access to the musig, however, today we need a final tx in order to be certain that no HTLC will be published onchain in the future. With HTLC expiration, we can make swaps 1 tx long, something that can be useful in a high fee environment.

Thanks for pointing this out. I agree, shorter HTLCs is an interesting primitive, which deserves exploration. This capability is contingent, however, on a reduced maturity rule (see comment above).

The only thing I’d highlight is that you need to carefully design the HTLC so that the receiver is immune to replacement cycling (see this construction).