At the end of the day I don't really care that much I just prefer something that doesn't throw taproot in for another review cycle.

A side effect of this proposal is it would seem to make it not possible to produce a signature for a transaction without having access to the inputs. This is limiting for a number of cases where you don't care about that data. There are a litany of use cases where you don't want to have SIGHASH_ALL behavior, and having to sign the scriptpubkeys breaks that. So at the very least it should respect other flags.

I also don't really understand the exact attack. So you submit a transaction to the wallet asking them to sign input 10. They sign. They've committed to the signature being bound to the specific COutpoint and input index, so I don't see how they wouldn't be required to sign a second signature with the other output too? Is there an attack you can describe end-to-end relying on this behavior?

If you look at the TXID hash the vouts are one of the last fields serialized. this makes it possible (at least, I think) to do a midstate proof so that all you are providing is the hash midstate, and the relevant transaction output,  the siblings after, and the locktime. So you get to skip all the input data, the witness data, and most of the output data.

This sort of data can easily go into the proprietary use (maybe becoming well defined if there's a standardization push) area in PSBT, so that hardware devices can get easy access to it. All they have to do to verify is to finalize the hash against that buffer and match to the correct input.


As an alternative proposal, I think you can just make a separate BIP for some new sigash flags that can be reviewed separately from taproot. There's a lot of value in investing in figuring out more granular controls over what the signature hash is you sign, which may have some exciting contracting implications!
--
@JeremyRubin


On Fri, May 1, 2020 at 5:26 AM Greg Sanders via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
For what it's worth this measure had been discussed as a lightweight way of informing offline signers if inputs were segwit or not for malleability analysis reasons. So there's at least a couple direct use-cases it seems. 

On Fri, May 1, 2020, 8:23 AM Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
While I'm not entirely convinced yet that accertaining non-ownership of an input is a robust method of solving the problem here, I also see little reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is already indirectly covered through the outpoints, so it is just a matter of optimization.  Furthermore in the consensus code, the ScriptPubKeys are part of the UTXO data set, and it is already being retrieved as part of the transaction checking process, so it is readily available.

I'm not sure how much my opinion on the topic matters, but I did include this kind of functionality in my design for Simplicity on Elements, and I have been leaning towards adding this kind of functionality in my Bitcoin demo application of Simplicity.

Regarding specifics, I personally think it would be better to keep the hashes of the ScriptPubKeys separate from the hashes of the input values.  This way anyone only interested in input values does not need to wade through what are, in principle, arbitrarily long ScriptPubKeys in order to check the input values (which each fixed size).  To that end, I would also (and independently) propose separating the hashing of the output values from the output ScriptPubKeys in `sha_outputs` so again, applications interested only in summing the values of the outputs (for instance to compute fees) do not have to wade through those arbitrarily long ScriptPubKeys in the outputs.

On Thu, Apr 30, 2020 at 4:22 AM Andrew Kozlik via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi everyone,

In the current draft of BIP-0341 [1] the signature message commits to the scriptPubKey of the output being spent by the input. I propose that the signature message should commit to the scriptPubKeys of *all* transaction inputs.

In certain applications like CoinJoin, a wallet has to deal with transactions containing external inputs. To calculate the actual amount that the user is spending, the wallet needs to reliably determine for each input whether it belongs to the wallet or not. Without such a mechanism an adversary can fool the wallet into displaying incorrect information about the amount being spent, which can result in theft of user funds [2].

In order to ascertain non-ownership of an input which is claimed to be external, the wallet needs the scriptPubKey of the previous output spent by this input. It must acquire the full transaction being spent and verify its hash against that which is given in the outpoint. This is an obstacle in the implementation of lightweight air-gapped wallets and hardware wallets in general. If the signature message would commit to the scriptPubKeys of all transaction inputs, then the wallet would only need to acquire the scriptPubKey of the output being spent without having to acquire and verify the hash of the entire previous transaction. If an attacker would provide an incorrect scriptPubKey, then that would cause the wallet to generate an invalid signature message.

Note that committing only to the scriptPubKey of the output being spent is insufficient for this application, because the scriptPubKeys which are needed to ascertain non-ownership of external inputs are precisely the ones that would not be included in any of the signature messages produced by the wallet.

The obvious way to implement this is to add another hash to the signature message:
sha_scriptPubKeys (32): the SHA256 of the serialization of all scriptPubKeys of the previous outputs spent by this transaction.

Cheers,
Andrew Kozlik

[1] https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev