From: Tom Zander <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Thu, 20 Apr 2017 11:46:33 +0200
Message-ID: <2652067.QRUcnb74ny@strawberry>
In-Reply-To: <CAFVRnyrQ3CMPW0=dtR-xnW1bF8cD9o5yvD67w25=w9wxVyJT9w@mail.gmail.com>
References: <CAFVRnypbQQ-vsSLqv48cYaqTCty4R1DmFRqfAvxe4mAqyQNXxQ@mail.gmail.com>
	<19dbfef2-3791-8fe7-1c00-c4052c3d6c45@gmail.com>
	<CAFVRnyrQ3CMPW0=dtR-xnW1bF8cD9o5yvD67w25=w9wxVyJT9w@mail.gmail.com>
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 Wednesday, 19 April 2017 19:30:30 CEST David Vorick via bitcoin-dev=20
wrote:
> > I suggested something similar which is a much simpler version;
> > https://zander.github.io/scaling/Pruning/

> Your proposal has a significant disadvantage: If every peer is dropping
> 75% of all blocks randomly, then you need to connect to a large number of
> peers to download the whole blockchain.
=2E..
> If you are downloading 450,000 blocks, you will need to
> connect to an expected 46 peers to download the whole blockchain.

I don=E2=80=99t really see the problem here, even if your math is a off. (S=
tatistics=20
is difficult, I know). Connecting to many nodes to download faster is reall=
y=20
not an issue and already happens.

> Your proposal is also a lot less able to handle active adversaries: if
> nodes are randomly dropping blocks, the probability that one block in
> particular is dropped by everyone goes up significantly.=20

You make the assumption that this new mode of pruning will be used by 100%=
=20
of the network, this is not how distributed systems work.

=2D-=20
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel