# Why hashing twice?

I'm trying to understand the Bitcoin protocol, and sometimes see instructions like this:

The TransactionId is defined by SHA256(SHA256(txbytes))

or

The hash of the public key is generated by performing a SHA256 hash on the public key, and then performing a RIPEMD160 hash on the result, with Big Endian notation. The function could look like this: RIPEMD160(SHA256(pubkey))

For what purpose is the hash calculated twice?

A common rationale for hashing twice is to guard against the length-extension property of the hash (if it has that property, as many hashes before SHA-3 did). For SHA-256, this property allows to compute $$\operatorname{SHA-256}(X\|Y\|Z)$$ knowing $$\operatorname{SHA-256}(X)$$ and the length of $$X$$, for some short $$Y$$ function only of the length of $$X$$, and some arbitrary given $$Z$$ (whatever the unknown $$X$$ might be). This can be a problem, see this question.

Additionally, the rationale of using SHA-256 then RIPEMD-160 might be that:

• A first-preimage attack (ability to invert the hash) on any one of the two hashes is unlikely to break the combination, arguably improving resilience against possible future attacks.
• Because the second hash is shorter than the first, the result is distributed closer to random (a drawback of hashing twice with the same hash is that about a third of the output values are not reached; but this can not be computationally detected).
• It guards against an attack that applies to the same hash iterated twice in some hypothetical proof-of-work protocols; see Yevgeniy Dodis, Thomas Ristenpart, John Steinberger, Stefano Tessaro: To Hash or Not to Hash Again? (In) differentiability Results for H2 and HMAC, in proceedings of Crypto 2012, and my regurgitation.
• It makes it less likely that existing brute-force search gears are suitable; that security-by-novelty works for a short time only, but might give some lead-time to those with advance knowledge of the design decision.
• It is a concise way of specifying a 160-bit hash with these 4 properties and recognizable names that are not tarnished by some collision-resistance attack, as SHA-1 is.

Notice that the second hash has a very short input, thus is fast; for large input of the first and overall hash, the construction is only marginally less efficient than a single hash.

• Great rationale, but I would add that SHA3, the successor of SHA-256, is resistant against length-extension attacks. So in the future such double SHA-256 calculations can perhaps be avoided. Jul 10 '17 at 13:19
• @juhist: I don't know how SHA3 works, but I would assume the that it probably does an internal extra final round of hashing at the end, effectively equivalent to this... is that correct? Jul 11 '17 at 0:15
• @Mehrdad: SHA-3 uses the sponge construction, where the message is first "absorbed" in (at least one) round(s), and the result extracted in (possibly zero) final "squeeze" round(s). Because part of the state (c) is not output, this is inherently immune to length-extension attack, much like SHA-512/256 is.
– fgrieu
Jul 11 '17 at 3:47
• @fgrieu: Ah, yeah, that sounds like they basically add an additional round in the beginning and the end like I expected, so the equivalent is already happening internally anyway. Cool, thanks! Jul 11 '17 at 3:55