From: Tom Zander <tomz@freedommail•ch>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes
Date: Fri, 21 Apr 2017 10:27:36 +0200 [thread overview]
Message-ID: <2769926.GQkkf7il9e@strawberry> (raw)
In-Reply-To: <20170420203211.GR10783@boulet.lan>
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.
> >
> > I don’t 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.
>
> I think the expected number of peers is actually ~47.75
Nice to join bitcoin-dev, Andrew. Haven’t seen you post here before.
I’m not sure how you reached that strange number, but I have to point out
your number is quite useless.
The actual amount of nodes you need to be 100% sure you find all the blocks
when you know each node will have a completely random 25% of the blocks is
not a maths problem that leads to a single answer because of the randomness
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
take to be 100% certain I have at least one “Heads”.
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
nodes (actual number depends on the amount of total blocks you are looking
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 least
one block being lost when there are N nodes, a block nobody has. That chance
is small with current > 6000 nodes, but not zero (a second reason why the
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
to predict how many nodes it takes to have 100% coverage, exact numbers are
worse than useless, they are misleading.
As I said in my initial email, statistics is hard. Crypto is much easier in
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
“archival” node, the goal of this pruning node is to provide an improvement
over the current pruning node which stops any and all serving of historical
blocks.
Anyone that feels the need to talk about pruning modes like 100% of the full
nodes will run it are in actual fact not talking about the real world.
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
experiments that only lead to confusion.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
next prev parent reply other threads:[~2017-04-21 8:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-17 6:54 David Vorick
2017-04-17 7:11 ` Danny Thorpe
2017-04-17 7:27 ` David Vorick
2017-04-20 15:50 ` Erik Aronesty
2017-04-20 23:42 ` Aymeric Vitte
2017-04-21 13:35 ` David Kaufman
2017-04-21 15:58 ` Leandro Coutinho
2017-04-17 10:14 ` Aymeric Vitte
2017-04-19 17:30 ` David Vorick
2017-04-20 9:46 ` Tom Zander
2017-04-20 20:32 ` Andrew Poelstra
2017-04-21 8:27 ` Tom Zander [this message]
2017-04-20 11:27 ` Aymeric Vitte
2017-04-18 7:43 ` Jonas Schnelli
2017-04-18 10:50 ` Tom Zander
2017-04-18 13:07 ` Tier Nolan
2017-04-18 23:19 ` Aymeric Vitte
2017-04-19 4:28 ` udevNull
2017-04-19 13:47 ` Angel Leon
2017-04-21 20:38 ` Gregory Maxwell
2017-04-23 16:27 ` Aymeric Vitte
2017-05-03 14:03 ` Erik Aronesty
2017-05-03 19:10 ` Natanael
2017-05-03 22:45 ` Aymeric Vitte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2769926.GQkkf7il9e@strawberry \
--to=tomz@freedommail$(echo .)ch \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox