33

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

3 Answers 3

31

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.

5
  • 3
    Do you have a reference to why SHA256 interacts (or is known/thought to interact) better than RIPEMD160 with ECDSA? Without any citations or underlying reasoning, I could argue the same thing: RIPEMD160 could have unexpected interactions with SHA256. Moreover, say RIPEMD160 was broken and only generated a set of 100 different hashes. Then it would be trivial to break this. Say SHA256 was broken instead. Then you'd be able to generate two keys that have the same hash (and some program may depend on that not being possible). If either SHA256 or RIPEMD160 is broken, so is this address scheme? Oct 28, 2013 at 22:25
  • @HaroldR.Eason We know RIPEMD160 isn't broken in the way you suggest. The issue is whether it might be broken when used with ECDSA. But what Satoshi did is used SHA256+RIPEMD160 with ECDSA, which is much less likely to be broken. It's not that one interacts better than the other, it's that a flaw in the two of them composed seems almost impossible. Oct 28, 2013 at 23:22
  • 1
    But if there's a break in SHA256 to generate collisions, then one could construct two addresses with the same hash, which makes bitcoin addresses no longer a real hash. It's plausible that some code would rely on the collision resistance property of bitcoin addresses in their code, though I don't know of any. Nov 4, 2013 at 15:12
  • @HaroldR.Eason agreed. This answer is incorrect. A collision in either hash variant creates a collision in the composite hash. Thus employing two variants nested if any effect makes the collision resistance worse. There’s no second preimage security advantage with a double hash. Feb 22 at 3:08
  • @HaroldR.Eason That's true, but not sure why you think that's relevant to this question. I never said it protected against any potential breaks in SHA256. Feb 22 at 18:29
10

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

3
  • I will reformulate my question. RIPEMD is also used to create the address, my question is why do we use RIPEMD and SHA, why not to use only SHA?
    – anapaso
    Apr 5, 2013 at 18:08
  • 2
    Right answer, but to a different question. ;) Apr 5, 2013 at 21:05
  • Length extension attacks are impossible in Bitcoin because length extension attacks only apply where the hashed data is secret. This answer is incorrect. Feb 22 at 2:50
-1

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.

2

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.