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
|
Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 21BAF11A1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 19:13:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com
[209.85.217.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 287EDAB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 19:13:14 +0000 (UTC)
Received: by lbcbn3 with SMTP id bn3so44524246lbc.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 12:13:12 -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=OGda3mvkbI+P8nTZhHoDU2ydBohSHiAObdli2tb8EnU=;
b=wJvP0EerMkJlcorajSPEN9xQnOd7jG4BiXjKYC+ZtdpqG3rdCxMyIWYjtmpKjHtQc2
CVkObWHbUTfovcC5WzML5aldigKCMALSB1Ku+NIQrCORKToytgmx9Hcph+eIN+9CvfyC
FKRjx9IVSXAZHIhKtosJoGXAERmfATkbrtUu3QsxXTBQ7QCfn5oGrzUdOd0OhykFqmGE
LeNYzrQvVJpmPbyUvLi0ejpz8yNTgig7ctZGr3ghUt7BWwO5/ONsLAsVipBz7nP5ZgPD
OARMrxlmKwVhtUq4AhgGuGVjTEIJ9MfS8kaD/6CPNrAU8WI9sBDBQx5e7vlzmXDWNnX0
izxw==
MIME-Version: 1.0
X-Received: by 10.152.6.41 with SMTP id x9mr5766291lax.120.1440875592491; Sat,
29 Aug 2015 12:13:12 -0700 (PDT)
Received: by 10.114.220.225 with HTTP; Sat, 29 Aug 2015 12:13:12 -0700 (PDT)
Received: by 10.114.220.225 with HTTP; Sat, 29 Aug 2015 12:13:12 -0700 (PDT)
In-Reply-To: <CABr1YTe+sCAioRMqsAjUC-1v+bfsz24=jjDKaatP=Gbm9sDf8g@mail.gmail.com>
References: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
<CADr=VrQR6rYK4sJJsDpUdFJaWZqhv=AkMqcG64EhsOCg1tDxVg@mail.gmail.com>
<CADJgMzvkBDBD9_=53kaD_6_jWH=vbWOnNwOKK5GOz8Du-F08dQ@mail.gmail.com>
<2081355.cHxjDEpgpW@crushinator>
<A30CC2E3-A769-445C-95A2-35B963EFC283@gmail.com>
<CAB+qUq7ZzLHrFZ5FQazrcALA-b-jFh_bf-XX1GaJbGY1KQB5YA@mail.gmail.com>
<CAOG=w-vkOzGXosc=C7NwX5_ewaT0Sdrkw49gfO+a9hohYctLaw@mail.gmail.com>
<CABm2gDreJ1PwZu3WgZdj_RR0W9JoQTF9w-Qwyfoh6uk1EM0ajg@mail.gmail.com>
<CAOG=w-uYFbyUF+PZABNvMqHei2-yuoCETtXnfkYV-Rr9-pPKuw@mail.gmail.com>
<CADJgMzvJDSk6oZMZPc4C8ENHhGvspdeF7WURfnY6OPKWs33a7w@mail.gmail.com>
<CABr1YTe+sCAioRMqsAjUC-1v+bfsz24=jjDKaatP=Gbm9sDf8g@mail.gmail.com>
Date: Sat, 29 Aug 2015 21:13:12 +0200
Message-ID: <CAAt2M19uCDHgMU8eFVhxuHka7aZ__9VoYtpHEp9qY5APC132Kw@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=089e0141a9a2db2ad3051e77fd55
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_05,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-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Consensus based block size retargeting algorithm
(draft)
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: Sat, 29 Aug 2015 19:13:15 -0000
--089e0141a9a2db2ad3051e77fd55
Content-Type: text/plain; charset=UTF-8
My current idea:
* There's a scheduled hardcap that goes up over time.
* Miners vote on the blocksize limit within the hardcap, choosing the new
votecap. No particular idea for scheduling change. The 2016 block period
seems a bit long though, in case of sudden peak load.
(I'd suggest rolling vote over X blocks, enacted Y blocks later (with votes
counted from block A to block B = block A+X, the change is enacted at block
C = B+Y = A+X+Y). I'm fine with fixed-period schedules too if they span a
reasonable time, such as IMHO 2 days - we need rapid peak adjustment. No
suggestion on vote result calculation mechanism.)
* Casting votes are free.
* The mean (average) blocksize over the last time period X is calculated
for every block, or at the end of every fixed-length period (depending on
what scheduling is used for votes).
* Creating blocks larger than the mean but below the votecap raises the
difficulty target for the miner (and slightly raises the mean for future
blocks).
* The degree of difficulty raise depends on where between the mean and
votecap that the size of the given block is (and it follows that lots of
votes for large raise reduces per-extra-Kb penalty, allowing for cheaper
peak load adjustment if a large miner majority agrees). The degree of
increase may be either linear or logarithmic, I've got no suggestion
currently on any particular metric.
(Some might think this is an easy way for miners to collude to make large
blocks cheaper. If so, you could commit to only pay fee to miners that
don't vote for a block size above the size you accept, as a
counter-incentive.)
* Question: When the votecap is lowered, should the calculated mean be
forced down to follow (forcing a penalty for making blocks close to the
votecap straight after the change)? If so, how? Or should it be allowed to
fall naturally as new blocks with size below the votecap are created?
This is how miners would pay for actually creating larger blocks, and
leaves us with three methods of keeping the size in check (hardcap, votecap
and softcap). The softcap mechanism is then our third check to use if
deemed necessary (orphaning valid blocks if considered problematically
large). This third option do not need coordination with miners, they just
need to be aware which block size is accepted by the community.
I can't think of any sensible non-miner mechanism of deciding max block
size outside of using a community coordinated softcap, anything else will
not work reliably. Too hard to measure objectively and judge fairly.
The community would thus agree on a hardcap schedule in advance, and have
the option to threaten orphaning blocks via softfork later on if
circumstances would change and the votecap is too large.
--089e0141a9a2db2ad3051e77fd55
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">My current idea:</p>
<p dir=3D"ltr">* There's a scheduled hardcap that goes up over time.</p=
>
<p dir=3D"ltr">* Miners vote on the blocksize limit within the hardcap, cho=
osing the new votecap. No particular idea for scheduling change. The 2016 b=
lock period seems a bit long though, in case of sudden peak load.<br>
(I'd suggest rolling vote over X blocks, enacted Y blocks later (with v=
otes counted from block A to block B =3D block A+X, the change is enacted a=
t block C =3D B+Y =3D A+X+Y). I'm fine with fixed-period schedules too =
if they span a reasonable time, such as IMHO 2 days - we need rapid peak ad=
justment. No suggestion on vote result calculation mechanism.)</p>
<p dir=3D"ltr">* Casting votes are free. </p>
<p dir=3D"ltr">* The mean (average) blocksize over the last time period X i=
s calculated for every block,=C2=A0or at the end of every fixed-length peri=
od (depending on what scheduling is used for votes).</p>
<p dir=3D"ltr">* Creating blocks larger than the mean but below the votecap=
raises the difficulty target for the miner (and slightly raises the mean f=
or future blocks). </p>
<p dir=3D"ltr">* The degree of difficulty raise depends on where between th=
e mean and votecap that the size of the given block is (and it follows that=
lots of votes for large raise reduces per-extra-Kb penalty, allowing for c=
heaper peak load adjustment if a large miner majority agrees). The degree o=
f increase may be either linear or logarithmic, I've got no suggestion =
currently on any particular metric.<br>
(Some might think this is an easy way for miners to collude to make large b=
locks cheaper. If so, you could commit to only pay fee to miners that don&#=
39;t vote for a block size above the size you accept, as a counter-incentiv=
e.) </p>
<p dir=3D"ltr">* Question: When the votecap is lowered, should the calculat=
ed mean be forced down to follow (forcing a penalty for making blocks close=
to the votecap straight after the change)? If so, how? Or should it be all=
owed to fall naturally as new blocks with size below the votecap are create=
d? </p>
<p dir=3D"ltr">This is how miners would pay for actually creating larger bl=
ocks, and leaves us with three methods of keeping the size in check (hardca=
p, votecap and softcap). The softcap mechanism is then our third check to u=
se if deemed necessary (orphaning valid blocks if considered problematicall=
y large). This third option do not need coordination with miners, they just=
need to be aware which block size is accepted by the community.</p>
<p dir=3D"ltr">I can't think of any sensible non-miner mechanism of dec=
iding max block size outside of using a community coordinated softcap, anyt=
hing else will not work reliably. Too hard to measure objectively and judge=
fairly.</p>
<p dir=3D"ltr">The community would thus agree on a hardcap schedule in adva=
nce, and have the option to threaten orphaning blocks via softfork later on=
if circumstances would change and the votecap is too large.</p>
--089e0141a9a2db2ad3051e77fd55--
|
