Does SHA-256d's fixed second-hash padding create measurable internal structure beyond random oracle behavior?

External question — Bitcoin Stack Exchange Author: Noctarion Original post: https://bitcoin.stackexchange.com/questions/130694 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. Bitcoin mining uses SHA-256d: SHA-256(SHA-256(data)). I recently discovered experimentally (IACR ePrint 2026/109079) that the second SHA-256 application has a structurally constrained message schedule: The second hash always receives exactly 32 bytes (the first hash output) + fixed Merkle-Damgård padding This makes W[8-15] in the second hash always constant (0x80000000... + length encoding) Only 30 unique carry count values exist in the second hash's W-schedule (constrained Binomial distribution due to constant input) Measurable cross-hash carry anti-correlation: r=−0.029, 6.5σ, N=50K (internal state — first hash carry count negatively predicts second hash carry count) My questions: Was this structural property of SHA-256d considered when Bitcoin adopted double-SHA-256? Or was it chosen purely for length-extension attack resistance? Is there any documentation of this constrained W-schedule effect in Bitcoin's design rationale? Does this property have any known implications for Bitcoin's security model beyond length-extension resistance? The carry correlation is not exploitable (r=−0.029, <0.1% variance). Note: observable hash outputs are statistically independent — cross-hash LZ correlation r≈0.000. The structural property is in internal computation, consistent with Dodis et al. (CRYPTO 2012, IACR 2013/382) who proved SHA-256d is not indifferentiable from a random oracle. Update 2026-04-27: Self-check (N=200K) confirmed the original "9.56σ anti-correlation" measured internal carry state, not observable output. Corrected values above. See Dodis et al. for the theoretical foundation.

External answer — Bitcoin Stack Exchange Author: RedGrittyBrick Original post: https://bitcoin.stackexchange.com/a/130695 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. Bitcoin did not start with a published detailed design rationale for those kinds of choices. No one knows, we only have speculation.

External answer — Bitcoin Stack Exchange Author: bca-0353f40e Original post: https://bitcoin.stackexchange.com/a/130696 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. Bitcoin security never depended on resistance to length-extension because preimages are public anyway, and common belief is that the double was used just for defense-in-depth. I don't think Bitcoin ever uses hashes in a way that would suffer from length extensions, but I guess Satoshi went with the safe choice of preventing it everywhere. To avoid this property, Ferguson and Schneier suggested using SHA256d = SHA256(SHA256(x)) which avoids length-extension attacks. This construction has some minor weaknesses (not relevant to bitcoin), so I wouldn't recommend it for new protocols, and would use HMAC with constant key, or truncated SHA512 instead. https://bitcoin.stackexchange.com/a/8461/137501 The paper's discovery is interesting in that it would move SHA256d further away from a random oracle which has implications for secondary on-chain uses (e.g. in smart contracts or as 32-byte P2SH wrapper ). Interestingly, Bitcoin developers didn't think that securing against length-extension matters so they went with plain SHA256 for SegWit P2WSH address hashes . Later, Bitcoin Cash developers chose SHA256d for P2SH32 , thus maintaining consistency with the rest of the protocol, and unlinkability between never-spent-from addresses. Readers might be interested in some older related work, that has already shown a weakness against an exotic use-case ( Dodis et al., 2013 ): We exhibit a cryptographic setting, called mutual proofs of work, in which the highlighted structure of H2 can be exploited. In mutual proofs of work, two parties prove to each other that they have computed some asserted amount of computational effort. This task is inspired by, and similar to, client puzzles [20, 21, 27, 28, 40] and puzzle auctions [42]. We give a protocol for mutual proofs of work whose computational task is computing hash chains. This protocol is secure when using a random oracle, but when using instead H2 an attacker can cheat by abusing the structural properties discussed above.