summaryrefslogtreecommitdiff
path: root/9d/aa7ca4dd76dae6ba60c9b95a1998ba931e4fe8
blob: 45282594ab628ee97a2320d0bc33b77213edc39c (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: <jaredr26@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3E297B0B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 19:07:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com
	[209.85.213.42])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6CDC317E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 19:07:17 +0000 (UTC)
Received: by mail-vk0-f42.google.com with SMTP id d188so29270919vka.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 12:07:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=fC0dm4apVMMj1j/6RcZbaIlShimTKvplW+f+FhfO2mQ=;
	b=jN1G3liGhOhzwSwKapd1AgTZ7qgcK2uKPOup7oGAq3NY1Yg7iB0u92EXdnQJM9Vkwb
	nPZwpu1jgu+2ySRnpvMCEbRrVRc5EA9qM487/tCzVosceThCvFEC0WxNIz3RymX8xe9k
	6oypWU09CCfmRYKsXbXfbQ4tPEoEdthLsplNyhyVhof+aT5HGMsbQsvfvhv2McTw9oGI
	FQJuqJRmb6YoMZaZvxSt45wz7rkileCJYVsYegQS7aRJMR9ZpXWDASLp3eCh9LkUEqqD
	DhMrypb9hh5D6F9wu+JZmY2ClRqWg5BjjrMEbLIUSvI94uEYdJUJeXOLOyg9j3sOCk1S
	lDoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=fC0dm4apVMMj1j/6RcZbaIlShimTKvplW+f+FhfO2mQ=;
	b=adl7AvKqOFH1HImdmEFrSo15AAcbONwVCjqVdyBrBRL+qU3fP37gBEOsGakJaVu7a0
	Qe24T4QsWP41rf/LqADBNQMLkbmqyEQ9YGMJNUpQ4xyUmD0KuodFdKnAyl8JrYiKNdk9
	6Ctiy0snqjHCncgQ2XA0Jnc7Hhk/b+7ulsuMD53GJZdiK3Q0cynNJy8+R8WnMsLGJJNr
	xRUoICue0yiqt4hjifPgy3k5EL5QWGIrKTMTRejPf+gGFcX7byTVC9lXkfwySc38k7Ia
	7dQnzUGJm6dvwh0GMhHEjU2WMEu4lEGBP2Rpg7MsZHiCH2vkjMYjQlEolBZ/SfNkP7dt
	M+gw==
X-Gm-Message-State: AFeK/H0cVDFfe/W+6y7FvAHpWZZ6QFX1obDKMHKRc3qojTZf/E5Ml1s6KiukIXtJsrFG7++qg+HIAJPWYOnkYQ==
X-Received: by 10.31.218.195 with SMTP id r186mr938243vkg.112.1490814436328;
	Wed, 29 Mar 2017 12:07:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.143 with HTTP; Wed, 29 Mar 2017 12:07:15 -0700 (PDT)
In-Reply-To: <CABm2gDrN5Wt9+2sVAjRiDG_axHmxF+iFujvApBMqrs-GjBG4pg@mail.gmail.com>
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
	<CA+KqGkpFW8qDPVgY+11o_CC+6FMWUNUZ7REHJKYM9-3wbrUwYw@mail.gmail.com>
	<CABm2gDrN5Wt9+2sVAjRiDG_axHmxF+iFujvApBMqrs-GjBG4pg@mail.gmail.com>
From: Jared Lee Richardson <jaredr26@gmail.com>
Date: Wed, 29 Mar 2017 12:07:15 -0700
Message-ID: <CAD1TkXuEE4ajE071R32skuHOq-0QHJuaO0OpztfSq=ZXpvd6Pw@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c07adbce74d92054be3481a
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 29 Mar 2017 19:08:56 +0000
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Wed, 29 Mar 2017 19:07:18 -0000

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

> While Segwit's change from 1 mb size limit to 4 mb weight limit seems to
be controversial among some users [..] I don't think it's very interesting
to discuss further size increases.

