Date: Tue, 22 Aug 2023 13:23:09 -0700
From: Brandon Black <freedom@reardencode.com>
To: Greg Sanders <gsanders87@gmail.com>
Message-ID: <ZOUZLdQUdJetkPaR@console>
Mail-Followup-To: Greg Sanders <gsanders87@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <ZOTqppwATA9HyfND@console>
 <CAB3F3Dvhp-Zznd0USWW=sWh7AFL4OV3KneWTgdqZu5Z1BYYJKg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAB3F3Dvhp-Zznd0USWW=sWh7AFL4OV3KneWTgdqZu5Z1BYYJKg@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Combined CTV+APO to minimal TXHASH+CSFS
Precedence: list

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