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
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WdFC8-0005A5-EK
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 08:39:48 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.178 as permitted sender)
client-ip=209.85.214.178; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f178.google.com;
Received: from mail-ob0-f178.google.com ([209.85.214.178])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WdFC7-0007Z2-9Y
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 08:39:48 +0000
Received: by mail-ob0-f178.google.com with SMTP id wn1so2342180obc.9
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 01:39:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.142.229 with SMTP id rz5mr479655obb.12.1398328781981;
Thu, 24 Apr 2014 01:39:41 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Thu, 24 Apr 2014 01:39:41 -0700 (PDT)
In-Reply-To: <CAAS2fgQV0=QfCWhwVh6-mw=eg9MDd1E21P_7rFAnGp0P43c1Fw@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>
Date: Thu, 24 Apr 2014 10:39:41 +0200
X-Google-Sender-Auth: TV3-HSS58ZxJldHVemZOQJ8GCVY
Message-ID: <CANEZrP3vT6Q72X6PrcDQ8_fDeF90WmV4-M045Ac=kJY+PhuAdg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c362e654509804f7c5caab
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: 1WdFC7-0007Z2-9Y
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 08:39:48 -0000
--001a11c362e654509804f7c5caab
Content-Type: text/plain; charset=UTF-8
On Thu, Apr 24, 2014 at 10:19 AM, Gregory Maxwell <gmaxwell@gmail.com>wrote:
> This is not voting.
>
It absolutely is! It was widely discussed as such at the time, here is a
thread where people ask how to vote and the operator of Eclipse said he was
removing his vote for P2SH:
https://bitcointalk.org/index.php?topic=60937.0
You might not feel it's a particularly fair or representative vote, but
it's still miners saying "I support enforcement of this new rule" or "I do
not support this" where the majority of cast votes wins. Some miners have
more votes than others, but it's still a vote.
> Yes, making really distributed systems that work in a complex world is
> hard. It certantly would be /easier/ to just declare miners "trusted
> parties"
>
Miners *are* trusted parties, they are just not all trusted simultaneously.
Bitcoin can tolerate a small number of dishonest miners whilst producing a
degraded service. It cannot work if all miners are dishonest or decide to
deviate from their intended operation, like if they all produce empty
blocks. The white paper made this clear from the start, and it's also
common sense.
Allowing the majority of honest miners to keep the dishonest ones in check
is what Bitcoin is all about. I don't understand this view that a very
small change to the existing protocol is somehow terrible or impossible,
but expecting everyone to simply build an entirely new system from scratch
is easy and inevitable. I'd much prefer to just keep the existing system
working as well as it has so far, and I think that is true of most users
too.
> Temporarily censoring transactions by orphaning otherwise valid blocks
> that contain them for as long as you retain a majority is possible
No, coinbases are deletable. If some miners fork the chain and build a
longer one, the others will all switch to it and the coinbases blocks they
previously mined will never become spendable (effectively they were
"deleted" before maturity). Only if the other miners also blacklist the
majorities fork and never join it, then the majority for some reason gives
up and rejoins the minority, is what you described correct. But why would
they do that? If they're the majority then all the other nodes will follow
them. They have no incentive to throw away their fork and rejoin the
minority chain ever again.
I think the root of this disagreement is whether the block chain algorithm
left by Satoshi is somehow immutable and itself the end, or whether it's
(as I see it) just a means to an end and therefore an algorithm that can be
tweaked and improved, to get us closer to the goal.
If the end is a useful payments system, as decentralised as possible, that
prevents double spending, then this proposal is a simple enhancement of the
current system that ensures corrupt miners don't get paid by honest users
for services they didn't provide, thus discouraging a particular kind of
attack.
--001a11c362e654509804f7c5caab
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">On T=
hu, Apr 24, 2014 at 10:19 AM, Gregory Maxwell <span dir=3D"ltr"><<a href=
=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>>=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"">This is not voting.<br></div></blockquote>=
<div>
<br></div><div>It absolutely is! It was widely discussed as such at the tim=
e, here is a thread where people ask how to vote and the operator of Eclips=
e said he was removing his vote for P2SH:</div><div><br></div><div><a href=
=3D"https://bitcointalk.org/index.php?topic=3D60937.0">https://bitcointalk.=
org/index.php?topic=3D60937.0</a><br>
</div><div><br></div><div>You might not feel it's a particularly fair o=
r representative vote, but it's still miners saying "I support enf=
orcement of this new rule" or "I do not support this" where =
the majority of cast votes wins. Some miners have more votes than others, b=
ut it's still a vote.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div class=3D""></div><div class=3D"">Yes=
, making really distributed systems that work in a complex world is<br>
</div>
hard. It certantly would be /easier/ to just declare miners "trusted<b=
r>
parties"<br></blockquote><div><br></div><div>Miners <b>are</b>=C2=A0tr=
usted parties, they are just not all=C2=A0trusted simultaneously. Bitcoin c=
an tolerate a small number of dishonest miners whilst producing a degraded =
service. It cannot work if all miners are dishonest or decide to deviate fr=
om their intended operation, like if they all produce empty blocks. The whi=
te paper made this clear from the start, and it's also common sense.</d=
iv>
<div><br></div><div>Allowing the majority of honest miners to keep the dish=
onest ones in check is what Bitcoin is all about. I don't understand th=
is view that a very small change to the existing protocol is somehow terrib=
le or impossible, but expecting everyone to simply build an entirely new sy=
stem from scratch is easy and inevitable. I'd much prefer to just keep =
the existing system working as well as it has so far, and I think that is t=
rue of most users too.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
<div class=3D"">Temporarily censoring transactions by orphaning otherwise v=
alid blocks<br></div>
that contain them for as long as you retain a majority is possible</blockqu=
ote><div><br></div><div>No, coinbases are deletable. If some miners fork th=
e chain and build a longer one, the others will all switch to it and the co=
inbases blocks they previously mined will never become spendable (effective=
ly they were "deleted" before maturity). Only if the other miners=
also blacklist the majorities fork and never join it, then the majority fo=
r some reason gives up and rejoins the minority, is what you described corr=
ect. But why would they do that? If they're the majority then all the o=
ther nodes will follow them. They have no incentive to throw away their for=
k and rejoin the minority chain ever again.</div>
<div><br></div><div>I think the root of this disagreement is whether the bl=
ock chain algorithm left by Satoshi is somehow immutable and itself the end=
, or whether it's (as I see it) just a means to an end and therefore an=
algorithm that can be tweaked and improved, to get us closer to the goal.<=
/div>
<div><br></div><div>If the end is a useful payments system, as decentralise=
d as possible, that prevents double spending, then this proposal is a simpl=
e enhancement of the current system that ensures corrupt miners don't g=
et paid by honest users for services they didn't provide, thus discoura=
ging a particular kind of attack.</div>
</div></div></div>
--001a11c362e654509804f7c5caab--
|
