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
|
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0F71ABEC
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Mar 2017 19:42:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com
[209.85.220.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1168D240
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Mar 2017 19:42:12 +0000 (UTC)
Received: by mail-qk0-f180.google.com with SMTP id p64so83929104qke.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 08 Mar 2017 11:42:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:from:date:message-id:subject:to;
bh=nGWDJ/pw0b/KQGE8KN1XYCneBV/DEyIOlYjLKNuiWSg=;
b=MC2fJW8GBvLU64LbeAOHXXF1x8gNw3masVPzOV0m4VRca2H/d7fyJ/vCeVQ2ofjr2s
0QTIOFFfzwRB5Cq3VF80n5p2RC9/fJu4ad7gfQw+49aMTxqlyJpdgieR3zaORwaZY7Zs
7JJ3Yem2eJ9gZ8fdnYNqdaByptub6yFloBqpKpEMDtMEZql5UCSjIRJ0CZPA1V1lA3gn
UfNOYePrUzGHULy0DrEBYZWdBjY0XdX6dRjRXnrQUilxdVdQApbfhYyHdk9NhWDtSg5K
JESg++7C04reEWQgdSWbG66xEjAQyOHB802Nuol40SM7V4T7vqR/hbVuOK/qU8/JAL7n
+Wew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:from:date:message-id:subject
:to; bh=nGWDJ/pw0b/KQGE8KN1XYCneBV/DEyIOlYjLKNuiWSg=;
b=ioaLAqhdy2Zb862LTfWQjZ5lfB0lWcxRAnCMN3WKlo2kGVd06wmueNSwpV2xrDMZ18
3FMVbHi8UwxCM01g1BFyCvFf7EwJkPPlGFbt632E9CYXjgklQa9Olp4WwBBgpLat4lrL
FFimDZL/TAPFnjDwFa3UZu+xPwdn4EkEB5lpsSRix9gVk8WmO/9bh7kUdmZbXTkFr4/z
FJpzYGT/D4UKkI641CuHT0SmOTNyASOB2NqHwmyZJIZ7mcRkcEJ0pO3w0QQYXxcg5IIw
MIMoFFAXgR8uN2s9k0JlMsTmZyQIfLriIBgoEAPmHn0lSMLbGi/jXLY7Z6sS1Dr62I+0
vZrg==
X-Gm-Message-State: AMke39ntNhH313JXvp1+X99376yo34grvKfXWoCSAmYa15h5CPXu69rqG3CMo6YbSckHXPLErBDcfcLuWjt01Q==
X-Received: by 10.55.121.194 with SMTP id u185mr9246145qkc.56.1489002131849;
Wed, 08 Mar 2017 11:42:11 -0800 (PST)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.200.55.113 with HTTP; Wed, 8 Mar 2017 11:42:11 -0800 (PST)
From: Erik Aronesty <erik@q32.com>
Date: Wed, 8 Mar 2017 14:42:11 -0500
X-Google-Sender-Auth: BFfiMu_kT0CQjOrHSUOjcjWdZeY
Message-ID: <CAJowKgL5Vyy-an54gWtpbxZdgMsNdixgyXD92OBnMoWN1bw_fA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c05a19623a2fd054a3d5330
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] High consensus fork system for scaling without limits
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Wed, 08 Mar 2017 19:42:14 -0000
--94eb2c05a19623a2fd054a3d5330
Content-Type: text/plain; charset=UTF-8
I woudl like to propose a BIP that works something like this:
1. Allow users to signal readiness by publishing an EB. This EB is an
absolute upper bound, and cannot be overridden by miners. Current EB is
1MB, the status-quo. Maybe EB can be configured in a config file, not a
UI, since it's an "advanced" feature.
2. Miners can also signal readiness by publishing their own EB in a block.
3. If 95% of blocks within a one month signalling period contain an EB
greater than the previous consensus EB, a fork date is triggered at 6
months using the smallest 5th percentile EB published. (Other times can be
selected, but these are fairly conservative, looking for feedback here).
Miner signalling is ignored during the waiting period.
4. Block heights used for timing
5. After 6 months, any users which already have the new EB or greater begin
actually using it to validate transactions. Users use the EB or the latest
95% consensus triggered value - whichever is less. This means that the
portion of users that originally signaled for the increase do not have to
upgrade their software to participate in the hard fork.
6. Core can (optionally) ship a version with a default EB in-line with
their own perceived consensus.
7. Some sort of versioning system is used to ensure that the two networks
(old and new) are incompatible... blocks hashed in one cannot be used in
the other.
Any users which don't already have the new EB or greater should update
their EB within the 6 month period - or they will be excluded from the
majority fork.
It would be in the best interests of major exchanges and users would to
publicly announce their EB's.
Users are free to safely set very high EB levels, based on their current
hardware and network speeds. These EB levels don't cause those users to
accept invalid blocks ever. They are safe because block size transitions
behave like normal hard forks with high miner consensus (95%).
No code changes will be needed to fork the network as many times as both
users and miners feel the need to do so. (Bitcoin core is off the hook for
"scaling" issues...forever!)
If a smaller block size is needed, a reduced size can also be published and
agreed upon by *both* users and miners using a the same mechanism, but the
largest 5th percentile is used. In other words... the requires broad
consensus to deviate from status quo and fork.
Any new node can simply follow these rules to validate all the blocks in a
chain... even if the sizes changes a lot (at most twice per year).
--94eb2c05a19623a2fd054a3d5330
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I woudl like to propose a BIP that works something li=
ke this:<br><br>1. Allow users to signal readiness by publishing an EB. Thi=
s EB is an absolute upper bound, and cannot be overridden by miners. Curren=
t EB is 1MB, the status-quo.=C2=A0=C2=A0 Maybe EB can be configured in a co=
nfig file, not a UI, since it's an "advanced" feature.<br><br=
>2. Miners can also signal readiness by publishing their own EB in a block.=
<br><br>3. If 95% of blocks within a one month signalling period contain an=
EB greater than the previous consensus EB, a fork date is triggered at 6 m=
onths using the smallest 5th percentile EB published. (Other times can be s=
elected, but these are fairly conservative, looking for feedback here).=C2=
=A0=C2=A0=C2=A0 Miner signalling is ignored during the waiting period.<br><=
br>4. Block heights used for timing<br><br>5. After 6 months, any users whi=
ch already have the new EB or greater begin actually using it to validate t=
ransactions. Users use the EB or the latest 95% consensus triggered value -=
whichever is less.=C2=A0=C2=A0 This means that the portion of users that o=
riginally signaled for the increase do not have to upgrade their software t=
o participate in the hard fork.<br><br></div>6. Core can (optionally) ship =
a version with a default EB in-line with their own perceived consensus.=C2=
=A0=C2=A0 <br><div><br></div><div>7. Some sort of versioning system is used=
to ensure that the two networks (old and new) are incompatible... blocks h=
ashed in one cannot be used in the other.<br><br></div><div>Any users which=
don't already have the new EB or greater should update their EB within=
the 6 month period - or they will be excluded from the majority fork.<br><=
br>It would be in the best interests of major exchanges and users would to =
publicly announce their EB's.<br><br>Users are free to safely set very =
high EB levels, based on their current hardware and network speeds. These E=
B levels don't cause those users to accept invalid blocks ever. They ar=
e safe because block size transitions behave like normal hard forks with hi=
gh miner consensus (95%).<br><br>No code changes will be needed to fork the=
network as many times as both users and miners feel the need to do so.=C2=
=A0 (Bitcoin core is off the hook for "scaling" issues...forever!=
)<br><br>If a smaller block size is needed, a reduced size can also be publ=
ished and agreed upon by *both* users and miners using a the same mechanism=
, but the largest 5th percentile is used.=C2=A0=C2=A0 In other words... the=
requires broad consensus to deviate from status quo and fork.<br><br>Any n=
ew node can simply follow these rules to validate all the blocks in a chain=
... even if the sizes changes a lot (at most twice per year).<br><br><br></=
div></div>
--94eb2c05a19623a2fd054a3d5330--
|
