Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.181 as permitted sender)
	client-ip=209.85.217.181; envelope-from=gmaxwell@gmail.com;
	helo=mail-lb0-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 11:57:01 -0700
Message-ID: <CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
	Finney attacks
Precedence: list

On Wed, Apr 23, 2014 at 12:55 AM, Mike Hearn <mike@plan99.net> wrote:
> Lately someone launched Finney attacks as a service (BitUndo). As a remin=
der
> for newcomers, Finney attacks are where a miner secretly works on a block
> containing a double spend.

Hm? I didn't think this is at all what they did.  What they claim to
do is to prioritize transactions in their mempool from people who pay
them, potentially over and above other transactions which they may or
may not have received first.

This may still be bad news for someone taking an irreversible action
in response to an unconfirmed payment and it may or may not be really
ill advised in general, but I think it's less sinister than it sounds
in your posts.  Is there some reason to believe it isn't what it
claims to be?

I think we have very clear evidence that the Bitcoin community doesn't
care if miners reorder transactions in their mempool to profitable
ends: In https://bitcointalk.org/index.php?topic=3D327767.0 it's
demonstrated that GHash.IO, currently the largest publicly identified
pool was used to rip off Betcoin dice via double-spends.

> first started using Bitcoin, nowadays most of my purchases with it are fo=
r
> food and drink. If Bitcoin could not support such purchases, I would use =
it
> much less.

Accepting zero-conf inherently has some risk (well, so does all
business, but there is substantially more in a zero-conf payment).
Even in a spherical-cow Bitcoin absent anything like Bitundo someone
can just give a double spend to a large miner and currently give the
whole rest of the network the one paying the merchant.  They will,
with high success rate be successful.   Worse, it may _appear_ to the
network that the miner was a "bitundo" but they really were not.   The
blockchain exists to establish consensus ordering, prior to the
blockchain there is no order, and so it is not easy to really say
which transaction came first in any meaningful sense.

But in business we balance risks and the risk that sometimes a
transaction will be reversed exists in every electronic payment system
available today, in most of them the risk persists for _months_ rather
than minutes.  Businesses can still operate in the face of these
risks.

More importantly, it's possible to deploy technological approaches to
make zero-conf very secure against reversal: Things like performing
multi-sig with a anti-double-spending system, or using an external
federated payment network... but this stuff requires substantial
development work=E2=80=94 though it's not work thats likely to happen if
people are still confused about the level of security that zero-conf
has.

> Miners can vote to reallocate the coinbase value of bad blocks before the=
y
> mature.

I think miners 'voting' to reallocate coins, even if they're
thoroughly convinced that the owner of the coins is a nasty party, is
a much greater violation of the Bitcoin social contract than some
twiddling with the unspecified unconfirmed transaction ordering.

Doubly so because a 'nasty' party with non-trivial hash-power can
doublespend their own transactions with a pretty good success rate (as
was the case for the GHash.io betcoin spends) including not-just
zero-conf (though with obviously reduced effectiveness), and all of
your reliable detection depends on it being a public service.

A much better defense is having the control of hash power very well
distributed and so there isn't any central point that excerts enough
influence to change the risk statistics much.  Giving miners the
ability to steal each others payments is, if anything, a force away
from that decentralization.