<p>The problem was that in case a duplicate transaction was created in a side branch that is afterwards reverted, and is only seen by a certain portion of the network, a fork risk exists. The nodes A that have seen the duplicate transactions and its reversal, will consider the original transaction unspendable (as it was overwritten and subsequently removed from their transaction database in the reorganisation), while nodes B that did not see the duplicate would consider the original spendable. When the original transaction is spent afterwards, and a majority of the network is in B, the network will split, as the A nodes will consider the chain created by B as invalid.</p>

<p>The third solution presented is implemented by BIP30 - this was a stopgap solution to prevent the worst from happening. A more complete solution (the first one) being deployed as BIP 34</p>

CC BY-SA 3.0
2012-12-22T22:37:51.830Z
2014-09-12T21:21:38.117Z
2014-09-12T21:21:38.117Z
Pieter Wuille
<p>I'm having trouble understanding the bug that was fixed in <a href="https://en.bitcoin.it/wiki/BIP_0030" rel="nofollow">BIP030</a>, and how it would be exploited.</p>

<p>Is the premise of this attack that there would have to be a netsplit and the chain was forked, then subsequently rolled back the old transactions?</p>

<p>What would the validation psuedo-logic of the following look like?</p>

<blockquote>
  <p>There are several potential solutions to this problem:</p>
  
  <ul>
  <li>Guarantee that all coinbases are unique, making duplicate transactions very hard to create.</li>
  <li>Remember previous remaining outputs of a given transaction identifier, in case a new transaction with the same identifier is
  added.</li>
  <li>Only allow duplicate transactions in case the previous instance of the transaction had no spendable outputs left. Removing a block from
  the chain can then safely reset the removed transaction's outputs to
  nothing.</li>
  </ul>
</blockquote>

<p>The reason I'm asking is so I can develop additional validation rules that work in parallel with the existing client.</p>

<transactions><security><confirmations>
Where can I learn more about BIP30; namely the exploit and the background discussion?
makerofthings7
# Where can I learn more about BIP30; namely the exploit and the background discussion?

(Asked by: username_0 on 2012-12-22)

I'm having trouble understanding the bug that was fixed in [BIP030](https://en.bitcoin.it/wiki/BIP_0030), and how it would be exploited.

Is the premise of this attack that there would have to be a netsplit and the chain was forked, then subsequently rolled back the old transactions?

What would the validation psuedo-logic of the following look like?

> There are several potential solutions to this problem:
>
> * Guarantee that all coinbases are unique, making duplicate transactions very hard to create.
> * Remember previous remaining outputs of a given transaction identifier, in case a new transaction with the same identifier is
>   added.
> * Only allow duplicate transactions in case the previous instance of the transaction had no spendable outputs left. Removing a block from
>   the chain can then safely reset the removed transaction's outputs to
>   nothing.

The reason I'm asking is so I can develop additional validation rules that work in parallel with the existing client.

**Tags:** transactions, security, confirmations


---

## 1 answers

### Answer by username_1 on 2012-12-22. Score: 9 | Accepted answer

The problem was that in case a duplicate transaction was created in a side branch that is afterwards reverted, and is only seen by a certain portion of the network, a fork risk exists. The nodes A that have seen the duplicate transactions and its reversal, will consider the original transaction unspendable (as it was overwritten and subsequently removed from their transaction database in the reorganisation), while nodes B that did not see the duplicate would consider the original spendable. When the original transaction is spent afterwards, and a majority of the network is in B, the network will split, as the A nodes will consider the chain created by B as invalid.

The third solution presented is implemented by BIP30 - this was a stopgap solution to prevent the worst from happening. A more complete solution (the first one) being deployed as BIP 34


---

