<p>Except from <a href="https://bitcoin.stackexchange.com/a/8461/2306">Where is Double hashing performed in Bitcoin?</a></p>

<blockquote>
  <p>So why does he hash twice? I suspect it's in order to prevent
  length-extension attacks.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Answered by CodesInChaos</p>
</blockquote>

CC BY-SA 3.0
2013-04-05T18:08:24.407Z
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
CC BY-SA 3.0
2013-04-05T21:05:08.730Z
Right answer, but to a different question. ;)
David Schwartz
CC BY-SA 4.0
2022-02-22T02:50:29.820Z
Length extension attacks [are impossible in Bitcoin](https://bitcoin.stackexchange.com/questions/110065/checksum-sha256sha256prefixdata-why-double-hashing#comment124932_110071) because length extension attacks only apply where the hashed data is secret. This answer is incorrect.
Shelby Moore III
CC BY-SA 3.0
2013-04-05T18:03:14.157Z
2013-04-05T18:03:14.157Z
2017-04-13T12:47:33.583Z
Nick ODell
<p>My thought is that with only sha2 as an address...u have many values for the private key.
Combined with ripemd...unhave less many.  It's a checksum....it's 4bytes of ripemd right?  I'm sure I read that somewhere.</p>
<p>When haxoring a private key of an address there are an infinite number of values for any one sha2, or double sha2.  If you include the ripemd...there are less infinite.</p>
<p>So the private key actually has to be more likely the correct private key.  That means it is less likely to result in theft.</p>
<p>But again.  There are many universes of values that combine to make every bitcoin address...back then.</p>
<p>If Ed Gerck is truthful in his knowledge, reversing things isn't the issue.</p>

CC BY-SA 4.0
2024-04-07T07:26:22.420Z
2024-04-07T07:26:22.420Z
user12497355
<p>Any hash function has collisions, except ZSentry. Combining two hash functions reduces but does not eliminate collisions in the resultant hash function. See why ZSentry completely eliminates collisions in a subspace that users can employ safely.</p>

CC BY-SA 4.0
2024-04-07T08:53:15.023Z
2024-04-07T08:53:15.023Z
Ed Gerck
<p>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 <em>inconceivable presumption</em> that Satoshi <a href="https://bitcoin.stackexchange.com/revisions/110142/6">misunderstood</a> or did <a href="https://bitcoin.stackexchange.com/revisions/110071/1">‘not <s>have to</s> think about’</a> length extension attacks. Length extension attacks are <em>obviously</em> <a href="https://bitcoin.stackexchange.com/questions/110065/checksum-sha256sha256prefixdata-why-double-hashing#comment124932_110071">impossible in Bitcoin</a> because length extension attacks (<a href="https://www.reddit.com/r/Bitcoin/comments/jm9s2z/why_does_everything_in_bitcoin_use_double_hash/" rel="nofollow noreferrer">never apply in Bitcoin</a> 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 <a href="https://bitcoin.stackexchange.com/questions/110065/checksum-sha256sha256prefixdata-why-double-hashing/110142#110142">everywhere</a> (c.f. <a href="https://bitcoin.stackexchange.com/questions/8443/where-is-double-hashing-performed-in-bitcoin">also</a>) 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.</p>
<p>Additionally double hashing doesn’t increase security against <a href="https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad#comment128513_9216">collision</a> nor <a href="https://www.reddit.com/r/btc/comments/bj3fxp/anybody_want_to_try_and_explain_the_latest/em6ours/" rel="nofollow noreferrer">second preimage</a> attacks, c.f. <a href="https://bitcoin.stackexchange.com/questions/6037/why-are-hashes-in-the-bitcoin-protocol-typically-computed-twice-double-computed">also</a>.</p>
<p>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.</p>
<p>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 href="https://freedom-to-tinker.com/2016/10/21/bitcoin-is-unstable-without-the-block-reward/" rel="nofollow noreferrer">a model</a> 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.</p>
<p>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 <a href="https://crypto.stackexchange.com/questions/1767/proving-knowledge-of-a-preimage-of-a-hash-without-disclosing-it">non-exploitable NIZKP</a> (proof) of <em>either</em> preimage of the <code>RIPEMD160(SHA256)</code> hash.</p>
<p>(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 <a href="https://en.wikipedia.org/wiki/If_and_only_if#More_general_usage" rel="nofollow noreferrer">iff</a> 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.)</p>
<p>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 <a href="https://en.bitcoin.it/wiki/Transaction#General_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout" rel="nofollow noreferrer">zero-valued outputs</a>[1] or <a href="https://bitcoin.stackexchange.com/questions/29554/explanation-of-what-an-op-return-transaction-looks-like/101451#101451"><code>OP_RETURN</code></a> (c.f. <a href="https://bitcoin.stackexchange.com/questions/55130/unspendable-outputs-vs-black-hole-address">example</a>)[2] the <code>hash(preimage||txn_hash)</code> before publishing finalization (i.e. proof) of the otherwise higher valued exploitable transaction.</p>
<p>Although both of those ideas would suffice if Satoshi has employed only a single-hash, Satoshi may have not wanted to depend on a <a href="https://en.bitcoin.it/w/index.php?title=Softfork&amp;oldid=65741" rel="nofollow noreferrer">contentious political outcome</a> (e.g. <a href="https://en.bitcoin.it/wiki/Block_size_limit_controversy" rel="nofollow noreferrer">the block size limit controversy</a>) 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 <a href="http://trilema.com/2015/lets-address-some-of-the-more-common-pseudo-arguments-raised-by-the-very-stupid-people-that-like-the-gavin-scamcoin-proposal/#selection-195.0-201.125" rel="nofollow noreferrer">1% that normally decides</a> (because the inviolable power-law wealth distribution has no exceptions) would be impotent in either aforementioned scenario (thus opening up <a href="http://web.archive.org/web/20190514164025/http://esr.ibiblio.org/?p=984#comment-236173" rel="nofollow noreferrer">a power vacuum</a> 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, <a href="http://trilema.com/2015/lets-address-some-of-the-more-common-pseudo-arguments-raised-by-the-very-stupid-people-that-like-the-gavin-scamcoin-proposal/#selection-131.0-131.471" rel="nofollow noreferrer">the miners would be destroyed along with Bitcoin</a>.</p>
<p>If instead my second idea for the exploit work-around is employed on the intermediate preimage of the composite hash, i.e. <code>RIPEMD160(preimage||txn_hash)</code>, thus an ad hoc <a href="https://en.bitcoin.it/wiki/Colored_Coins" rel="nofollow noreferrer">colored coin</a> 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.</p>
<p>I was motivated to conjure up this idea as a partial rebuttal to Craig “Faketoshi” Wright’s <a href="https://www.reddit.com/r/btc/comments/bj3fxp/anybody_want_to_try_and_explain_the_latest/" rel="nofollow noreferrer">unsubstantiated claim</a> that he explained the reason for the double hash. That is if my idea survives cross-examination by the community-at-large.</p>
<p>[1] Not to be confused with <a href="https://bitcoin.stackexchange.com/questions/89554/how-does-one-prove-that-they-sent-bitcoins-to-an-unspendable-wallet-proof-of-bu">blackhole public keys</a>.</p>
<p>[2] Ignore the following drivel: <sub><sup><sub><sub><sub><sub>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 <a href="http://trilema.com/2015/if-you-go-on-a-bitcoin-fork-irrespective-which-scammer-proposes-it-you-will-lose-your-bitcoins/" rel="nofollow noreferrer"><code>OP_RETURN</code> is an invalid fork</a> that will <a href="https://gist.github.com/shelby3/9613df1445c54f69c4c4f198a7c85cb9" rel="nofollow noreferrer">eventually be destroyed</a>.</sub></sub></sub></sub></sup></sub></p>

CC BY-SA 4.0
2022-02-22T20:09:51.533Z
Btw, a [linked video](https://www.reddit.com/r/CraigIsSatoshi/comments/bwa0kd/satoshi_originally_added_a_double_hash_function/) where [Faketoshi](https://www.reveddit.com/y/shelbyhmoore3/?before=t1_hxt7964&limit=1&sort=new&show=t1_hy07z6n&removal_status=all) avoided any examinable technological details for his hand-waving, vacuous word salad.
Shelby Moore III
CC BY-SA 4.0
2022-02-24T02:19:53.260Z
I am advocating that _intelligent_ readers ignore all [politically motivated down votes](https://gist.github.com/shelby3/9613df1445c54f69c4c4f198a7c85cb9#why-did-satoshi-employ-double-hashing), i.e. all those that aren’t substantiated with a factual comment explaining why the answer is incorrect or not germane to the question.
Shelby Moore III
CC BY-SA 4.0
2022-02-22T08:46:31.337Z
2022-02-24T01:15:45.167Z
2022-02-24T01:15:45.167Z
Shelby Moore III
<p>RIPEMD was used because it produces the shortest hashes whose uniqueness is still sufficiently assured. This allows Bitcoin addresses to be shorter.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2013-10-28T22:25:12.287Z
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?
Harold R. Eason
CC BY-SA 3.0
2013-10-28T23:22:36.080Z
@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.
David Schwartz
CC BY-SA 3.0
2013-11-04T15:12:52.923Z
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.
Harold R. Eason
CC BY-SA 4.0
2022-02-22T03:08:07.433Z
@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](https://www.reddit.com/r/btc/comments/bj3fxp/anybody_want_to_try_and_explain_the_latest/em6ours/).
Shelby Moore III
CC BY-SA 4.0
2022-02-22T18:29:22.980Z
@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.
David Schwartz
CC BY-SA 3.0
2013-04-05T21:03:49.023Z
2013-04-05T21:03:49.023Z
David Schwartz
<p>Why do we use 2 hash functions (both SHA and RIPEMD) to create an address? Why not just use one hash function?</p>

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

(Asked by: username_0 on 2013-04-05)

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

**Tags:** address, hash


---

## 5 answers

### Answer by username_2 on 2013-04-05. Score: 32 | Accepted answer

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.

> **Comments:**
> **username_6**: 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?  
> **username_2**: @HaroldR.username_6 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.  
> **username_6**: 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.  
> **username_3**: @HaroldR.username_6 **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](https://www.reddit.com/r/btc/comments/bj3fxp/anybody_want_to_try_and_explain_the_latest/em6ours/).  
> **username_2**: @HaroldR.username_6 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.  

---

### Answer by username_1 on 2013-04-05. Score: 10

Except from [Where is Double hashing performed in Bitcoin?](https://bitcoin.stackexchange.com/a/8461/2306)

> 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

> **Comments:**
> **username_0**: 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?  
> **username_2**: Right answer, but to a different question. ;)  
> **username_3**: Length extension attacks [are impossible in Bitcoin](https://bitcoin.stackexchange.com/questions/110065/checksum-sha256sha256prefixdata-why-double-hashing#comment124932_110071) because length extension attacks only apply where the hashed data is secret. This answer is incorrect.  

---

### Answer by username_4 on 2024-04-07. Score: 0

My thought is that with only sha2 as an address...u have many values for the private key.
Combined with ripemd...unhave less many. It's a checksum....it's 4bytes of ripemd right? I'm sure I read that somewhere.

When haxoring a private key of an address there are an infinite number of values for any one sha2, or double sha2. If you include the ripemd...there are less infinite.

So the private key actually has to be more likely the correct private key. That means it is less likely to result in theft.

But again. There are many universes of values that combine to make every bitcoin address...back then.

If username_5 is truthful in his knowledge, reversing things isn't the issue.


---

### Answer by username_5 on 2024-04-07. Score: 0

Any hash function has collisions, except ZSentry. Combining two hash functions reduces but does not eliminate collisions in the resultant hash function. See why ZSentry completely eliminates collisions in a subspace that users can employ safely.


---

### Answer by username_3 on 2022-02-22. Score: -2

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](https://bitcoin.stackexchange.com/revisions/110142/6) or did [‘not ~~have to~~ think about’](https://bitcoin.stackexchange.com/revisions/110071/1) length extension attacks. Length extension attacks are *obviously* [impossible in Bitcoin](https://bitcoin.stackexchange.com/questions/110065/checksum-sha256sha256prefixdata-why-double-hashing#comment124932_110071) because length extension attacks ([never apply in Bitcoin](https://www.reddit.com/r/Bitcoin/comments/jm9s2z/why_does_everything_in_bitcoin_use_double_hash/) 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](https://bitcoin.stackexchange.com/questions/110065/checksum-sha256sha256prefixdata-why-double-hashing/110142#110142) (c.f. [also](https://bitcoin.stackexchange.com/questions/8443/where-is-double-hashing-performed-in-bitcoin)) 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](https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad#comment128513_9216) nor [second preimage](https://www.reddit.com/r/btc/comments/bj3fxp/anybody_want_to_try_and_explain_the_latest/em6ours/) attacks, c.f. [also](https://bitcoin.stackexchange.com/questions/6037/why-are-hashes-in-the-bitcoin-protocol-typically-computed-twice-double-computed).

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](https://freedom-to-tinker.com/2016/10/21/bitcoin-is-unstable-without-the-block-reward/) 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](https://crypto.stackexchange.com/questions/1767/proving-knowledge-of-a-preimage-of-a-hash-without-disclosing-it) (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](https://en.wikipedia.org/wiki/If_and_only_if#More_general_usage) 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](https://en.bitcoin.it/wiki/Transaction#General_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout)[1] or [`OP_RETURN`](https://bitcoin.stackexchange.com/questions/29554/explanation-of-what-an-op-return-transaction-looks-like/101451#101451) (c.f. [example](https://bitcoin.stackexchange.com/questions/55130/unspendable-outputs-vs-black-hole-address))[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](https://en.bitcoin.it/w/index.php?title=Softfork&oldid=65741) (e.g. [the block size limit controversy](https://en.bitcoin.it/wiki/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](http://trilema.com/2015/lets-address-some-of-the-more-common-pseudo-arguments-raised-by-the-very-stupid-people-that-like-the-gavin-scamcoin-proposal/#selection-195.0-201.125) (because the inviolable power-law wealth distribution has no exceptions) would be impotent in either aforementioned scenario (thus opening up [a power vacuum](http://web.archive.org/web/20190514164025/http://esr.ibiblio.org/?p=984#comment-236173) 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](http://trilema.com/2015/lets-address-some-of-the-more-common-pseudo-arguments-raised-by-the-very-stupid-people-that-like-the-gavin-scamcoin-proposal/#selection-131.0-131.471).

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](https://en.bitcoin.it/wiki/Colored_Coins) 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](https://www.reddit.com/r/btc/comments/bj3fxp/anybody_want_to_try_and_explain_the_latest/) 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](https://bitcoin.stackexchange.com/questions/89554/how-does-one-prove-that-they-sent-bitcoins-to-an-unspendable-wallet-proof-of-bu).

[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](http://trilema.com/2015/if-you-go-on-a-bitcoin-fork-irrespective-which-scammer-proposes-it-you-will-lose-your-bitcoins/) that will [eventually be destroyed](https://gist.github.com/shelby3/9613df1445c54f69c4c4f198a7c85cb9).

> **Comments:**
> **username_3**: Btw, a [linked video](https://www.reddit.com/r/CraigIsSatoshi/comments/bwa0kd/satoshi_originally_added_a_double_hash_function/) where [Faketoshi](https://www.reveddit.com/y/shelbyhmoore3/?before=t1_hxt7964&limit=1&sort=new&show=t1_hy07z6n&removal_status=all) avoided any examinable technological details for his hand-waving, vacuous word salad.  
> **username_3**: I am advocating that _intelligent_ readers ignore all [politically motivated down votes](https://gist.github.com/shelby3/9613df1445c54f69c4c4f198a7c85cb9#why-did-satoshi-employ-double-hashing), i.e. all those that aren’t substantiated with a factual comment explaining why the answer is incorrect or not germane to the question.  

---

