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
