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
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 41C0DCB5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Dec 2015 04:50:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f179.google.com (mail-io0-f179.google.com
[209.85.223.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 584D7EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Dec 2015 04:50:23 +0000 (UTC)
Received: by mail-io0-f179.google.com with SMTP id e126so143577323ioa.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 20:50:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=3dIT3D9CcbSq/lRXhpr5cMbkf8NwGa1oHNs+CtEMayM=;
b=oMoSKtRHwgpDYodoz42GpRyyOB4lpe0cig5WCrHxkK3qsWbWuzcAj08GLRzBPo9uD1
qacIuAmyrIYCcvO+dfirUhUAuI/Di3F4L3GslLKvKUApvjd4tKioLCQw0VWjPhSmj9js
WPdG3GRrtjw6hLZ9BDWTZ1E9vHwb14wW4KdTjbZjsjhbwAGT/BSoABAmxOVAqGvTyPSo
kb/7e9HcUIcPF0h64PEx7p8bK7S34ik0iLOCcITsbcS2Jn5kT5DPP1tvtmyQhqbhD/Q2
obLp9rNk2F9vXbsvTI4+MxY+rmWtrdOc10AAp08nyZuNc+qYZ/hsKrRaPvzqdpK1aatX
1cPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=3dIT3D9CcbSq/lRXhpr5cMbkf8NwGa1oHNs+CtEMayM=;
b=Pd7+loDHdJmTSuODmIGGkdIOLr/1nnO+IuHDXJWaObIIoyWCq92RjySMjxvNkP/+PY
ZcyoWvVP8CpnShX7M2vJHxF52/nZNYOl7jk7PsP8bVwZCSfma+cx6S2Kolt21ToXUGS6
safyzLrsYnVZogs/SPsr6FgsLDMGQTAv6Qfi9ouXItW7wLht/qTpQwn2tfDgj6ylKBDe
z9khd7NqrE4epPNibwyuXsqvpuXI0t27dk+cpKPnYTGsLoIBDvNL+dKG+JfiRYmFCC2h
IV+sSLsUUkIKd+C4nebe6a56Avu6YC0HFAvmUrkjzT3DywAo+ZF+83viaNIV06nr2HIA
1K1g==
X-Gm-Message-State: ALoCoQklpfnZP5WL5U9L5K+ovTOezcwbvbaqHMI2kk7frljZZTkccDLdxlBY/j7eDXwiECulUF1934wp3CNbd6cSPPCltr0NLg==
X-Received: by 10.107.130.90 with SMTP id e87mr2057889iod.77.1450673422717;
Sun, 20 Dec 2015 20:50:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.132.193 with HTTP; Sun, 20 Dec 2015 20:50:03 -0800 (PST)
X-Originating-IP: [49.218.55.28]
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: Mark Friedenbach <mark@friedenbach.org>
Date: Mon, 21 Dec 2015 12:50:03 +0800
Message-ID: <CAOG=w-soDwM+iZAOAYEEh+Fb=qQ4CkY622L8mfB59yPmb8tmmQ@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a113eb42a0becbf0527613a91
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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:50:25 -0000
--001a113eb42a0becbf0527613a91
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I am fully in support of the plan laid out in "Capacity increases for the
bitcoin system".
This plan provides real benefit to the ecosystem in solving a number of
longstanding problems in bitcoin. It improves the scalability of bitcoin
considerably.
Furthermore it is time that we stop bikeshedding, start implementing, and
move forward, lest we lose more developers to the toxic atmosphere this
hard-fork debacle has created.
On Mon, Dec 21, 2015 at 12: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
>
>
--001a113eb42a0becbf0527613a91
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I am fully in support of the plan laid out in "C=
apacity increases for the bitcoin system".<br><br></div>This plan prov=
ides real benefit to the ecosystem in solving a number of longstanding prob=
lems in bitcoin. It improves the scalability of bitcoin considerably.<br><b=
r>Furthermore it is time that we stop bikeshedding, start implementing, and=
move forward, lest we lose more developers to the toxic atmosphere this ha=
rd-fork debacle has created.<br></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Mon, Dec 21, 2015 at 12:33 PM, Pieter Wuille via bi=
tcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr"><span cla=
ss=3D"">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></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><span class=3D"HOEn=
Zb"><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>
--001a113eb42a0becbf0527613a91--
|
