{"type":"rich","version":"1.0","author_name":"npub1mtxs7jztn027d9cylej99hltqq9vq84uxm80zl4naxafd9hpxqwsj9g5zm","author_url":"https://nostr.ae/npub1mtxs7jztn027d9cylej99hltqq9vq84uxm80zl4naxafd9hpxqwsj9g5zm","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-23\n📝 Original message:Just a few issues with the idea as it currently stands:\n\n1. This provides a very strong incentive to always vote for\nreallocating a block if it isn't yours, regardless of whether it's bad\nor not (there's a positive expected return to voting to reallocate\ncoinbases from other miners). The incentive is bigger the more hash\npower you have. You can partially address this by:\n    a) Requiring supermajorities\n    b) Requiring a vote to include proof of a double spend (that's not\na very strong safeguard, since anyone can create them after the fact\nif one of their own transactions has been included).\n    c) Burning, rather than reallocating, the coins. Miners' immediate\nincentive to attack honest pools is much reduced.\n\n2. BitUndo gets paid using additional txouts in the double-spend\ntransaction, no by miner's fees. This means that the coinbase\ntransaction will represent a smaller and smaller share of their\nrevenues over time (however if the total honest transaction fees they\nget in their block are high enough, the risk of losing those might\nstill be enough).\n\nOn Wed, Apr 23, 2014 at 3:55 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e Lately someone launched Finney attacks as a service (BitUndo). As a reminder\n\u003e for newcomers, Finney attacks are where a miner secretly works on a block\n\u003e containing a double spend. When they eventually find a block, they run to\n\u003e the merchant and pay, then broadcast the block. In a simpler variant of this\n\u003e attack you make purchases as normal with a modified wallet that always\n\u003e submits a double spend to the service, and then N% of the time where N is\n\u003e the percentage of overall hash power the dishonest miners have, you get your\n\u003e money back minus their fee.\n\u003e\n\u003e N does not need to be very high to render Bitcoin much less useful. Real\n\u003e time transactions are very important. Although I never expected it when I\n\u003e first started using Bitcoin, nowadays most of my purchases with it are for\n\u003e food and drink. If Bitcoin could not support such purchases, I would use it\n\u003e 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 win\n\u003e about 40% of chargeback disputes. So if N was only, say, 5%, and there was a\n\u003e large enough population of users who were systematically trying to defraud\n\u003e merchants, we'd already be having worse security than magstripe credit\n\u003e cards. EMV transactions have loss rates in the noise, so for merchants who\n\u003e take those Bitcoin would be dramatically less secure.\n\u003e\n\u003e The idea of discouraging blocks that perform Finney attacks by having honest\n\u003e miners refuse to build on them has been proposed. But it has a couple of\n\u003e problems:\n\u003e\n\u003e It's hard to automatically detect Finney attacks. Looking for blocks that\n\u003e contain unseen transactions that override the mempool doesn't work - the\n\u003e dishonest users could broadcast all their double spends once a Finney block\n\u003e was found and then broadcast the block immediately afterwards, thus making\n\u003e the block look like any other would in the presence of double spends.\n\u003e\n\u003e If they could be automatically identified, it possibly could be converted\n\u003e into a DoS on the network by broadcasting double spends in such a way that\n\u003e the system races, and every miner produces a block that looks like a Finney\n\u003e attack to some of the others. The chain would stop advancing.\n\u003e\n\u003e Miners who want to vote \"no\" on a block take a big risk, they could be on\n\u003e 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 Dishonest blocks can be identified out of band, by having honest miners\n\u003e submit double spends against themselves to the service anonymously using a\n\u003e separate tool. When their own double spend appears they know the block is\n\u003e bad.\n\u003e\n\u003e Miners can vote to reallocate the coinbase value of bad blocks before they\n\u003e mature. If a majority of blocks leading up to maturity vote for\n\u003e reallocation, the value goes into a pot that subsequent blocks are allowed\n\u003e to claim for themselves. Thus there is no risk to voting \"no\" on a block,\n\u003e the work done by the Finney attacker is not wasted, and users do not have to\n\u003e suffer through huge reorgs.\n\u003e\n\u003e This may seem a radical suggestion, but I think it's much less radical than\n\u003e some of the others being thrown around.\n\u003e\n\u003e The above approach works as long as the majority of hashpower is honest,\n\u003e defined to mean, working to stop double spending. This is the same security\n\u003e property as described in the white paper, thus this introduces no new\n\u003e security assumptions. Note that assuming all miners are dishonest and are\n\u003e willing to double spend automatically resolves the Bitcoin experiment as a\n\u003e failure, because that would invalidate the entire theory upon which the\n\u003e system is built. That doesn't mean the assumption is wrong! It may be that\n\u003e an entirely unregulated market for double spending prevention cannot work\n\u003e and the participants eventually all end up trashing the commons - but the\n\u003e hope is that smart incentives can replace the traditional reliance on law\n\u003e 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 bitcoins. A\n\u003e majority of miners can already reallocate coinbases by forking them out, but\n\u003e this wastes energy and work presenting a significant discouragement to vote\n\u003e unless you already know via some out of band mechanism that you have a solid\n\u003e majority. Placing votes into the coinbase scriptSig as is done with other\n\u003e things avoids that 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 RPC. It\n\u003e can be expected that double spending services would try to identify and\n\u003e block the sentinel transactions, which is why it's better to have the code\n\u003e that fights this arms race be out of process and developed externally to\n\u003e Bitcoin Core itself, which should ultimately just enforce the new (forking)\n\u003e rule change.\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 Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e"}