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
131
132
133
134
135
136
137
138
139
140
141
142
143
144
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1V1ZhN-0000DT-9w
for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 10:20:05 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.51 as permitted sender)
client-ip=209.85.219.51; envelope-from=pieter.wuille@gmail.com;
helo=mail-oa0-f51.google.com;
Received: from mail-oa0-f51.google.com ([209.85.219.51])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V1ZhL-0007pQ-Km
for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 10:20:05 +0000
Received: by mail-oa0-f51.google.com with SMTP id i4so10573472oah.38
for <bitcoin-development@lists.sourceforge.net>;
Tue, 23 Jul 2013 03:19:58 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.42.93.2 with SMTP id v2mr19119716icm.25.1374574798264; Tue,
23 Jul 2013 03:19:58 -0700 (PDT)
Received: by 10.50.20.225 with HTTP; Tue, 23 Jul 2013 03:19:58 -0700 (PDT)
In-Reply-To: <201307231100.24538.andyparkins@gmail.com>
References: <CAJHLa0Ou1xF=LeLVu_wH1-XgJ1PavDV7_NHoDevo3R9+4z-ZfQ@mail.gmail.com>
<201307231030.14139.andyparkins@gmail.com>
<20130723094703.GA25900@savin>
<201307231100.24538.andyparkins@gmail.com>
Date: Tue, 23 Jul 2013 12:19:58 +0200
Message-ID: <CAPg+sBgXviFDBZqS5EhCkb2fLsvP3ySN+b_Q9K3tK5Q=z8Bv_w@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
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
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1V1ZhL-0007pQ-Km
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] HTTP REST API for bitcoind
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: Tue, 23 Jul 2013 10:20:05 -0000
On Tue, Jul 23, 2013 at 12:00 PM, Andy Parkins <andyparkins@gmail.com> wrote:
>> The REST API has nothing to do with SPV clients; it's similar to the RPC
>> interface and won't be exposed to the network as a whole.
>
> Yes; I know that. I'm saying that it would make it easier for SPV (and other
> lightweight clients) for that matter.
In what way?
>> Increasing the resource usage by SPV clients on full nodes is undesirable;
>
> I don't think that's thinking big enough. What I imagine is that making it
> easier and easier to store a partial blockchain would result in lower demand
> on full nodes.
A partial blockchain is quite useless, as you can't build an UTXO set from it.
If you're talking simply about the storage requirements for maintaining history,
perhaps, but why rely on SPV nodes for this? Right now, those don't store any
blocks at all, and there is no reason why they should.
The only requirement is that old blocks remain available for new full
nodes to be
able to bootstrap. It's certainly not required that everyone keeps
every block ever
created. That's how the software currently works, but as soon as we get to a few
protocol changes that would allow new full nodes to find specific
peers with the data
they need, we can have fully-verifying yet (partially) pruning nodes.
I think that's a
much better idea than conflating "maintaining a wallet" with
"maintaining a subset
of historical block data".
> Obviously the miners would still be keeping the entire
> chain, but we'd have a lot more nodes in the network, each contributing a
> little bit and so reducing the load on the full nodes.
I disagree strongly here. The rules of the network are enforced by
full nodes, not by
miners - they are just trying to satisfy the rules demaned by the network.
And as far as I know, there is no way to do some "partial validation"
using just the blocks
you care about (and remember, SPV nodes currently have none at all).
One interesting
possibility here is fraud proofs, where the network can relay proofs
that certain blocks or
transactions are violating certain network rules. In this case, even
SPV nodes can just
communicate with eachother and get some "herd immunity". But storing some blocks
doesn't matter here - it is all about whether you can maintain the
UTXO set or not.
>
>> In any case UTXO data currently requires you to have full trust in
>> whomever is providing you with it, and that situation will continue
>> until UTXO commitments are implemented - if they are implemented.
>
> Almost; because you can go and ask someone else the same question, it's pretty
> easy to check if you're being lied to. Also, it's far easier to maintain a
> headers-only block chain. When you fetch your relevant block subset, you can
> easily see that they are real blocks in your headers-only blockchain; and so
> it's pretty much impossible to lie to "give me the block containing
> transaction X".
That's assuming there is no powerful enough attacker that can benefit from doing
a sybil attack on you. For SPV nodes currently, that risk is limited
to an attacker
that can spend enough on faking a chain with valid proof-of-work, to make you
accept a transaction that will be reversed.
If you go let SPV nodes rely on unauthenticated UTXO set data, there is no such
limitation, and they can let you believe *anything*. There are some safeguards,
like combining it with merkle paths for all outputs that credit you (which again
requires a more expensive index on the other side), but you can't ever guarantee
that a particular outputs isn't spent yet.
--
Pieter
|
