Subject: Re: [bitcoindev] [3/4] OP_TX

From: Anthony Towns <[email-masked]>
Date: Mon, 6 Oct 2025 21:41:44 +1000

On Sat, Sep 27, 2025 at 08:59:04PM +0930, Rusty Russell wrote:
> ==OP_TX==
>
> OP_TX operates as follows:
>
> Examine bits in ''selection_vector'':
> - For each existing input ''i'' in the range ''first_input'' to ''first_input'' + ''num_inputs'':
>   - If TXSELECT_INPUT_OUTPOINT_HASH is set:
>     - output input ''i''s outpoint hash (32 bytes)
>   - If TXSELECT_INPUT_OUTPOINT_INDEX is set:
>     - output input ''i''s outpoint index (32 bits)

>   - If TXSELECT_INPUT_SCRIPT is set:
>     - output input ''i''s script as a variable size object

I think you should be clearer which "script" this is; it could be
the scriptPubKey (except you have a different selector for that), the
redeemScript from the scriptSig (except we haven't defined taproot outputs
for non-empty scriptSigs), or what this presumably is, ie the tapscript
v2 script from the witness. We have too many things called "script"...

>   - If TXSELECT_INPUT_AMOUNT is set:
>     - output input ''i''s input amount (64 bits)
>   - If TXSELECT_INPUT_SCRIPTPUBKEY is set:
>     - output input ''i''s scriptPubkey as a variable size object

Shouldn't these be named TXSELECT_INPUT_OUTPOINT_{AMOUNT,SCRIPTPUBKEY}
(or COIN or UTXO in place of OUTPOINT) since they are obtained from
outpoint being spent, rather than directly from the input?

I think it would be good to also have a selector:

    TXSELECT_INPUT_OUTPOINT_HEIGHT

which pushes the height of the block at which the coin being spent
was confirmed. (In order to make that not terrible wrt reorgs, it
should also imply somewhere between "6 CHECKSEQUENCEVERIFY" and "100
CHECKSEQUENCEVERIFY")

The benefit of this is that you could then turn a relative timelock
into an absolute one via script. The idea is that this is useful for
eltoo approaches where you may wish to publish a finalisation state to
the blockchain, but may need to update that state to the most recent
one. In an adversarial scenario that can double the delay -- they abort
the off-chain protocol in the middle of updating from state n to n+1,
so that they can complete state n+1 but you can't; publish state n to the
blockchain (or allow you to do so), wait x blocks, then publish state n+1,
and force you to wait another x blocks.

With the ability to update script code (ie, part 4 of this series of
bips), and a "parent height" query, we could programmatically allow
replacing a script's requirement of "X CSV" with a requirement of "[H+X]
CLTV", and instead of requring the n+1 state update to preserve "X CSV",
require it to preserve "[H+X] CLTV" instead. In that case, if you wait
X blocks to publish state n+1, it doesn't cause any additional delay.

(To be explicit: the idea here is that if state finalisation is time
sensitive to you, you pay for an on-chain transaction replacing
the relative timelock with an absolute timelock, so that if your
counterparties later update the state in other ways, the finalisation
doesn't get delayed further no matter what they do)

cf https://delvingbitcoin.org/t/contract-level-relative-timelocks-or-lets-talk-about-ancestry-proofs-and-singletons/1353

Providing TXSELECT_INPUT_OUTPOINT_WAS_COINBASE for completeness might
be worth considering. That could perhaps be useful for allowing things
like drivechains that give miners influence over coin movements to be
redesigned to not require additional consensus support?

Cheers,
aj

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aOOq-Pw0ht_R0OAK%40erisian.com.au.