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
|
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C57F61243
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 03:38:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com
[209.85.212.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E63D1143
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 03:38:34 +0000 (UTC)
Received: by wicfx3 with SMTP id fx3so5556376wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 02 Sep 2015 20:38:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=FDQIlD5i5p8pVt0chsGMmonXOtxd5ki0P00akFVB5YU=;
b=wXu1Or5t+f0mR9832NB6j/+pK/3yd7+jLttaTgORf50xpOJElko4jCz+lOXjxTTWYH
fphagK+EzqDKQAO9egHla02PnxX9Mxljd6kEgsY8y7RGqRNTRzKdU59KoLjHwfYVXsaO
PafYUnyJbHPM+oFZRLrzuQhIW2hodb7lNwi2QhcA55mdLmePRWKVpJ3orAI/NwLrA74k
Y8rC44tf6nio0rgFba5dyj7UByP8t+pazMM8dJFAfsG9dqSKX/M8Q9/E2zbezgUeBvh6
we69D78eMCyw0OXtgrQzTGiqEIW5SRIBtojhhf2dqJTZKtIOkKLVJ+HElnWsR4nMdnbs
nzvw==
MIME-Version: 1.0
X-Received: by 10.180.75.11 with SMTP id y11mr10364524wiv.46.1441251513582;
Wed, 02 Sep 2015 20:38:33 -0700 (PDT)
Received: by 10.28.15.11 with HTTP; Wed, 2 Sep 2015 20:38:33 -0700 (PDT)
In-Reply-To: <201509030017.43036.luke@dashjr.org>
References: <CADm_WcZpOxLJdxENe=GXqrp17C-Q2karunOvzegGz-NQ2b_AEg@mail.gmail.com>
<CADm_WcZEbAe_+VXxS1eMKQ1SM3KiJwVDS50-GtfUPw-Mdd5O2w@mail.gmail.com>
<201509030017.43036.luke@dashjr.org>
Date: Wed, 2 Sep 2015 23:38:33 -0400
Message-ID: <CADm_WcapYX+4wqd+6JLALt9FLJif8EL3v4dmuGHO5rnhTHpJSw@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=f46d043c7cd87fc920051ecf8449
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,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] BIP 100 repo
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: Thu, 03 Sep 2015 03:38:35 -0000
--f46d043c7cd87fc920051ecf8449
Content-Type: text/plain; charset=UTF-8
Luke,
- Definitely agree with most of your suggestions on the practical side;
several clarification could be made.
- The power to decrease the hard limit appears riskier long term in my
analysis. This is mitigated somewhat by the ease at which miners may
locally or collectively lower the block size at any time, without a vote.
On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr <luke@dashjr.org> wrote:
> On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev
> wrote:
> > The repo: https://github.com/jgarzik/bip100
>
> What is the purpose of the newly added 1 MB floor? It seems clear from the
> current information available that 1 MB is presently too high for the
> limit,
> and it is entirely one-sided to only allow increases when decreases are
> much
> more likely to be needed in the short term.
>
> Must the new size limit votes use 11 bytes of coinbase? Why not just use a
> numeric value pushed after height? Since this is a hardfork, I suggest
> increasing the coinbase length to allow for 100 bytes *in addition* to the
> pushed height and size-vote.
>
> I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32
> MB
> (or whatever value is deemed appropriate) to make it clear that the limit
> remains a part of the consensus protocol and p2p protocol limits are not to
> have an effect on consensus rules.
>
> Furthermore, I suggest modifying the voting to require 50% to set the limit
> floor. This has the effect of merely coordinating what miners can already
> effectively do today by rejecting blocks larger than some collusion-
> determined limit.
>
> Thoughts?
>
> Luke
>
--f46d043c7cd87fc920051ecf8449
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Luke,<div><br></div><div>- Definitely agree with most of y=
our suggestions on the practical side; several clarification could be made.=
<div>- The power to decrease the hard limit appears riskier long term in my=
analysis.=C2=A0 This is mitigated somewhat by the ease at which miners may=
locally or collectively lower the block size at any time, without a vote.<=
/div></div><div><br></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr <span dir=3D"l=
tr"><<a href=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@dashjr.or=
g</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday, Sep=
tember 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev<br>
wrote:<br>
> The repo: <a href=3D"https://github.com/jgarzik/bip100" rel=3D"norefer=
rer" target=3D"_blank">https://github.com/jgarzik/bip100</a><br>
<br>
What is the purpose of the newly added 1 MB floor? It seems clear from the<=
br>
current information available that 1 MB is presently too high for the limit=
,<br>
and it is entirely one-sided to only allow increases when decreases are muc=
h<br>
more likely to be needed in the short term.<br>
<br>
Must the new size limit votes use 11 bytes of coinbase? Why not just use a<=
br>
numeric value pushed after height? Since this is a hardfork, I suggest<br>
increasing the coinbase length to allow for 100 bytes *in addition* to the<=
br>
pushed height and size-vote.<br>
<br>
I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to =
32 MB<br>
(or whatever value is deemed appropriate) to make it clear that the limit<b=
r>
remains a part of the consensus protocol and p2p protocol limits are not to=
<br>
have an effect on consensus rules.<br>
<br>
Furthermore, I suggest modifying the voting to require 50% to set the limit=
<br>
floor. This has the effect of merely coordinating what miners can already<b=
r>
effectively do today by rejecting blocks larger than some collusion-<br>
determined limit.<br>
<br>
Thoughts?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div>
--f46d043c7cd87fc920051ecf8449--
|
