Hi all,

On Tuesday, May 5, 2020 3:20 AM, Jonas Nick via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is a reasonable suggestion. Committing to every spent scriptPubKey and
> therefore every element of the TxOut instead of just the amount makes sense
> conceptually. And it would be a small diff (~4 lines + rationale) compared to
> the current bip-taproot version.

I agree.

There have been several steps so far towards making it possible for signers to 
determine whether they can safely sign with just O(1) information per input. 
This was initially attempted in BIP141 (by committing to spent input, to thwart 
the ability to lie about fees to ofline signers), and is improved in the 
current BIP341.

I think the CoinJoin + offline signer model indeed shows that is still 
incomplete, as it is yet another example where a signer may need to be provided 
with the entire creating transaction, which would be very unfortunate.

It's also counter to the model proposed by BIP147 (PSBT) workflows: the 
assumption is effectively already that it is sufficient to provide signers with 
just amount + scriptPubKey of the spent outputs. It feels very natural that 
signatures then indeed also need to commit to all that data; otherwise there 
should be ways that this information can be undetectably wrong.

AJ's approach seems great. It means not increasing the per-signature hashing, 
while retaining the ability to cache information across BIP141/BIP341.

As for coinbaseness and height: these are indeed also things currently kept 
track of in the UTXO set, but I don't think any signer is using this 
information to determine whether to sign or not (which I think is the minimum 
requirement for it to be included in a signature hash, see above). Signing 
height would cripple the ability to spend unconfirmed outputs, or force signers 
to reveal they're doing so (if done through a separate sighash flag) - both of 
which would be undesirable. That leaves coinbaseness, but I think the utility 
is very low.

The only downside is that this potentially slows down review, but I agree with 
earlier comments that it's hard to see how this would hurt. I also think it's 
important to get these things right from the start. Many things inside 
BIP341/BIP342 are extensible with future softforks, but signature hashes for 
key-path spends is not one of them (the set of potential signature hash 
semantics must be committed to directly by the output, so changing them 
requires a new output type - which would be highly unfortunate for fungibility 

Thus, unless there are objections, I'd like to go through with this and make 
the suggested changes.



bitcoin-dev mailing list

Reply via email to