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