From: Anthony Towns <aj@erisian•com.au>
To: Rusty Russell <bitcoin-dev@rustcorp•com.au>
Cc: bitcoindev@googlegroups.com, Julian Moik <julianmoik@gmail•com>
Subject: Re: [bitcoindev] [3/4] OP_TX
Date: Mon, 6 Oct 2025 21:41:44 +1000 [thread overview]
Message-ID: <aOOq-Pw0ht_R0OAK@erisian.com.au> (raw)
In-Reply-To: <87y0q0m8vz.fsf@rustcorp.com.au>
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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aOOq-Pw0ht_R0OAK%40erisian.com.au.
prev parent reply other threads:[~2025-10-06 11:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-27 8:12 [bitcoindev] [0/4] A Bitcoin Scripting Proposal BIP Quartet Rusty Russell
2025-09-27 11:27 ` [bitcoindev] [1/4] Varops Budget For Script Runtime Constraint Rusty Russell
2025-09-27 11:28 ` [bitcoindev] [2/4] Restoration of disabled script functionality (Tapscript v2) Rusty Russell
2025-09-27 11:29 ` [bitcoindev] [3/4] OP_TX Rusty Russell
2025-09-27 11:29 ` [bitcoindev] [4/4] New Opcodes for Tapscript v2 Rusty Russell
2025-09-29 22:55 ` Brandon Black
2025-10-06 11:29 ` Anthony Towns
2025-10-06 11:41 ` Anthony Towns [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aOOq-Pw0ht_R0OAK@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@rustcorp$(echo .)com.au \
--cc=bitcoindev@googlegroups.com \
--cc=julianmoik@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox