Brandon Black [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2022-04-28 to 2023-03-13
💬 Posted a total of 4 messages
📚 Participated in the following categories: bitcoin-dev, PROPOSAL
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-08-24 12:13:21

- reply

📅 Original date posted:2023-08-22
🗒️ Summary of this message: The text discusses updates to the OP_CSFS opcode and compares its efficiency to BIP118. It also mentions the possibility of adding an opcode for the taproot inner pubkey and addresses malleability bugs.
📝 Original message:
> > * If the top item on the stack is not a minimally encoded `OP_0`, `OP_1`,
> or
> `OP_2`; succeed immediately[^2].
>
> I presume this was supposed to go to OP_4 now.
Fixed, thanks!
> > ### How does the efficiency compare to [bip118][]?
>
> Just noting BIP118 also allows pubkey of "1" to stand in for the taproot
> inner pubkey, which would be a common use-case. "simply" adding an opcode
> ala OP_INNER_PUBKEY could also have the same effect of course.
Updated the spec for OP_CSFS to replace OP_0 as pubkey with the taproot
internal key. That's a great feature to keep!
> Also, BIP118 also opens the door for non-APO signatures to have a sighash
> digest that commits to additional data, closing a couple of taproot
> malleability bugs. See
> https://github.com/bitcoin-inquisition/bitcoin/issues/19 for more
> discussion along those lines. These aren't make or break, but would be nice
> to clean up if possible
Agreed. If this proposal moves forward, I will carefully consider the
contents of the hash (as shown in the table at the end) for each mode,
and add (or remove) committed data. It might be worth having mode 0
(CTVish) commit to the spend_type and annex as well.
Thanks much,
--Brandon

2023-08-24 12:13:20

- reply

📅 Original date posted:2023-08-22
🗒️ Summary of this message: The author is seeking feedback on a proposal that combines the functionality of bip118 and bip119 while addressing objections and providing clear upgrade paths. The proposal introduces new opcodes and defines methods for hashing transactions and checking signatures. The motivation behind the proposal is to clarify the differences between the two proposals and move towards consensus on improving Bitcoin script development.
📝 Original message:
Hi list,
https://gist.github.com/reardencode/2aa98700b720174598d21989dd46e781
I'm seeking feedback on this proposal to provide the functionality
requested by those advocating for bip118 and bip119 in a combined way
that retains the low risk associated with each of those separate
proposals. At least part of the reason for creating this is similar to
my reason for creating bips PR#1472, and my covenant comparo
spreadsheet, i.e. to help further the discussion of these proposals and
make more clear the similarities and differences between them.
https://github.com/bitcoin/bips/pull/1472
https://docs.google.com/spreadsheets/d/1YL5ttNb6-SHS6-C8-1tHwao1_19zNQ-31YWPAHDZgfo/edit
It's become clear to me that in large part the separation between
advocates of these two proposals stems from a lack of full understanding
of their properties. My hope is that this work helps to clarify our
thinking about them individually and together, and potentially move
toward consensus on a path toward enabling better lightning, vaults, and
likely other amazing ways to use bitcoin in the future.
-----------------------
# Abstract
This proposal is an alternative to [bip119][] and [bip118][], providing the
functionality of both proposals with no additional overhead in [many
cases](#compared-to-non-tapscript-ctv), while clearing certain objections to
both, and opening clear upgrade paths.
This is, in essence, an initially constrained version of Russel O'Connor's
[OP_TXHASH+OP_CSFS proposal][].
We define three new Tapscript-only opcodes. Replacing `OP_SUCCESS80`,
`OP_SUCCESS187`, and `OP_SUCCESS188` with `OP_TXHASH`, `OP_CHECKSIGFROMSTACK`,
and `OP_CHECKSIGFROMSTACKVERIFY` respectively.
# Summary
For `OP_TXHASH`, we define exactly 5 methods of hashing the transaction depending
on a minimally encoded numeric argument popped from the stack:
argument | behavior
-------- | -----------------
0 | as in [bip119][]
1 | as in [bip118][] with sighash flag `0x41`
2 | as in [bip118][] with sighash flag `0xc1`
3 | as in [bip118][] with sighash flag `0x43`
4 | as in [bip118][] with sighash flag `0xc3`
`OP_CHECKSIGFROMSTACK(VERIFY)` is defined similarly to the [implementation in
the Elements project][OP_CHECKSIGFROMSTACK in elements], but does not
internally SHA256 hash the data argument. As [bip340][] defines signatures on
arbitrary length messages, and these `OP_CHECKSIGFROMSTACK(VERIFY)` are
defined only in Tapscript, the internal hashing is unnecessarily restrictive.
Users may wish to use pre-hashed values as in this proposal, or non-SHA256
hashes available in script.
# Motivation
Much ink has been spilled on the discussion of what is next for bitcoin scipt
development. The two proposals nearest to consensus are [bip118][] and
[bip119][], but the proponents of each disagree about the relative priority
and the merrits of the other. Here, we'll briefly outline some of the
objections to each and demonstrate how this proposal reduces those objections.
We will not discuss the concerns about the introduction of covenants or
recursive covenants generally.
## [CTV][bip119] Objections
* Not general enough
* Inefficient when otherwise validating the hash (e.g. when combined with
`OP_CHECKSIGFROMSTACK`)
* Uses `OP_NOPx` extension semantics even though `OP_SUCCESSx` is available
## [APO][bip118] Objections
* Not general enough
* Accidentally enables inefficient, hard to use covenants
* Uses new Tapscript key version to avoid accidents
## Solutions
* By providing the behavior of both [bip118][] and [bip119][], this proposal
is more general than either of those proposals. It also provides explicit
upgrade hooks for further generality (e.g. to
[full OP_TXHASH][OP_TXHASH+OP_CSFS proposal]).
* By splitting the hashing from the validation of [bip119], the hash can be
used in ways other than `OP_EQUALVERIFY`.
* We use `OP_SUCCESSx` upgrade semantics.
* We explicitly enable some of the sighash-based covenants accidentally
enabled by [bip118][].
* By using new signature checking opcodes, we do not require the safety of a
new Tapscript key version.
# Specification
## `OP_TXHASH`
When validating Tapscript, the behavior of `OP_SUCCESS80` is modified as
follows:
* If there is not at least one item on the stack, fail[^1].
* If the top item on the stack is not a minimally encoded `OP_0`, `OP_1`, or
`OP_2`; succeed immediately[^2].
* Pop the top item from the stack, and name it `hash_mode`
* If `hash_mode` is 0:
* Hash the transaction as defined in [bip119][]
* Push the resulting hash to the stack
* If `hash_mode` is 1:
* Hash the transaction as defined in [bip118][] using `sighash_type=0x41`
* Push the resulting hash to the stack
* If `hash_mode` is 2:
* Hash the transaction as defined in [bip118][] using `sighash_type=0xc1`
* Push the resulting hash to the stack
* If `hash_mode` is 3:
* Hash the transaction as defined in [bip118][] using `sighash_type=0x43`
* Push the resulting hash to the stack
* If `hash_mode` is 4:
* Hash the transaction as defined in [bip118][] using `sighash_type=0xc3`
* Push the resulting hash to the stack
## `OP_CHECKSIGFROMSTACK(VERIFY)`
When validating Tapscript, the behavior of `OP_SUCCESS187` and `OP_SUCCESS188`
are modified as follows:
* If there are not at least 3 items on the stack, fail[^1].
* If the top-minus-0 stack item's length is not 32, succeed immediately[^2].
* If the top-minus-2 stack item's length is not 64, fail[^3].
* Pop the top 3 stack items as `pubkey`, `msg`, and `sig` respectively.
* Let `result` equal the result of verifying `sig` against `msg` and `pubkey` according to [bip340][].
* Push `true` if `result` otherwise `false` to the stack.
* If validating `OP_CHECKSIGFROMSTACKVERIFY`
* Pop the top item from the stack as `check`.
* If `check` is not `true`, fail.
# Discussion
### How does the efficiency compare to [bip118][]?
`SIGHASH_ANYPREVOUT`:
```
<64-byte signature>||<1-byte sighash type> <33-byte pubkey> OP_CHECKSIG(VERIFY)
with pushes: 64+1+1 + 33+1 + 1 = 101 witness bytes (25.25vBytes)
```
This proposal:
```
<64-byte signature> <1-byte argument> OP_TXHASH <32-byte pubkey> OP_CHECKSIGFROMSTACK(VERIFY)
with pushes: 64+1 + 1 + 1 + 32+1 + 1 = 101 witness bytes (25.25vBytes)
```
### How does the efficiency compare to [bip119][]?
#### Both in Tapscript
`OP_CHECKTEMPLATEVERIFY` alone:
```
<32-byte hash> OP_CHECKTEMPLATEVERIFY OP_DROP OP_TRUE
with pushes: 32+1 + 1 + 1 + 1 = 36 witness bytes (9vBytes)
```
`OP_CHECKTEMPLATEVERIFY` with a subsequent check:
```
<32-byte hash> OP_CHECKTEMPLATEVERIFY OP_DROP <...>
with pushes: 32+1 + 1 + 1 = 35 witness bytes (8.75vBytes)
```
This proposal:
```
<1-byte argument> OP_TXHASH <32-byte hash> OP_EQUAL(VERIFY)
with pushes: 1 + 1 + 32+1 + 1 = 36 witness bytes (9 vBytes)
```
#### Compared to non-Tapscript CTV
Bare `OP_CHECKTEMPLATEVERIFY`:
```
Lock: <32-byte hash> OP_CHECKTEMPLATEVERIFY OP_DROP OP_TRUE
with pushes: 32+1 + 1 + 1 + 1 = 36 bytes (36vBytes)
Unlock: <empty>
Total: 36 + 0 = 36vBytes
```
Witness v0 CTV:
```
Lock: OP_0 <32-byte hash>
with pushes: 1 + 32+1 = 34 bytes (34 vBytes)
Unlock:
<36-byte witness script>
with sizes: 36+1 = 37 witness bytes (9.25vBytes)
Total: 34 + 9.25 = 43.25vBytes
```
This proposal:
```
Lock: OP_1 <32-byte pubkey>
with pushes: 1 + 32+1 = 34 bytes (34 vBytes)
Unlock:
<36-byte leaf script> <33-byte control block>
with sizes: 36+1 + 33+1 = 71 witness bytes (17.75vBytes)
Total: 34 + 17.75 = 51.75vBytes
```
Compared to bare CTV, this proposal is 15.75vBytes more costly. If CTV use
cases gain popularity, a separate upgrade for bare CTV may be warranted,
either as specified in [bip119][], as its own witness version, or some
alternative.
Bearing in mind the risks mentioned in [bip119][], fee sensitive users can add
`OP_RIPEMD160` to save 2.75 vBytes when using `OP_TXHASH` with
`OP_EQUAL(VERIFY)`. This brings the excess cost relative to bare CTV down to
13vBytes.
### Why not include modes for [bip118][] sighash_types 0x42 and 0xc2?[^4]
Possibly due to a lack of imagination, we are unable to see a use for signing
none of the inputs and none of the outputs (or a single input script and none
of the outputs).
### Can this be used in ln-symmetry?
Yes, this is fully compatible with ln-symmetry. It uses a different script,
but has the same size and behavior as [bip118][] for this purpose.
### Can this be used in PTLCs?
Yes, this is fully compatible with PTLCs. It uses a different script, but has
the same size and behavior as [bip118][] for this purpose.
### Can this be used with OP_VAULT?
Yes, this is fully compatible with OP_VAULT. It uses a different script, but
has the same size and behavior as [bip119][] for this purpose.
# What is hashed?
| field \ mode | CTV(0) | APO/ALL(1) | APOAS/ALL(2) | APO/SINGLE(3) | APOAS/SINGLE(4) |
| ----------------------------------- | ------ | ---------- | ------------ | ------------- | --------------- |
| hash_type | | x | x | x | x |
| version/locktime | x | x | x | x | x |
| this input UTXO | | | | | |
| other input UTXOs | | | | | |
| this script pubkey/amount | | x | | x | |
| other script pubkeys/amounts | | | | | |
| this script sig | x | | | | |
| other script sig | x | | | | |
| the number of inputs | x | | | | |
| this input sequence | x | x | x | x | x |
| other input sequences | x | | | | |
| this input spend type/annex | | x | x | x | x |
| other input spend types/annexes | | | | | |
| corresponding output script/amount | x | x | x | x | x |
| other output scripts/amounts | x | x | x | | |
| the number of outputs | x | | | | |
# Notes
[^1]: We fail on invalid stack lengths to ensure that attackers cannot skip
validation.
[^2]: We succeed on unspecified txhash modes or pubkey lengths to allow future
extensions.
[^3]: We fail on invalid signature lengths _after_ the pubkey length check,
thus allowing only 64-byte signatures for 32-byte keys, but allowing future
key types to potentially also have different signature lengths.
[^4]: As far as we know there is no use for sighash types other than those
defined in [bip118][] with this proposal, as the other types either reduce
to `OP_CHECKSIG(VERIFY)` or create infinite hash loops.
[bip118]: https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
[bip119]: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
[bip340]: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
[OP_TXHASH+OP_CSFS proposal]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
[OP_CHECKSIGFROMSTACK in elements]: https://github.com/ElementsProject/elements/blob/f08447909101bfbbcaf89e382f55c87b2086198a/src/script/interpreter.cpp#L1399
[proposed ln-symmetry scripts]: https://github.com/instagibbs/bolts/blob/eltoo_draft/XX-eltoo-transactions.md
-----------------------
Best,
--Brandon

2023-08-24 12:13:20

- reply

📅 Original date posted:2023-08-22
🗒️ Summary of this message: James O'Beirne's input revealed that CTV is cheaper than initially thought. The proposal is slightly larger than CTV when used together in Tapscript.
📝 Original message:
Quick update to the proposal thanks to James O'Beirne: CTV is 2-bytes
less expensive than I thought when used alone. I thought that script
success required exactly OP_TRUE not just a CastToBool()=true value on
the stack.
This means that my proposal is 2 weight units (0.5vBytes) larger than
CTV when both are used in Tapscript.
--Brandon

2023-08-07 01:37:35

- reply

📅 Original date posted:2023-08-05
🗒️ Summary of this message: The proposal suggests using different byte lengths to encode expiration times in Bitcoin addresses, with varying granularities. The author argues against a fixed granularity and explains the potential degradation over time.
📝 Original message:
On 2023-08-05 (Sat) at 14:06:10 +0000, Peter Todd via bitcoin-dev wrote:
> > bytes | prefix | usable bits | granularity | max expiration
> > ------|------------|-------------|-------------|---------------
> > 1 | 0b0 | 7 | year | 128 years
> > 2 | 0b10 | 14 | week | 315 years
> > 3 | 0b110 | 21 | day | 5700 years
> > 4 | 0b1110 | 28 | block | 5100 years
> > 5 | 0b11110 | 35 | ??? | ???
> > 6 | 0b111110 | 42 | ??? | ???
> > 7 | 0b1111110 | 49 | ??? | ???
> > 8 | 0b11111110 | 56 | ??? | ???
>
> 1) Having the granularity of the limit depend on *when* the limit is to be
> applied in a UX nightmare. It is far simpler to just pick a useful granularity,
> and include enough bytes of integer to work until well into the future. 3
> bytes, 24-bits, of days is 45,000 years. That's plenty.
I must not have explained my proposal clearly. The granularity depends
not on when it is applied, but on the encoding. For example, the bits
0b00000001 encode an expiration 1-year from the epoch of the system. The
bits 0b10000000 10000000 encode an expiration 128 weeks from the epoch.
When decoding, the position of the highest `0` bit in the expiration
indicates the byte-length, and the granularity. If the expiration's
highest bit is `0`, it is 1-byte long, and the bits following the
highest `0` encode a number of years. If the first `0` bit is in the
second highest position, then it is 2-bytes long and the bits following
the highest 0 encode a number of weeks. &c.
> 2) Your suggestion would result in a protocol that degrades over time, as the
> granularity of *newly* created addresses goes up. This isn't like CTV/CLTV,
> where we're creating something now with a limit in the future. 100 years from
> now - if silent payments still exists - people will still want to create silent
> payment addresses that expire, say, 30 days in the future. Your suggestion does
> not allow that.
My suggestion does degrade over time in one sense: if it is still in use
128 years in the future, users are required to start using at least 2
bytes to encode their expiration instead of 1, even if they only need
year granularity. After 315 years they have to start using at least 3
bytes even if they only need week granularity.
I'd rather enable users to encode their expirations in 1 or 2 bytes
today and degrade by requiring more bytes than require 3 bytes now.
Best,
--Brandon

