1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WdGOL-0002ax-EI
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 09:56:29 +0000
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;
Received: from mail-ob0-f170.google.com ([209.85.214.170])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WdGOK-0006zZ-H6
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 09:56:29 +0000
Received: by mail-ob0-f170.google.com with SMTP id vb8so2423145obc.29
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 02:56:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.132.75 with SMTP id os11mr697149oeb.70.1398333383225;
Thu, 24 Apr 2014 02:56:23 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Thu, 24 Apr 2014 02:56:23 -0700 (PDT)
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
X-Google-Sender-Auth: FFLPz7LTqPsAAVd1IxRRksxFk50
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
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WdGOK-0006zZ-H6
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
Finney attacks
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 24 Apr 2014 09:56:29 -0000
--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't like the idea of destroying money (equi=
valently, 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.</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'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 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'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--
|
