<p>You should also know that the task of finding an SHA256 collision (same hash for two different byte arrays) is a pretty complex one. Miners are spending terahashes per second to find a hash which is smaller than a target. An exact match would be very hard to find.</p>

<p>Also, the attacker in this task is required to be a miner with enough power to solve and broadcast a [special] block to be included in the main chain.</p>

<p>In short, I can say that this task requires so much hashing power - so if someone has enough power for that, he may perform a less complex 51% attack rather than this one.</p>

CC BY-SA 3.0
2013-03-19T17:37:39.083Z
2013-03-19T22:13:44.370Z
2013-03-19T22:13:44.370Z
Pentarh Udi
<p>Even without the whole discussion about merkle trees, having two transactions with the same hash could create a fork that would not be resolved without manual intervention.</p>

<p>As the transactions are also identified by their hash on the protocol the clients would get either <code>t</code> or <code>t'</code>, where <code>hash(t) = hash(t')</code>, that means that while nodes believe they accepted the same transaction, they would in fact have agreed upon two different transactions that conflict with each other. This would cause havoc down the line when a transaction tries to claim the outputs created by <code>t</code>. As these outputs are created in <code>t</code> and not in <code>t'</code> depending on which of the two you accepted, the followup transaction would be either valid or invalid, and so the problem spreads from one transaction to many.</p>

<p>A transaction being valid in one part of the network and not in the other will cause a blockchain fork, that might persist possibly requiring manual intervention.</p>

<p>Going back to the scenario you stated: the merchant would be tricked out of his money. He would believe the funds to be spendable, but every transaction he attempts with those outputs would be flagged as invalid, as per your scenario he gets <code>t</code> whereas a majority of the mining power gets <code>t'</code> and therefore <code>t'</code> will make it into the chain.</p>

<p>That being said, SHA-256 is thought to be collision resistant and the chance of finding a collision to a specific hash requires incredible amounts of attempts. Even finding a collision between any two inputs is incredibly hard, and the subject of many research challenges. So, it's unlikely to happen anytime soon.</p>

CC BY-SA 3.0
2013-03-19T21:21:33.257Z
Does Bitcoin use SHA1 anywhere?  I though every hash was SHA2 -based.
makerofthings7
CC BY-SA 3.0
2013-03-20T08:57:49.927Z
You are of course right, it's SHA-256 or RIPEMD160 for addresses. I'll correct that in my answer.
cdecker
CC BY-SA 3.0
2013-03-19T19:41:21.283Z
2015-05-08T09:27:13.333Z
2015-05-08T09:27:13.333Z
cdecker
<p><a href="https://crypto.stackexchange.com/a/781/371">This question on crypto.SE</a> describes how preimage attacks are avoided in the Bitcoin network.</p>

<blockquote>
  <p>For a second preimage attack:</p>
  
  <p><code>hash(x) = hash(y)</code> implies <code>hash(hash(x)) = hash(hash(y))</code></p>
  
  <p>So it wouldn't protect against a direct preimage attack. Bitcoin
  builds a <a href="https://en.bitcoin.it/wiki/Protocol_specification#Merkle_Trees" rel="nofollow noreferrer">Merkle
  tree</a>
  for <code>a b c</code> like this:
  <code>hash(hash(hash(a)+hash(b))+hash(hash(c)+hash(c)))</code>.</p>
  
  <p>You can see again that if someone found a <code>c'</code> that has the same
  SHA-256 hash as <code>c</code>, they could substitute it and the final result
  would still be the same.</p>
  
  <p>While it's true that this might improve resistance to first preimage
  attacks, there aren't any obvious cases where those would matter -- an
  attacker typically would have the plaintext that generated the hash.
  (And preimage attacks on addresses seem far fetched, given that the
  ECDSA operation is in there.)</p>
</blockquote>

<p>Suppose two offline transactions are generated with the same <code>c'</code> hash.  Assume it takes several months/years to create each Tx.   Then:</p>

<ol>
<li>The attacker creates a Tx to a merchant</li>
<li>The attacker creates  a second Tx with the same inputs as #1.  Then a private key is regenerated until the Tx hash equals the hash of c'.</li>
</ol>

