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
|
Return-Path: <Peter_R@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0327D1B47
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 17:34:04 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D417D219
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 17:34:02 +0000 (UTC)
Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx103)
with ESMTPSA (Nemesis) id 0M24Vr-1abopo4B35-00u4xa;
Mon, 05 Oct 2015 19:34:00 +0200
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/alternative;
boundary="Apple-Mail=_0D9EA63B-7F22-4FCA-9D68-48A794B91B68"
From: Peter R <peter_r@gmx.com>
In-Reply-To: <5612ACF3.2080006@gmail.com>
Date: Mon, 5 Oct 2015 10:33:55 -0700
Message-Id: <5570C084-0C2D-4B79-A78E-B25699600EA9@gmx.com>
References: <CAKzdR-rPoByn=+CgsTc1ZnLkjwtYyJnbQLbn-VHOvz0dLciefQ@mail.gmail.com>
<CA+w+GKSNa3TWgHXrp3=3gXdAbE6vVjW_uzus3_2YG9gzKJSskg@mail.gmail.com>
<5612ACF3.2080006@gmail.com>
To: Paul Sztorc <truthcoin@gmail.com>
X-Mailer: Apple Mail (2.2104)
Sender: Peter_R@gmx.com
X-Provags-ID: V03:K0:yN/VrQF2cdUL62dLyKKZ6Zrb/bJ/bSdf9JN/Cbjc0eVYVMM47uh
ZDWQqokMtvz1yYoOGHyNXhEs78sTVz9WAX7JzJBSOLPlAQuPtxHFOogjyTCF8ghznzjSaEy
FtJ1T01TZgakms80nkfwbonClnE0RUpmO6dusVKC3Bt7+x+n3jwEk+/8nH7HthuZ6zCANo8
NH/h+JDOIqkh2ph7M0W+g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:MLfXH7ch2tw=:+JcuqENDpMeMkCj6kLxQin
dEnbtu2myQJzWEVSf+elASLn309zw+nC8wvFQ8Eeq5W8vikqWSm3PvNU+10m28xK/tX3I6xDt
DMEJDibkVFZJChzQBbxDnwlFGUcVDBxy1GMzjOESd9N7431huEwa8qeqkVOWVoHnZSno80SiU
KSzF2GULGQPGYT41z/4iaka8mLX6vzPOLsPOHj1zCdH/eDpr7pR6rGZIerFHUZtkLRu+LcInx
rkDCi8r5wkbgtR08o14GdYBQP0b4cWzMvuJ8APVwu5fmRt75LloYMV15FqtXXeGswguL0wmIR
3j2lj7YLYiKnq1Npaq3a/kdF05NipL77NX25lvhPu1LE+HnDlFJXU5j26UEs3Cp6W3lFBiY+4
6aGkaPdnU2RjuZHIl+brRwNy+9W4AGMIS2j1zWAX3rHBCr0G/++afHCxhd5TtW1xMQhRiTNx6
ff72wOaG2kV3N4fXDoNv96TBq9/NbNrQCBmsmoLOoRmGyLNbPSa87sOH+bBH3PuSFY3+h/STu
IwXJB5eKrdVvn3Jp9rzJyETEP76iigIseqYOfc/mkKGWTKDMm1uOzoE6YH1CneiLJC6WyBtyH
5tNqBYPbHJeWN0wt+Gwe82DC+J3aZP1p1XefqwJ54FNpSNjjDU0sTE9AYu8zohVVwwF0DgG3o
rPOoFxBW3XfTf9ftZhit3eiNj11zeqUY659EZGfV8Pk5GfdwpsQBOXj7VHKfkV/pywGvnKKLc
/z/E5MzcpWwghYir/qYSbA+OrstIRL+6/W0M61EGETV3LFPc5vgbq5q+hCby+mqvZRPKgT+FK
LsjlGtg
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 17:34:04 -0000
--Apple-Mail=_0D9EA63B-7F22-4FCA-9D68-48A794B91B68
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Dear Bitcoin Development Community:
I would like to share my opinion that Mike is correct regarding the soft =
fork versus hard fork debate. I agree that CLTV should be done with a =
hard fork for the reasons that Mike has discussed several times in the =
past (mainly that a hard forks requires active consensus while a soft =
fork requires only indifference). I believe this is a controversial =
change and=E2=80=94if Core Dev believes that controversial changes to =
the consensus rules must not happen=E2=80=94then my interpretation is =
that CLTV should not happen in its current form. =20
I also agree with Mike that Core's requirement for unanimous consensus =
results in development grid lock and should be revisited. In my =
opinion, the idea that unanimity is required should be replaced with the =
idea that the longest chain composed of valid transactions is the =
correct chain. It shouldn=E2=80=99t matter really how the chain becomes =
the longest=E2=80=94only that it does. =20
I believe that a good way to return power to the bitcoin community is to =
foster mutiple forkwise-compatible implementations of the protocol. =
Each implementation could have its own governance model and design =
objectives and use techniques like BIP101=E2=80=99s 750/1000 signalling =
mechanism to activate changes that may be desirable to the community. =
If a super majority does not support the change, then it won=E2=80=99t =
be activated. I created an animated GIF that visualizes one possibility =
for how multiple protocol implementations might emerge over time:
=
https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_bitcoin_cor=
e_visualizing_the/ =
<https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_bitcoin_co=
re_visualizing_the/>
Decentralizing development and supporting multiple forkwise-compatible =
implementations of the protocol is a worthwhile goal that will =
simultaneously make Bitcoin more robust and more responsive to the will =
of the market.
Nodes would express their acceptance of a block by mining on top of it. =
Consensus would be determined by the code we choose to run.=20
Best regards,
Peter=20
> On Oct 5, 2015, at 10:01 AM, Paul Sztorc via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> On 10/5/2015 12:56 PM, Mike Hearn via bitcoin-dev wrote:
>>=20
>> As everyone in the Bitcoin community has been clearly told that
>> controversial changes to the consensus rules must not happen, it's
>> clear that CLTV cannot happen in its current form.
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail=_0D9EA63B-7F22-4FCA-9D68-48A794B91B68
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D""><div class=3D"">Dear Bitcoin Development =
Community:</div><div class=3D""><br class=3D""></div><div class=3D"">I =
would like to share my opinion that Mike is correct regarding the soft =
fork versus hard fork debate. I agree that CLTV should be done with a =
hard fork for the reasons that Mike has discussed several times in the =
past (mainly that a hard forks requires active consensus while a soft =
fork requires only indifference). I believe this is a =
controversial change and=E2=80=94if Core Dev believes that controversial =
changes to the consensus rules must not happen=E2=80=94then my =
interpretation is that CLTV should not happen in its current form. =
</div><div class=3D""><br class=3D""></div><div class=3D"">I also =
agree with Mike that Core's requirement for unanimous consensus results =
in development grid lock and should be revisited. In my opinion, =
the idea that unanimity is required should be replaced with the idea =
that the longest chain composed of valid transactions is the correct =
chain. It shouldn=E2=80=99t matter really how the chain becomes =
the longest=E2=80=94only that it does. </div><div class=3D""><br =
class=3D""></div><div class=3D"">I believe that a good way to return =
power to the bitcoin community is to foster mutiple forkwise-compatible =
implementations of the protocol. Each implementation could have =
its own governance model and design objectives and use techniques like =
BIP101=E2=80=99s 750/1000 signalling mechanism to activate changes that =
may be desirable to the community. If a super majority does not =
support the change, then it won=E2=80=99t be activated. I created =
an animated GIF that visualizes one possibility for how multiple =
protocol implementations might emerge over time:</div><div class=3D""><br =
class=3D""></div><div class=3D""><a =
href=3D"https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_bit=
coin_core_visualizing_the/" =
class=3D"">https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_=
bitcoin_core_visualizing_the/</a></div><div class=3D""><br =
class=3D""></div><div class=3D"">Decentralizing development and =
supporting multiple forkwise-compatible implementations of the protocol =
is a worthwhile goal that will simultaneously make Bitcoin more robust =
and more responsive to the will of the market.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Nodes would express their acceptance of =
a block by mining on top of it. Consensus would be determined by =
the code we choose to run. </div><div class=3D""><br =
class=3D""></div><div class=3D"">Best regards,</div><div =
class=3D"">Peter </div></div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Oct 5, 2015, at 10:01 AM, =
Paul Sztorc via bitcoin-dev <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D"">On 10/5/2015 12:56 =
PM, Mike Hearn via bitcoin-dev wrote:<br class=3D""><blockquote =
type=3D"cite" class=3D""><br class=3D"">As everyone in the Bitcoin =
community has been clearly told that<br class=3D"">controversial changes =
to the consensus rules must not happen, it's<br class=3D"">clear that =
CLTV cannot happen in its current form.<br class=3D""></blockquote><br =
class=3D"">_______________________________________________<br =
class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br class=3D""></body></html>=
--Apple-Mail=_0D9EA63B-7F22-4FCA-9D68-48A794B91B68--
|
