What would be a drawback if sum instead of SHA-256 of amounts was used the TapRoot signature message?
What would be a drawback if sum instead of SHA-256 of amounts was used the TapRoot signature message?
Loading saved threads...
Greg Tonoski BIP-110 Blake2b · External communityPost link
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
.
Quote
Report
1uba · External communityPost link
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.
Quote
Report
Post Reply
Quoted from Forex.com.bd-Editorial External answer — Bitcoin Stack Exchange Author: 1uba Source score (net votes, not local likes): 3 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.
Checking account access…