Re: [bitcoin-dev] Combined CTV+APO to minimal TXHASH+CSFS
> > * 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Combined CTV+APO to minimal TXHASH+CSFS
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Combined CTV+APO to minimal TXHASH+CSFS
Hi Brandon, Not going to dive too deep here, just adding a bit of color. > * 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. > ### 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. 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 Best, Greg On Tue, Aug 22, 2023 at 3:04 PM Brandon Black via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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
[bitcoin-dev] Combined CTV+APO to minimal TXHASH+CSFS
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
