Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.179 as permitted sender)
	client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f179.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CAAS2fgTJpFQKeVTQsAeqe0UK-2XhrLZG4oocEHM11_spWLtrEA@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
	<CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
	<CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
	<CAAS2fgTJpFQKeVTQsAeqe0UK-2XhrLZG4oocEHM11_spWLtrEA@mail.gmail.com>
Date: Wed, 23 Apr 2014 21:59:14 +0200
Message-ID: <CANEZrP0fUhiFeH4A1Y9sLCORpggJs3dxHz+exgpKaLQe9rgFeA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=089e01538848b973bb04f7bb2aeb
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
	Finney attacks
Precedence: list

--089e01538848b973bb04f7bb2aeb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> What you're talking about is just disagreement about the content of
> the memory pool
>

That's the same thing. Whilst you're mining your double spend tx, it's in
your mempool but you don't broadcast it as per normal. Then when you find
the block you broadcast it to override everyone elses mempool. So yours and
theirs were inconsistent.

The only slight way BitUndo differs is, they provide it as a service, and I
don't know if they inform you when they found a block (probably not), so
you have to do the purchase and then hope BitUndo finds the next block.
Otherwise the purchase clears. But they could certainly add a
pre-notification before they broadcast to get back to the exact scheme
originally described, they have everything else in place.


> Oscar himself can be implemented as a majority M parties to further
> increase confidence


This just brings us back to square one. Who are these parties and what if I
pay them to be corrupt? What if they offer to be corrupt as a service?

Let's say I succeed in finding some parties who are incorruptible no matter
how large of a percentage I offer them. At this point, why bother with
miners at all? Why pay for double spend protection twice, once to a group
of Oscar's who are trustworthy and once to a group of miners who are not?

The point of the broadcast network and mining is so there can be lots of
Oscar's and I don't have to know who they are or sign up with them or put
any effort into evaluating their reputation.


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

But as you point out, cheating my GHash.io did not result in any obvious
negative consequence to them, despite that preventing double spending is
their sole task. Why would Oscar be different to GHash.io?

Trying to solve the problem of dishonest miners is effectively trying to
solve the "automatically find trusted third parties" problem at scale.

--089e01538848b973bb04f7bb2aeb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"">What you&#39;re talking about is=
 just disagreement about the content of<br>
</div>
the memory pool<br></blockquote><div><br></div><div>That&#39;s the same thi=
ng. Whilst you&#39;re mining your double spend tx, it&#39;s in your mempool=
 but you don&#39;t broadcast it as per normal. Then when you find the block=
 you broadcast it to override everyone elses mempool. So yours and theirs w=
ere inconsistent.</div>
<div><br></div><div>The only slight way BitUndo differs is, they provide it=
 as a service, and I don&#39;t know if they inform you when they found a bl=
ock (probably not), so you have to do the purchase and then hope BitUndo fi=
nds the next block. Otherwise the purchase clears. But they could certainly=
 add a pre-notification before they broadcast to get back to the exact sche=
me originally described, they have everything else in place.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"">Oscar himself can be implemented as a majority M parties to=
 further<br></div>
increase confidence</blockquote><div><br></div><div>This just brings us bac=
k to square one. Who are these parties and what if I pay them to be corrupt=
? What if they offer to be corrupt as a service?</div><div><br></div><div>
Let&#39;s say I succeed in finding some parties who are incorruptible no ma=
tter how large of a percentage I offer them. At this point, why bother with=
 miners at all? Why pay for double spend protection twice, once to a group =
of Oscar&#39;s who are trustworthy and once to a group of miners who are no=
t?</div>
<div><br></div><div>The point of the broadcast network and mining is so the=
re can be lots of Oscar&#39;s and I don&#39;t have to know who they are or =
sign up with them or put any effort into evaluating their reputation.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">value retail transactions=
=E2=80=94 the fact that any cheating by oscar is<br>
cryptographically provable (just show them the double signatures)<br>
maybe be strong enough alone.<br></blockquote><div><br></div><div>But as yo=
u point out, cheating my GHash.io did not result in any obvious negative co=
nsequence to them, despite that preventing double spending is their sole ta=
sk. Why would Oscar be different to GHash.io?</div>
<div><br></div><div>Trying to solve the problem of dishonest miners is effe=
ctively trying to solve the &quot;automatically find trusted third parties&=
quot; problem at scale.</div></div></div></div>

--089e01538848b973bb04f7bb2aeb--