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
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
|
Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1501F13CC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Sep 2015 17:10:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
[209.85.212.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 51067186
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Sep 2015 17:10:10 +0000 (UTC)
Received: by wicfx3 with SMTP id fx3so72568364wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Sep 2015 10:10:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=94e7/BJADgysgcnlc7w91JWMTmZeYgSBWE49rx9g6AM=;
b=bpGx4+PrvTI21W+2L/kspV3gxRY3fdOfT0vzDbZMN0dI8nQzWxzTIbl+EG97k8Se6d
fTmOSKBwBkhaRzN11woFDoSKkVk9dUkBdRivYb05pquhLaHyBprXHabkbfFMC7/Vwm6X
eprHjUJc4xIPQfE6yted0edA4LyroqYvS5vk7K2ueEBtFnnBbPXMe3aCQ8ZMl3SrPogt
FOohVdwSXaau4295SBWwKiDgTC5xqkTiJFho+NCDfIsnZbkeFGa6mdnt4XDA9fjzQf9c
AhAxdRyY6V3X1Yroq0N7WeCL7wS7ZJcORqzm7P4ifGA2hf3joeXQzIZum07lJdcNMN3z
SpYw==
MIME-Version: 1.0
X-Received: by 10.194.121.100 with SMTP id lj4mr8538214wjb.104.1442596208922;
Fri, 18 Sep 2015 10:10:08 -0700 (PDT)
Sender: dscotese@gmail.com
Received: by 10.27.211.132 with HTTP; Fri, 18 Sep 2015 10:10:08 -0700 (PDT)
In-Reply-To: <CAOG=w-t2ZYQbx8+mG5FX8vzgAC_tb8A6KMABmudHQbrquEqX-Q@mail.gmail.com>
References: <CADm_WcaLKqhR=WcJ5B52Q9SAAa+AdZY6Kz5OCQVUc_RQm6e9gg@mail.gmail.com>
<55F9E47D.50507@mattcorallo.com>
<CAOG=w-t2ZYQbx8+mG5FX8vzgAC_tb8A6KMABmudHQbrquEqX-Q@mail.gmail.com>
Date: Fri, 18 Sep 2015 10:10:08 -0700
X-Google-Sender-Auth: avi_KdaH50NELItN1TknG1qEgvk
Message-ID: <CAGLBAheJyK60m2Y9wP=VvGQOsbqjBDMOEn00fKrKad+MmE4M1A@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=089e011777b59656f90520089a99
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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 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 17:10:12 -0000
--089e011777b59656f90520089a99
Content-Type: text/plain; charset=UTF-8
"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."
+1. A ratio is much more valuable than a simple metric. It seems clearly
difficult to identify a reasonable limit to block size, but the ratio
between any one of several possible metrics and bytes in a block would work
well and may already have a very good reasonable expected range.
I like BTCDaysDestroyed (BTCDD) best. If it might be time consuming to
compute, then it need only be computed for all blocks less than or equal in
size to the average size of the largest 200 or so blocks in the previous
difficulty period. To exceed that limit, a miner would have to ensure that
the block has enough BTCDD per byte. "Enough" could be hardcoded in each
release, or if it's simple enough, use the ratio as computed over all the
blocks in the previous difficulty period as the lower limit.
notplato
On Thu, Sep 17, 2015 at 10:55 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
--089e011777b59656f90520089a99
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>"But if a metric were chosen that addressed=
my concerns (worst case=20
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."=
;<br><br></div>+1.=C2=A0 A ratio is much more valuable than a simple metric=
.=C2=A0 It seems clearly difficult to identify a reasonable limit to block =
size, but the ratio between any one of several possible metrics and bytes i=
n a block would work well and may already have a very good reasonable expec=
ted range.<br><br>I like BTCDaysDestroyed (BTCDD) best.=C2=A0 If it might b=
e time consuming to compute, then it need only be computed for all blocks l=
ess than or equal in size to the average size of the largest 200 or so bloc=
ks in the previous difficulty period.=C2=A0 To exceed that limit, a miner w=
ould have to ensure that the block has enough BTCDD per byte.=C2=A0 "E=
nough" could be hardcoded in each release, or if it's simple enoug=
h, use the ratio as computed over all the blocks in the previous difficulty=
period as the lower limit.<br><br></div>notplato<br></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Thu, Sep 17, 2015 at 10:55 PM,=
Mark Friedenbach via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.l=
inuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<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>> - Many interested or at least willing to acce=
pt 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><br></span></blockquote><div><br></div><div>Perhaps it is =
accurate to say that there wasn't consensus at all except that (1) we t=
hink we can work together on resolving this impasse (yay!), and (2) it is c=
onceivable that changing from block size to some other metric might provide=
the basis for a compromise on near-term numbers.<br><br></div><div>As an e=
xample, I do not think the net-UTXO metric provides any benefit with respec=
t to scalability, and in some ways makes the situation worse (even though i=
t helpfully solves an unrelated problem of spammy dust outputs). But there =
are other possible metrics and I maintain hope that data will show the bene=
fit 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 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 a=
ccounting/adjusting is done... But if a metric were chosen that addressed m=
y concerns (worst case propagation and validation time), then I could be in=
favor of an initial bump that allowed a larger number of typical transacti=
ons in a block.<br><br></div><div>But where I really need to disagree is on=
the requirement for a 2nd hard fork. I will go on record as being definiti=
vely 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 a=
s part of any proposal. I am willing to accept a hard-fork if the adopted p=
lan is too conservative, but I do not want to be kicking the can down the r=
oad to a scheduled 2nd hard fork that absolutely must occur. That, I feel, =
could be a more dangerous outcome than an exponential that outlasts conserv=
ative historical trends.<br><br></div><div>I commend Jeff for writing a Cha=
tham-rules summary of the outcome of some hallway conversations that occurr=
ed. On the whole I think his summary does represent the majority view of th=
e opinions expressed by core developers at the workshop. I will caution tho=
ugh that on nearly every issue there were those expressed disagreement but =
did not fight the issue, and those who said nothing and left unpolled opini=
ons. 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 D=
ecember, in order that they have a higher likelihood of success.<br></div><=
/div></div></div></div>
<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><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature"><div dir=3D"ltr">I like to provide some work at no charge to pr=
ove my value. Do you need a techie?=C2=A0 <br>I own <a href=3D"http://www.l=
itmocracy.com" target=3D"_blank">Litmocracy</a> and <a href=3D"http://www.m=
emeracing.net" target=3D"_blank">Meme Racing</a> (in alpha). <br>I'm th=
e webmaster for <a href=3D"http://www.voluntaryist.com" target=3D"_blank">T=
he Voluntaryist</a> which now accepts Bitcoin.<br>I also code for <a href=
=3D"http://dollarvigilante.com/" target=3D"_blank">The Dollar Vigilante</a>=
.<br>"He ought to find it more profitable to play by the rules" -=
Satoshi Nakamoto</div></div>
</div>
--089e011777b59656f90520089a99--
|
