summaryrefslogtreecommitdiff
path: root/58/cd503304d6bbbc4606b54ec7038792e23b7a6b
blob: 7d43026f279a74310bf3a554de8cba5c4f9a41b1 (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
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B0C18109A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 29 Jan 2016 07:57:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f182.google.com (mail-pf0-f182.google.com
	[209.85.192.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CFBB2101
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 29 Jan 2016 07:57:02 +0000 (UTC)
Received: by mail-pf0-f182.google.com with SMTP id x125so38417449pfb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 28 Jan 2016 23:57:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:message-id:references:to;
	bh=+T/i07rC53tHSiSVTXqKv1qLpfHH7yWmY8G1w+O2Vvc=;
	b=jBCahPFUUGSgzAY0imNOicNdhQmIFanIbvWGv3IXIc7f8EXDudPE0+IVjr1QHlrHV+
	jxjMcz/5M/rUITyT6XsrnjN4aG+xhGqUuvOp/2t5jsaINADSVLxD4oLvlaAATFkzqBcm
	IEnMHbqXWmLXYqpoKgjYRddHjLyGKQFJUksxBnGOdFW8wCydzFumTg9ZgPiHl6HIFtP7
	M1LyWhaGsX8Nkn7K+Fwe0WxGvlUgnDtwtFnfuZmNDe5NXCbebqXwwOIAqbpdX08ANI2h
	ZIW8azZLlCqFiUGYWccyOv5j4f6OvGkXGfpNm1k5sNDOAqGirVGI9Izh1hMjSci8EUrY
	uwRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:subject:mime-version:content-type:from
	:in-reply-to:date:cc:message-id:references:to;
	bh=+T/i07rC53tHSiSVTXqKv1qLpfHH7yWmY8G1w+O2Vvc=;
	b=RSAaiI40ChLv1yzNdSJxLuIn7cspbzmFDyVaEzLou6ksJYWEB94WTSV+t+D7w1BAte
	30K9WNdzOMOjj2AJ+TGWrgZhtVAxklwlCNtAoQJMhQI1m8NXa0kNIUWtDrUK09H5azTq
	Hep9ChZsxd4Lccduub8KbR/aiFM3AE2i53BIKalZhNs2oWz+hkUBZXLf0diz/FDwRoFn
	lPCJsjUktXw/7DdIRpEwc6vCzj4q/Ao03/GEMG4L9MhcIFFqvcIEZ7qmLIZiLFnTVemR
	OmtF2GuJNrBLx3R6TUGCE1RL31/cPPmmm7vJndFe7fsNrWmgUONIQ17ep1TSoUKpoLfL
	ITLw==
X-Gm-Message-State: AG10YOSpZu5kNHxmfgihH5DhIJiNhKP0fdXACmyFCffJOVbGfWcsIms9dDEUNp1RPbiP0g==
X-Received: by 10.98.70.151 with SMTP id o23mr11357257pfi.124.1454054222590;
	Thu, 28 Jan 2016 23:57:02 -0800 (PST)
Received: from [192.168.1.109] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
	l9sm21430678pfb.29.2016.01.28.23.57.01
	(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Thu, 28 Jan 2016 23:57:01 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_4A2301DB-3FF9-4E20-A56E-18063FB916F0";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.1
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CADJgMzv8o8fewFa7nsFf6-2N=Qo8S2bLsTpYd7F6jcsO1oYrXA@mail.gmail.com>
Date: Thu, 28 Jan 2016 23:57:00 -0800
Message-Id: <7DA5E08C-DABB-48F8-A47F-0852F059EB74@gmail.com>
References: <42F57F58-7C67-43DD-81DE-2C77E03733F2@gmail.com>
	<CADJgMzv8o8fewFa7nsFf6-2N=Qo8S2bLsTpYd7F6jcsO1oYrXA@mail.gmail.com>
To: Btc Drak <btcdrak@gmail.com>
X-Mailer: Apple Mail (2.2098)
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] BIP Classification Process
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: Fri, 29 Jan 2016 07:57:03 -0000


--Apple-Mail=_4A2301DB-3FF9-4E20-A56E-18063FB916F0
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4A43D1AD-A345-4FD1-B653-BB8277BF773C"


--Apple-Mail=_4A43D1AD-A345-4FD1-B653-BB8277BF773C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Codebase forks with nonconsensus features are totally fine! It=E2=80=99s =
the bitterness and resentment that arose out of the need to get everyone =
to agree on something that not everyone really needs to agree on =
that=E2=80=99s the problem.

> On Jan 28, 2016, at 11:21 PM, Btc Drak <btcdrak@gmail.com> wrote:
>=20
> Your proposal does not solve the issue related to Mike creating his =
own fork. He created his own for because he had a non-consensus feature =
set that Bitcoin Core disagreed with and he wanted. That is to be =
_encouraged_. I also maintain my own Bitcoin fork with a specific =
(non-consensus) feature for the same reason and I am perfectly happy =
with the arrangement, as are my userbase.
>=20
> Classification of BIPs is fine, I have no problem with that and I =
support your BIP, but your proposition it would have stopped Mike from =
creating his own distribution is false (nor desirable): it was down to a =
strong differing of technical opinions between Mike and a dozen other =
developers as well as node security concerns (which were proved =
correct).
>=20
>=20
> On Fri, Jan 29, 2016 at 12:52 AM, Eric Lombrozo via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> Folks,
>=20
> I think the current situation with forks could have been avoided with =
a better process that can distinguish between different layers for =
bitcoin modification proposals.
>=20
> For instance, BIP64 was proposed by Mike Hearn, which does not affect =
the consensus layer at all. Many Core devs disliked the proposal and =
Mike had lots of pushback. Regardless of whether or not you agree with =
the merits of Mike=E2=80=99s ideas here, fact is having nodes that =
support BIP64 would not fundamentally break the Bitcoin network.
>=20
> This issue prompted Mike to break off from Core and create XT as the =
applications he was developing required BIP64 to work. With this split, =
Gavin found a new home for his big block ideas=E2=80=A6and the two =
teamed up.
>=20
> We need to have a process that clearly distinguishes these different =
layers and allows much more freedom in the upper layers while requiring =
agreement at the consensus layer. Many of these fork proposals are =
actually conflating different features, only some of which would =
actually be consensus layer changes. When people proposing nonconsensus =
features get pushback from Core developers they feel rejected and are =
likely to team up with others trying to push for hard forks and the =
like.
>=20
> A while back I had submitted a BIP -  BIP123 - that addresses this =
issue. I have updated it to include all the currently proposed and =
accepted BIPs and have submitted a PR: =
https://github.com/bitcoin/bips/pull/311 =
<https://github.com/bitcoin/bips/pull/311>
>=20
> I urge everyone to seriously consider getting this BIP accepted as a =
top priority before we get more projects all trying their hand at stuff =
and not understanding these critical distinctions.
>=20
>=20
> - Eric
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>=20
>=20


--Apple-Mail=_4A43D1AD-A345-4FD1-B653-BB8277BF773C
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"">Codebase forks with nonconsensus features are totally fine! =
It=E2=80=99s the bitterness and resentment that arose out of the need to =
get everyone to agree on something that not everyone really needs to =
agree on that=E2=80=99s the problem.<div class=3D""><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
Jan 28, 2016, at 11:21 PM, Btc Drak &lt;<a =
href=3D"mailto:btcdrak@gmail.com" class=3D"">btcdrak@gmail.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D"">Your proposal does not solve the issue related to =
Mike creating his own fork. He created his own for because he had a =
non-consensus feature set that Bitcoin Core disagreed with and he =
wanted. That is to be _encouraged_. I also maintain my own Bitcoin fork =
with a specific (non-consensus) feature for the same reason and I am =
perfectly happy with the arrangement, as are my userbase.<div =
class=3D""><br class=3D""></div><div class=3D"">Classification of BIPs =
is fine, I have no problem with that and I support your BIP, but your =
proposition it would have stopped Mike from creating his own =
distribution is false (nor desirable): it was down to a strong differing =
of technical opinions between Mike and a dozen other developers as well =
as node security concerns (which were proved correct).&nbsp;</div><div =
class=3D""><br class=3D""></div></div><div class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote">On Fri, Jan 29, 2016 at 12:52 AM, =
Eric Lombrozo via bitcoin-dev <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D"">Folks,<div class=3D""><br =
class=3D""></div><div class=3D"">I think the current situation with =
forks could have been avoided with a better process that can distinguish =
between different layers for bitcoin modification proposals.</div><div =
class=3D""><br class=3D""></div><div class=3D"">For instance, BIP64 was =
proposed by Mike Hearn, which does not affect the consensus layer at =
all. Many Core devs disliked the proposal and Mike had lots of pushback. =
Regardless of whether or not you agree with the merits of Mike=E2=80=99s =
ideas here, fact is having nodes that support BIP64 would not =
fundamentally break the Bitcoin network.</div><div class=3D""><br =
class=3D""></div><div class=3D"">This issue prompted Mike to break off =
from Core and create XT as the applications he was developing required =
BIP64 to work. With this split, Gavin found a new home for his big block =
ideas=E2=80=A6and the two teamed up.</div><div class=3D""><br =
class=3D""></div><div class=3D"">We need to have a process that clearly =
distinguishes these different layers and allows much more freedom in the =
upper layers while requiring agreement at the consensus layer. Many of =
these fork proposals are actually conflating different features, only =
some of which would actually be consensus layer changes. When people =
proposing nonconsensus features get pushback from Core developers they =
feel rejected and are likely to team up with others trying to push for =
hard forks and the like.</div><div class=3D""><br class=3D""></div><div =
class=3D"">A while back I had submitted a BIP - &nbsp;BIP123 - that =
addresses this issue. I have updated it to include all the currently =
proposed and accepted BIPs and have submitted a PR: <a =
href=3D"https://github.com/bitcoin/bips/pull/311" target=3D"_blank" =
class=3D"">https://github.com/bitcoin/bips/pull/311</a></div><div =
class=3D""><br class=3D""></div><div class=3D"">I urge everyone to =
seriously consider getting this BIP accepted as a top priority before we =
get more projects all trying their hand at stuff and not understanding =
these critical distinctions.</div><span class=3D"HOEnZb"><font =
color=3D"#888888" class=3D""><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D"">- =
Eric</div></font></span></div><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"">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D"">
<br class=3D""></blockquote></div><br class=3D""></div>
</div></blockquote></div><br class=3D""></div></body></html>=

--Apple-Mail=_4A43D1AD-A345-4FD1-B653-BB8277BF773C--

--Apple-Mail=_4A2301DB-3FF9-4E20-A56E-18063FB916F0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWqxtMAAoJEJNAI64YFENUBnAQAItOQxxtgrPM0wq6aRpRi59Q
6AOhMXSUA65R++gi1nkqgcv593pRrmwllAXFA9aSYXnP2eg2B3ttU/LP0kDpzv1M
tt75S3meKaX6HR5FBecShFW3i7rAg5IiD+G/6oIE/YHw0i8TFJDhK+FbmUtf9xto
sPuRP4PubR2ilI5Au27ugx1+vSyo0O93cRoquat+po1DX+TwW/uDWKkyQHl0AdN+
ydbLfb9KRmLNvP0fvegxXtPLae9Cj+bhDsPnkM+/eEuR9w39MuqqI5nR8CbRHTQs
9pLOUXvp/lDGj+lpR8vr0FSrD5avcOLv/wG6Rj2byGJiQ5yGENGgECI0Mv11R72n
iyLz+AJ4MhO8y5MyNotdRcdlFkEdW9mvTlMBjf0U5OjyYfDiUPH8l0quF0VieFdg
nuK39/UGALbdD1EDvnJNMqhUQYPR4zbA18bcJSdAfCMWudHotMsF3UqFKh0nMsJc
y8uH2j15VCO7ete9/2Yc4WFVw19xmMK8HawV14OziDyIkwfRYN5bOmEqa3+C69qf
Ws4aL49JBC2BwxZ52cL+LC8fEw/T0SREgOScVej9HWQQ8blhKPIjHUSg0o5uJvcI
5zSj461E8n6KgRAByOUmoFeV9DGvTR6n9htKnPjSrR5MsDAWewYsInXtRIW/geJA
P3rVOFtmSdfAw0zkCJL+
=iBZk
-----END PGP SIGNATURE-----

--Apple-Mail=_4A2301DB-3FF9-4E20-A56E-18063FB916F0--