Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.172 as permitted sender)
	client-ip=209.85.217.172; envelope-from=gmaxwell@gmail.com;
	helo=mail-lb0-f172.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
	<CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
	<CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
Date: Wed, 23 Apr 2014 12:47:46 -0700
Message-ID: <CAAS2fgTJpFQKeVTQsAeqe0UK-2XhrLZG4oocEHM11_spWLtrEA@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:19 PM, Mike Hearn <mike@plan99.net> wrote:
> That's the definition of a Finney attack, right?

A finney attack is where you attempt to mine a block with a
transaction paying you, and as soon as you are successful you quickly
make a transaction spending that coin to someone else, then release
the block after they've taken an irreversible action. If everything is
automated it should have something like a 99% success rate, though it
has a cost of some small increase in the number of orphan blocks you
experience.

> I mean, I hope that's the definition of a Finney attack, given that I coi=
ned
> the term :)

You might have coined the term, but I don't think the attack you're
describing is the attack Hal described:
https://bitcointalk.org/index.php?topic=3D3441.msg48384#msg48384

What you're talking about is just disagreement about the content of
the memory pool, but we have no consensus mechanism there (the
blockchain _is_ the consensus mechanism).  Mempools are sometimes
inconsistent all on their own, without any attacker being involved.

> These sorts of proposals are all just ways of saying block chains kind of
> suck and we should go back to using trusted third parties.

I think thats an unsophisticated view.

Consider this protocol.

I take some of my funds and assign them to a 2 of 2 multisig with
myself and Oscar. I do not announce this transaction until I get Oscar
to sign a timelocked anyonecanpay refund to send the coin back to me
(say in 3 months).  Oscar gives me my refund and I announce the
transaction.

Later I can make instant payments with oscar signing up until the
refund time comes clue to anyone who trusts Oscar to never double
spend.  For the receiver this is purely additive with regular
blockchain security: in that even with Oscar's help I cannot double
spend except where I would have been successful absent Oscar. On the
sender side, Oscar cannot up and steal my funds and he can't try to
extort me (except by creating a delay up to the refund time).

Oscar himself can be implemented as a majority M parties to further
increase confidence, though if you're talking about using this for low
value retail transactions=E2=80=94 the fact that any cheating by oscar is
cryptographically provable (just show them the double signatures)
maybe be strong enough alone. (Though there is a multitude of other
proposals to provide more evidence of Oscar's honesty). There are also
ways to blind Oscar so he can't reliably identify which transactions
are ones he signed for.

I don't think this is at all a "return to trusted third parties"=E2=80=94 t=
hat
it's a shrug and an admission of defeat. Its a very narrowly scoped
trust, filling in precisely where large scale decentralized consensus
is fundamentally weak... the result is something which combines
advantages from both classes and is stronger than either trust or
blockchains alone.  (I'm also not trying to say that an implementation
of this is _simple_ by any means, working out all the details is
hard.)

By contrast, I think proposals which overly depend on colluding miners
to behave in very specific ways are themselves just a way of saying
block chains suck unless we turn the miners themselves into a trusted
third party. I'm much more in favor of adding a little bit of
mastercard to transactions where mastercard is really what people
want, than turning mining=E2=80=94 and thus bitcoin itself=E2=80=94 into ma=
stercard,
especially since miners=E2=80=94 self selecting as they are=E2=80=94 are a =
pretty poor
set of parties to act as trusted agents. :)

>> Doubly so because a 'nasty' party with non-trivial hash-power can
>> doublespend their own transactions
> If a miner is vertically integrated and defrauding merchants themselves,
> with no service component, pretty quickly people would talk to each other=
,
> notice this pattern and stop trading with them, making their coins rather
> useless. Also if their real identity is ever revealed they could be liabl=
e
> and there'd be a lot of people wanting to sue them.

We have an existence proof that it isn't so=E2=80=94 you can say that it
wasn't consistent enough, but what is? There wasn't any major doubt
that they were actually doing it. They're the largest identifiable
pool as we speak.

I think, instead, that strong zero-conf security isn't a part of what
many people think of when they think of Bitcoin's characteristics.
Zero conf is risky, and I think for a lot of people thats okay.  If it
isn't there are ways to improve it that don't involve asking miners to
participate in a majority vote to take away funds from people.