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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jrn@jrn.me.uk>) id 1YqQhA-0002m2-Bf
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 18:38:52 +0000
X-ACL-Warn:
Received: from hapkido.dreamhost.com ([66.33.216.122])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YqQh8-0003C5-Ue for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 18:38:52 +0000
Received: from homiemail-a3.g.dreamhost.com (homie.mail.dreamhost.com
[208.97.132.208])
by hapkido.dreamhost.com (Postfix) with ESMTP id 2787B9ED07
for <bitcoin-development@lists.sourceforge.net>;
Thu, 7 May 2015 11:21:56 -0700 (PDT)
Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1])
by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 5C38E284082;
Thu, 7 May 2015 11:21:50 -0700 (PDT)
Received: from [192.168.0.6] (cpc12-cmbg17-2-0-cust830.5-4.cable.virginm.net
[86.30.131.63])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: jrn@jrn.me.uk)
by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id 9DBC8284090;
Thu, 7 May 2015 11:21:49 -0700 (PDT)
Message-ID: <554BAD3B.2050404@jrn.me.uk>
Date: Thu, 07 May 2015 19:21:47 +0100
From: Ross Nicoll <jrn@jrn.me.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
References: <554A91BE.6060105@bluematt.me> <CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com> <CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com> <CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com> <CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com> <CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com> <CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com> <554BA032.4040405@bluematt.me> <CANEZrP3yM9wsSPNgpOsXDk-DjUy5PW2XuRTvK2AyCNbVJ5hZHw@mail.gmail.com> <CADJgMzti7ROH90APiwg4NOAT5+Av=4i295b8VN0sbSLr4+WWRw@mail.gmail.com>
<CANEZrP39jWHLF02z-81Z4+9X1vH5+hMuS=-3ED81=Q1o9U=DKw@mail.gmail.com>
In-Reply-To: <CANEZrP39jWHLF02z-81Z4+9X1vH5+hMuS=-3ED81=Q1o9U=DKw@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------030508090401080706080902"
X-Spam-Score: 0.9 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [66.33.216.122 listed in list.dnswl.org]
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: 1YqQh8-0003C5-Ue
Subject: Re: [Bitcoin-development] Block Size Increase
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: Thu, 07 May 2015 18:38:52 -0000
This is a multi-part message in MIME format.
--------------030508090401080706080902
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Can I just add my own support for this - as has been stated elsewhere in
this discussion, hard forks are difficult, and risky. The earlier we
have a decision, and the earlier the change goes into the code, the
easier that is.
Even if the decision was the actual block size change is fine to leave
until 2020, I'd like to see the code committed ASAP so that every new
install, and every upgrade from there on gets the new version.
My personal opinion only is that 7 transactions a second is insanely
limited even if the main chain does nothing but act as a backbone
between other chains and transaction networks. I don't think that's
overly controversial. I think 2016 is too early for a 20mb block size,
though. I'm inclined to suggest a schedule of expansion, say to 2mb in
2016, 4mb in 2018, 8mb in 2020 and 20mb in 2022 where it stops. The
intent would be to provide enough size pressure to motivate scaling
work, while not limiting Bitcoin overly.
Further, I think this highlights that we need more work on fees. Right
now fees and transactions included are fairly naive, but I'd like to see
the absolute block size limit as a hard upper bound, with miners
imposing soft limits based on a balance cost of storage, number of
outputs vs inputs (and therefore impact on the UTXOs), and risk of
orphan blocks to determine which transactions are actually worth
including in each block. If anyone has numbers on block size vs orphan
rate that would be really useful, BTW.
Ross
On 07/05/2015 19:06, Mike Hearn wrote:
>
> I think you are rubbing against your own presupposition that
> people must find and alternative right now. Quite a lot here do
> not believe there is any urgency, nor that there is an immanent
> problem that has to be solved before the sky falls in.
>
>
> I have explained why I believe there is some urgency, whereby "some
> urgency" I mean, assuming it takes months to implement, merge, test,
> release and for people to upgrade.
>
> But if it makes you happy, imagine that this discussion happens all
> over again next year and I ask the same question.
>
>
>
> ------------------------------------------------------------------------------
> 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
--------------030508090401080706080902
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Can I just add my own support for this - as has been stated
elsewhere in this discussion, hard forks are difficult, and risky.
The earlier we have a decision, and the earlier the change goes into
the code, the easier that is.<br>
<br>
Even if the decision was the actual block size change is fine to
leave until 2020, I'd like to see the code committed ASAP so that
every new install, and every upgrade from there on gets the new
version.<br>
<br>
My personal opinion only is that 7 transactions a second is insanely
limited even if the main chain does nothing but act as a backbone
between other chains and transaction networks. I don't think that's
overly controversial. I think 2016 is too early for a 20mb block
size, though. I'm inclined to suggest a schedule of expansion, say
to 2mb in 2016, 4mb in 2018, 8mb in 2020 and 20mb in 2022 where it
stops. The intent would be to provide enough size pressure to
motivate scaling work, while not limiting Bitcoin overly.<br>
<br>
Further, I think this highlights that we need more work on fees.
Right now fees and transactions included are fairly naive, but I'd
like to see the absolute block size limit as a hard upper bound,
with miners imposing soft limits based on a balance cost of storage,
number of outputs vs inputs (and therefore impact on the UTXOs), and
risk of orphan blocks to determine which transactions are actually
worth including in each block. If anyone has numbers on block size
vs orphan rate that would be really useful, BTW.<br>
<br>
Ross<br>
<br>
<div class="moz-cite-prefix">On 07/05/2015 19:06, Mike Hearn wrote:<br>
</div>
<blockquote
cite="mid:CANEZrP39jWHLF02z-81Z4+9X1vH5+hMuS=-3ED81=Q1o9U=DKw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>I think you are rubbing against your own
presupposition that people must find and
alternative right now. Quite a lot here do not
believe there is any urgency, nor that there is an
immanent problem that has to be solved before the
sky falls in.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I have explained why I believe there is some urgency,
whereby "some urgency" I mean, assuming it takes months to
implement, merge, test, release and for people to upgrade.</div>
<div><br>
</div>
<div>But if it makes you happy, imagine that this discussion
happens all over again next year and I ask the same
question.</div>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
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.
<a class="moz-txt-link-freetext" href="http://ad.doubleclick.net/ddm/clk/290420510;117567292;y">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------030508090401080706080902--
|
