Why does Bitcoin core use SHA256d instead of single SHA256 for PoW?

[Comeacross]

While going through bitcoin/src/pow.cpp in Core v28, I noticed that GetPoWHash() still uses SHA256d (SHA256(SHA256(block_header))).This made me wonder why Satoshi didn’t simply use single SHA256. I understand double hashing defends against length-extension attacks but single SHA256 already offers full 256-bit preimage resistance which is what PoW mainly needs.

My questions are:
Was SHA256d chosen primarily for protection against length-extension attacks, or were there other reasons in 2008/2009 (extra security margin, protocol consistency, caution about unknown weaknesses, etc.)?

From a performance perspective, double hashing adds roughly 2x the hashing work for miners. Has there ever been any serious Core dev discussion (or old Satoshi-era discussion) about switching to single SHA256 or SHA256+HMAC in a hypothetical future hard fork? Or is SHA256d now considered an immutable part of Bitcoin’s consensus/security model?

Are there any known practical attacks that work on single SHA256 but are defeated (or meaningfully hindered) by SHA256d specifically in the Bitcoin mining/PoW context?

I’ve searched BIP docs, the Bitcoin wiki, and older threads but haven’t found a definitive answer from Satoshi or early devs. So I would appreciate input from anyone familiar with the early source decisions or relevant cryptography papers.

[nc50lc]

My questions are:
Was SHA256d chosen primarily for protection against length-extension attacks, or were there other reasons in 2008/2009 (extra security margin, protocol consistency, caution about unknown weaknesses, etc.)?

There have been some discussions without any conclusion since only satoshi himself can accurately answer this.

Check these threads for example:

• /index.php?topic=928202.0
• /index.php?topic=45456.0

The latter contains a link to an older semi-related topic with a reply from satoshi that didn't directly answer your question but can be used to guess it.

[stwenhao]

This made me wonder why Satoshi didn’t simply use single SHA256.

Because of length extension attacks.

but single SHA256 already offers full 256-bit preimage resistance which is what PoW mainly needs

Of course. But the same hashing is used in other places: in transaction hashing, during computing sighashes, when creating merkle trees, and so on. Satoshi simply created it once, and reused everywhere.

were there other reasons in 2008/2009

Not really, Satoshi just created some code, which was convienient to implement, and that was it. For the same reason, block hashes are little endian: it is not necessary to change endianness, and they could be written as big endian numbers as well, but because x86 machines were little endian, and because big number implementation from OpenSSL stored them as such, he simply didn't convert it to big endian, because it was not needed.

So, a lot of things don't have that much justification, other than how easy it was to implement it.

From a performance perspective, double hashing adds roughly 2x the hashing work for miners.

Satoshi didn't care that much about mining performance, for example because nonces in block headers have only 32 bits. If he would care, then additional bits, for example from the previous block hash, would be used instead. But it is, what it is, which is why miners tweak block versions and timestamps, to get more speedup, even if it would be better, when they would just change expanded nonce instead.

He was just a CPU miner. He mainly tested, that mining works correctly, and he stopped mining, when the rest of the network started using GPUs, FPGAs, or ASICs, to reach better performance.

switching to single SHA256 or SHA256+HMAC in a hypothetical future hard fork?

If people will ever switch, then probably to SHA-3, or a completely different hash function, but only if SHA-256 will be broken. If not, then it will stay, as it is.

As a developer, you can always change the mining algorithm, just like a lot of altcoins did, but it would deprecate all of that hardware, which was created specifically for double SHA-256. And there is no reason to do that, as long as SHA-256 works fine.

[Comeacross]

Not really, Satoshi just created some code, which was convienient to implement, and that was it. For the same reason, block hashes are little endian: it is not necessary to change endianness, and they could be written as big endian numbers as well, but because x86 machines were little endian, and because big number implementation from OpenSSL stored them as such, he simply didn't convert it to big endian, because it was not needed.

So, a lot of things don't have that much justification, other than how easy it was to implement it.

Thank you. But following this logic, do you think SHA256d fall under convenience category as little endian block hashes? Or was double hash more deliberate security choice? I'm asking this because length extension attacks were already known earlier from Merkel Damgard construction. So I wonder if Satoshi picked SHA256d specifically to avoid that attack or it was just a copy/paste from openSSL examples.

And there is no reason to do that, as long as SHA-256 works fine.

Of course, there is no reason to change it while it's still secured but I was just trying to understand if it was just for convenience or both for convenience and caution.

There have been some discussions without any conclusion since only satoshi himself can accurately answer this.

Check these threads for example:

• /index.php?topic=928202.0
• /index.php?topic=45456.0

The latter contains a link to an older semi-related topic with a reply from satoshi that didn't directly answer your question but can be used to guess it.

Thank you for the links. Unfortunately I didn't see Satoshi reply in any of the threads you mentioned. Maybe it's deleted? 

Whatever the case maybe, we are all just inferring since there is no direct confirmation from Satoshi himself.

[stwenhao]

do you think SHA256d fall under convenience category as little endian block hashes?

