I was checking the bitcoin/src/pow.cpp in Core v28, and I noticed that GetPoWHash() still uses SHA256d. This makes me wonder, why not just go with a single SHA256? I get the double hashing helps against length-extension attacks, but single SHA256 already gives full preimage resistance.
So, my questions are: was SHA256d mainly for length-extension protection, or were there other reasons back in 2008/2009 like added security or protocol consistency?
There have been quite a few discussions on this, but honestly, only Satoshi could give a definite answer.
Check out some related threads if you're curious.
Yeah, I get it. But length extension attacks are a real concern.
And it’s kind of funny that Satoshi’s hashing method shows up in other places too, like in transaction hashing and Merkle trees. Seems like he just made a choice and stuck with it.
Satoshi just did what worked at the time. The code was convenient to implement, and he reused it wherever needed. It's like, the block hashes are little endian because x86 machines are little endian. No need to complicate things for no reason.
Thanks for the input! But does that mean SHA256d was just a convenience thing like the little endian hashes? Or was there a more serious security reason behind it? I mean, length extension attacks were already known back then, so did Satoshi pick SHA256d intentionally to avoid them, or was it just easy for him?
I think you might be onto something. You could try compiling Satoshi's original client and see how much work it would take to implement changes. It’s tricky, though. Satoshi really is the only one who knows for sure.
This is kinda off topic because of the difficulty adjustment, but if hashing was easier, you’d still end up with the same performance. The mining difficulty would just ramp up.
Framing is key here. Just to clarify on the length extension point, it’s really a concern when hashing is used as a secret MAC. In BTC, that's not how it works, so attacks aren’t really relevant.
Actually, you're right. A single hash might make mining easier in some cases. But with double hashing, it gets trickier to game the system since the final hash relies on a 64-bit input. Plus, we call it proof of work for a reason it helps against collision attacks.
Swapping out the algorithm means a complete overhaul of mining rigs. Thanks to the open-source mining community, we know the interfaces of newer ASICs. They can’t just hash once. The job is sent to them, and they handle the double hashing and nonce rolls.
From what I've seen, there hasn't been a clear explanation from Satoshi. However, most think SHA256d was a conservative design choice, avoiding length extension issues.
Practically, there aren’t known attacks that single SHA256 prevents that SHA256d doesn’t. Changing it now would mean a hard fork, risking ASIC compatibility.
The length extension concept needs some context. In mining, we’re hashing a fixed 80-byte header, so those classic attacks don’t really apply. I’ve always believed SHA256d was more about a cautious design choice rather than a direct response to a specific threat.
Yeah, PoW doesn’t rely on collision resistance at all. It’s more focused on partial preimage resistance. Miners are just trying to find an input that hashes below a certain target. So really, double SHA256 isn’t providing any extra collision protection in this context.
I still feel like we’re dancing around the main point. Why did Satoshi favor SHA256d over just single SHA256? Length extension attacks seem less relevant here because the data sizes are fixed. Maybe double SHA256 gives a little peace of mind in case a flaw is found in single SHA256.