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
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
|
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 D15BCB7E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 9 Mar 2017 15:29:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com
[209.85.215.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 718CD1ED
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 9 Mar 2017 15:29:09 +0000 (UTC)
Received: by mail-lf0-f48.google.com with SMTP id y193so29623229lfd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 09 Mar 2017 07:29:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=issUYXKWwEFgaZH8xiLAT72TqTG0pAYfv57Ry3wDrdY=;
b=L/V6qr9yz7ty3QdieklZWCLC0P9XerdX+ps5fyT5mkrCJk8RoGdd1kiIDyi0Mit931
pyvkjh6KaMQbMfn1vMRtaN1MGMS2f6jHJVBNRiU3PeqfUBYj9eA9SULa1A+gf/qOeZwZ
2m03UvzbFZid09uwXCkXb++pcrF9oa9DtB1tFVy8Anznllo0JTcjCPmHN/7twfGdBOAo
Gz5oAxYMaiRUk7NYHuY3lzB7ek0fhevXwm/+fxlqRWUIBkrMQJ8wjf8Mz0wGxve4cRKj
BEnrXmK7a5sISaBJoKArZfk5i+k4vZ6SQYySGZDzGFL086+62TpWqvWGGkdiAXQwKQGC
JwEg==
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:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=issUYXKWwEFgaZH8xiLAT72TqTG0pAYfv57Ry3wDrdY=;
b=JMxv34GM8//9uOgLfxLoPROr6kUDfgAlEmwdQn73N5icKfj4xopUBrgY4s3zlTXa7g
6Wn/10w8CY7SM4tZ5MrOsF7me7/TAnm3hk+xQrc8EfAAU/Znziyr+mSHCcKenFhZN67P
caTMK85Fep4pi/cCsWrjm8l2HSIZdT/odLqME4RlOdXqi8dTJ4QSbl0KTpgVVCDej+eB
QdoPdftwCkmYmfOSPrGpp5TTM0bqzY1FM+I29heo/BwDnCXzkjrRdY7vYp6isovHP6RX
N/wWRebW8SzJiBPt1v6h3nFolcwfuBUdLKgWFsyrjN73XxArJ9fYREDj11WrpA3CI6Cn
vRUA==
X-Gm-Message-State: AMke39mWwk2yxK25l5b0Xbp4yyZXaN8pGDvqLuJpNyRRi6Awal3WBc37LwcFOt3mfGEG6JY2OFT3LjfYsl9t5g==
X-Received: by 10.25.150.82 with SMTP id y79mr3287779lfd.167.1489073347755;
Thu, 09 Mar 2017 07:29:07 -0800 (PST)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.25.160.203 with HTTP; Thu, 9 Mar 2017 07:29:07 -0800 (PST)
In-Reply-To: <4db320cc-a165-c6bd-798b-ea85ee7fc9de@achow101.com>
References: <CAJowKgL5Vyy-an54gWtpbxZdgMsNdixgyXD92OBnMoWN1bw_fA@mail.gmail.com>
<4db320cc-a165-c6bd-798b-ea85ee7fc9de@achow101.com>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 9 Mar 2017 10:29:07 -0500
X-Google-Sender-Auth: g6E8PLfwTsQ65NhTle4ugzC44bk
Message-ID: <CAJowKgKnTLRAsXnXm9zK6BvMPasjpLLTHjZ5au-d-jJKed5UeQ@mail.gmail.com>
To: Andrew Chow <achow101-lists@achow101.com>
Content-Type: multipart/alternative; boundary=001a11401e26f00b29054a4de748
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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
X-Mailman-Approved-At: Thu, 09 Mar 2017 15:36:01 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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: Thu, 09 Mar 2017 15:29:10 -0000
--001a11401e26f00b29054a4de748
Content-Type: text/plain; charset=UTF-8
> 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.
>
> What does EB stand for?
Excessive block size.
> What is the point of users publishing an EB? Is it for miners to
determine what to set theirs to? If so, what about sybil attacks with fake
nodes publishing EBs?
You can't trivially fake coinbase's full node, or gemini's, etc. Large
users would also be encouraged to report their EB's publically as well.
> How do users publish an EB? Do they use a transaction? Or is it something
that goes into the User Agent?
Same way a version string is published by a node. Maybe *in* the version
string.
> How high can the EB go? What is its maximum?
Maybe 4MB for now? Seems fine. Trivial to change it later, since it's
not a fork to do so.
> 6. Core can (optionally) ship a version with a default EB in-line with
their own perceived consensus.
I would say that Core /should/ ship new versions with new default EB's
in-line with both miner and the economic majority after a 95% consensus
fork.
> 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.
>
> I think this would require a soft fork beforehand in order to implement
such a system.
I thought versionbits could handle this? Can't they? ALP pointed out
that it was important for a fork to be fully incompatible.
> It would be in the best interests of major exchanges and users would to
publicly announce their EB's.
>
> Why?
So miners can have a more reliable signal to go on. No reasonable miner
would start mining signal for a fork unless they were confident that they
are doing so in-line with users and exchanges.
> "Scaling" includes a lot more than just the block size. There is much
more to scaling than just increasing the block size.
Yes, which is why I used air-quotes. The primary idea is to remove a
political issue from affecting core developers. There is a perception
among some people that "if only core would....". Plus, fees are
*inherently* political because it is a barrier for low-net-worth
individuals transacting using this technology. Even if lightning worked
perfectly, how can a small business in Africa afford to set up a full node
and being to participate as a hub if fees are $50? OMG blame core.
Miners and users should be free to wrangle each other over fees any time
they want without the involvement of developers. I suspect the status quo
would be even *more* stable in that scenario... not less.
> What if the EB of a new node is set to be smaller than the current block
size?
Then it is only used for signal unless a fork occurs that results in a
reduction <= EB... in which case the EB becomes a hard upper bound, just
like any other. When an EB is set by a user a block-height needs to be
recorded along with it, so it can be handled correctly. EB set to <
active seems to me to be a special case. Likewise the percentile shoudl
be the upper 5% in the case of EB < active.
This essentially partitions signalling into "< active" and "> active".
--001a11401e26f00b29054a4de748
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>> 1. Allow users to signal readiness by publishing=
an EB. This EB is an absolute upper bound, and cannot be overridden by min=
ers. Current EB is 1MB, the status-quo. =C2=A0 Maybe EB can be configured i=
n a config file, not a UI, since it's an "advanced" feature.<=
br>><br>> What does EB stand for?<br><br></div>Excessive block size.=
=C2=A0=C2=A0 <br><br><div>> What is the point of users publishing an EB?=
Is it for miners to determine what to set theirs to? If so, what about syb=
il attacks with fake nodes publishing EBs?<br><br></div><div>You can't =
trivially fake coinbase's full node, or gemini's, etc.=C2=A0=C2=A0 =
Large users would also be encouraged to report their EB's publically as=
well.<br><br></div><div>> How do users publish an EB? Do they use a tra=
nsaction? Or is it something that goes into the User Agent?<br><br></div><d=
iv>Same way a version string is published by a node.=C2=A0=C2=A0 Maybe *in*=
the version string.<br></div><div><br>> How high can the EB go? What is=
its maximum?<br><br></div><div>Maybe 4MB for now?=C2=A0=C2=A0 Seems fine.=
=C2=A0=C2=A0 Trivial to change it later, since it's not a fork to do so=
.<br><br></div><div>> 6. Core can (optionally) ship a version with a def=
ault EB in-line with their own perceived consensus.=C2=A0 <br><br></div><di=
v>I would say that Core /should/ ship new versions with new default EB'=
s in-line with both miner and the economic majority after a 95% consensus f=
ork.<br><br></div><div>> 7. Some sort of versioning system is used to en=
sure that the two networks (old and new) are incompatible... blocks hashed =
in one cannot be used in the other.<br>><br>> I think this would requ=
ire a soft fork beforehand in order to implement such a system.<br><br></di=
v><div>I thought versionbits could handle this?=C2=A0=C2=A0 Can't they?=
=C2=A0 ALP pointed out that it was important for a fork to be fully incompa=
tible.<br><br></div><div>> It would be in the best interests of major ex=
changes and users would to publicly announce their EB's.<br>><br>>=
; Why?<br><br></div><div>So miners can have a more reliable signal to go on=
.=C2=A0=C2=A0 No reasonable miner would start mining signal for a fork unle=
ss they were confident that they are doing so in-line with users and exchan=
ges.<br><br></div><div>> "Scaling" includes a lot more than ju=
st the block size. There is much more to scaling than just increasing the b=
lock size.<br><br></div><div>Yes, which is why I used air-quotes.=C2=A0=C2=
=A0 The primary idea is to remove a political issue from affecting core dev=
elopers.=C2=A0=C2=A0 There is a perception among some people that "if =
only core would....".=C2=A0=C2=A0 Plus, fees are *inherently* politica=
l because it is a barrier for low-net-worth individuals transacting using t=
his technology.=C2=A0=C2=A0 Even if lightning worked perfectly, how can a s=
mall business in Africa afford to set up a full node and being to participa=
te as a hub if fees are $50?=C2=A0=C2=A0 OMG blame core.=C2=A0 <br><br>Mine=
rs and users should be free to wrangle each other over fees any time they w=
ant without the involvement of developers.=C2=A0=C2=A0 I suspect the status=
quo would be even *more* stable in that scenario... not less.<br><br></div=
><div>> What if the EB of a new node is set to be smaller than the curre=
nt block size?<br><br></div><div>Then it is only used for signal unless a f=
ork occurs that results in a reduction <=3D EB... in which case the EB b=
ecomes a hard upper bound, just like any other.=C2=A0=C2=A0 When an EB is s=
et by a user a block-height needs to be recorded along with it, so it can b=
e handled correctly.=C2=A0=C2=A0 EB set to < active seems to me to be a =
special case.=C2=A0=C2=A0 Likewise the percentile shoudl be the upper 5% in=
the case of EB < active.=C2=A0=C2=A0=C2=A0 <br><br>This essentially par=
titions signalling into "< active" and "> active"=
.=C2=A0=C2=A0 <br><br></div><div><br></div></div>
--001a11401e26f00b29054a4de748--
|