I think the reason for this is largely because SegWit as a blocksize
increase isn't very satisfying.  It resolves to a one-time increase with no
future plans, thus engendering the same objections as people who demand we
just "raise the number to N."  People can argue about what N should be, but
when N is just a flat number, we know we'll have to deal with the issue
again.

In that light I think it is even more essential to continue to discuss the
blocksize debate and problem.

> I find more interesting to talk to the users and see how they think
Segwit harms them,

From an inordinant amount of time spent reading Reddit, I believe this
largely comes down to the rumor that has a deathgrip on the BU community -
That Core are all just extensions of Blockstream, and blockstream wants to
restrict growth on-chain to force growth of their 2nd layer
services(lightning and/or sidechains).

I believe the tone of the discussion needs to be changed, and have been
trying to work to change that tone for weeks now.  There's one faction that
believes that Bitcoin will rarely, if ever, benefit from a blocksize
increase, and fees rising is a desired/unavoidable result.  There's a
different faction that believes Bitcoin limits are arbitrary and that all
people worldwide should be able to put any size transactions, even
microtransactions, on-chain.  Both factions are extreme in their viewpoints
and resort to conspiracy theories to interpret the actions of
Core(blockstream did it) or BU(Jihan controls everything and anyone who
says overwise is a shill paid by Roger Ver!)

It is all very unhealthy for Bitcoin.  Both sides need to accept that
microtransactions from all humans cannot go on-chain, and that never
increasing the blocksize doesn't mean millions of home users will run
nodes.  The node argument breaks down economically and the microtransaction
argument is an impossible mountain for a blockchain to climb.


On Wed, Mar 29, 2017 at 2:37 AM, Jorge Tim=C3=B3n via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> While Segwit's change from 1 mb size limit to 4 mb weight limit seems to
> be controversial among some users (I find that very often it is because
> they have been confused about what segwit does or even outright lied abou=
t
> it) I don't think it's very interesting to discuss further size increases=
.
> I find more interesting to talk to the users and see how they think Segwi=
t
> harms them, maybe we missed something in segwit that needs to be removed
> for segwit to become uncontroversial, or maybe it is just disinformation.
>
> On the other hand, we may want to have our first uncontroversial hardfork
> asap, independently of block size. For example, we could do something as
> simple as fixing the timewarp attack as bip99 proposes. I cannot think of=
 a
> hf that is easier to implement or has less potential for controversy than
> that.
>
> On 29 Mar 2017 8:32 am, "Bram Cohen via bitcoin-dev" <bitcoin-dev@lists.
> linuxfoundation.org> wrote:
>
> On Tue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> The basic idea is, as many of us agree, hard fork is risky and should
>> be well prepared. We need a long time to deploy it.
>>
>
> Much as it may be appealing to repeal the block size limit now with a
> grace period until a replacement is needed in a repeal and replace
> strategy, it's dubious to assume that an idea can be agreed upon later wh=
en
> it can't be agreed upon now. Trying to put a time limit on it runs into t=
he
> possibility that you'll find that whatever reasons there were for not
> having general agreement on a new setup before still apply, and running
> into the embarrassing situation of winding up sticking with the status qu=
o
> after much sturm and drang.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-size:12.8px">While Segwit&#3=
9;s change from 1 mb size limit to 4 mb weight limit seems to be controvers=
ial among some users [..]=C2=A0</span><span style=3D"font-size:12.8px">I do=
n&#39;t think it&#39;s very interesting to discuss further size increases.<=
/span><span style=3D"font-size:12.8px"><br><br>I think the reason for this =
is largely because SegWit as a blocksize increase isn&#39;t very satisfying=
.=C2=A0 It resolves to a one-time increase with no future plans, thus engen=
dering the same objections as people who demand we just &quot;raise the num=
ber to N.&quot; =C2=A0People can argue about what N should be, but when N i=
s just a flat number, we know we&#39;ll have to deal with the issue again.<=
br><br>In that light I think it is even more essential to continue to discu=
ss the blocksize debate and problem.<br><br>&gt;=C2=A0</span><span style=3D=
"font-size:12.8px">I find more interesting to talk to the users and see how=
 they think Segwit harms them,<br><br>From an inordinant amount of time spe=
