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
|
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 42C241144
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Sep 2015 05:56:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com
[209.85.213.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8D1EB13D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Sep 2015 05:56:15 +0000 (UTC)
Received: by igxx6 with SMTP id x6so10721849igx.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Sep 2015 22:56:15 -0700 (PDT)
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=YAA4BBNHplD94zLcNjVrONbj1LJpCU84DRK8wfH/rvE=;
b=RQeDSfHpY3DyJTJMizS22IXc1+b2fwOt94zDqIuguNALqPgXCtfYBQZjUY/HQ21huZ
IbnF7tnJ0uoOxEXe8roFMYoMg12AXTe4qGwCxJoDTn4B4d7p8bC8r0IGT9AHWMGiHk66
P/ViSYhvLook0NSm+Q1E5PTr9aKJ8Cd9Geh+ww5qZRvt4D2MRLqt2MFpLPHO0rRf5+Xo
2QjdnJWT7vr9dKEGospMBXq1sd+WKK1PYhzZb48WnIIjPz4fcxFhYf1gDLy7LddMq/m4
7IV8EuwU2xbw/gcY8E0fa+Ls+AbO/9wL8G9MMjEF7L7+03zPWMEi/5rhtNdGp0h/tVcE
lhTQ==
X-Gm-Message-State: ALoCoQnmmRMckFfdZW8FrsdGNLV939A4caY8Oig7ez/Fbae+NdZ1AUPImiykZsVOd7ht95HfHapQ
X-Received: by 10.50.83.73 with SMTP id o9mr12137393igy.40.1442555774956; Thu,
17 Sep 2015 22:56:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.135.104 with HTTP; Thu, 17 Sep 2015 22:55:55 -0700 (PDT)
X-Originating-IP: [24.114.98.158]
In-Reply-To: <55F9E47D.50507@mattcorallo.com>
References: <CADm_WcaLKqhR=WcJ5B52Q9SAAa+AdZY6Kz5OCQVUc_RQm6e9gg@mail.gmail.com>
<55F9E47D.50507@mattcorallo.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Fri, 18 Sep 2015 01:55:55 -0400
Message-ID: <CAOG=w-t2ZYQbx8+mG5FX8vzgAC_tb8A6KMABmudHQbrquEqX-Q@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary=089e0116076c8919e4051fff3081
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_05,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 development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
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: Fri, 18 Sep 2015 05:56:16 -0000
--089e0116076c8919e4051fff3081
Content-Type: text/plain; charset=UTF-8
Correction of a correction, in-line:
On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > - Many interested or at least willing to accept a "short term bump", a
> > hard fork to modify block size limit regime to be cost-based via
> > "net-utxo" rather than a simple static hard limit. 2-4-8 and 17%/year
> > were debated and seemed "in range" with what might work as a short term
> > bump - net after applying the new cost metric.
>
> I would be careful to point out that hard numbers were deliberately NOT
> discussed. Though some general things were thrown out, they were not
> extensively discussed nor agreed to. I personally think 2-4 is "in
> range", though 8 maybe not so much. Of course it depends on exactly how
> the non-blocksize limit accounting/adjusting is done.
>
> Still, the "greatest common denominator" agreement did not seem to be
> agreeing to an increase which continues over time, but which instead
> limits itself to a set, smooth increase for X time and then requires a
> second hardfork if there is agreement on a need for more blocksize at
> that point.
>
Perhaps it is accurate to say that there wasn't consensus at all except
that (1) we think we can work together on resolving this impasse (yay!),
and (2) it is conceivable that changing from block size to some other
metric might provide the basis for a compromise on near-term numbers.
As an example, I do not think the net-UTXO metric provides any benefit with
respect to scalability, and in some ways makes the situation worse (even
though it helpfully solves an unrelated problem of spammy dust outputs).
But there are other possible metrics and I maintain hope that data will
show the benefit of another metric or other metrics combined with net-UTXO
in a way that will allow us to reach consensus.
As a further example, I also am quite concerned about 2-4-8MB with either
block size or net-UTXO as the base metric. As you say, it depends on how
the non-blocksize limit accounting/adjusting is done... But if a metric
were chosen that addressed my concerns (worst case propagation and
validation time), then I could be in favor of an initial bump that allowed
a larger number of typical transactions in a block.
But where I really need to disagree is on the requirement for a 2nd hard
fork. I will go on record as being definitively against this. While being
conservative with respect to exponentials, I would very much like to make
sure that there is a long-term growth curve as part of any proposal. I am
willing to accept a hard-fork if the adopted plan is too conservative, but
I do not want to be kicking the can down the road to a scheduled 2nd hard
fork that absolutely must occur. That, I feel, could be a more dangerous
outcome than an exponential that outlasts conservative historical trends.
I commend Jeff for writing a Chatham-rules summary of the outcome of some
hallway conversations that occurred. On the whole I think his summary does
represent the majority view of the opinions expressed by core developers at
the workshop. I will caution though that on nearly every issue there were
those expressed disagreement but did not fight the issue, and those who
said nothing and left unpolled opinions. Nevertheless this summary is
informative as it feeds forwards into the design of proposals that will be
made prior to the Hong Kong workshop in December, in order that they have a
higher likelihood of success.
--089e0116076c8919e4051fff3081
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Correction of a correction, in-line:<br><div><br>On Wed, S=
ep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev <span dir=3D"ltr"><=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><span class=3D"">> - Many interested or at least will=
ing to accept a "short term bump", a<br>
> hard fork to modify block size limit regime to be cost-based via<br>
> "net-utxo" rather than a simple static hard limit.=C2=A0 2-4=
-8 and 17%/year<br>
> were debated and seemed "in range" with what might work as a=
short term<br>
> bump - net after applying the new cost metric.<br>
<br>
</span>I would be careful to point out that hard numbers were deliberately =
NOT<br>
discussed. Though some general things were thrown out, they were not<br>
extensively discussed nor agreed to. I personally think 2-4 is "in<br>
range", though 8 maybe not so much. Of course it depends on exactly ho=
w<br>
the non-blocksize limit accounting/adjusting is done.<br>
<br>
Still, the "greatest common denominator" agreement did not seem t=
o be<br>
agreeing to an increase which continues over time, but which instead<br>
limits itself to a set, smooth increase for X time and then requires a<br>
second hardfork if there is agreement on a need for more blocksize at<br>
that point.<span class=3D""><br></span></blockquote><div><br></div><div>Per=
haps it is accurate to say that there wasn't consensus at all except th=
at (1) we think we can work together on resolving this impasse (yay!), and =
(2) it is conceivable that changing from block size to some other metric mi=
ght provide the basis for a compromise on near-term numbers.<br><br></div><=
div>As an example, I do not think the net-UTXO metric provides any benefit =
with respect to scalability, and in some ways makes the situation worse (ev=
en though it helpfully solves an unrelated problem of spammy dust outputs).=
But there are other possible metrics and I maintain hope that data will sh=
ow the benefit of another metric or other metrics combined with net-UTXO in=
a way that will allow us to reach consensus.<br><br></div><div>As a furthe=
r example, I also am quite concerned about 2-4-8MB with either block size o=
r net-UTXO as the base metric. As you say, it depends on how the non-blocks=
ize limit accounting/adjusting is done... But if a metric were chosen that =
addressed my concerns (worst case propagation and validation time), then I =
could be in favor of an initial bump that allowed a larger number of typica=
l transactions in a block.<br><br></div><div>But where I really need to dis=
agree is on the requirement for a 2nd hard fork. I will go on record as bei=
ng definitively against this. While being conservative with respect to expo=
nentials, I would very much like to make sure that there is a long-term gro=
wth curve as part of any proposal. I am willing to accept a hard-fork if th=
e adopted plan is too conservative, but I do not want to be kicking the can=
down the road to a scheduled 2nd hard fork that absolutely must occur. Tha=
t, I feel, could be a more dangerous outcome than an exponential that outla=
sts conservative historical trends.<br><br></div><div>I commend Jeff for wr=
iting a Chatham-rules summary of the outcome of some hallway conversations =
that occurred. On the whole I think his summary does represent the majority=
view of the opinions expressed by core developers at the workshop. I will =
caution though that on nearly every issue there were those expressed disagr=
eement but did not fight the issue, and those who said nothing and left unp=
olled opinions. Nevertheless this summary is informative as it feeds forwar=
ds into the design of proposals that will be made prior to the Hong Kong wo=
rkshop in December, in order that they have a higher likelihood of success.=
<br></div></div></div></div></div>
--089e0116076c8919e4051fff3081--
|
