<p>Prevents some types of attacks.</p>
<p>Satoshi wanted to build something for the ages and was trying to prevent any and all attacks.</p>
<p>See here for details
<a href="https://bitcoin.stackexchange.com/questions/6037/why-are-hashes-in-the-bitcoin-protocol-typically-computed-twice-double-computed">Why are hashes in the bitcoin protocol typically computed twice (double computed)?</a></p>

CC BY-SA 4.0
2021-10-09T16:12:00.617Z
I'm aware of that, but I don't understand what it has to do with checksum. The checksum is there to make sure you copy/type the data correctly, no?
Rony Tesler
CC BY-SA 4.0
2021-10-11T09:34:29.323Z
Ah, ok. Yes, for checksum I don't see it making any sense. Maybe double-sha was a primitive at that point so just used out of habit/convenience. Slightly wasteful if true.
Paul Otto
CC BY-SA 4.0
2021-10-09T16:06:01.367Z
2021-10-09T16:06:01.367Z
Paul Otto
<p>My conjecture is the double hashing everywhere was a red-herring to make us think Satoshi was sloppy, lame and take our focus away from a posited valid use case for the <code>RIPEMD160(SHA256)</code>.</p>
<p>My lengthy and elaborate rationale is in <a href="https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad/112565#112565">my answer</a> on the related question.</p>

CC BY-SA 4.0
2022-02-22T10:18:59.797Z
2022-02-22T10:18:59.797Z
Shelby Moore III
<p>Here's an answer from Zooko in 2011 that explains it is a convention used to &quot;not have to think&quot; about length extension attacks:
<a href="https://crypto.stackexchange.com/questions/779/hashing-or-encrypting-twice-to-increase-security/884#884">https://crypto.stackexchange.com/questions/779/hashing-or-encrypting-twice-to-increase-security/884#884</a></p>

CC BY-SA 4.0
2021-10-10T02:57:13.640Z
An attack here is finding another address with the same hash (thus the same checksum). 1- How can someone use that for his favor? 2- Isn't finding another address with the same checksum, more or less as easy as mining a block?
Rony Tesler
CC BY-SA 4.0
2021-10-11T21:40:02.870Z
Note that length extension attacks _only_ apply when hashing secret data. In the case of hashing public data like addresses or blocks or transactions in Bitcoin, they are irrelevant.
Pieter Wuille
CC BY-SA 4.0
2022-02-22T09:36:15.973Z
I reject the _inconceivable presumption_ that Satoshi did ‘not h̶a̶v̶e̶ ̶t̶o̶ think’ about the impossibility of length extension vulnerabilities in Bitcoin without double hashing. I [conjectured](https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad/112565#112565) another idea instead.
Shelby Moore III
CC BY-SA 4.0
2021-10-09T16:39:50.593Z
2021-10-09T16:39:50.593Z
af7313
<p>Just convention, there’s no possible justification.</p>

CC BY-SA 4.0
2021-10-11T21:20:39.747Z
@af7313 so you agree with this answer?
Rony Tesler
CC BY-SA 4.0
2022-02-22T09:38:06.960Z
I [conjectured](https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad/112565#112565) a possible justification.
Shelby Moore III
CC BY-SA 4.0
2021-10-09T02:36:48.507Z
2021-10-09T02:36:48.507Z
Claris
<p>Satoshi standardized on using double-SHA256 for 32-byte hashes, and SHA256+RIPEMD160 (each once) for 20-byte hashes, presumably because of (likely misguided) concern about certain attacks (like length extension attacks, which only apply when hashing secret data), and then used those everywhere:</p>
<ul>
<li>P2PKH scriptPubKeys use SHA256+RIPEMD160 of the public key</li>
<li>P2PKH address checksums use truncated double-SHA256 of the payload</li>
<li>Transaction hashes (txids) use double-SHA256</li>
<li>Block hashes (and equivalently, proof of work) use double-SHA256</li>
<li>The transaction Merkle tree uses double-SHA256 to compute the next layer.</li>
<li>P2P network packets use truncated double-SHA256 of the payload as checksum.</li>
<li>The message being ECDSA signed to authorize transactions (sighash) is the double-SHA256 hash of a variant of the serialization of a transaction.</li>
</ul>
<p>To the best of my knowledge, none of these use cases actually benefit at all from double hashing.</p>
<p>Later additions at first copied this practice, presumably because the rationale wasn't that well understood, and continuing with the same approach was easiest to convince people was safe:</p>
<ul>
<li>P2SH addresses (<a href="https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki" rel="noreferrer">BIP13</a>) use truncated double-SHA256 as a checksum.</li>
<li>P2SH scriptPubKeys (<a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki" rel="noreferrer">BIP16</a>) use SHA256+RIPEMD160 of the script.</li>
<li>WIF (&quot;wallet import format&quot;) private keys also use truncated double-SHA256 as a checksum.</li>
<li>The same is true for the extended key xpub and xprv formats (<a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki" rel="noreferrer">BIP32</a>). The derivation algorithm for keys there uses <a href="https://en.wikipedia.org/wiki/HMAC" rel="noreferrer">HMAC</a>-SHA512 (which for that purpose is similar to double-SHA512).</li>
<li>P2WPKH scriptPubKeys use SHA256+RIPEMD160 hashes of the public key (<a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="noreferrer">BIP141</a>)</li>
<li>Witness transaction identifiers (wtxids) use double-SHA256 like normal txids do (<a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="noreferrer">BIP141</a>).</li>
<li>The witness Merkle tree uses the same double-SHA256 based hashing as the transaction tree (<a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="noreferrer">BIP141</a>).</li>
<li>The message being ECDSA signed for authorizing witness v0 scripts is the double-SHA256 hash of a different message scheme (<a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki" rel="noreferrer">BIP143</a>).</li>
</ul>
<p>In more modern additions, it is no longer used:</p>
<ul>
<li>P2WSH scriptPubKeys use a <strong>single</strong> SHA256 hash of the public key (<a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="noreferrer">BIP141</a>).</li>
<li>Bech32 and Bech32m address encoding (used for native P2WPKH, P2WSH, and soon, P2TR) addresses use a checksum based on error correction codes, not hashing (<a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="noreferrer">BIP173</a> and <a href="https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki" rel="noreferrer">BIP350</a>).</li>
<li>The upcoming taproot softfork will introduce P2TR scriptPubKeys, which combine public keys and scripts, in a scheme which involves multiple hashing steps, but they are all single-SHA256 (with a tag prefixed to them to guarantee uniquenesss). The same is true for the message being (Schnorr) signed, and the hash inside the signature algorithm. (<a href="https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki" rel="noreferrer">BIP340</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="noreferrer">BIP341</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki" rel="noreferrer">BIP342</a>).</li>
</ul>
<p>In addition, various places where no cryptographically-sized hash is needed have been using other hash functions too:</p>
<ul>
<li>In the (now deprecated) server-side Bloom filtering protocol, <a href="https://en.wikipedia.org/wiki/MurmurHash" rel="noreferrer">MurmurHash3</a> was used to determine filter positions (<a href="https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki" rel="noreferrer">BIP37</a>).</li>
<li>In client-side compact block filtering, <a href="https://en.wikipedia.org/wiki/SipHash" rel="noreferrer">SipHash-2-4</a> is used to determine filter positions (<a href="https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki" rel="noreferrer">BIP158</a>).</li>
<li>In the compact block P2P protocol extension, <a href="https://en.wikipedia.org/wiki/SipHash" rel="noreferrer">SipHash-2-4</a> is used to generate short (48-bit) transaction identifiers (<a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki" rel="noreferrer">BIP152</a>).</li>
</ul>
<p>Disclaimer: I'm a co-author of several proposals mentioned here, and may have forgotten other extensions.</p>

CC BY-SA 4.0
2021-10-11T22:27:49.963Z
Thanks! But why do you say that "none of these use cases actually benefit at all from double hashing"? Double hash does solve the length extension attack, doesn't it?
Rony Tesler
CC BY-SA 4.0
2021-10-11T22:30:57.050Z
Length extension is not relevant for any of these use cases. It applies in settings where someone uses a hash directly as a MAC mechanism to authenticate secret data (proper solutions like HMAC prevent it). All these use cases are hashes of public data.
Pieter Wuille
CC BY-SA 4.0
2022-02-22T09:29:03.060Z
Commendable compendium. My one nitpick is I reject the _inconceivable presumption_ that Satoshi was ‘misguided’ in this understanding of impossibility of length extension vulnerabilities in Bitcoin without double hashing. I [proffered](https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad/112565#112565) another idea instead.
Shelby Moore III
CC BY-SA 4.0
2021-10-11T21:57:09.980Z
2021-10-13T13:55:45.360Z
2021-10-13T13:55:45.360Z
Pieter Wuille
<p>From '<a href="https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch04.asciidoc#base58alphabet" rel="noreferrer">Mastering bitcoin</a>' -</p>
<pre><code>checksum = SHA256(SHA256(prefix+data))
</code></pre>
<p>The 'data' is, for example, an address, which was calculated using SHA256 and then RIPEMD160.
Why do we need double hashing when calculating the checksum?</p>

<sha256><checksum><mastering-bitcoin>
checksum = SHA256(SHA256(prefix+data)) - why double hashing?
Rony Tesler
# checksum = SHA256(SHA256(prefix+data)) - why double hashing?

(Asked by: username_0 on 2021-10-09)

From '[Mastering bitcoin](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch04.asciidoc#base58alphabet)' -

```
checksum = SHA256(SHA256(prefix+data))

```

The 'data' is, for example, an address, which was calculated using SHA256 and then RIPEMD160.
Why do we need double hashing when calculating the checksum?

**Tags:** sha256, checksum, mastering-bitcoin


---

## 5 answers

### Answer by username_4 on 2021-10-11. Score: 14 | Accepted answer

Satoshi standardized on using double-SHA256 for 32-byte hashes, and SHA256+RIPEMD160 (each once) for 20-byte hashes, presumably because of (likely misguided) concern about certain attacks (like length extension attacks, which only apply when hashing secret data), and then used those everywhere:

* P2PKH scriptPubKeys use SHA256+RIPEMD160 of the public key
* P2PKH address checksums use truncated double-SHA256 of the payload
* Transaction hashes (txids) use double-SHA256
* Block hashes (and equivalently, proof of work) use double-SHA256
* The transaction Merkle tree uses double-SHA256 to compute the next layer.
* P2P network packets use truncated double-SHA256 of the payload as checksum.
* The message being ECDSA signed to authorize transactions (sighash) is the double-SHA256 hash of a variant of the serialization of a transaction.

To the best of my knowledge, none of these use cases actually benefit at all from double hashing.

Later additions at first copied this practice, presumably because the rationale wasn't that well understood, and continuing with the same approach was easiest to convince people was safe:

* P2SH addresses ([BIP13](https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki)) use truncated double-SHA256 as a checksum.
* P2SH scriptPubKeys ([BIP16](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki)) use SHA256+RIPEMD160 of the script.
* WIF ("wallet import format") private keys also use truncated double-SHA256 as a checksum.
* The same is true for the extended key xpub and xprv formats ([BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)). The derivation algorithm for keys there uses [HMAC](https://en.wikipedia.org/wiki/HMAC)-SHA512 (which for that purpose is similar to double-SHA512).
* P2WPKH scriptPubKeys use SHA256+RIPEMD160 hashes of the public key ([BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki))
* Witness transaction identifiers (wtxids) use double-SHA256 like normal txids do ([BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)).
* The witness Merkle tree uses the same double-SHA256 based hashing as the transaction tree ([BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)).
* The message being ECDSA signed for authorizing witness v0 scripts is the double-SHA256 hash of a different message scheme ([BIP143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki)).

In more modern additions, it is no longer used:

* P2WSH scriptPubKeys use a **single** SHA256 hash of the public key ([BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)).
* Bech32 and Bech32m address encoding (used for native P2WPKH, P2WSH, and soon, P2TR) addresses use a checksum based on error correction codes, not hashing ([BIP173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) and [BIP350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)).
* The upcoming taproot softfork will introduce P2TR scriptPubKeys, which combine public keys and scripts, in a scheme which involves multiple hashing steps, but they are all single-SHA256 (with a tag prefixed to them to guarantee uniquenesss). The same is true for the message being (Schnorr) signed, and the hash inside the signature algorithm. ([BIP340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki), [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki), [BIP342](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki)).

In addition, various places where no cryptographically-sized hash is needed have been using other hash functions too:

* In the (now deprecated) server-side Bloom filtering protocol, [MurmurHash3](https://en.wikipedia.org/wiki/MurmurHash) was used to determine filter positions ([BIP37](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki)).
* In client-side compact block filtering, [SipHash-2-4](https://en.wikipedia.org/wiki/SipHash) is used to determine filter positions ([BIP158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki)).
* In the compact block P2P protocol extension, [SipHash-2-4](https://en.wikipedia.org/wiki/SipHash) is used to generate short (48-bit) transaction identifiers ([BIP152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki)).

Disclaimer: I'm a co-author of several proposals mentioned here, and may have forgotten other extensions.

> **Comments:**
> **username_0**: Thanks! But why do you say that "none of these use cases actually benefit at all from double hashing"? Double hash does solve the length extension attack, doesn't it?  
> **username_4**: Length extension is not relevant for any of these use cases. It applies in settings where someone uses a hash directly as a MAC mechanism to authenticate secret data (proper solutions like HMAC prevent it). All these use cases are hashes of public data.  
> **username_2**: Commendable compendium. My one nitpick is I reject the _inconceivable presumption_ that Satoshi was ‘misguided’ in this understanding of impossibility of length extension vulnerabilities in Bitcoin without double hashing. I [proffered](https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad/112565#112565) another idea instead.  

---

### Answer by username_1 on 2021-10-09. Score: 1

Prevents some types of attacks.

Satoshi wanted to build something for the ages and was trying to prevent any and all attacks.

See here for details
[Why are hashes in the bitcoin protocol typically computed twice (double computed)?](https://bitcoin.stackexchange.com/questions/6037/why-are-hashes-in-the-bitcoin-protocol-typically-computed-twice-double-computed)

> **Comments:**
> **username_0**: I'm aware of that, but I don't understand what it has to do with checksum. The checksum is there to make sure you copy/type the data correctly, no?  
> **username_1**: Ah, ok. Yes, for checksum I don't see it making any sense. Maybe double-sha was a primitive at that point so just used out of habit/convenience. Slightly wasteful if true.  

---

### Answer by username_2 on 2022-02-22. Score: 0

My conjecture is the double hashing everywhere was a red-herring to make us think Satoshi was sloppy, lame and take our focus away from a posited valid use case for the `RIPEMD160(SHA256)`.

My lengthy and elaborate rationale is in [my answer](https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad/112565#112565) on the related question.


---

### Answer by username_3 on 2021-10-09. Score: 0

Here's an answer from Zooko in 2011 that explains it is a convention used to "not have to think" about length extension attacks:
<https://crypto.stackexchange.com/questions/779/hashing-or-encrypting-twice-to-increase-security/884#884>

> **Comments:**
> **username_0**: An attack here is finding another address with the same hash (thus the same checksum). 1- How can someone use that for his favor? 2- Isn't finding another address with the same checksum, more or less as easy as mining a block?  
> **username_4**: Note that length extension attacks _only_ apply when hashing secret data. In the case of hashing public data like addresses or blocks or transactions in Bitcoin, they are irrelevant.  
> **username_2**: I reject the _inconceivable presumption_ that Satoshi did ‘not h̶a̶v̶e̶ ̶t̶o̶ think’ about the impossibility of length extension vulnerabilities in Bitcoin without double hashing. I [conjectured](https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad/112565#112565) another idea instead.  

---

### Answer by username_5 on 2021-10-09. Score: -2

Just convention, there’s no possible justification.

> **Comments:**
> **username_0**: @username_3 so you agree with this answer?  
> **username_2**: I [conjectured](https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad/112565#112565) a possible justification.  

---

