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
|
Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0995EA95
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Dec 2015 04:44:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f180.google.com (mail-io0-f180.google.com
[209.85.223.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5032DEE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Dec 2015 04:44:50 +0000 (UTC)
Received: by mail-io0-f180.google.com with SMTP id o67so143323196iof.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 20:44:50 -0800 (PST)
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=XPtcRr5j0hMJbD9o2KopS5Eo3FxuSILrHa7IGwbeFKM=;
b=N1YsRm9fhNrnOYXG/rry+LCMYiLCJdtkQm7CCR7z1FeT32yX8ZwTkBQNGLC4B1VLeR
japPctog8H6Ts1epkLcILiWhuDsKpDtigUUWfKlpyh/Fdc9FJFS1q1QWL4KHaL2VxMIu
f9WBhR60ga3Pst51kSqfTUy7VxobRmwQuJFFmgYFlj3kKKBvUBseD+Tn2oqjqv134t94
ej1A0DMI+qW1eEQ+T8eYz78P/XTSmvSnJvyMfxPxds5qw/J08SMn7TYJZwqgBpyja037
4sMq1A0aC1PyQucaJxPMRA5tuI1WjJZc/d1NKvHyA8DIBb7A6vfJyCoOym9r3TaiNZB6
f9DQ==
MIME-Version: 1.0
X-Received: by 10.107.39.193 with SMTP id n184mr17497568ion.14.1450673089842;
Sun, 20 Dec 2015 20:44:49 -0800 (PST)
Received: by 10.64.25.18 with HTTP; Sun, 20 Dec 2015 20:44:49 -0800 (PST)
In-Reply-To: <CAPg+sBhQN2HDvH8dfq2VsQ0dTA9V=HgQsCJdP6B72fj1SDA4yw@mail.gmail.com>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
<20151208110752.GA31180@amethyst.visucore.com>
<CAPWm=eUomq6SBC0ky0WSs5=_G942vigm4RmgYuq0O-yJ-vqC2A@mail.gmail.com>
<CAPg+sBig9O5+he0PWhTkX5iin14QLz5+eCCu6KfwU=DxntKYtg@mail.gmail.com>
<CAPg+sBhQN2HDvH8dfq2VsQ0dTA9V=HgQsCJdP6B72fj1SDA4yw@mail.gmail.com>
Date: Sun, 20 Dec 2015 23:44:49 -0500
Message-ID: <CAPWm=eX7VCdE_oZN+wT7rbUR+X7dAnWEicLp_K1mhFAnkSSnCA@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a11407fec3492ec05276126b5
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>,
Gregory Maxwell <gmaxwell@gmail.com>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
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, 21 Dec 2015 04:44:51 -0000
--001a11407fec3492ec05276126b5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'm also strongly in favor of moving forward with this plan.
A couple of points:
1) There has been too much confusion in looking at segwit as an alternative
way to increase the block size and I think that is incorrect. It should
not be drawn into the block size debate as it brings many needed
improvements and tools we'd want even if no one were worried about block
size now.
2) The full capacity increase plan Greg lays out makes it clear that we can
accomplish a tremendous amount without a contentious hard fork at this
point.
3) Let's stop arguing endlessly and actually do work that will benefit
everyone.
On Sun, Dec 20, 2015 at 11:33 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wrote:
> > On Mon, Dec 07, 2015 at 10:02:17PM +0000, Gregory Maxwell via
> bitcoin-dev wrote:
> >> TL;DR: I propose we work immediately towards the segwit 4MB block
> >> soft-fork which increases capacity and scalability, and recent speedup=
s
> >> and incoming relay improvements make segwit a reasonable risk. BIP9
> >> and segwit will also make further improvements easier and faster to
> >> deploy. We=E2=80=99ll continue to set the stage for non-bandwidth-incr=
ease-based
> >> scaling, while building additional tools that would make bandwidth
> >> increases safer long term. Further work will prepare Bitcoin for furth=
er
> >> increases, which will become possible when justified, while also
> providing
> >> the groundwork to make them justifiable.
> >
> > Sounds good to me.
>
> Better late than never, let me comment on why I believe pursuing this pla=
n
> is important.
>
> For months, the block size debate, and the apparent need for agreement on
> a hardfork has distracted from needed engineering work, fed the external
> impression that nothing is being done, and generally created a toxic
> environment to work in. It has affected my own productivity and health, a=
nd
> I do not think I am alone.
>
> I believe that soft-fork segwit can help us out of this deadlock and get
> us going again. It does not require the pervasive assumption that the
> entire world will simultaneously switch to new consensus rules like a
> hardfork does, while at the same time:
> * Give a short-term capacity bump
> * Show the world that scalability is being worked on
> * Actually improve scalability (as opposed to just scale) by reducing
> bandwidth/storage and indirectly improving the effectiveness of systems
> like Lightning.
> * Solve several unrelated problems at the same time (fraud proofs, script
> extensibility, malleability, ...).
>
> So I'd like to ask the community that we work towards this plan, as it
> allows to make progress without being forced to make a possibly divisive
> choice for one hardfork or another yet.
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a11407fec3492ec05276126b5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm also strongly in favor of moving forward with this=
plan.<div><br></div><div>A couple of points:</div><div>1) There has been t=
oo much confusion in looking at segwit as an alternative way to increase th=
e block size and I think that is incorrect.=C2=A0 It should not be drawn in=
to the block size debate as it brings many needed improvements and tools we=
'd want even if no one were worried about block size now.</div><div>2) =
The full capacity increase plan Greg lays out makes it clear that we can ac=
complish a tremendous amount without a contentious hard fork at this point.=
</div><div>3) Let's stop arguing endlessly and actually do work that wi=
ll benefit everyone.</div><div><br></div><div><br></div><div><br></div></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Dec 20,=
2015 at 11:33 PM, Pieter Wuille via bitcoin-dev <span dir=3D"ltr"><<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><span class=3D""><p dir=3D"ltr">On Tue, Dec 8, 2015 at 6:07 =
AM, Wladimir J. van der Laan wrote:<br>
> On Mon, Dec 07, 2015 at 10:02:17PM +0000, Gregory Maxwell via bitcoin-=
dev wrote:<br>
>> TL;DR: I propose we work immediately towards the segwit 4MB block<=
br>
>> soft-fork which increases capacity and scalability, and recent spe=
edups<br>
>> and incoming relay improvements make segwit a reasonable risk. BIP=
9<br>
>> and segwit will also make further improvements easier and faster t=
o<br>
>> deploy. We=E2=80=99ll continue to set the stage for non-bandwidth-=
increase-based<br>
>> scaling, while building additional tools that would make bandwidth=
<br>
>> increases safer long term. Further work will prepare Bitcoin for f=
urther<br>
>> increases, which will become possible when justified, while also p=
roviding<br>
>> the groundwork to make them justifiable.<br>
><br>
> Sounds good to me.</p>
<p dir=3D"ltr">Better late than never, let me comment on why I believe purs=
uing this plan is important.</p>
</span><p dir=3D"ltr">For months, the block size debate, and the apparent n=
eed for agreement on a hardfork has distracted from needed engineering work=
, fed the external impression that nothing is being done, and generally cre=
ated a toxic environment to work in. It has affected my own productivity an=
d health, and I do not think I am alone.</p><div class=3D"HOEnZb"><div clas=
s=3D"h5">
<p dir=3D"ltr">I believe that soft-fork segwit can help us out of this dead=
lock and get us going again. It does not require the pervasive assumption t=
hat the entire world will simultaneously switch to new consensus rules like=
a hardfork does, while at the same time:<br>
* Give a short-term capacity bump<br>
* Show the world that scalability is being worked on<br>
* Actually improve scalability (as opposed to just scale) by reducing bandw=
idth/storage and indirectly improving the effectiveness of systems like Lig=
htning.<br>
* Solve several unrelated problems at the same time (fraud proofs, script e=
xtensibility, malleability, ...).</p>
<p dir=3D"ltr">So I'd like to ask the community that we work towards th=
is plan, as it allows to make progress without being forced to make a possi=
bly divisive choice for one hardfork or another yet.</p>
</div></div><span class=3D"HOEnZb"><font color=3D"#888888"><p dir=3D"ltr">-=
- <br>
Pieter<br>
</p>
</font></span><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>
<br></blockquote></div><br></div>
--001a11407fec3492ec05276126b5--
|
