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.