2023-08-05 23:58:15

- reply

📅 Original date posted:2023-08-04
🗒️ Summary of this message: Adding a field to silent payment addresses to encode expiration dates in terms of days after an epoch can fix the risk of non-expiring addresses in Bitcoin. Custom compact encoding can be used for different levels of granularity.
📝 Original message:
I agree. Non-expiring addresses are a significant risk to bitcoin users.
On 2023-08-04 (Fri) at 17:39:03 +0000, Peter Todd via bitcoin-dev wrote:
> Fixing this is easy: add a 3 byte field to silent payments addresses, encoding
> the expiration date in terms of days after some epoch. 2^24 days is 45,000
> years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180
> years. We'll be lucky if Bitcoin still exists in 180 years.
Instead of a fixed width nDays, consider a custom compact encoding with
the position of the first 0-bit indicating the number of extension bytes
and the encoded granularity.
bytes | prefix | usable bits | granularity | max expiration
------|------------|-------------|-------------|---------------
1 | 0b0 | 7 | year | 128 years
2 | 0b10 | 14 | week | 315 years
3 | 0b110 | 21 | day | 5700 years
4 | 0b1110 | 28 | block | 5100 years
5 | 0b11110 | 35 | ??? | ???
6 | 0b111110 | 42 | ??? | ???
7 | 0b1111110 | 49 | ??? | ???
8 | 0b11111110 | 56 | ??? | ???
For address expiration, year or week expiration will typically be
sufficiently granular, but for rare occasions more granularity can be
encoded with longer addresses. This method also degrades cleanly even if
the same address format is still in use in 100 or 300 years.
I included block-based expiration to enable SP users to match CLTVs
embedded in their scripts, e.g.
<2 years> OP_CLTV <recovery_path> OP_VAULT_RECOVER
or
<2 years> OP_CLTV <backup_key> OP_CHECKSIG
Best,
--Brandon

