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
|
Return-Path: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4CA05E90
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Dec 2015 05:22:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3E03910C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Dec 2015 05:22:16 +0000 (UTC)
Received: by mail-wm0-f54.google.com with SMTP id p187so53304558wmp.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 21:22:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=tbVYj0PzhvuxYQzIBFaS9TT/f2l8WgaNKpmta0hMwHs=;
b=DOuY/r8eomUNXzdrDoWRyVgPW05RCQof8qIZaVfi4qPsD0hluN1/ikSxBv8+jXg7rf
N/uhrD5+L3gm4fEnJItsC0gMz1a+3v07Z98hHJqGsp6OiSdKkvXA7yQljUwA2dTKcz4V
w7a9amWsn0UxG4HO45H3+kHwNMDxb+yG3ua6klCDvIjuN0IR6jaashTf7dUWEEu/xTE2
PMD6HspprVBQXuVztiDXCDkR008IJEmxqoUmrFSidFI3BTuCiDNQ6j257DORwQMTqmnw
ixT1lYzhIUooFkGfW8mVHzZ2ovIyxCGQOIhbfBmr/j0ELshvRVyTMarmvtLpMh0/FyGi
q9qQ==
X-Received: by 10.194.116.40 with SMTP id jt8mr20266270wjb.57.1450675334873;
Sun, 20 Dec 2015 21:22:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.111.149 with HTTP; Sun, 20 Dec 2015 21:21:55 -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>
From: Btc Drak <btcdrak@gmail.com>
Date: Mon, 21 Dec 2015 05:21:55 +0000
Message-ID: <CADJgMzuk9Q09AnmR5=77p0HfkeUWOTRSNCSkAAQN0zDq4Hsbqw@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a1130d0ae0506ae052761ace7
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
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 05:22:17 -0000
--001a1130d0ae0506ae052761ace7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mon, Dec 21, 2015 at 4:33 AM, 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.
>
Thank you for saying this. I also think the plan is solid and delivers
multiple benefits without being contentious. The number of wins are so
numerous, it's frankly a no-brainer.
I guess the next step for segwit is a BIP and deployment on a testnet?
--001a1130d0ae0506ae052761ace7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Dec 21, 2015 at 4:33 AM, Pieter Wuille via bitcoin-dev <span dir=3D"ltr=
"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><p dir=3D"ltr"><span class=3D"">On Tue, Dec 8, 201=
5 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></span><span class=3D"">
>> 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.</span></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></blockquote><div>T=
hank you for saying this. I also think the plan is solid and delivers multi=
ple benefits without being contentious. The number of wins are so numerous,=
it's frankly a no-brainer.<br></div><div><br></div><div>I guess the ne=
xt step for segwit is a BIP and deployment on a testnet?</div><div>=C2=A0</=
div></div><br></div></div>
--001a1130d0ae0506ae052761ace7--
|
