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
|
Return-Path: <peter_r@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8005F728
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Nov 2016 23:35:56 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 503B7CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Nov 2016 23:35:55 +0000 (UTC)
Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx001
[212.227.17.184]) with ESMTPSA (Nemesis) id 0LdHeL-1cbd1715N3-00iT7z;
Sun, 27 Nov 2016 00:35:52 +0100
Content-Type: multipart/alternative;
boundary="Apple-Mail=_0B1F3391-D70D-48C7-875B-9532A9BA582E"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Peter R <peter_r@gmx.com>
In-Reply-To: <2318925.r6f9XVyAit@cherry>
Date: Sat, 26 Nov 2016 15:35:49 -0800
Message-Id: <6AAD09CF-937E-4D35-B70A-CFDAB84A6B32@gmx.com>
References: <C10BF9D1-435D-47C9-B98C-9B118B5922A1@gmx.com>
<CAKzdR-rL9ndo9JZodLiSc0BEThiF1kQMs4yvkjJyc_8nzmp8DA@mail.gmail.com>
<CAKzdR-oE44Qcb1sfz3RmcVmtR9qzB+9J5ufTgGmdQ_Xctenh7A@mail.gmail.com>
<2318925.r6f9XVyAit@cherry>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.2104)
X-Provags-ID: V03:K0:KghG9RfxUKtXnES3lXFY/jdH6KL8R4Cz8ubFgvHJusgMFUugCDk
Ne8tSQ74GUg2wkMgG85xB9uj+U9epcO8bt2CWZc82JTWFnImXjAFNig3uouSKaPg/2XNQN9
Z0hWCx1EHaerg7ebJtNECdXsMKAOafktCNxqKclyrJR1BVwnKu39XxNRB3MBtBWx8/cs6FF
xAflXrctaEWrGhUc6z5Pw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:76uCOtAuZq4=:FHeX1tO4YCstqFe8+PrSxM
lloupK30c7rB/lQhpnEN6oLIhhYfwMhBDgKTiJOZxVVz8rYgVLGp6Fri7O4mqd833ysXyZdep
aq8sp9jTHaL+S0X5pTLMRV39rMB4uNwLeVOiAfI0alYph6oX4URN8tQiK7Jb4DGpPBynHYcrC
MD1o6S3NNuE4INiLusTS7vT4mf17ET6eQ79YXxVfd1K/ZxGli/b91hKgW67k1c0pBBk75W35i
/w/2WoRhhL97JLp2BIhRXV5qhlvhpE516+9zJ92WMy0sOcq38AjHujd+kL2wj3tOxlDl68cjN
bSrUcA99Hafn0as64CWVI37pBNHP8zW3pGo2zd55lput4Iln9Q/dJ7pufdNvDCvjfDG0UDX+y
hXyvpBWYRecbB0OQD0jXeob/5Za/tAeDGJLy2uCBqA+ilBYOsnH48RTOj+lxGpJ0bOnupMykw
3P2NVh+DTsQmNTbet/zW908cGE2sxEqQQ4q0Rxa/ASzoJQ1zRzQOv4tUvQ0cCzVECBJ3Nbxwv
KAaElkhsLTVCzYo8FhZuYJzPAzWLg4XJn4JFNY4H1fccjHh47F8qMXmPo9na1FbEwAQd6hPOU
wRgg+aSPv90XOH3vXWV2Fu0SCkNF6lCFfeazoG6HchZs4T2Np1g5YkCr1xNQ246sXiPi5rHX3
P9CpOUJCKC2wjpaZipfCFW/uFHxkpRsue4lS17YXfP0tboy/eY3DKR1UjExNZdYttZlY/aCOh
3n+3je5fzJegrWyZZzqRPh0AbwL4V9vk43WYbs/qmXau28oIU8VQTX4dOnzO1kUJ51ZOeg7rd
fGLwJtumgOX5lhrjYBjE4EYK9+qvl3dd22vzM29JWMprf/jIoc5pMawHKw3249SI7EkpV+YBL
Gk9g96M5j2Q8kg14lSyQ==
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
HTML_MESSAGE, MIME_QP_LONG_LINE,
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: Sun, 27 Nov 2016 00:40:39 +0000
Subject: Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited
Node Deals With Large Blocks
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: Sat, 26 Nov 2016 23:35:56 -0000
--Apple-Mail=_0B1F3391-D70D-48C7-875B-9532A9BA582E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Great discussion, Sergio and Tom!
> I now think my reasoning and conclusions are based on a false premise: =
that BU block size policies for miners can be heterogeneous.
Right, miners who set their block size limits (BSL) above OR below the =
"effective BSL" are disadvantaged. Imagine that we plot the =
distribution (by hash power) for all miners' BSLs. We might get a chart =
that looks like this:
http://imgur.com/a/tWNr6 <http://imgur.com/a/tWNr6>
In this chart, the "effective BSL" is defined as the largest block size =
that no less than half the hash power will accept. =20
If a block is mined with a size Q that is less than the "effective BSL," =
then all the hash power with BSLs between BSL_min and Q will be forked =
from the longest chain (until they update their software if they're =
running Core or until their acceptance depth is hit if they're running =
BU). This wastes these miners' hash power. =20
However, if a block is mined with a size Q that is greater than the =
effective BSL, then all the hash power with BSLs between Q and BSL_max =
will temporarily be mining on a "destined to be orphaned" chain. This =
also wastes these miners' hash power. =20
Therefore, it is in the best interest of miners to all set the same =
block size limit (and reliably signal in their coinbase TX what that =
limit is, as done by Bitcoin Unlimited miners). =20
We have empirical evidence the miners in fact behave this way:=20
(1) No major miner has ever set his block size limit to less than 1 MB =
(not even those such as Luke-Jr who think 1 MB is too big) because doing =
so would just waste money. =20
(2) After switching to Bitcoin Unlimited, both ViaBTC and the =
Bitcoin.com pool temporarily set their BSLs to 2 MB and 16 MB, =
respectively (of course keeping their _generation limit_ at 1MB). =
However, both miners quickly reduced these limits back to 1 MB when they =
realized how it was possible to lose money in an attack scenario. (This =
actually surprised me because the only way they could lose money is if =
some _other_ miner wasted even more money by purposely mining a =
destined-to-be-orphaned block.) =20
The follow-up article I'm working on is about the topics we're =
discussing now, particularly about how Bitcoin Unlimited's =
=E2=80=9Cnode-scale=E2=80=9D behavior facilitates the emergence of a =
fluid and organic block size limit at the network scale. Happy to keep =
continue with this current discussion, however.
Best regards
Peter
--Apple-Mail=_0B1F3391-D70D-48C7-875B-9532A9BA582E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">Great discussion, Sergio and Tom!</div><div =
class=3D""><br class=3D""></div><div class=3D""><blockquote type=3D"cite" =
class=3D"">I now think my reasoning and conclusions are based on a false =
premise: that BU block size policies for miners can be =
heterogeneous.</blockquote></div><div class=3D""><br class=3D""></div><div=
class=3D"">Right, miners who set their block size limits (BSL) above OR =
below the "effective BSL" are disadvantaged. Imagine that we plot =
the distribution (by hash power) for all miners' BSLs. We might =
get a chart that looks like this:</div><div class=3D""><br =
class=3D""></div><div class=3D""><a href=3D"http://imgur.com/a/tWNr6" =
class=3D"">http://imgur.com/a/tWNr6</a></div><div class=3D""><br =
class=3D""></div><div class=3D"">In this chart, the "effective BSL" is =
defined as the largest block size that no less than half the hash power =
will accept. </div><div class=3D""><br class=3D""></div><div =
class=3D"">If a block is mined with a size Q that is less than the =
"effective BSL," then all the hash power with BSLs between BSL_min and Q =
will be forked from the longest chain (until they update their software =
if they're running Core or until their acceptance depth is hit if =
they're running BU). This wastes these miners' hash power. =
</div><div class=3D""><br class=3D""></div><div class=3D"">However, =
if a block is mined with a size Q that is greater than the effective =
BSL, then all the hash power with BSLs between Q and BSL_max will =
temporarily be mining on a "destined to be orphaned" chain. This =
also wastes these miners' hash power. </div><div class=3D""><br =
class=3D""></div><div class=3D"">Therefore, it is in the best interest =
of miners to all set the same block size limit (and reliably signal in =
their coinbase TX what that limit is, as done by Bitcoin Unlimited =
miners). </div><div class=3D""><br class=3D""></div><div =
class=3D"">We have empirical evidence the miners in fact behave this =
way: </div><div class=3D""><br class=3D""></div><div class=3D"">(1) =
No major miner has ever set his block size limit to less than 1 MB (not =
even those such as Luke-Jr who think 1 MB is too big) because doing so =
would just waste money. </div><div class=3D""><br =
class=3D""></div><div class=3D"">(2) After switching to Bitcoin =
Unlimited, both ViaBTC and the <a href=3D"http://Bitcoin.com" =
class=3D"">Bitcoin.com</a> pool temporarily set their BSLs to 2 MB and =
16 MB, respectively (of course keeping their _generation limit_ at 1MB). =
However, both miners quickly reduced these limits back to 1 MB =
when they realized how it was possible to lose money in an attack =
scenario. (This actually surprised me because the only way they =
could lose money is if some _other_ miner wasted even more money by =
purposely mining a destined-to-be-orphaned block.) =
</div><div class=3D""><br class=3D""></div><div class=3D"">The=
follow-up article I'm working on is about the topics we're discussing =
now, particularly about how Bitcoin Unlimited's =E2=80=9Cnode-scale=E2=80=9D=
behavior facilitates the emergence of a fluid and organic block size =
limit at the network scale. Happy to keep continue with this =
current discussion, however.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Best regards</div><div =
class=3D"">Peter</div><div class=3D""><br class=3D""></div></body></html>=
--Apple-Mail=_0B1F3391-D70D-48C7-875B-9532A9BA582E--
|