nt reading Reddit, I believe this largely comes down to the rumor that has =
a deathgrip on the BU community - That Core are all just extensions of Bloc=
kstream, and blockstream wants to restrict growth on-chain to force growth =
of their 2nd layer services(lightning and/or sidechains).</span><div><span =
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:1=
2.8px">I believe the tone of the discussion needs to be changed, and have b=
een trying to work to change that tone for weeks now.=C2=A0 There&#39;s one=
 faction that believes that Bitcoin will rarely, if ever, benefit from a bl=
ocksize increase, and fees rising is a desired/unavoidable result.=C2=A0 Th=
ere&#39;s a different faction that believes Bitcoin limits are arbitrary an=
d that all people worldwide should be able to put any size transactions, ev=
en microtransactions, on-chain.=C2=A0 Both factions are extreme in their vi=
ewpoints and resort to conspiracy theories to interpret the actions of Core=
(blockstream did it) or BU(Jihan controls everything and anyone who says ov=
erwise is a shill paid by Roger Ver!)</span></div><div><span style=3D"font-=
size:12.8px"><br>It is all very unhealthy for Bitcoin.=C2=A0 Both sides nee=
d to accept that microtransactions from all humans cannot go on-chain, and =
that never increasing the blocksize doesn&#39;t mean millions of home users=
 will run nodes.=C2=A0 The node argument breaks down economically and the m=
icrotransaction argument is an impossible mountain for a blockchain to clim=
b.<br><br></span></div></div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Wed, Mar 29, 2017 at 2:37 AM, Jorge Tim=C3=B3n via bitcoin-d=
ev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>While Se=
gwit&#39;s change from 1 mb size limit to 4 mb weight limit seems to be con=
troversial among some users (I find that very often it is because they have=
 been confused about what segwit does or even outright lied about it) I don=
&#39;t think it&#39;s very interesting to discuss further size increases.</=
div><div dir=3D"auto">I find more interesting to talk to the users and see =
how they think Segwit harms them, maybe we missed something in segwit that =
needs to be removed for segwit to become uncontroversial, or maybe it is ju=
st disinformation.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>On the other hand, we may want to have our first uncontroversial hardfork =
asap, independently of block size. For example, we could do something as si=
mple as fixing the timewarp attack as bip99 proposes. I cannot think of a h=
f that is easier to implement or has less potential for controversy than th=
at.<br><div class=3D"gmail_extra" dir=3D"auto"><br><div class=3D"gmail_quot=
e"><div><div class=3D"h5">On 29 Mar 2017 8:32 am, &quot;Bram Cohen via bitc=
oin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:=
<br type=3D"attribution"></div></div><blockquote class=3D"m_797406792067308=
3629quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"m_7974067920673083629quoted-text">=
On Tue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev <span dir=3D"ltr=
">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfounda<wbr>tion.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"><br>
The basic idea is, as many of us agree, hard fork is risky and should<br>
be well prepared. We need a long time to deploy it.<br></blockquote><div><b=
r></div></div><div>Much as it may be appealing to repeal the block size lim=
it now with a grace period until a replacement is needed in a repeal and re=
place strategy, it&#39;s dubious to assume that an idea can be agreed upon =
later when it can&#39;t be agreed upon now. Trying to put a time limit on i=
t runs into the possibility that you&#39;ll find that whatever reasons ther=
e were for not having general agreement on a new setup before still apply, =
and running into the embarrassing situation of winding up sticking with the=
 status quo after much sturm and drang.</div><div><br></div></div></div></d=
iv>
<br></div></div><span class=3D"">______________________________<wbr>_______=
__________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></span></blockquote></div><br></div></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--94eb2c07adbce74d92054be3481a--