What would be a drawback if sum instead of SHA-256 of amounts was used the TapRoot signature message?

External question — Bitcoin Stack Exchange Author: Greg Tonoski BIP-110 Blake2b Original post: https://bitcoin.stackexchange.com/questions/130977 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. Would there be any drawback of using sum of amounts instead of SHA-256 of amounts in the TapRoot signature message? There is the sha_amounts (32): the SHA256 of the serialization of all input amounts. specified in the BIP-341: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message . SHA-256 seems more computationally expensive than e.g. sum_amount (8): sum of all input amounts .

External answer — Bitcoin Stack Exchange Author: 1uba Original post: https://bitcoin.stackexchange.com/a/130992 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. Yes. The drawback is that sum_amount would only commit to the total value of all inputs , while sha_amounts commits to the amount of every input in order . For example, these would have the same sum_amount : input A: 9 BTC input B: 1 BTC and: input A: 1 BTC input B: 9 BTC Both sum to 10 BTC, but they produce different sha_amounts . For the specific fee-overpayment problem that BIP341 mentions, a sum would actually be enough, because: fee = sum(inputs) - sum(outputs) So if the signature commits to the total input amount, the host cannot lie about the fee without invalidating the signature. This should also prevent the problem behind CVE-2020-14199. However, a sum would still allow the host to lie about which amount belongs to which input , as long as the total stays unchanged. That matters for offline/hardware signers and collaborative transactions. Taproot also commits to all input scriptPubKey s, so a signer can identify its own inputs. With only sum_amount , it could know which input is its own, but not cryptographically verify the amount assigned to that input. sha_amounts avoids this by committing to the complete ordered list of amounts. The computational difference is very small. Only 8 bytes per input are hashed, and the hash can be computed once and reused for all signatures in the transaction. So sum_amount would be a valid simpler alternative if the only goal was protecting the transaction fee. sha_amounts provides the stronger property of binding each amount to its corresponding input, at very little extra cost. Another possible design would be to hash each input's amount and scriptPubKey together. This was discussed during BIP341 development, but separate hashes were chosen so signers that only need amounts do not also need the scripts.