1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
Return-Path: <tomz@freedommail.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6CCFBB7E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Apr 2017 09:46:39 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx-out02.mykolab.com (mx.kolabnow.com [95.128.36.1])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0E66016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Apr 2017 09:46:37 +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-out02.mykolab.com (Postfix) with ESMTPS id A1D40617C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Apr 2017 11:46:34 +0200 (CEST)
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"
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 20 Apr 2017 13:11:35 +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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Apr 2017 09:46:39 -0000
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
|
