From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 745F3273 for ; Thu, 20 Aug 2015 14:32:30 +0000 (UTC) X-Greylist: delayed 00:05:04 by SQLgrey-1.7.6 Received: from mout.web.de (mout.web.de [212.227.17.11]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7CD70109 for ; Thu, 20 Aug 2015 14:32:29 +0000 (UTC) Received: from mail-lb0-f182.google.com ([209.85.217.182]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0MgfJz-1Z5Ybu3udT-00O3ia for ; Thu, 20 Aug 2015 16:27:22 +0200 Received: by lbbpu9 with SMTP id pu9so24972176lbb.3 for ; Thu, 20 Aug 2015 07:27:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.141.8 with SMTP id rk8mr3056828lbb.87.1440080840078; Thu, 20 Aug 2015 07:27:20 -0700 (PDT) Received: by 10.114.83.6 with HTTP; Thu, 20 Aug 2015 07:27:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Aug 2015 16:27:20 +0200 Message-ID: From: Timo Hanke To: Luv Khemani Content-Type: multipart/alternative; boundary=001a11c33d5eebbc10051dbef207 X-Provags-ID: V03:K0:DQzmePH0nAO6+thb7evNtanmUylPOjVt8t9HXyZKnq0lxyWeYyl PoOxYHD5s97kXyOJskQTWI+DdXagvnmXRbn7UKXDRRks8h7jaGUik4nAjGQwUyNDZTlzu4p 1mBbjrT/+YF5BUVxR2C95DQLpSjsMBcDHAMAj/2aaW3tW3BuetvsZfj/q99jRR8qgSMW5aI kedmKgg9ovX50RVGeMQ2Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:3PnfyUkaHHE=:3IILK42/lmLpln9tPZF0gs rHkNnSHD6IgiOKY+IogN1L8tP9u81//8A/nnUPqahzK+2waiVKrmCGremP2n0ExOL/uFTWFpL F3lFqRt57UaBqgdXDPk206AKikkkbf+GykLW6lbchLLumU5X0PzsttP4sKGp1Ts4VTACrHG9+ 5/5XUOr46U+he/1rltfp/NV3bCvZjU4Ku3VEywJHzke/sBe0tulVM5vGvyCbRsGUWrFHbiyTw DuSrCOrQedJoZTpy/ghRn6X8R8avl2t/iplQL5gwJOfG92SLBfKKTIgY8Zn6DgfK+ZcZ5WAFo YOIwxMPwRFGENt8R5+5OvvdDBHsjaPTwSeSyXPrdfQTkAB3QR9PDbEIXSHsfGj7UCZW+ayxpI t8FXjiVnkXeU6ostW3P5Q7iQ8SD9uuUIVnj8YBonDr/YFzqiWk2BXcMxqVmMPoJct3oZ/Ktgz V+ro0DD544Hyvy1OxqzgjV82HavGDpwsMlVqfPfVVcFvo/AJzXPoSG+AIPlFhL1PXCbakRHu/ 1kiJuvSl3MgaQRB50us+zKvGvzGxEXlm5Id2uaKD7NaheCngMZu/77ikUXZ92x9KczoHB4w99 zoxT62I6wv5NEvj1nRIQlXhcMouqlp9LQfS7pdRbZiMuecDg8diJJZMKwzIoj/DIQkE0VMmXE G64gnkzA9lEvT7uFa2p8Mzs2odqd2eGVNiPYlkEYw//dwtPJoSeWY80KMB6nz//F+jIJmDuw3 gzsPJYLZ7opRFd3gRFNSmpObfjR3RwKKHGaXdA== X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD 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] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 14:32:30 -0000 --001a11c33d5eebbc10051dbef207 Content-Type: text/plain; charset=UTF-8 That's not a valid conclusion. Just because you observe a miner producing empty blocks doesn't mean he is SPV mining. There can be many reasons for mining on an empty block even after having fully verified the previous block. And therefore these reasons would be completely independent of block size. You cannot conclude that miners are struggling with a certain block size. For example, there are reasons rooted in the mining hardware and mining software itself, which have nothing to do with the node software, in particular not with block propagation, verification or transaction selection. See also https://github.com/BlockheaderNonce2/bitcoin/wiki where this was warned about. The effect can be expected to become more pronounced in the future. Timo On Mon, Aug 17, 2015 at 10: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 > > --001a11c33d5eebbc10051dbef207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's not a valid conclusion. Just because you observ= e a miner producing empty blocks doesn't mean he is SPV mining.

= There can be many reasons for mining on an empty block even after having fu= lly verified the previous block. And therefore these reasons would be compl= etely independent of block size. You cannot conclude that miners are strugg= ling with a certain block size.

For example, there are reasons root= ed in the mining hardware and mining software itself, which have nothing to= do with the node software, in particular not with block propagation, verif= ication or transaction selection. See also https://github.com/BlockheaderNonce2/bitcoin/= wiki=C2=A0where this was warned about. The effect can be expected to be= come more pronounced in the future.

Timo

=

On Mon, Aug= 17, 2015 at 10:42 AM, Luv Khemani via bitcoin-dev <bi= tcoin-dev@lists.linuxfoundation.org> wrote:
Hi all,

=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.

The data= actually paints a very grim picture of the current bandwidth/validating ca= pacity of the global mining network.

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 insight.bitpay.com):

EmptyBlock /Time since previous block/ Size of previous block(bytes= )/Mined by
=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
370165 =C2=A029s =C2=A0720784 =C2=A0Antpoo= l
370160 =C2=A031s =C2=A050129 =C2=A0 =C2=A0BTCChinaPool
3700= 76 =C2=A049s =C2=A0469988 =C2=A0F2Pool
370059 =C2=A034s =C2=A0110= 994 =C2=A0Antpool
370057 =C2=A073s =C2=A0131603 =C2=A0Antpool

We have preceding blocks as small as 50KB with 30s pa= ssing and the miner continues to mine empty blocks via SPV mining.
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>
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

And if these pools go out of business, it w= ill lead to even more mining centralization which is already too centralize= d 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/mail= man/listinfo/bitcoin-dev


--001a11c33d5eebbc10051dbef207--