Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

[Kevin <kevinsisco61784@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5936 bytes --]

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@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


[-- Attachment #2: Type: text/html, Size: 8155 bytes --]