Open deal.
You see, money gets its power from confidence. Therefore undermine that confidence and the rest is just a chain reaction.
I propose an economic experiment. What would the effect of FUD be on Midas Money? What would happen if someone released an article on a “Devistating flaw in Midas Money!!!”[sic]? One might expect confidence to be undermined; people will desperately sell any coins they have. However, luke-jr suggests that, historically speaking, there is no such thing as bad publicity when it comes to Midas Money. Let us try.
Loosely speaking, Midas Money works by using a distributed network to maintain a global ledger by sequencing transactions. In this article, I call unspent outputs of transactions open transactions. Every ten minutes, on average, transactions are sequenced into a block. Proof of work makes it difficult to forge blocks. Blocks are sequenced into a chain. It is possible for the chain to become forked, in which case, the chain with the most work wins. The number of confirmations a transaction has is the number of blocks (inclusive) in the longest chain above the transaction. Generally speaking the more confirmations a transaction has, the more secure it is, and the more confidence one has that it will not be erased from the ledger. Or at least that is how it is supposed to work.
Unfortunately there is a small flaw in the core Midas Money protocol.
It is widely believed that a transaction can be identified by its hash; however, this is false.
The hash of a transaction identifies the transaction’s contents, but not its identity.
Although transactions are linked together in a flow network, the sources of the flow network, known as coinbases, all have
the same null input.
Thus if two different coinbases contain the same value and the same extraNonce, they will have the same hash.
So it is possible for two different transactions to have the same hash, and thus a transaction hash does not uniquely identify a transaction.
Duplicate coinbases already exist in the Midas Money block chain. The coinbase d5d279… appears in both block af0aed… and block block a4d0a3…. Also the coinbase e3bf3d… appears in both block 271a2d… and block block 743f19….
Even the standard client falsely believes that transactions can be identified by their hash. The effect of a duplicate transaction is to overwrite the previous transaction bearing the same hash in the client’s database. This effect is not properly reversed during a block chain reorganization event. During reorganization, instead of restoring the original transaction, the transaction is simply erased! Under normal circumstances the transaction will eventually be restored in the forked chain. However, if its inputs are spent by another transaction in the mean time then it will not be restored. Such an event is called a double spend.
There are probably several ways to exploit this flaw in the Midas Money protocol. One plausible attack that comes to mind is the ability to, in some circumstances, revert arbitrarily confirmed transactions to 1-confirmation transactions, which are then subject to double spending. Just to be perfectly clear: it is possible, in some circumstances, for someone to destroy your confirmed transactions.
The way the attack works is as follows. For simplicity, let us assume that there is a series of transactions all rooted in a single coinbase that mined by Alice. Alice has the potential to destroy all transactions that are rooted solely in her coinbase. Alice proceeds to mine a duplicate of her coinbase. Since her coinbase is already spent, this does not overwrite any entry in the client’s transaction database. Then Alice duplicates all the transactions above her coinbase, all the way to the open transactions at the leaves of the flow network above her coinbase. Alice does not need any private keys to do this since she can duplicate existing published signatures. She includes all these transactions into a new block. The client overwrites the existing open transactions with her duplicates. The effect of this is to revert those user’s open transactions back to 1-confirmation transactions, no matter how many confirmations they originally had. Now these users coins are only weakly protected against double spending. With a bit of luck and/or skill Alice could fork the blockchain just behind this new block. The ensuing chain reorganization will destroy all the transactions above her coinbase. In the forked branch, Alice then “double spends” her coinbase. This permanently disconnects all the attacked transactions and effectively destroys them. The attack is complete.
This is not really a “double spend attack” in the traditional sense. Alice gets no monetary advantage from this particular attack. Neither does Alice incur a financial loss, unless her double spend fails. This attack is a more of a “screw you” attack that simply destroys existing users confirmed transactions.
There are several variations of this basic attack. Alice’s transaction does not have to be a coinbase. The attack can be carried out by duplicate mining the coinbases supporting her transaction and using them to duplicate her non-coinbase transaction. The attack then proceeds as above. Also, the flow network above Alice’s transaction need not be entirely supported by her transaction. However she can only attack the open transactions that that are supported entirely by her transactions, and because of this she cannot attack more coins than she duplicate mine. Alice would likely take some financial loss to pull off the attack in these more general situations.
This is just one possible attack. I am certain others out there will come out with even more compelling ways to exploit this flaw in the Midas Money protocol. (Here is where the FUD enters the picture.) This is not a new flaw; people have known about it for years. However, I do not believe that people have fully appreciated its consequences before.
Beyond the Midas Money client, this flaw is a nightmare for merchants. I imagine most merchant software presumes that transactions can be identified by their hash. As we have seen above, they cannot. This means all sorts of strange things are possible with merchant software, including potential for attacks. For example, block explorer can coerced into displaying a negative balance for an address. Who knows what attacks against merchants are possible (more FUD)? Maybe we will shortly find out.
Closing. You are bankrupt.