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
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <john.dillon892@googlemail.com>) id 1VBFbA-0001ZV-FB
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Aug 2013 02:53:40 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of googlemail.com
designates 209.85.215.170 as permitted sender)
client-ip=209.85.215.170;
envelope-from=john.dillon892@googlemail.com;
helo=mail-ea0-f170.google.com;
Received: from mail-ea0-f170.google.com ([209.85.215.170])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VBFb9-0002n5-CI
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Aug 2013 02:53:40 +0000
Received: by mail-ea0-f170.google.com with SMTP id h14so2045297eak.1
for <bitcoin-development@lists.sourceforge.net>;
Sun, 18 Aug 2013 19:53:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.14.89.72 with SMTP id b48mr8984320eef.43.1376880813011; Sun,
18 Aug 2013 19:53:33 -0700 (PDT)
Received: by 10.223.41.4 with HTTP; Sun, 18 Aug 2013 19:53:32 -0700 (PDT)
In-Reply-To: <CABsx9T3MFqmLchc1Uu20BhiVKsYWFtt0eneVSey846y2hdQ7Rg@mail.gmail.com>
References: <20130819001357.GA4281@savin>
<CABsx9T3MFqmLchc1Uu20BhiVKsYWFtt0eneVSey846y2hdQ7Rg@mail.gmail.com>
Date: Mon, 19 Aug 2013 02:53:32 +0000
Message-ID: <CAPaL=UWH=3qj7AW-azrO9rJqRj3BKBff8-eETfF03po9kPJO4g@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.4 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(john.dillon892[at]googlemail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (john.dillon892[at]googlemail.com)
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1VBFb9-0002n5-CI
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bloom io attack effectiveness
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 19 Aug 2013 02:53:40 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Mon, Aug 19, 2013 at 12:59 AM, Gavin Andresen
<gavinandresen@gmail.com> wrote:
> Peter said:
> "In any case given that SPV peers don't contribute back to the network
> they should obviously be heavily deprioritized and served only with
> whatever resources a node has spare."
>
> This seems very much like a "cut off your nose to spite your face" solution.
>
> SPV peers are INCREDIBLY IMPORTANT to the growth of Bitcoin; much more
> important than nodes that have the bandwidth and disk I/O capability of
> being a full node. Bitcoin will be just fine if there are never more than
> 10,000 big, beefy, full nodes forming the backbone of the network, but will
> be NOTHING if we don't support tens of millions of lightweight SPV devices.
>
> Ok, that's an exaggeration, Bitcoin would be just fine in an Electrum model
> where tens of millions of lightweight devices rely 100% on a full node to
> operate. But I would prefer the more decentralized, less-trust-required SPV
> model.
So tell us how is your "vision" of 10,000 big beefy full nodes with SPV peers
any different from the Electrum model? These days Electrum clients have block
headers and verify that transactions have merkle paths to the block headers.
The only difference I see is that SPV uses bloom filtering and Electrum can
query by transaction. But Mike wants to add querying by transaction to full
nodes anyway, and one of the purported advantages of this UTXO proof stuff is
that you can query servers for UTXO's by address, so I see no difference at
all. A patch to do bloom filtering on Electrum would be amusing to me.
Here you have Peter talking about clever ways to actually get decentralization
by having SPV peers donate back to the network with spare bandwidth, like
relaying blocks, not to mention his partial UTXO set ideas, and you completely
ignore that. But I guess that would raise ugly questions when people realize
they can't now contribute back to Bitcoin, because the blocksize is a gigabyte
of microtransactions... It may also raise ugly questions with regulators that
may find the idea of "full node == data chokepoint == regulatory chokepoint" an
attractive notion. Why are there not any competent people other than Peter who
really have the guts to bring up these proposals? I've little luck getting
proof-of-concepts built for money anyway. Maybe we just have a darth of smart
competent people in this space.
You do a good job of signaling your priorities Gavin. The payment protocol
includes no notion that you may want to pay anyone but a SSL certified
merchant. Yes I know the crypto can be upgraded, but it says volumes that you
pushed for that first, without even the slightest token effort to allow
individuals to participate in any way. Sad given you have made things *less*
secure because there is no safe way to get money *into* my wallet with the
payment protocol, but could have been.
Tell me, when my decentralization pull-req is voted on, which way are you
planning on voting?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSEYg/AAoJEEWCsU4mNhiPQBIH/A2cef0NDzu72CY0+N1HdPO+
fdixwncAg1ok6YdJj5WALjHbkhJ+QRVEZoRr6rHPxxxTywI+HiPN1oaopIrq3StP
bNpvouaWXLyw6xHMrMYefVOluHNZg3lu1akLdGuYA7rDHLwP/RhlF1FFzXSxKFsp
ANcw4WW7U5r5nfBHYc/a9xo8S6THI7Nv2NDW6WaRQO4X9sbSKSdwanoe75CLsRzE
E2cPNvwG4WA/MUgkl3Ao6dMsEPPa8dJK98LaS4BE/m9iFWQiV8t35/FQ0GAFQoJo
PQUs8aAWiI0caAxI0vddxKQ+YlwPw2m1QH6h19wUO7+KLKOtxMFmWoDu/OLdTRM=
=IfkA
-----END PGP SIGNATURE-----
|