<p><strong>Question</strong></p>

<ol>
<li><p>How does the Bitcoin network respond to these competing transactions with the same hash?</p></li>
<li><p>How would the outcome be different if the transaction was non-standard, and therefore not replicated across miners?</p></li>
</ol>

<transactions><security><doublespend><hash>
Possible to create a double spend attack by replacing a Tx in the merkle tree?
makerofthings7
# Possible to create a double spend attack by replacing a Tx in the merkle tree?

(Asked by: username_0 on 2013-03-19)

[This question on crypto.SE](https://crypto.stackexchange.com/a/781/371) describes how preimage attacks are avoided in the Bitcoin network.

> For a second preimage attack:
>
> `hash(x) = hash(y)` implies `hash(hash(x)) = hash(hash(y))`
>
> So it wouldn't protect against a direct preimage attack. Bitcoin
> builds a [Merkle
> tree](https://en.bitcoin.it/wiki/Protocol_specification#Merkle_Trees)
> for `a b c` like this:
> `hash(hash(hash(a)+hash(b))+hash(hash(c)+hash(c)))`.
>
> You can see again that if someone found a `c'` that has the same
> SHA-256 hash as `c`, they could substitute it and the final result
> would still be the same.
>
> While it's true that this might improve resistance to first preimage
> attacks, there aren't any obvious cases where those would matter -- an
> attacker typically would have the plaintext that generated the hash.
> (And preimage attacks on addresses seem far fetched, given that the
> ECDSA operation is in there.)

Suppose two offline transactions are generated with the same `c'` hash. Assume it takes several months/years to create each Tx. Then:

1. The attacker creates a Tx to a merchant
2. The attacker creates a second Tx with the same inputs as #1. Then a private key is regenerated until the Tx hash equals the hash of c'.

**Question**

1. How does the Bitcoin network respond to these competing transactions with the same hash?
2. How would the outcome be different if the transaction was non-standard, and therefore not replicated across miners?

**Tags:** transactions, security, doublespend, hash


---

## 2 answers

### Answer by username_1 on 2013-03-19. Score: 6

You should also know that the task of finding an SHA256 collision (same hash for two different byte arrays) is a pretty complex one. Miners are spending terahashes per second to find a hash which is smaller than a target. An exact match would be very hard to find.

Also, the attacker in this task is required to be a miner with enough power to solve and broadcast a [special] block to be included in the main chain.

In short, I can say that this task requires so much hashing power - so if someone has enough power for that, he may perform a less complex 51% attack rather than this one.


---

### Answer by username_2 on 2013-03-19. Score: 3

Even without the whole discussion about merkle trees, having two transactions with the same hash could create a fork that would not be resolved without manual intervention.

As the transactions are also identified by their hash on the protocol the clients would get either `t` or `t'`, where `hash(t) = hash(t')`, that means that while nodes believe they accepted the same transaction, they would in fact have agreed upon two different transactions that conflict with each other. This would cause havoc down the line when a transaction tries to claim the outputs created by `t`. As these outputs are created in `t` and not in `t'` depending on which of the two you accepted, the followup transaction would be either valid or invalid, and so the problem spreads from one transaction to many.

A transaction being valid in one part of the network and not in the other will cause a blockchain fork, that might persist possibly requiring manual intervention.

Going back to the scenario you stated: the merchant would be tricked out of his money. He would believe the funds to be spendable, but every transaction he attempts with those outputs would be flagged as invalid, as per your scenario he gets `t` whereas a majority of the mining power gets `t'` and therefore `t'` will make it into the chain.

That being said, SHA-256 is thought to be collision resistant and the chance of finding a collision to a specific hash requires incredible amounts of attempts. Even finding a collision between any two inputs is incredibly hard, and the subject of many research challenges. So, it's unlikely to happen anytime soon.

> **Comments:**
> **username_0**: Does Bitcoin use SHA1 anywhere?  I though every hash was SHA2 -based.  
> **username_2**: You are of course right, it's SHA-256 or RIPEMD160 for addresses. I'll correct that in my answer.  

---

