From: Tom Zander <tomz@freedommail.ch>
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: <CAFVRnypbQQ-vsSLqv48cYaqTCty4R1DmFRqfAvxe4mAqyQNXxQ@mail.gmail.com>
	<2652067.QRUcnb74ny@strawberry> <20170420203211.GR10783@boulet.lan>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes
Precedence: list

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