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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1Z4ocS-0002qO-Da
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Jun 2015 11:01:28 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.174 as permitted sender)
client-ip=209.85.220.174; envelope-from=tier.nolan@gmail.com;
helo=mail-qk0-f174.google.com;
Received: from mail-qk0-f174.google.com ([209.85.220.174])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z4ocR-0000VS-3f
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Jun 2015 11:01:28 +0000
Received: by qkhu186 with SMTP id u186so6622659qkh.0
for <bitcoin-development@lists.sourceforge.net>;
Tue, 16 Jun 2015 04:01:21 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.48.79 with SMTP id w76mr33070867qkw.21.1434452481705;
Tue, 16 Jun 2015 04:01:21 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Tue, 16 Jun 2015 04:01:21 -0700 (PDT)
In-Reply-To: <557FB198.7080905@mail.bihthai.net>
References: <CALqxMTGBt7MNs5YWf8QzKe+4Fr-uKVimf8=VbytBANEDm=s50g@mail.gmail.com>
<CANEZrP31AEson9DZ=ZU7d4t=DvmGodh1ja6EaZ6xQZ3bFEXeVA@mail.gmail.com>
<557FB198.7080905@mail.bihthai.net>
Date: Tue, 16 Jun 2015 12:01:21 +0100
Message-ID: <CAE-z3OVGYmXJa3crAPX=PtJdmrCqq3T5akkxHbvMm2nCE4968w@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a114902249e8d4c0518a07eb6
X-Spam-Score: 0.6 (/)
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
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1Z4ocR-0000VS-3f
Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork &
non-consensus hard-fork
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: Tue, 16 Jun 2015 11:01:28 -0000
--001a114902249e8d4c0518a07eb6
Content-Type: text/plain; charset=UTF-8
On Tue, Jun 16, 2015 at 6:18 AM, Venzen <venzen@mail.bihthai.net> wrote:
> Mike Hearn, you should cease your activity of a unilateral hard-fork
> immediately. You are doing untold damage by breaking FOSS governance
> protocol requiring methodical collaborative work and due process of
> change implementation by consensus.
The main principle of open source software is that anyone can fork the code
if they wish. They don't do it very often, but they can.
This means that if a project dies, someone can take it over. If some of
the devs want to take things in a different direction, they can. Users can
decide which version they prefer.
The software itself is what is valuable.
In the case of bitcoin, the blockchain is also (very) valuable. Simply
splitting into two projects is not possible for bitcoin.
Otherwise, the discussion would have ended already, those who want a larger
block would simply create a fork of the software and create an alt chain.
The fundamental problem is that there is no clear way to make this decision
once and for all.
An agreed set of rules for a hard fork would be a nice thing to have, but
it is hard to have rules about how to change fundamental rules.
I think using the soft fork rules (maybe with a higher threshold than 95%)
plus a delay is a reasonable compromise on hard fork rules.
Even then, it would be nice to include users of the software too. Peter
Todd's suggestion of encoding a vote in transactions is a step in that
direction (YES transactions in YES blocks and NO transactions in NO blocks).
> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
> you cannot have it.
Nobody owns it, so there is no court of final appeal.
If miners vote >95% for the fork, users could still refuse to accept the
change.
Maybe the sequence could be
version 3 blocks means no opinion
version 4 blocks means NO to fork
version 5 blocks means YES to fork & YES transactions
version 6 blocks means YES to fork & NO transactions
Transaction matching rule:
version 1, 2, 3 transactions means no opinion (can be in any block)
version 4 transactions means YES to fork (cannot be in version 6 blocks)
version 5 transactions means NO to fork (cannot be in version 5 blocks)
Rules
0) if 750 of the last 1000 blocks are version 5 or 6 blocks, tx matching
rule activates for version 5 & 6 blocks
1) if 950 of the last 1000 blocks are version 5 or 6 blocks, then version 4
blocks are rejected
2) if 750 of the last 1000 blocks are version 4 blocks, then version 5 & 6
blocks are rejected
3) if 750 of the last 1000 blocks are version 5 transactions and 950 of the
last 1000 are version 5 or 6, then the fork is accepted
4) 25,000 blocks after 3 is accepted, hard fork actually takes effect
Once miner acceptance is achieved, then only version 5 and 6 blocks are
allowed. The split between version 5 and 6 blocks should be roughly in
proportion to the number of transactions of each kind produced.
75% of miners can kill the fork by producing version 4 blocks, but 95% is
needed for acceptance. Even then, transaction volume needs to support the
fork. I think 75% is reasonable here. (95% of miners and 75% of
merchants/users is a pretty strong majority).
> You may accuse the community for being antagonistic to you, and
> therefore uncooperative, but it is plain to see that your bullheaded
> manner eventually generates antagonism wherever you go. Taking Bitcoin
> away from this community, in anger, won't solve the problem and will
> be like killing the goose that lays the golden eggs.
>
They are still suggesting some kind of fork threshold process (or at least
that is what is being suggested)
If their system requires 95% miner approval, they aren't taking unilateral
action. Miners are though if they vote in favour.
--001a114902249e8d4c0518a07eb6
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=
ue, Jun 16, 2015 at 6:18 AM, Venzen <span dir=3D"ltr"><<a href=3D"mailto=
:venzen@mail.bihthai.net" target=3D"_blank">venzen@mail.bihthai.net</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Mike Hearn, you should cease your activity of a unilateral hard-fork<br>
immediately. You are doing untold damage by breaking FOSS governance<br>
protocol requiring methodical collaborative work and due process of<br>
change implementation by consensus.</blockquote><div><br></div><div>The mai=
n principle of open source software is that anyone can fork the code if the=
y wish.=C2=A0 They don't do it very often, but they can.<br><br></div><=
div>This means that if a project dies, someone can take it over.=C2=A0 If s=
ome of the devs want to take things in a different direction, they can.=C2=
=A0 Users can decide which version they prefer.<br></div><div><br></div><di=
v>The software itself is what is valuable.=C2=A0 <br><br>In the case of bit=
coin, the blockchain is also (very) valuable.=C2=A0 Simply splitting into t=
wo projects is not possible for bitcoin.<br><br></div><div>Otherwise, the d=
iscussion would have ended already, those who want a larger block would sim=
ply create a fork of the software and create an alt chain.<br></div><div><b=
r></div><div>The fundamental problem is that there is no clear way to make =
this decision once and for all.<br><br></div><div>An agreed set of rules fo=
r a hard fork would be a nice thing to have, but it is hard to have rules a=
bout how to change fundamental rules.<br><br></div><div>I think using the s=
oft fork rules (maybe with a higher threshold than 95%) plus a delay is a r=
easonable compromise on hard fork rules.=C2=A0 <br><br>Even then, it would =
be nice to include users of the software too.=C2=A0 Peter Todd's sugges=
tion of encoding a vote in transactions is a step in that direction (YES tr=
ansactions in YES blocks and NO transactions in NO blocks).<br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,<br>
you cannot have it. </blockquote><div><br></div><div>Nobody owns it, so the=
re is no court of final appeal.=C2=A0 <br><br></div><div>If miners vote >=
;95% for the fork, users could still refuse to accept the change.<br><br></=
div><div>Maybe the sequence could be <br><br></div><div>version 3 blocks me=
ans no opinion<br></div><div>version 4 blocks means NO to fork<br></div><di=
v>version 5 blocks means YES to fork & YES transactions<br></div><div>v=
ersion 6 blocks means YES to fork & NO transactions<br></div><div><br><=
/div><div>Transaction matching rule:<br><br></div><div>version 1, 2, 3 tran=
sactions means no opinion (can be in any block)<br></div><div>version 4 tra=
nsactions means YES to fork (cannot be in version 6 blocks)<br></div><div>v=
ersion 5 transactions means NO to fork (cannot be in version 5 blocks)<br><=
/div><div><br></div><div>Rules<br></div><div>0) if 750 of the last 1000 blo=
cks are version 5 or 6 blocks, tx matching rule activates for version 5 &am=
p; 6 blocks<br></div><div>1) if 950 of the last 1000 blocks are version 5 o=
r 6 blocks, then version 4 blocks are rejected<br></div><div>2) if 750 of t=
he last 1000 blocks are version 4 blocks, then version 5 & 6 blocks are=
rejected<br></div><div>3) if 750 of the last 1000 blocks are version 5 tra=
nsactions and 950 of the last 1000 are version 5 or 6, then the fork is acc=
epted<br></div><div>4) 25,000 blocks after 3 is accepted, hard fork actuall=
y takes effect<br></div><div><br>Once miner acceptance is achieved, then on=
ly version
5 and 6 blocks are allowed.=C2=A0 The split between version 5 and 6 blocks=
=20
should be roughly in proportion to the number of transactions of each=20
kind produced. =C2=A0=C2=A0 <br><br></div><div>75% of miners can kill the f=
ork by producing version 4 blocks, but 95% is needed for acceptance.=C2=A0 =
Even then, transaction volume needs to support the fork.=C2=A0 I think 75% =
is reasonable here.=C2=A0 (95% of miners and 75% of merchants/users is a pr=
etty strong majority).</div><div></div><div>=C2=A0<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">
You may accuse the community for being antagonistic to you, and<br>
therefore uncooperative, but it is plain to see that your bullheaded<br>
manner eventually generates antagonism wherever you go. Taking Bitcoin<br>
away from this community, in anger, won't solve the problem and will<br=
>
be like killing the goose that lays the golden eggs.<br></blockquote><div><=
br></div><div>They are still suggesting some kind of fork threshold process=
(or at least that is what is being suggested)<br><br></div><div>If their s=
ystem requires 95% miner approval, they aren't taking unilateral action=
.=C2=A0 Miners are though if they vote in favour.<br></div></div></div></di=
v>
--001a114902249e8d4c0518a07eb6--
|
