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
|
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 1Yz8XG-00041o-II
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 19:04:38 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.41 as permitted sender)
client-ip=209.85.213.41;
envelope-from=stephencalebmorse@gmail.com;
helo=mail-yh0-f41.google.com;
Received: from mail-yh0-f41.google.com ([209.85.213.41])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yz8XF-0000Tk-Ma
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 19:04:38 +0000
Received: by yhpn97 with SMTP id n97so28463578yhp.0
for <bitcoin-development@lists.sourceforge.net>;
Sun, 31 May 2015 12:04:32 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.45.2 with SMTP id o2mr19057791yhb.194.1433099072196;
Sun, 31 May 2015 12:04:32 -0700 (PDT)
Received: by 10.13.245.70 with HTTP; Sun, 31 May 2015 12:04:32 -0700 (PDT)
Date: Sun, 31 May 2015 15:04:32 -0400
Message-ID: <CABHVRKSFV_dXZeLnhBLfRK=wrBFsRH5kFBZqwECh-LyCkwrmtQ@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e0122f52e2055d7051765615d
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: 1Yz8XF-0000Tk-Ma
Subject: [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: Sun, 31 May 2015 19:04:38 -0000
--089e0122f52e2055d7051765615d
Content-Type: text/plain; charset=UTF-8
This is likely very similar to other proposals, but I want to bring voting
procedures back into the discussion. The goal here is to create a voting
procedure that is as simple as possible to increase the block size limit.
Votes are aggregated over each 2016 block period. Each coinbase transaction
may have an output at tx.vout[0] with OP_RETURN data in it of the format:
OP_RETURN {OP_1 or OP_2}
OP_2 means the miner votes to increase the block size limit. OP_1 means the
miner votes to not increase the block size limit. *Not including such a
vote is equivalent to voting to NOT increase the block size. *I first
thought that not voting should mean that you vote with your block size, but
then decided that it would be too gameable by others broadcasting
transactions to affect your block size.
If in a 2016 block round there were more than 1008 blocks that voted to
increase the block size limit, then the max block size increases by 500 kb.
The votes can start when there is a supermajority of miners signaling
support for the voting procedure.
A few important properties of this simple voting:
- It's not gameable via broadcasting transactions (assuming miners don't
set their votes to be automatic, based on the size of recent blocks).
- Miners don't have to bloat their blocks artificially just to place a
vote for larger block sizes, and, similarly, don't need to exclude
transactions even when they think the block size does not need to be raised.
- The chain up until the point that this goes into effect may be
interpreted as just lacking votes to increase the block size.
We can't trust all miners, but we have to trust that >50% of them are
honest for the system to work. This system makes it so that altering the
maximum block size requires >50% of miners (hash power) to vote to increase
the consensus-limit.
Thanks for your time. I think this is an important time in Bitcoin's
history. I'm not married to this proposal, but I think it would work. I
think a lot of the proposals mentioned on this mailing list would work. I
think it's time we just pick one and run with it.
Please let me know your thoughts. I will start working on a pull request if
this receives any support from miners/core devs/community members, unless
someone with more experience volunteers.
Best,
Stephen
--089e0122f52e2055d7051765615d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is likely very similar to other proposals, but I want=
to bring voting procedures back into the discussion. The goal here is to c=
reate a voting procedure that is as simple as possible to increase the bloc=
k size limit.<div><br></div><div>Votes are aggregated over each 2016 block =
period. Each coinbase transaction may have an output at <font face=3D"monos=
pace, monospace">tx.vout[0]</font> with <font face=3D"monospace, monospace"=
>OP_RETURN</font> data in it of the format:<br></div><div><br></div><div><f=
ont face=3D"monospace, monospace">=C2=A0 OP_RETURN {OP_1 or OP_2}</font></d=
iv><div><br></div><div><font face=3D"monospace, monospace">OP_2</font>=C2=
=A0means the miner votes to increase the block size limit. <font face=3D"mo=
nospace, monospace">OP_1</font>=C2=A0means the miner votes to not increase =
the block size limit. <b>Not including such a vote is equivalent to voting =
to NOT increase the block size. </b>I first thought that not voting should =
mean that you vote with your block size, but then decided that it would be =
too gameable by others broadcasting transactions to affect your block size.=
=C2=A0</div><div><br></div><div>If in a 2016 block round there were more th=
an 1008 blocks that voted to increase the block size limit, then the max bl=
ock size increases by 500 kb. The votes can start when there is a supermajo=
rity of miners signaling support for the voting procedure.=C2=A0</div><div>=
<br></div><div>A few important properties of this simple voting:</div><div>=
<ul><li>It's not gameable via broadcasting transactions (assuming miner=
s don't set their votes to be automatic, based on the size of recent bl=
ocks).</li><li>Miners don't have to bloat their blocks artificially jus=
t to place a vote for larger block sizes, and, similarly, don't need to=
exclude transactions even when they think the block size does not need to =
be raised.<br></li><li>The chain up until the point that this goes into eff=
ect may be interpreted as just lacking votes to increase the block size.=C2=
=A0</li></ul></div><div>We can't trust all miners, but we have to trust=
that >50% of them are honest for the system to work. This system makes =
it so that altering the maximum block size requires >50% of miners (hash=
power) to vote to increase the consensus-limit.</div><div><br></div><div>T=
hanks for your time. I think this is an important time in Bitcoin's his=
tory. I'm not married to this proposal, but I think it would work. I th=
ink a lot of the proposals mentioned on this mailing list would work. I thi=
nk it's time we just pick one and run with it.=C2=A0</div><div><br></di=
v><div>Please let me know your thoughts. I will start working on a pull req=
uest if this receives any support from miners/core devs/community members, =
unless someone with more experience volunteers.</div><div><br></div><div>Be=
st,</div><div>Stephen</div><div><br></div><div><br></div></div>
--089e0122f52e2055d7051765615d--
|
