Brandon Black [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-22 🗒️ Summary of this message: The text ...
📅 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
🗒️ 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