From da3837639fd987e5d25a0abb209700c3d7ff55ed Mon Sep 17 00:00:00 2001 From: Orfeas Stefanos Thyfronitis Litos Date: Mon, 25 Nov 2019 16:25:24 +0000 Subject: Typo: max bytes hashed for sig is 210 --- bip-taproot.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-taproot.mediawiki b/bip-taproot.mediawiki index d3e2222..0fa4194 100644 --- a/bip-taproot.mediawiki +++ b/bip-taproot.mediawiki @@ -142,7 +142,7 @@ As the message for signature verification, transaction digest is ''hashTapS ** If the SIGHASH_SINGLE flag is set: *** sha_single_output (32): the SHA256 of the corresponding output in CTxOut format. -The total number of bytes hashed is at most ''211'' (excluding sub-hashes such as `sha_prevouts`)'''What is the number of bytes hashed for the signature hash?''' The total size of the input to ''hashTapSighash'' (excluding the initial 64-byte hash tag) can be computed using the following formula: ''178 - is_anyonecanpay * 52 - is_none * 32 + has_annex * 32''.. Sub-hashes may be cached across signatures of the same transaction. +The total number of bytes hashed is at most ''210'' (excluding sub-hashes such as `sha_prevouts`)'''What is the number of bytes hashed for the signature hash?''' The total size of the input to ''hashTapSighash'' (excluding the initial 64-byte hash tag) can be computed using the following formula: ''178 - is_anyonecanpay * 52 - is_none * 32 + has_annex * 32''.. Sub-hashes may be cached across signatures of the same transaction. In summary, the semantics of the [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143] sighash types remain unchanged, except the following: # The way and order of serialization is changed.'''Why is the serialization in the transaction digest changed?''' Hashes that go into the digest and the digest itself are now computed with a single SHA256 invocation instead of double SHA256. There is no expected security improvement by doubling SHA256 because this only protects against length-extension attacks against SHA256 which are not a concern for transaction digests because there is no secret data. Therefore doubling SHA256 is a waste of resources. The digest computation now follows a logical order with transaction level data first, then input data and output data. This allows to efficiently cache the transaction part of the digest across different inputs using the SHA256 midstate. Additionally, sub-hashes can be skipped when calculating the digest (for example `sha_prevouts` if SIGHASH_ANYONECANPAY is set) instead of setting them to zero and then hashing them as in BIP143. Despite that, collisions are made impossible by committing to the length of the data (implicit in hash_type and spend_type) before the variable length data. -- cgit v1.2.3