As I understand it, current implementation is susceptible to a relatively low cost 0-confirmation double spend attack. Notably this attack is as simple as running two bitcoind instances with the same wallet data connected to different hosts. The json-rpc interface could then be used to do a simultaneous spend of the same address from the two instances. If the receiver doesn't see the transaction you want them to see just redo from a different address but switch which daemon is sending the "legitimate" transaction. This its a very viable attach requiring relatively limited technical knowledge that could be further reduced if someone released a version of the daemon for just this purpose. If you are able to determine and connect directly to the host of the receiver this attack can be made to work with a high degree of success otherwise it has about a 50% (based on what transaction the successful miner receives) chance of working each time attempted.
If a proper double spend notification feature is implemented, this attack becomes much more expensive. Notably it would require collusion with powerful miners to be viable. It seems to me such a feature is worthwhile even though it will not eliminate the need to wait for confirmations under all circumstances.
These are the counter arguments I have seen in the forms
* Miners self interest will be to include the transaction with the highest fee.
I expect even today most hosts in the bitcoin network are not miners and they have no interest in breaking the current policy of dropping the second transaction of a double spend. This means that if two double spend transactions are sent simultaneously, double spend notification would quickly notify the receiving party or if the two transactions are sent with a significant delay (10s) most miners will never see the second transaction. A proper double spend notification should not transmit the full second transaction as it would exacerbate the double spend problem. But if the double spend notification contains the simplified hash of the transaction (not the full transaction) used in the signature verification and the input script (scriptSig) this would provide proof there was a double spend without the full transaction. Requiring proof of a double spend should ensure a double spend would have no more burden on the network than any other single transaction.
* Adversaries could collude with miners (or be miners) to include the "illegitimate" transaction
This is possible but much more difficult than double spending is now. The second transaction can not be quickly submitted on the normal bitcoin network as it would produce a double spend notification. But it only takes one good guy in the nefarious mining pool to forward the second transaction. The larger the pool the more likely you will have a good guy. The smaller the less likely that pool will mine the next block. Most people will do the right thing if it doesn't cost much. If it never becomes viable to get away with double spends, miners won't bother to change the implementation to take advantage of it. Making double spends harder now could stop nefarious software, miners and social networks from forming or at least slow their progress.
* This doesn't address the Finney attach.
True, but the Finney attack is significantly more expensive than a simple double spend is today. I would consider a Finney attach to be a particular form of colluding with miners. This attack can be significantly mitigated if the receiving end specified the time the transaction should be submitted. I am hard pressed to think of a real world transaction that is sizeable enough to make a Finney attack worthwhile yet you can't either wait for a few confirmations or just specify within a few minutes when the transaction should be sent. On the other hand, for small transactions like purchases at most stores, it can be cost effective to do a double spend today but not worthwhile to do a Finney attack.
* You can detect double spends with services like blockchain.info
The point of bitcoin is to be distributed and decentralized and if double spend notification is widely adopted it would have better coverage than any central service.
* The only proper solution to 0-conf spends is to add some trusted 3rd party
Yep. A trusted 3rd party absolutely can make 0-conf spends more trustworthy and I hope we see organizations established to do this especially related to escrowing online purchases. This doesn't eliminate the value of a 3rd party but does provide a significant improvement if one chooses to not use a centralized 3rd party as most bitcoin transactions are done today.
Double spend notification isn't a perfect solution to 0-conf transactions but I expect does provide sufficient additional integrity to be worth implementing. Is this not implemented because of some issue I am missing or because nobody has bothered to do the work?
Topic: Thoughts on double spend notification (Read 403 times)
Jump to: