Where can I learn more about BIP30; namely the exploit and the background discussion?

Question

I'm having trouble understanding the bug that was fixed in BIP030, 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.

Answer 1

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