I think so. You can try to compile the old Satoshi's client, and try to implement some things differently and see, how much harder it would be. In general, only Satoshi knows for sure, but by re-writing some code, you can confirm or reject some explanations.

Also, if you check timestamps, then you can easily notice, that the first prototype could even use SHA-1, just like HashCash did.

Unfortunately I didn't see Satoshi reply in any of the threads you mentioned. Maybe it's deleted?

SHA256 is not like the step from 128 bit to 160 bit.

To use an analogy, it's more like the step from 32-bit to 64-bit address space.  We quickly ran out of address space with 16-bit computers, we ran out of address space with 32-bit computers at 4GB, that doesn't mean we're going to run out again with 64-bit anytime soon.

SHA256 is not going to be broken by Moore's law computational improvements in our lifetimes.  If it's going to get broken, it'll be by some breakthrough cracking method.  An attack that could so thoroughly vanquish SHA256 to bring it within computationally tractable range has a good chance of clobbering SHA512 too.

If we see a weakness in SHA256 coming gradually, we can transition to a new hash function after a certain block number.  Everyone would have to upgrade their software by that block number.  The new software would keep a new hash of all the old blocks to make sure they're not replaced with another block with the same old hash.

[d5000]

From a performance perspective, double hashing adds roughly 2x the hashing work for miners.

This isn't really relevant because of the difficulty mechanism. If hashing (=mining) was only half as difficult, then with the same hardware you would generate two times as many hashes, and the difficulty would increase as a consequence, leading to roughly the same performance as before.

The performance aspect could have some minimal effect in other situations where SHA256d is used, but not in mining.

[nc50lc]

The latter contains a link to an older semi-related topic with a reply from satoshi that didn't directly answer your question but can be used to guess it.

Thank you for the links. Unfortunately I didn't see Satoshi reply in any of the threads you mentioned. Maybe it's deleted? 

Its link is quite hidden as a clickable "this thread" text in the second topic's OP.
stwenhao already quoted it but to get the full picture, I recommend you to read the thread.

[Ceemv22]

Satoshi just created some code, which was convienient to implement, and that was it.

i think that framing is the most accurate and id add a bit of precision to the length extension point because its often stated in a slightly misleading way

length extension is only an actual security problem when the hash is used as a secret prefix MAC for example, something like MAC = H (secret || message). knowing H (secret || message) + the length lets an attacker compute H (secret || message || padding || extension) and forge a valid tag without ever knowing the secret. that's the scenario the attack breaks

btc never uses SHA256 that way. everything it hashes, block headers, tx, Merkle nodes, is fully public data with no secret prefix. if you length extend a block header hash, all you get is the hash of a different, invalid header; nothing is being authenticated, so nothing is forged.

[satashi_nokamato]

Actually with a single hash you could find some shortcuts in mining, but when you double it,  finding ways to cheat mining become harder because the final hash depends on a 64 bit input.  There are some tweaks to the non 64 bit input which would make it possible to find new blocks faster.  Besides,  it's called proof of work,  not to mention it greatly helps against collision finding attacks.

[n0nce]

As a developer, you can always change the mining algorithm, just like a lot of altcoins did, but it would deprecate all of that hardware, which was created specifically for double SHA-256. And there is no reason to do that, as long as SHA-256 works fine.

If we see a weakness in SHA256 coming gradually, we can transition to a new hash function after a certain block number.  Everyone would have to upgrade their software by that block number.

I'd like to emphasize replacing the algorithm would necessitate replacing all mining hardware.
In big parts thanks to the open-source miner movement around Bitaxe, we know what interfaces the latest generations of mining-ASICs provide.
There is no way to let the device hash something just once; you send it 'work' (job_packet) and receive an asic_result with the following fields. In essence, you can only send the data to be hashed and receive the nonce and an ID for further processing. The ASIC does everything else by itself: double-hashing, rolling the nonce, checking that the hash matches the configured difficulty.

typedef struct __attribute__((__packed__))
{
    uint32_t nonce;                   // 2-5
    uint8_t midstate_num;             // 6
    uint8_t id;                       // 7
} bm1397_asic_result_job_t;

typedef struct __attribute__((__packed__))
{
    uint32_t value;                   // 2-5
    uint8_t asic_address;             // 6
    uint8_t register_address;         // 7
} bm1397_asic_result_cmd_t;

typedef struct __attribute__((__packed__))
{
    uint16_t preamble;                // 0-1
    union {
        bm1397_asic_result_job_t job; // 2-7
        bm1397_asic_result_cmd_t cmd; // 2-7
    };
    uint8_t crc             : 5;      // 8:0-5
    uint8_t                 : 2;      // 8:6-7
    uint8_t is_job_response : 1;      // 8:8
} bm1397_asic_result_t;

[Mia Chloe]

~snip

Well as far as i know I don't  think there was actually an official explanation from Satoshi but I think the common view is that SHA256d was more like a conservative design choice because it actually avoids length extension issues.

Actually if we talk about the PoW context I don't think there are actually known practical attacks against single SHA256 that SHA256d prevents. Since double hashing roughly kinda the work per hash changing it now would require a hard fork and it might even break ASIC compatibility.