2023-06-08 01:20:08

- reply

📅 Original date posted:2023-03-13
🗒️ Summary of this message: Brandon suggests replacing the internal key with a hardcoded NUMS point to enable batching of multiple vault inputs with the same scriptpubkey.
📝 Original message:Hi Gents,
> > I don't think replacing the internal-public-key makes sense -- if it
> was immediately spendable via the keypath before there's no reason for
> it not to be immediately spendable now.
>
> Slavishly following the current proposal was the idea to make sure all
> functionality was captured; I agree with this change.
I think we do need to replace the internal key with a hardcoded NUMS
point to allow us to batch multiple vault inputs which might have
different internal keys but the same OP_FLU/OP_VAULT_TRIGGER script to
the same time+template-restricted output.
I like that in James' current PR proposal we can explicitly batch via
the implied input/output summation rules while avoiding address reuse.
If we can retain some or all of that, I think it would be good for on
chain efficiency and potentially privacy.
My thoughts on batching:
Many inputs with different internal keys can be combined to satisfy the
total output value for a single output, as long as their scriptpubkeys
with FLU and NUMS internal key are equal This enables avoiding address
reuse within the vault.
Many inputs with the same scriptpubkey can be combined to satisfy a
single CTV output template. This allows a user to unfsck themselves if
they initiate a withdrawal that cannot be satisfied because they didn't
send enough sats to satisfy their template.
Best,
--Brandon

