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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <stephencalebmorse@gmail.com>) id 1YzwaG-0006Rp-Ia
for bitcoin-development@lists.sourceforge.net;
Wed, 03 Jun 2015 00:31:04 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.51 as permitted sender)
client-ip=209.85.213.51;
envelope-from=stephencalebmorse@gmail.com;
helo=mail-yh0-f51.google.com;
Received: from mail-yh0-f51.google.com ([209.85.213.51])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YzwaF-0002w2-P9
for bitcoin-development@lists.sourceforge.net;
Wed, 03 Jun 2015 00:31:04 +0000
Received: by yhom41 with SMTP id m41so46000702yho.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 02 Jun 2015 17:30:58 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.170.128.139 with SMTP id u133mr36146808ykb.49.1433291458204;
Tue, 02 Jun 2015 17:30:58 -0700 (PDT)
Received: by 10.13.245.70 with HTTP; Tue, 2 Jun 2015 17:30:58 -0700 (PDT)
In-Reply-To: <2342620.MypLiFWdOh@crushinator>
References: <CABHVRKSFV_dXZeLnhBLfRK=wrBFsRH5kFBZqwECh-LyCkwrmtQ@mail.gmail.com>
<2342620.MypLiFWdOh@crushinator>
Date: Tue, 2 Jun 2015 20:30:58 -0400
Message-ID: <CABHVRKTPevP-Z9te2W_N=SaJrF-yUkYgREQQ5O=khOzoL-sbZQ@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>
Content-Type: multipart/alternative; boundary=001a11395ece39d8890517922c97
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
(stephencalebmorse[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: 1YzwaF-0002w2-P9
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
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: Wed, 03 Jun 2015 00:31:04 -0000
--001a11395ece39d8890517922c97
Content-Type: text/plain; charset=UTF-8
>
> Why do it as an OP_RETURN output? It could be a simple token in the
> coinbase input script, similar to how support for P2SH was signaled among
> miners. And why should there be an explicit token for voting for the status
> quo? Simply omitting any indication should be an implicit vote for the
> status quo. A miner would only need to insert an indicator into their block
> if they wished for a larger block.
>
I don't really care the exact location it's put in. I just thought there
wasn't an explicit need to put it in the header (via a bit of nVersion),
and the scriptSig is already used for many things (block height, merged
mining hash, "\"P2SH\"", miner identifier). And voting to keep the block
size the same by not voting is fine by me.
> That said, proposals of this type have been discussed before, and the
> objection is always that miners would want larger blocks than the rest of
> the network could bear. Unless you want Bitcoin to become centralized in
> the hands of a few large mining pools, you shouldn't hand control over the
> block size limits to the miners.
>
Yeah, that was the conclusion we came to chatting on #bitcoin-wizards the
other day. I now think that this could be useful to dynamically increase a
lower limit, but that there should still be a hard upper limit like 20 MB.
I think that just changing the upper limit might be simpler and better,
though.
- Stephen
--001a11395ece39d8890517922c97
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">Why do it as an OP_RETURN output? It could be a simple token i=
n the coinbase input script, similar to how support for P2SH was signaled a=
mong miners. And why should there be an explicit token for voting for the s=
tatus quo? Simply omitting any indication should be an implicit vote for th=
e status quo. A miner would only need to insert an indicator into their blo=
ck if they wished for a larger block.<br></blockquote><div><br></div><div>I=
don't really care the exact location it's put in. I just thought t=
here wasn't an explicit need to put it in the header (via a bit of nVer=
sion), and the scriptSig is already used for many things (block height, mer=
ged mining hash, "\"P2SH\"", miner identifier). And vot=
ing to keep the block size the same by not voting is fine by me.=C2=A0</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex">That said, proposals of this type have b=
een discussed before, and the objection is always that miners would want la=
rger blocks than the rest of the network could bear. Unless you want Bitcoi=
n to become centralized in the hands of a few large mining pools, you shoul=
dn't hand control over the block size limits to the miners.<br></blockq=
uote><div><br></div><div>Yeah, that was the conclusion we came to chatting =
on #bitcoin-wizards the other day. I now think that this could be useful to=
dynamically increase a lower limit, but that there should still be a hard =
upper limit like 20 MB. I think that just changing the upper limit might be=
simpler and better, though.</div><div><br></div><div>- Stephen</div></div>=
</div></div>
--001a11395ece39d8890517922c97--
|
