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
|
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 46B65132A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 04:09:27 +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 60A47118
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 04:09:26 +0000 (UTC)
Received: by wicmc4 with SMTP id mc4so5989464wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 02 Sep 2015 21:09:25 -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=gaSZtRjKS4IIpzUW6RKRNBqtxyLl9U9PZwUAA4hWvtc=;
b=REzUaLWgPjtawxzqVKqA+hU4iKd2vemoFUDA9DFH4SKGSTFWtS4BxNMfwUvjjwNqTZ
0/URVVvYgpk2h/FoXKZrT+ncg487RB7VJoIT3TYg1oRqfTge4tKJqbbe8DInv/4bu176
ddPrgcvzVqMA/nahETN+JAA07XPXah6KPWrGOrtdeTIvXKLMLEb5CxVhYm5lc/oCN0PZ
FnmW7b6bmsX6pF07Pbt3PUjddjD1RTCkAS7XK0xa11OPS+5d3U7fJ/Zo1fKl3axM96tI
5QobbtMahqtEd1J8F8jIR8k5nbG57d9L1WxHbYQqjLx4WjfX+pRCVFd4wFbJYU/POtHw
HniQ==
MIME-Version: 1.0
X-Received: by 10.194.176.201 with SMTP id ck9mr45961781wjc.108.1441253365085;
Wed, 02 Sep 2015 21:09:25 -0700 (PDT)
Received: by 10.28.15.11 with HTTP; Wed, 2 Sep 2015 21:09:25 -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: Thu, 3 Sep 2015 00:09:25 -0400
Message-ID: <CADm_WcawXU3b5g_kuUCKxHQ2YVRPmVh6g33qWDWqdw-X4tSE7Q@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=089e013d1eb4db7b14051ecff28e
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 04:09:27 -0000
--089e013d1eb4db7b14051ecff28e
Content-Type: text/plain; charset=UTF-8
Oh, and answering your question about the 1M: It is a safety rail. It can
perform no worse on the low end than the current system. Eliminates
unlikely scenarios that squeeze users.
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
>
--089e013d1eb4db7b14051ecff28e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Oh, and answering your question about the 1M: =C2=A0It is =
a safety rail.=C2=A0 It can perform no worse on the low end than the curren=
t system.=C2=A0 Eliminates unlikely scenarios that squeeze users.<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"ltr"><<a href=3D"mail=
to:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">On Wednesday, September 02, 2015 11:58:5=
4 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>
--089e013d1eb4db7b14051ecff28e--
|