2023-06-08 01:13:03

- reply

📅 Original date posted:2022-08-24
📝 Original message:On 2022-08-24 (Wed) at 11:18:43 +0200, Craig Raw via bitcoin-dev wrote:
> I would like to propose a BIP that specifies a format for the export and
> import of labels from a wallet. While transferring access to funds across
> wallet applications has been made simple through standards such as BIP39,
> wallet labels remain siloed and difficult to extract despite their value,
> particularly in a privacy context.
I like the idea of standardizing the transfer of this valuable
information.
> The proposed format is a simple two column CSV file, with the reference to
> a transaction, address, input or output in the first column, and the label
> in the second column. CSV was chosen for its wide accessibility, especially
> to users without specific technical expertise. Similarly, the CSV file may
> be compressed using the ZIP format, and optionally encrypted using AES.
It seems like the format would be more useful if it also included
descriptors so that a single file could be used to transfer a wallet. I
think such an addition would improve usability for advanced users who
might have many such CSVs to manage, and would then be able to more
easily select between them. Descriptor,Label pairs could also be useful
in the format for the transfer of a wallet with several sub accounts.
Thanks,
--Brandon

2023-06-08 01:09:30

- reply

📅 Original date posted:2022-05-10
📝 Original message:Hi Rusty,
Thanks for this. Seems like a productive direction to explore.
To me, one of the biggest limitations of CTV is that the script is
specific to the amount of the input being spent. OP_TX makes it
possible, although clumsy, to emulate OP_IN_OUT_AMOUNT, which could be
combined with CTV emulation less OPTX_SELECT_OUTPUT_AMOUNT32x2 to allow
a single script to be reused. Given that potential, I wonder if
OPTX_SELECT_IN_OUT_AMOUNT32x2 would be worth adding to the initial set
of flags.
With that addition, a small script can be constructed for a relocatable,
batchable construction (eg. as a building block for vaults):
OPTX_SEPARATELY|OPTX_UNHASHED|OPTX_INPUTNUM OP_TX OP_DUP
OPTX_SELECT_VERSION|
OPTX_SELECT_LOCKTIME|
OPTX_SELECT_INPUT_SINGLE|
OPTX_SELECT_INPUT_SCRIPT|
OPTX_SELECT_INPUT_NSEQUENCE|
OPTX_SELECT_OUTPUT_SINGLE|
OPTX_SELECT_OUTPUT_SCRIPTPUBKEY|
OPTX_SELECT_IN_OUT_AMOUNT32x2 OP_TX <expectedhash> OP_EQUAL
* Additional inputs and change outputs can be added
* Could commit to 0 fee and still be useful
* Arbitrary amounts can be sent to the same script
* There is no txid predictability (unlike CTV)
* Anyone could rearrange such input/output pairs after broadcast
* Not suitable for some uses
* Potentially helpful for others
Best,
--Brandon
On 2022-05-10 (Tue) at 20:05:54 +0930, Rusty Russell via bitcoin-dev wrote:
> Hi all,
>
> TL;DR: a v1 tapscript opcode for generic covenants, but
> OP_SUCCESS unless it's used a-la OP_CHECKTEMPLATEVERIFY. This gives an
> obvious use case, with clean future expansion. OP_NOP4 can be
> repurposed in future as a shortcut, if experience shows that to be a
> useful optimization.
>
> (This proposal builds on Russell O'Connor's TXHASH[1], with Anthony
> Towns' modification via extending the opcode[2]; I also notice on
> re-reading that James Lu had a similar restriction idea[3]).
>
> Details
> -------
>
> OP_TX, when inside v1 tapscript, is followed by 4 bytes of flags.
> Unknown flag patterns are OP_SUCCESS, though for thoroughness some future
> potential uses are documented here. Note that pushing more than 1000
> elements on the stack or an element more than 512 bytes will hit the
> BIP-342 resource limits and fail.
>
> Defined bits
> ------------
>
> (Only those marked with * have to be defined for this soft fork; the
> others can have semantics later).
>
> OPTX_SEPARATELY: treat fields separately (vs concatenating)
> OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before push)
>
> - The first nicely sidesteps the lack of OP_CAT, and the latter allows
> OP_TXHASH semantics (and avoid stack element limits).
>
> OPTX_SELECT_VERSION*: version
> OPTX_SELECT_LOCKTIME*: nLocktime
> OPTX_SELECT_INPUTNUM*: current input number
> OPTX_SELECT_INPUTCOUNT*: number of inputs
> OPTX_SELECT_OUTPUTCOUNT*: number of outputs
>
> OPTX_INPUT_SINGLE: if set, pop input number off stack to apply to
> OPTX_SELECT_INPUT_*, otherwise iterate through all.
> OPTX_SELECT_INPUT_TXID: txid
> OPTX_SELECT_INPUT_OUTNUM: txout index
> OPTX_SELECT_INPUT_NSEQUENCE*: sequence number
> OPTX_SELECT_INPUT_AMOUNT32x2: sats in, as a high-low u31 pair
> OPTX_SELECT_INPUT_SCRIPT*: input scriptsig
> OPTX_SELECT_INPUT_TAPBRANCH: ?
> OPTX_SELECT_INPUT_TAPLEAF: ?
>
> OPTX_OUTPUT_SINGLE: if set, pop input number off stack to apply to
> OPTX_SELECT_OUTPUT_*, otherwise iterate through all.
> OPTX_SELECT_OUTPUT_AMOUNT32x2*: sats out, as a high-low u31 pair
> OPTX_SELECT_OUTPUT_SCRIPTPUBKEY*: output scriptpubkey
>
> OPTX_SELECT_19...OPTX_SELECT_31: future expansion.
>
> OP_CHECKTEMPLATEVERIFY is approximated by the following flags:
> OPTX_SELECT_VERSION
> OPTX_SELECT_LOCKTIME
> OPTX_SELECT_INPUTCOUNT
> OPTX_SELECT_INPUT_SCRIPT
> OPTX_SELECT_INPUT_NSEQUENCE
> OPTX_SELECT_OUTPUTCOUNT
> OPTX_SELECT_OUTPUT_AMOUNT32x2
> OPTX_SELECT_OUTPUT_SCRIPTPUBKEY
> OPTX_SELECT_INPUTNUM
>
> All other flag combinations result in OP_SUCCESS.
>
> Discussion
> ----------
>
> By enumerating exactly what can be committed to, it's absolutely clear
> what is and isn't committed (and what you need to think about!).
>
> The bits which separate concatenation and hashing provide a simple
> mechanism for template-style (i.e. CTV-style) commitments, or for
> programatic treatment of individual elements (e.g. amounts, though the
> two s31 style is awkward: a 64-bit push flag could be added in future).
>
> The lack of double-hashing of scriptsigs and other fields means we
> cannot simply re-use hashing done for SIGHASH_ALL.
>
> The OP_SUCCESS semantic is only valid in tapscript v1, so this does not
> allow covenants for v0 segwit or pre-segwit inputs. If covenants prove
> useful, dedicated opcodes can be provided for those cases (a-la
> OP_CHECKTEMPLATEVERIFY).
>
> Cheers,
> Rusty.
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019819.html
> [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019816.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
--Brandon