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 47C445A9 for ; Fri, 21 Apr 2017 08:27:42 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out03.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5A73A206 for ; Fri, 21 Apr 2017 08:27:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101]) by mx-out03.mykolab.com (Postfix) with ESMTPS id 1D44822100 for ; Fri, 21 Apr 2017 10:27:38 +0200 (CEST) From: Tom Zander To: bitcoin-dev@lists.linuxfoundation.org Date: Fri, 21 Apr 2017 10:27:36 +0200 Message-ID: <2769926.GQkkf7il9e@strawberry> In-Reply-To: <20170420203211.GR10783@boulet.lan> References: <2652067.QRUcnb74ny@strawberry> <20170420203211.GR10783@boulet.lan> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 21 Apr 2017 09:28:40 +0000 Subject: Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 08:27:42 -0000 On Thursday, 20 April 2017 22:32:12 CEST Andrew Poelstra wrote: > > > If you are downloading 450,000 blocks, you will need to > > > connect to an expected 46 peers to download the whole blockchain. > >=20 > > I don=E2=80=99t really see the problem here, even if your math is a off. > > (Statistics is difficult, I know). Connecting to many nodes to download > > faster is really not an issue and already happens. >=20 > I think the expected number of peers is actually ~47.75 Nice to join bitcoin-dev, Andrew. Haven=E2=80=99t seen you post here before. I=E2=80=99m not sure how you reached that strange number, but I have to poi= nt out=20 your number is quite useless. The actual amount of nodes you need to be 100% sure you find all the blocks= =20 when you know each node will have a completely random 25% of the blocks is= =20 not a maths problem that leads to a single answer because of the randomness= =20 involved. The actual answer is a series of probabilities. Same as the answer is to the age old question; how many coin flips does it= =20 take to be 100% certain I have at least one =E2=80=9CHeads=E2=80=9D. In our blocks retrieval scenario; with num-nodes < 4, probability is zero. There is a really really small chance you will get 100% of the blocks with = 4=20 nodes (actual number depends on the amount of total blocks you are looking= =20 for). And this goes up as you add more nodes, but never reaches 100% At the other end of this question you can ask what the chance is of at leas= t=20 one block being lost when there are N nodes, a block nobody has. That chanc= e=20 is small with current > 6000 nodes, but not zero (a second reason why the=20 previous parag never reaches 100%). Bottom line, it is silly to assume 100% of the nodes would be partial- pruning, and if you continue on that path you will only have probabilities= =20 to predict how many nodes it takes to have 100% coverage, exact numbers are= =20 worse than useless, they are misleading. As I said in my initial email, statistics is hard. Crypto is much easier in= =20 that it is absolute. Either correct or false. Never in between. To repeat, the goal of this pruning method is not to replace a full=20 =E2=80=9Carchival=E2=80=9D node, the goal of this pruning node is to provid= e an improvement=20 over the current pruning node which stops any and all serving of historical= =20 blocks. Anyone that feels the need to talk about pruning modes like 100% of the ful= l=20 nodes will run it are in actual fact not talking about the real world.=20 Distributed systems will never (and should never) end up being a mono- culture. Diversity is the essential thing you aim for. I would suggest we focus on the real world and not on irreleavant math=20 experiments that only lead to confusion. =2D-=20 Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel