{"type":"rich","version":"1.0","author_name":"npub1vdngmkaq73c0aq4fp7xgzjjtp9l66l2t50j7ma242lcp8rleuvls8sc3yk","author_url":"https://nostr.ae/npub1vdngmkaq73c0aq4fp7xgzjjtp9l66l2t50j7ma242lcp8rleuvls8sc3yk","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-23\n📝 Original message:On 4/23/2014 3:55 AM, Mike Hearn wrote:\n\u003e Lately someone launched Finney attacks as a service (BitUndo). As a \n\u003e reminder for newcomers, Finney attacks are where a miner secretly \n\u003e works on a block containing a double spend. When they eventually find \n\u003e a block, they run to the merchant and pay, then broadcast the block. \n\u003e In a simpler variant of this attack you make purchases as normal with \n\u003e a modified wallet that always submits a double spend to the service, \n\u003e and then N% of the time where N is the percentage of overall hash \n\u003e power the dishonest miners have, you get your money back minus their fee.\n\u003e\n\u003e N does not need to be very high to render Bitcoin much less useful. \n\u003e Real time transactions are very important. Although I never expected \n\u003e it when I first started using Bitcoin, nowadays most of my purchases \n\u003e with it are for food and drink. If Bitcoin could not support such \n\u003e purchases, I would use it much less.\n\u003e Even with their woeful security many merchants see \u003c1-2% credit card \n\u003e chargeback rates, and chargebacks can be disputed. In fact merchants \n\u003e win about 40% of chargeback disputes. So if N was only, say, 5%, and \n\u003e there was a large enough population of users who were systematically \n\u003e trying to defraud merchants, we'd already be having worse security \n\u003e than magstripe credit cards. EMV transactions have loss rates in the \n\u003e noise, so for merchants who take those Bitcoin would be dramatically \n\u003e less secure.\n\u003e\n\u003e The idea of discouraging blocks that perform Finney attacks by having \n\u003e honest miners refuse to build on them has been proposed. But it has a \n\u003e couple of problems:\n\u003e\n\u003e  1. It's hard to automatically detect Finney attacks. Looking for\n\u003e     blocks that contain unseen transactions that override the mempool\n\u003e     doesn't work - the dishonest users could broadcast all their\n\u003e     double spends once a Finney block was found and then broadcast the\n\u003e     block immediately afterwards, thus making the block look like any\n\u003e     other would in the presence of double spends.\n\u003e\n\u003e  2. If they could be automatically identified, it possibly could be\n\u003e     converted into a DoS on the network by broadcasting double spends\n\u003e     in such a way that the system races, and every miner produces a\n\u003e     block that looks like a Finney attack to some of the others. The\n\u003e     chain would stop advancing.\n\u003e\n\u003e  3. Miners who want to vote \"no\" on a block take a big risk, they\n\u003e     could be on the losing side of the fork and end up wasting their work.\n\u003e\n\u003e We can resolve these problems with a couple of tweaks:\n\u003e\n\u003e  1. Dishonest blocks can be identified out of band, by having honest\n\u003e     miners submit double spends against themselves to the service\n\u003e     anonymously using a separate tool. When their own double spend\n\u003e     appears they know the block is bad.\n\u003e\n\u003e  2. Miners can vote to reallocate the coinbase value of bad blocks\n\u003e     before they mature. If a majority of blocks leading up to maturity\n\u003e     vote for reallocation, the value goes into a pot that subsequent\n\u003e     blocks are allowed to claim for themselves. Thus there is no risk\n\u003e     to voting \"no\" on a block, the work done by the Finney attacker is\n\u003e     not wasted, and users do not have to suffer through huge reorgs.\n\u003e\n\u003e This may seem a radical suggestion, but I think it's much less radical \n\u003e than some of the others being thrown around.\n\u003e\n\u003e The above approach works as long as the majority of hashpower is \n\u003e honest, defined to mean, working to stop double spending. This is the \n\u003e same security property as described in the white paper, thus this \n\u003e introduces no new security assumptions. Note that assuming \n\u003e /all/ miners are dishonest and are willing to double spend \n\u003e automatically resolves the Bitcoin experiment as a failure, because \n\u003e that would invalidate the entire theory upon which the system is \n\u003e built. That doesn't mean the assumption is wrong! It may be that an \n\u003e entirely unregulated market for double spending prevention cannot work \n\u003e and the participants eventually all end up trashing the commons - but \n\u003e the hope is that smart incentives can replace the traditional reliance \n\u003e on law and regulation to avoid this.\n\u003e\n\u003e The voting mechanism would only apply to coinbases, not arbitrary \n\u003e transactions, thus it cannot be used to steal arbitrary users \n\u003e bitcoins. A majority of miners can already reallocate coinbases by \n\u003e forking them out, but this wastes energy and work presenting a \n\u003e significant discouragement to vote unless you already know via some \n\u003e out of band mechanism that you have a solid majority. Placing votes \n\u003e into the coinbase scriptSig as is done with other things avoids that \n\u003e problem.\n\u003e\n\u003e The identification of Finney blocks relies on miners to take explicit \n\u003e action, like downloading and running a tool that submits votes via \n\u003e RPC. It can be expected that double spending services would try to \n\u003e identify and block the sentinel transactions, which is why it's better \n\u003e to have the code that fights this arms race be out of process and \n\u003e developed externally to Bitcoin Core itself, which should ultimately \n\u003e just enforce the new (forking) rule change.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Start Your Social Network Today - Download eXo Platform\n\u003e Build your Enterprise Intranet with eXo Platform Software\n\u003e Java Based Open Source Intranet - Social, Extensible, Cloud Ready\n\u003e Get Started Now And Turn Your Intranet Into A Collaboration Platform\n\u003e http://p.sf.net/sfu/ExoPlatform\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\nI have some questions:\n1.  How can we work towards solving the double-spending problem?\n2.  Is it possible to \"scan\" for double-spending and correct it?\n3.  Is the network at large not secure enough?\n\n\n-- \nKevin\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/e1e5bf4e/attachment.html\u003e"}