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
|
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DC4319EB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 14:35:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com
[209.85.212.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D10DD20D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 14:35:37 +0000 (UTC)
Received: by wicja10 with SMTP id ja10so121942314wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 07:35:36 -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=PHb9ZAZRciMkqsF/OWYjoSZ1GaX/mdRdbV1pPzQVgO4=;
b=rWSy3CvGgntqgWEz3k6rXD5SSgelS/a14mTXWIF679s8PPmiFVS7pklUC0LpxK6ilX
UZtp1RxRoL4STg1ndrzroW+lazIHADz6OPIzdtswaHnyelQ8Ud3k1cUsIQFU4OYOlz5K
s1FRou3pBVffl9ETKncGsepPZHgYdyfz1PJ3TUdhuA41IFLmhe5upX0z40Pfy5oyYBkD
0LeRJQF2Ez0r2zkaWQuA1QSO4Q9Xqj7rEZRX9YRkKcOtOwPFXFYQjgV3LQe98JlsdFlK
af6utxEgwducfJaPY/IKe35yeXMspG8hUWepJi4hVZnuWI1vpD2CQJeRp32i2LAg3x27
Gh7Q==
MIME-Version: 1.0
X-Received: by 10.194.176.201 with SMTP id ck9mr24078872wjc.108.1439994936443;
Wed, 19 Aug 2015 07:35:36 -0700 (PDT)
Received: by 10.28.52.84 with HTTP; Wed, 19 Aug 2015 07:35:36 -0700 (PDT)
In-Reply-To: <BLU172-W10F7A109C917CD56E7DF4DC2790@phx.gbl>
References: <BLU172-W10F7A109C917CD56E7DF4DC2790@phx.gbl>
Date: Wed, 19 Aug 2015 10:35:36 -0400
Message-ID: <CADm_WcYewnp-Xa_r7KDm22Vcv49nj-zxSCENEqQSvuS6c7euMQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Luv Khemani <luvb@hotmail.com>
Content-Type: multipart/alternative; boundary=089e013d1eb4aa493e051daaf2a5
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,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"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Miners are struggling with blocks far smaller
than 750KB blocks and resorting to SPV mining
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: Wed, 19 Aug 2015 14:35:39 -0000
--089e013d1eb4aa493e051daaf2a5
Content-Type: text/plain; charset=UTF-8
As jl2012 indicated, this is an insufficient analysis.
You cannot assume that because X time passed since the last block, the
miner's internal block maker has updated the template, and from there, is
shipped out to the hashers in the field. Further, even if you update the
block template at time Y, a hasher might return with a solution for the
block at time X, and the miner will of course publish solution X.
There are several steps of latency involved, even ignoring things such as
the miner relay network or getting US pool stratum links to a sub-pool in
China.
On Mon, Aug 17, 2015 at 4:42 AM, Luv Khemani via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi all,
>
> I previously mentioned in a post that i believe that technically nodes
> are capable of handling blocks an order of magnitude larger than the
> current blocksize limit, the only missing thing was an incentive to run
> them. I have been monitoring the blockchain for the past couple of weeks
> and am seeing that even miners who have all the incentives are for whatever
> reason struggling to download and validate much smaller blocks.
>
> The data actually paints a very grim picture of the current
> bandwidth/validating capacity of the global mining network.
>
> See the following empty blocks mined despite a non-trivial elapsed time
> from the previous block just from the past couple of days alone (Data from
> insight.bitpay.com):
>
> EmptyBlock /Time since previous block/ Size of previous block(bytes)/Mined
> by
> ====================================================
> 370165 29s 720784 Antpool
> 370160 31s 50129 BTCChinaPool
> 370076 49s 469988 F2Pool
> 370059 34s 110994 Antpool
> 370057 73s 131603 Antpool
>
> We have preceding blocks as small as 50KB with 30s passing and the miner
> continues to mine empty blocks via SPV mining.
> The most glaring case is Block 370057 where despite 73s elapsing and the
> preceding block being a mere 131KB, the miner is unable to
> download/validate fast enough to include transactions in his block. Unless
> ofcourse the miner is mining empty blocks on purpose, which does not make
> sense as all of these pools do mine blocks with transactions when the
> elapsed time is greater.
>
> This is a cause for great concern, because if miners are SPV mining for a
> whole minute for <750KB blocks, at 8MB blocks, the network will just fall
> apart as a significant portion of the hashing power SPV mines throughout.
> All a single malicious miner has to do is mine an invalid block on purpose,
> let these pools SPV mine on top of them while it mines a valid block free
> of their competition. Yes, these pools deserve to lose money in that event,
> but the impact of reorgs and many block orphans for anyone not running a
> full node could be disastrous, especially more so in the XT world where
> Mike wants everyone to be running SPV nodes. I simply don't see the XT fork
> having any chance of surviving if SPV nodes are unreliable.
>
> And if these pools go out of business, it will lead to even more mining
> centralization which is already too centralized today.
>
> Can anyone representing these pools comment on why this is happening? Are
> these pools on Matt's relay network?
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--089e013d1eb4aa493e051daaf2a5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">As jl2012 indicated, this is an insufficient analysis.<div=
><br></div><div>You cannot assume that because X time passed since the last=
block, the miner's internal block maker has updated the template, and =
from there, is shipped out to the hashers in the field.=C2=A0 Further, even=
if you update the block template at time Y, a hasher might return with a s=
olution for the block at time X, and the miner will of course publish solut=
ion X.</div><div><br></div><div>There are several steps of latency involved=
, even ignoring things such as the miner relay network or getting US pool s=
tratum links to a sub-pool in China.</div><div><br></div><div><br></div><di=
v><br></div><div><br></div><div><br></div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Mon, Aug 17, 2015 at 4:42 AM, Luv Khemani=
via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or=
g</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir=3D"ltr"><div>Hi all,</div><div><br></div><div>=C2=A0 I previo=
usly mentioned in a post that i believe that technically nodes are capable =
of handling blocks an order of magnitude larger than the current blocksize =
limit, the only missing thing was an incentive to run them. I have been mon=
itoring the blockchain for the past couple of weeks and am seeing that even=
miners who have all the incentives are for whatever reason struggling to d=
ownload and validate much smaller blocks.</div><div><br></div><div>The data=
actually paints a very grim picture of the current bandwidth/validating ca=
pacity of the global mining network.</div><div><br></div><div>See the follo=
wing empty blocks mined despite a non-trivial elapsed time from the previou=
s block just from the past couple of days alone (Data from <a href=3D"http:=
//insight.bitpay.com" target=3D"_blank">insight.bitpay.com</a>):<br><br></d=
iv><div>EmptyBlock /Time since previous block/ Size of previous block(bytes=
)/Mined by</div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D</div>370165 =C2=A029s =C2=A0720784 =C2=A0Antpoo=
l<div>370160 =C2=A031s =C2=A050129 =C2=A0 =C2=A0BTCChinaPool</div><div>3700=
76 =C2=A049s =C2=A0469988 =C2=A0F2Pool</div><div>370059 =C2=A034s =C2=A0110=
994 =C2=A0Antpool</div><div>370057 =C2=A073s =C2=A0131603 =C2=A0Antpool</di=
v><div><br></div><div>We have preceding blocks as small as 50KB with 30s pa=
ssing and the miner continues to mine empty blocks via SPV mining.<br>The m=
ost glaring case is Block 370057 where despite 73s elapsing and the precedi=
ng block being a mere 131KB, the miner is unable to download/validate fast =
enough to include transactions in his block. Unless ofcourse the miner is m=
ining empty blocks on purpose, which does not make sense as all of these po=
ols do mine blocks with transactions when the elapsed time is greater.<br><=
br></div><div>This is a cause for great concern, because if miners are SPV =
mining for a whole minute for <750KB blocks, at 8MB blocks, the network =
will just fall apart as a significant portion of the hashing power SPV mine=
s throughout. All a single malicious miner has to do is mine an invalid blo=
ck on purpose, let these pools SPV mine on top of them while it mines a val=
id block free of their competition. Yes, these pools deserve to lose money =
in that event, but the impact of reorgs and many block orphans for anyone n=
ot running a full node could be disastrous, especially more so in the XT wo=
rld where Mike wants everyone to be running SPV nodes. I simply don't s=
ee the XT fork having any chance of surviving if SPV nodes are unreliable.=
=C2=A0</div><div><br></div><div>And if these pools go out of business, it w=
ill lead to even more mining centralization which is already too centralize=
d today.<br><br>Can anyone representing these pools comment on why this is =
happening? Are these pools on Matt's relay network?</div><div><br></div=
><div><br></div><div><br></div><div><br></div> </div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--089e013d1eb4aa493e051daaf2a5--
|
