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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
