bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2026-07-06 17:46:00 +00:00
Code Issues Releases Wiki Activity

[trivial] Correct typos across bips

Browse Source 
BIPs 11, 16, 61, 98, 116, 117, 143, 157
This commit is contained in:
Varunram
2018-04-14 11:16:32 +05:30
committed by Luke Dashjr
parent 5415dd806e
commit c3e8379b61
8 changed files with 12 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
bip-0098.mediawiki
View File

@@ -57,8 +57,8 @@ The following image depicts an example unbalanced hash-tree:
'''A''', '''B''', and '''C''' are leaf labels, 32-byte double-SHA256 hashes of the data associated with the leaf.
'''Node''' and '''Root''' are inner nodes, whose labels are fast-SHA256 (defined below) hashes of their respective children's labels.
'''Node''' is labelled with the fast-SHA256 hash of the concatination of '''B''' and '''C'''.
'''Root''' is labelled with the fast-SHA256 hash of the concatination of '''A''' and '''Node''', and is the ''Merkle root'' of the tree.
'''Node''' is labelled with the fast-SHA256 hash of the concatenation of '''B''' and '''C'''.
'''Root''' is labelled with the fast-SHA256 hash of the concatenation of '''A''' and '''Node''', and is the ''Merkle root'' of the tree.
Nodes with single children are not allowed.
The ''double-SHA256'' cryptographic hash function takes an arbitrary-length data as input and produces a 32-byte hash by running the data through the SHA-256 hash function as specified in FIPS 180-4[3], and then running the same hash function again on the 32-byte result, as a protection against length-extension attacks.
@@ -96,7 +96,7 @@ The application of fast-SHA256 to inner node label updates is safe in this limit
so the sorts of attacks prevented by message padding and double-hashing do not apply.
The 'initialization vector' for fast-SHA256 is changed in order to prevent a category of attacks on higher level protocols where a partial collision can serve as both a leaf hash and as an inner node commitment to another leaf hash.
The IV is computed using standard SHA-256 plus midstate extraction so as to preserve compatability with cryptographic library interfaces that do not support custom IVs, at the cost of a 2x performance hit if neither custom IVs nor resuming from midstate are supported.
The IV is computed using standard SHA-256 plus midstate extraction so as to preserve compatibility with cryptographic library interfaces that do not support custom IVs, at the cost of a 2x performance hit if neither custom IVs nor resuming from midstate are supported.
The data hashed is a nothing-up-my-sleeve number that is unlikely to have a known hash preimage.
The prime 23 was chosen as the leading fractional bits of the first eight (8) primes, two (2) through nineteen (19), are constants used in the setup of SHA-256 itself.
Using the next prime in sequence reduces the likelihood of introducing weakness due to reuse of a constant factor.