summaryrefslogtreecommitdiff
path: root/64/83b7d380ce5ecb763493eead606ed0da65996b
blob: 87b072b348dc84df04af92959a03fd3a0a48de40 (plain)
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
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
Return-Path: <not.mike.hearn@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A81B3196B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  5 Oct 2015 18:50:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f196.google.com (mail-ig0-f196.google.com
	[209.85.213.196])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E257B159
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  5 Oct 2015 18:50:54 +0000 (UTC)
Received: by igbgg5 with SMTP id gg5so10833607igb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 05 Oct 2015 11:50:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=DzuZggw/y8QCIJd88eicxIKjF7lPDPkuFWZyejmA40g=;
	b=0IqEe2VIk/s79qgCu5hAlrczX/it4yQUET3Sbpmq/1LcpH/DSlklqAluXfIEvm+0Ix
	+hlzmOmwynQwzE8qtf1qunsXU6CyV0dCxPqxby6Qdx736HvFJyu097E8QnurW664WsQG
	1nOO97iP2Q/a91P3Vswl8hA6Z/oW78nhp68uo+TGGuhkk8qfYaPFT716IPLiAWV7ao2B
	2/5EQbHmMhQlFvM8Ixoi3oDUNaTjQw9MaLjKiO5Fonm5e76+XT57lM+OdYFW4haskn3b
	QMZ7M2TGdFNOr7h8kDvRscJu6oPUlYdUw8LNm6elkD7E5FOO5Kg0zO+vWMAiNdr1GfT7
	v68g==
MIME-Version: 1.0
X-Received: by 10.50.73.97 with SMTP id k1mr11793597igv.43.1444071054324; Mon,
	05 Oct 2015 11:50:54 -0700 (PDT)
Received: by 10.64.223.164 with HTTP; Mon, 5 Oct 2015 11:50:54 -0700 (PDT)
In-Reply-To: <10955467.d0sKIOBqLD@garp>
References: <CAKzdR-rPoByn=+CgsTc1ZnLkjwtYyJnbQLbn-VHOvz0dLciefQ@mail.gmail.com>
	<2142297.qudDqxHTIz@garp>
	<CAAS2fgQhWSLSZgNr9rUQ6-iamnh0ZsHdXui59e7xmTa94zYhpw@mail.gmail.com>
	<10955467.d0sKIOBqLD@garp>
Date: Mon, 5 Oct 2015 14:50:54 -0400
Message-ID: <CAKfs=Z8=wHee9aMaezbMArj2AOE1xEVFHR4_BY6ahtAoz1yfdw@mail.gmail.com>
From: NotMike Hearn <not.mike.hearn@gmail.com>
To: Tom Zander <tomz@freedommail.ch>
Content-Type: multipart/alternative; boundary=089e0122eb6639424a05215ffe1e
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork
 technical debate
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2015 18:50:55 -0000

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

For soft forks, consensus is required. In fact, we (today) have miners who
individually choose to mine blocks that are completely empty, with no known
input from (or communication with) the outside world. This is a consensus
process. Users can switch back and forth all they like, and this only
happens when there is unanimous miner-developer consensus. Most of the time
they don't even know, that they are under consensus.

It is only "controversial hard forks" which DON'T require wide agreement
and developer endorsements. Hear me out.

This is because, with zero dev-agreement, we have two benefits: first,
there are tremendous security issues which can be fixed by trying more than
one hard fork at once (these fixes can prevent loss of funds), and, second,
because each fork is equally Acked and Nacked (a Schrodinger's Ack, if you
will), they will have equal standing, and therefore users will be equally
indifferent to both forks and they will both live for a long time (and
users will be able to pick the fork that best fits them, empowering the
user).

People have overlooked how simple this issue is because of the political
climate. We need a climate change, pardon the pun.

On Mon, Oct 5, 2015 at 2:33 PM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Monday 5. October 2015 18.04.48 Gregory Maxwell wrote:
> > > Unsuccessfully.
> >
> > I think rather successfully.
>
> Arguing that BIP66 rollout was a full success is in the same park of
> "successful" ?
> Where for weeks people were told not to trust the longest chain until it
> was
> 30 blocks.
> Lets put that in perspective. The main functionality of Bitcoin
> Frankly, if that fiasco happened in a company, people would get fired for
> gross misconduct.
>
> Bottom line is that there is a horrible track record of doing soft forks =
in
> the past, there are some really good technical reasons why this should no=
t
> happen again.
>
> And the defence against this argument is to do character assassination
> because
> you think he has ulterior motives?  Like you say in this part;
>
> > That Mike himself continues to misexplain
> > things is not surprising since he has all but outright said that his
> > motivation here is to disrupt Bitcoin in order to try to force his
> > blocksize hardfork on people.
>
> "all but outright said" is still not said. Is still just a suspicion you
> have.
> And you are accusing a man of something he didn't do.
> That=E2=80=99s just not right.
>
> > > The point is that Bitcoin Core claims to have a consensus mechanism a=
nd
> > > sticks to "no change" on not reaching a consensus. And that rule is t=
he
> > > reason why bigger blocks were blocked for years.
> >
> > You're repeating Mike's claims there-- not anyone elses. Take your
> > complaint up with him-- not the list.
>
> There is no complaint. Why do you think there is?
> Are you claiming that not reaching consensus is NOT the reason that bigge=
r
> blocks are not in Bitcoin Core?
>
>
> Reaching consensus is an admirable goal. But its exactly that, a goal.
> And anyone that is a perfectionist will know that in the real world goals
> are
> often not reached. That doesn't make them less useful. That makes them
> goals.
> This specific goal is in conflict of building a good product and a well
> functioning community.
>
> A good product and a well functioning community needs rules and needs
> timely
> decisions and conflict resolution.
> It does not need muting of valuable voices, it does not need character
> assassinations and it really doesn't need egos.
>
> I suggest reading this book;
> http://www.artofcommunityonline.org/
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">For soft forks, consensus is required. In fact, we (today)
 have miners who individually choose to mine blocks that are completely emp=
ty, with no known input from (or communication with) the outside world. Thi=
s is a consensus process. Users can switch=20
back and forth all they like, and this only happens when there is unanimous=
 miner-developer consensus. Most of the time they=20
don&#39;t even know, that they are under consensus.<br>
<br>
It is only &quot;controversial hard forks&quot; which DON&#39;T require wid=
e agreement and=20
developer endorsements. Hear me out.<br><br>This is because, with zero dev-=
agreement, we have two benefits: first, there are=20
tremendous security issues which can be fixed by trying more than one hard =
fork at once (these fixes can prevent loss of funds), and, second, because =
each fork is equally Acked and Nacked (a Schrodinger&#39;s Ack, if you will=
), they will have equal standing, and therefore users will be equally indif=
ferent to both forks and they will both live for a long time (and users wil=
l be able to pick the fork that best fits them, empowering the user).<br><b=
r>People have overlooked how simple this issue is because of the political =
climate. We need a climate change, pardon the pun.</div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Mon, Oct 5, 2015 at 2:33 PM, Tom =
Zander via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat=
ion.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">On Monday 5. October <a href=3D"tel:2015%2018.04.48" value=3D"+120151=
80448">2015 18.04.48</a> Gregory Maxwell wrote:<br>
&gt; &gt; Unsuccessfully.<br>
&gt;<br>
&gt; I think rather successfully.<br>
<br>
</span>Arguing that BIP66 rollout was a full success is in the same park of=
<br>
&quot;successful&quot; ?<br>
Where for weeks people were told not to trust the longest chain until it wa=
s<br>
30 blocks.<br>
Lets put that in perspective. The main functionality of Bitcoin<br>
Frankly, if that fiasco happened in a company, people would get fired for<b=
r>
gross misconduct.<br>
<br>
Bottom line is that there is a horrible track record of doing soft forks in=
<br>
the past, there are some really good technical reasons why this should not<=
br>
happen again.<br>
<br>
And the defence against this argument is to do character assassination beca=
use<br>
you think he has ulterior motives?=C2=A0 Like you say in this part;<br>
<span class=3D""><br>
&gt; That Mike himself continues to misexplain<br>
&gt; things is not surprising since he has all but outright said that his<b=
r>
&gt; motivation here is to disrupt Bitcoin in order to try to force his<br>
&gt; blocksize hardfork on people.<br>
<br>
</span>&quot;all but outright said&quot; is still not said. Is still just a=
 suspicion you have.<br>
And you are accusing a man of something he didn&#39;t do.<br>
That=E2=80=99s just not right.<br>
<span class=3D""><br>
&gt; &gt; The point is that Bitcoin Core claims to have a consensus mechani=
sm and<br>
&gt; &gt; sticks to &quot;no change&quot; on not reaching a consensus. And =
that rule is the<br>
&gt; &gt; reason why bigger blocks were blocked for years.<br>
&gt;<br>
&gt; You&#39;re repeating Mike&#39;s claims there-- not anyone elses. Take =
your<br>
&gt; complaint up with him-- not the list.<br>
<br>
</span>There is no complaint. Why do you think there is?<br>
Are you claiming that not reaching consensus is NOT the reason that bigger<=
br>
blocks are not in Bitcoin Core?<br>
<br>
<br>
Reaching consensus is an admirable goal. But its exactly that, a goal.<br>
And anyone that is a perfectionist will know that in the real world goals a=
re<br>
often not reached. That doesn&#39;t make them less useful. That makes them =
goals.<br>
This specific goal is in conflict of building a good product and a well<br>
functioning community.<br>
<br>
A good product and a well functioning community needs rules and needs timel=
y<br>
decisions and conflict resolution.<br>
It does not need muting of valuable voices, it does not need character<br>
assassinations and it really doesn&#39;t need egos.<br>
<br>
I suggest reading this book;<br>
<a href=3D"http://www.artofcommunityonline.org/" rel=3D"noreferrer" target=
=3D"_blank">http://www.artofcommunityonline.org/</a><br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>

--089e0122eb6639424a05215ffe1e--