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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 583B5FED
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Dec 2015 04:33:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f182.google.com (mail-io0-f182.google.com
[209.85.223.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DE68CE0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Dec 2015 04:33:17 +0000 (UTC)
Received: by mail-io0-f182.google.com with SMTP id e126so143324126ioa.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 20:33:17 -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=jC3N+4yH0gyhrSKwnJKcf1j8T4BnVBGamXIBwSD9xZ4=;
b=IFfKfMfZ77rKHjpSfPhRjIIwCVsSddQWyv68qeoGAT4m8FYuXV2MOWuK4IhqaYq+jt
y4dL823BuEckNn52pmEkrmJNOaCrPjXnIqbiRRcMWKoqsshbI7z4xHE7g0tMcvzAKrXA
0NT6YTq/IFEUFO8HRRCP2nOzzld+90LsaVNmpKMhq0G1U7ciVZDD/cVxhN6kJfvc5YFK
LypvkpofN+dJaj9vorRxARGaS0Z5SD97iDLOJxXFim+aVEzi4zISLktZBTJUD4foxeo2
g6bGrwjWQFMIW4mEaDiSnlNPvJsHFdUZCU/k7p4n2VR1zv05MncD1xAucy7Gh4fqfuJU
MJmA==
MIME-Version: 1.0
X-Received: by 10.107.168.5 with SMTP id r5mr17356357ioe.126.1450672397331;
Sun, 20 Dec 2015 20:33:17 -0800 (PST)
Received: by 10.36.80.6 with HTTP; Sun, 20 Dec 2015 20:33:16 -0800 (PST)
Received: by 10.36.80.6 with HTTP; Sun, 20 Dec 2015 20:33:16 -0800 (PST)
In-Reply-To: <CAPg+sBig9O5+he0PWhTkX5iin14QLz5+eCCu6KfwU=DxntKYtg@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>
Date: Mon, 21 Dec 2015 05:33:16 +0100
Message-ID: <CAPg+sBhQN2HDvH8dfq2VsQ0dTA9V=HgQsCJdP6B72fj1SDA4yw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11421f2eedb4d4052760fcb5
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: 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:33:18 -0000
--001a11421f2eedb4d4052760fcb5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 speedups
>> 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-increa=
se-based
>> scaling, while building additional tools that would make bandwidth
>> increases safer long term. Further work will prepare Bitcoin for further
>> 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 plan
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, and
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.
--=20
Pieter
--001a11421f2eedb4d4052760fcb5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wro=
te:<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>
<p dir=3D"ltr">For months, the block size debate, and the apparent need for=
agreement on a hardfork has distracted from needed engineering work, fed t=
he external impression that nothing is being done, and generally created a =
toxic environment to work in. It has affected my own productivity and healt=
h, and I do not think I am alone.</p>
<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>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>
--001a11421f2eedb4d4052760fcb5--
|
