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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <clem.ds@gmail.com>) id 1YqfY5-0000eZ-Ph
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 10:30:29 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.169 as permitted sender)
client-ip=209.85.223.169; envelope-from=clem.ds@gmail.com;
helo=mail-ie0-f169.google.com;
Received: from mail-ie0-f169.google.com ([209.85.223.169])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqfY4-0003Q7-C6
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 10:30:29 +0000
Received: by iepj10 with SMTP id j10so56847259iep.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 08 May 2015 03:30:23 -0700 (PDT)
X-Received: by 10.42.187.65 with SMTP id cv1mr3339554icb.87.1431081023056;
Fri, 08 May 2015 03:30:23 -0700 (PDT)
MIME-Version: 1.0
References: <16096345.A1MpJQQkRW@crushinator>
In-Reply-To: <16096345.A1MpJQQkRW@crushinator>
From: =?UTF-8?Q?Cl=C3=A9ment_Elbaz?= <clem.ds@gmail.com>
Date: Fri, 08 May 2015 10:30:22 +0000
Message-ID: <CAP63atbdFSw0rDeuwgtjsDYsXnKSHNN9=zedzip2MsZ0hSY59w@mail.gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>,
bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=20cf303ea102062fb405158f84c7
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(clem.ds[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YqfY4-0003Q7-C6
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
function
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2015 10:30:29 -0000
--20cf303ea102062fb405158f84c7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Matt : I think proposal #1 and #3 are a lot better than #2, and #1 is my
favorite.
I see two problems with proposal #2.
The first problem with proposal #2 is that, as we see in democracies,
there is often a mismatch between the people conscious vote and these same
people behavior.
Relying on an intentional vote made consciously by miners by choosing a
configuration value can lead to twisted results if their actual behavior
doesn't correlate with their vote (eg, they all vote for a small block size
because it is the default configuration of their software, and then they
fill it completely all the time and everything crashes).
The second problem with proposal #2 is that if Gavin and Mike are right,
there is simply no time to gather a meaningful amount of votes over the
coinbases, after the fork but before the Bitcoin scalability crash.
I like proposal #1 because the "vote" is made using already available data.
Also there is no possible mismatch between behavior and vote. As a miner
you vote by choosing to create a big (or small) block, and your actions
reflect your vote. It is simple and straightforward.
My feelings on proposal #3 is it is a little bit mixing apples and oranges,
but I may not seeing all the implications.
Le ven. 8 mai 2015 =C3=A0 09:21, Matt Whitlock <bip@mattwhitlock.name> a =
=C3=A9crit :
> Between all the flames on this list, several ideas were raised that did
> not get much attention. I hereby resubmit these ideas for consideration a=
nd
> discussion.
>
> - Perhaps the hard block size limit should be a function of the actual
> block sizes over some trailing sampling period. For example, take the
> median block size among the most recent 2016 blocks and multiply it by 1.=
5.
> This allows Bitcoin to scale up gradually and organically, rather than
> having human beings guessing at what is an appropriate limit.
>
> - Perhaps the hard block size limit should be determined by a vote of the
> miners. Each miner could embed a desired block size limit in the coinbase
> transactions of the blocks it publishes. The effective hard block size
> limit would be that size having the greatest number of votes within a
> sliding window of most recent blocks.
>
> - Perhaps the hard block size limit should be a function of block-chain
> length, so that it can scale up smoothly rather than jumping immediately =
to
> 20 MB. This function could be linear (anticipating a breakdown of Moore's
> Law) or quadratic.
>
> I would be in support of any of the above, but I do not support Mike
> Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the
> road without actually solving the problem, and it does so in a
> controversial (step function) way.
>
>
> -------------------------------------------------------------------------=
-----
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--20cf303ea102062fb405158f84c7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>Matt : I think proposal #1 and #3 are a lot=
better than #2, and #1 is my favorite.<br><br></div><div>I see two problem=
s with proposal #2.<br></div>The first problem with proposal #2 is that, as=
we see in democracies,=C2=A0 there is often a mismatch between the people =
conscious vote and these same people behavior. <br><br>Relying on an=C2=A0 =
intentional vote made consciously by miners by choosing a configuration val=
ue can lead to twisted results if their actual behavior doesn't correla=
te with their vote (eg, they all vote for a small block size because it is =
the default configuration of their software, and then they fill it complete=
ly all the time and everything crashes).<br><br></div><div>The second probl=
em with proposal #2 is that if Gavin and Mike are right, there is simply no=
time to gather a meaningful amount of votes over the coinbases, after the =
fork but before the Bitcoin scalability crash. <br></div><div><br></div>I l=
ike proposal #1 because the "vote" is made using already availabl=
e data. Also there is no possible mismatch between behavior and vote. As a =
miner you vote by choosing to create a big (or small) block, and your actio=
ns reflect your vote. It is simple and straightforward.<br><br></div>My fee=
lings on proposal #3 is it is a little bit mixing apples and oranges, but I=
may not seeing all the implications.<br><div><div><div><div><div><br><div =
class=3D"gmail_quote">Le=C2=A0ven. 8 mai 2015 =C3=A0=C2=A009:21, Matt Whitl=
ock <<a href=3D"mailto:bip@mattwhitlock.name">bip@mattwhitlock.name</a>&=
gt; a =C3=A9crit=C2=A0:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Between all the f=
lames on this list, several ideas were raised that did not get much attenti=
on. I hereby resubmit these ideas for consideration and discussion.<br>
<br>
- Perhaps the hard block size limit should be a function of the actual bloc=
k sizes over some trailing sampling period. For example, take the median bl=
ock size among the most recent 2016 blocks and multiply it by 1.5. This all=
ows Bitcoin to scale up gradually and organically, rather than having human=
beings guessing at what is an appropriate limit.<br>
<br>
- Perhaps the hard block size limit should be determined by a vote of the m=
iners. Each miner could embed a desired block size limit in the coinbase tr=
ansactions of the blocks it publishes. The effective hard block size limit =
would be that size having the greatest number of votes within a sliding win=
dow of most recent blocks.<br>
<br>
- Perhaps the hard block size limit should be a function of block-chain len=
gth, so that it can scale up smoothly rather than jumping immediately to 20=
MB. This function could be linear (anticipating a breakdown of Moore's=
Law) or quadratic.<br>
<br>
I would be in support of any of the above, but I do not support Mike Hearn&=
#39;s proposed jump to 20 MB. Hearn's proposal kicks the can down the r=
oad without actually solving the problem, and it does so in a controversial=
(step function) way.<br>
<br>
---------------------------------------------------------------------------=
---<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div></div></div></div></div></div></div>
--20cf303ea102062fb405158f84c7--
|
