Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.181 as permitted sender)
	client-ip=209.85.213.181;
	envelope-from=christophe.biocca@gmail.com;
	helo=mail-ig0-f181.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
Date: Wed, 23 Apr 2014 08:43:56 -0400
Message-ID: <CANOOu=-9ngzfdzhred2hRkH2Zx=wfBXH0qd29xrxdcY+43AeTg@mail.gmail.com>
From: Christophe Biocca <christophe.biocca@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
	Finney attacks
Precedence: list

Just a few issues with the idea as it currently stands:

1. This provides a very strong incentive to always vote for
reallocating a block if it isn't yours, regardless of whether it's bad
or not (there's a positive expected return to voting to reallocate
coinbases from other miners). The incentive is bigger the more hash
power you have. You can partially address this by:
    a) Requiring supermajorities
    b) Requiring a vote to include proof of a double spend (that's not
a very strong safeguard, since anyone can create them after the fact
if one of their own transactions has been included).
    c) Burning, rather than reallocating, the coins. Miners' immediate
incentive to attack honest pools is much reduced.

2. BitUndo gets paid using additional txouts in the double-spend
transaction, no by miner's fees. This means that the coinbase
transaction will represent a smaller and smaller share of their
revenues over time (however if the total honest transaction fees they
get in their block are high enough, the risk of losing those might
still be enough).

On Wed, Apr 23, 2014 at 3:55 AM, Mike Hearn <mike@plan99.net> 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:
>
> 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.
>
> 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.
>
> 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:
>
> 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.
>
> 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
>