Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.170 as permitted sender)
	client-ip=209.85.214.170; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f170.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CAAS2fgQFx7-0vZ2AR3RnLORZZCqjBFHyUBqj688Jrz8OuMYPKA@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
	<CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
	<CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
	<CAE28kUSLXG0y350gMiwnv0CoOHUorMgLup9TG77Mjj+BJcuowA@mail.gmail.com>
	<CANEZrP0j0KoLUB+SE+W3fL8vTKay0niqoeQ38RKnU9cyGgvvYw@mail.gmail.com>
	<CAAS2fgQV0=QfCWhwVh6-mw=eg9MDd1E21P_7rFAnGp0P43c1Fw@mail.gmail.com>
	<CANEZrP3vT6Q72X6PrcDQ8_fDeF90WmV4-M045Ac=kJY+PhuAdg@mail.gmail.com>
	<CAAS2fgQFx7-0vZ2AR3RnLORZZCqjBFHyUBqj688Jrz8OuMYPKA@mail.gmail.com>
Date: Thu, 24 Apr 2014 11:56:23 +0200
Message-ID: <CANEZrP18=Y5EBcfR-sHumVvU3-yqYr1tuhr_J4ieG817HOpE=g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b471e7095b8c504f7c6dcd4
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
	Finney attacks
Precedence: list

--047d7b471e7095b8c504f7c6dcd4
Content-Type: text/plain; charset=UTF-8

>
> Yes, you can reorg out the blocks and actually remove them, but I
>
understood that you were _not_ proposing that quite specifically. But
> instead proposed without reorging taking txouts that were previously
> assigned to one party and simply assigning them to others.
>

Well, my original thought was just to delete the coinbases. But then some
people don't like the idea of destroying money (equivalently, reducing the
system's resolution) so I proposed reallocating it instead. I'm not sure
which is better though. Deletion is closer to what the existing system
allows, for sure.

Would you feel differently if the consequence was UTXO deletion rather than
reallocation? I think the difference makes no impact to the goal of
discouraging double spending.


> ... proposing the mechanism be used to claw back mining income from a
> hardware vendor accused of violating its agreements on the amount of
> self mining / mining on customers hardware.
>

I think this would not be doable in practice, unless there was a way to
identify that a block was mined with pre-sold equipment. Peter points out
that the pool in question is marking their blocks by reusing addresses -
ditto for the double spending against dice sites - but that's a trivial
thing for them to fix. Then it'd be difficult (impossible?) for miners to
identify KnC blocks even if there was a strong majority consensus to delete
their coinbases.

The reason I think this particular change is doable is that it should be
possible to quite reliably identify blocks that are Finney attacking for
profit. That doesn't generalise to any policy though. Blocks are intended
to be structurally identical to each other if best practices are followed
and even with the dire pool situation a big chunk of mining hash power
today is effectively anonymous.

--047d7b471e7095b8c504f7c6dcd4
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">Yes, you can reorg out the blocks and actually r=
emove them, but I<br>
</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
understood that you were _not_ proposing that quite specifically. But<br>
instead proposed without reorging taking txouts that were previously<br>
assigned to one party and simply assigning them to others.<br></blockquote>=
<div><br></div><div>Well, my original thought was just to delete the coinba=
ses. But then some people don&#39;t like the idea of destroying money (equi=
valently, reducing the system&#39;s resolution) so I proposed reallocating =
it instead. I&#39;m not sure which is better though. Deletion is closer to =
what the existing system allows, for sure.</div>
<div><br></div><div>Would you feel differently if the consequence was UTXO =
deletion rather than reallocation? I think the difference makes no impact t=
o the goal of discouraging double spending.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">

<div class=3D"">... proposing the mechanism be used to claw back mining inc=
ome from a<br></div>
hardware vendor accused of violating its agreements on the amount of<br>
self mining / mining on customers hardware.<br></blockquote><div><br></div>=
<div>I think this would not be doable in practice, unless there was a way t=
o identify that a block was mined with pre-sold equipment. Peter points out=
 that the pool in question is marking their blocks by reusing addresses - d=
itto for the double spending against dice sites - but that&#39;s a trivial =
thing for them to fix. Then it&#39;d be difficult (impossible?) for miners =
to identify KnC blocks even if there was a strong majority consensus to del=
ete their coinbases.</div>
<div><br></div><div>The reason I think this particular change is doable is =
that it should be possible to quite reliably identify blocks that are Finne=
y attacking for profit. That doesn&#39;t generalise to any policy though. B=
locks are intended to be structurally identical to each other if best pract=
ices are followed and even with the dire pool situation a big chunk of mini=
ng hash power today is effectively anonymous.</div>
<div><br></div><div><br></div></div></div></div>

--047d7b471e7095b8c504f7c6dcd4--