> > * 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
