Why does Bitcoin use two hash functions (SHA-256 and RIPEMD-160) to create an address?

Question

Why do we use 2 hash functions (both SHA and RIPEMD) to create an address? Why not just use one hash function?

Answer 1

RIPEMD was used because it produces the shortest hashes whose uniqueness is still sufficiently assured. This allows Bitcoin addresses to be shorter.

SHA256 is used as well because Bitcoin's use of a hash of a public key might create unique weaknesses due to unexpected interactions between RIPEMD and ECDSA (the public key signature algorithm). Interposing an additional and very different hash operation between RIPEMD and ECDSA makes it almost inconceivable that there might be a way to find address collisions that is significantly easier than brute force trying a large number of secret keys.

Essentially, it was a belt and suspenders approach. Bitcoin had to do something unique and rather than have to hope they got it exactly right, they overdesigned it.

Answer 2

Except from Where is Double hashing performed in Bitcoin?

So why does he hash twice? I suspect it's in order to prevent length-extension attacks.

SHA-2, like all Merkle-Damgard hashes suffers from a property called "length-extension". This allows an attacker who knows H(x) to calculate H(x||y) without knowing x. This is usually not a problem, but there are some uses where it totally breaks the security. The most relevant example is using H(k||m) as MAC, where an attacker can easily calculate a MAC for m||m'. 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.

Answered by CodesInChaos

Answer 3

Here’s a highly speculative idea which isn’t asserted to be definitive nor certain. Yet it’s the only plausible reason I’ve contemplated given I reject the inconceivable presumption that Satoshi misunderstood or did ‘not have to think about’ length extension attacks. Length extension attacks are obviously impossible in Bitcoin because length extension attacks (never apply in Bitcoin and) only apply where the hashed data is secret. It’s not fathomable to me that Satoshi would have been so sloppy. Although by employing the double hash everywhere (c.f. also) he ostensibly intended to fool us into (i.e. give us enough rope to hang ourselves with) that anodyne explanation. That is if as I speculate he only had a use for the double hash for the spending function.

Additionally double hashing doesn’t increase security against collision nor second preimage attacks, c.f. also.

So imagine in the future 256-bit ECDSA is realistically exploitable. Two scenarios: 1) all UXTO are trivially and cost effectively exploitable; or perhaps first 2) only high valued outputs are cost effectively exploitable given high computational cost.

In the latter case no adversary can be assured of not being undermined by a competitor in terms of booty percentage they must award to the miners, as the miner who wins the block will take the (adversarial, booty grabbing) replacement transaction with the highest fees. (Naive readers should note the miner can’t distinguish between an adversarial and the non-booty grabbing transaction.) This appears to be a Prisoner’s dilemma unless in the seemingly unlikely event the miners can form a consensus 50+% oligarchy to enforce said booty percentage, rejecting all minority hashrate blocks which defect. One might argue that the high valued only scenario exploit forces the formation of said oligarchy, lest a model seems to show loss of the incentives compatibility that normally converges on a single longest (i.e. highest difficulty) chain rule. But miners won’t likely destroy their non-repurposable sunk mining hardware capex, nor would hodlers have an incentive to forsake said percentage of their ₿ for reasons I explain below.

In both scenarios there are UXTO that can’t be spent without being stolen, unless the Bitcoin validation protocol is modified to offer spending with a non-exploitable NIZKP (proof) of either preimage of the RIPEMD160(SHA256) hash.

(ADDED: naive readers note that compromising ECDSA doesn’t compromise the stationary unspent transactions outputs (UXTO) if the hash function isn’t also compromised. Those UXTO would be stranded by a threat to steal them with said posited future ECDSA exploit when and iff spend transaction is published to the network because it reveals the ECDSA public key which is otherwise obscured and protected by the hash until spending.)

I also contemplated an alternative in which the payor first records to the blockchain with a low valued (either not cost effectively exploitable or in the first of aforementioned scenarios by incentivizing the miner out-of-band with colored coins to not chose the adversarial) transaction with zero-valued outputs[1] or OP_RETURN (c.f. example)[2] the hash(preimage||txn_hash) before publishing finalization (i.e. proof) of the otherwise higher valued exploitable transaction.

Although both of those ideas would suffice if Satoshi has employed only a single-hash, Satoshi may have not wanted to depend on a contentious political outcome (e.g. the block size limit controversy) for the layer zero protocol change, so as to not hold spending hostage interim. The miners would likely resist any solution and if I may express the tendentious fact that the 1% that normally decides (because the inviolable power-law wealth distribution has no exceptions) would be impotent in either aforementioned scenario (thus opening up a power vacuum of the factionalized analog of warlord chaos) if their UTXO can’t be spent without being stolen. In other words, the Nash equilibrium is such that any changes to the layer zero protocol are stable only if the vested interests of the economic majority (i.e. the 1%) have no better strategy. In the inconceivable event Satoshi was derelict enough to design such that the 1% could be entirely divested, the miners would be destroyed along with Bitcoin.

If instead my second idea for the exploit work-around is employed on the intermediate preimage of the composite hash, i.e. RIPEMD160(preimage||txn_hash), thus an ad hoc colored coin spend is instantly possible (and adopted by Schelling point convention as the only option) without any change required to the layer zero validation protocol that the miners enforce. When spending with the intermediate preimage then the exploitable ECDSA public key was never revealed if the payor had spent his publicly received outputs to himself with a secret public key before the ECDSA exploit arrived. The double hash is only required if the payor has some incentive to not publish the public key (instead of the said intermediate) as the preimage to finalize (i.e. prove) the colored coin spend. Said colored coins remain non-exploitable thus likely retain value regardless. The prospect of a future hard fork that restores the ability to spend ₿ unexploited, incentivizes not spending with the public key prematurely thus requiring the double hash interim for spending the ad hoc colored coins.

I was motivated to conjure up this idea as a partial rebuttal to Craig “Faketoshi” Wright’s unsubstantiated claim that he explained the reason for the double hash. That is if my idea survives cross-examination by the community-at-large.

[1] Not to be confused with blackhole public keys.

[2] Ignore the following drivel: ^{_{As an aside so I won’t be ridiculed by the 1% economic majority who know the truth, but please if you have any conscience the following shouldn’t be considered when deciding whether to agree or disagree with my answer, my personal opinion is OP_RETURN is an invalid fork that will eventually be destroyed.}}