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
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1V1Zf6-00044n-S3
for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 10:17:45 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.111 as permitted sender)
client-ip=62.13.148.111; envelope-from=pete@petertodd.org;
helo=outmail148111.authsmtp.net;
Received: from outmail148111.authsmtp.net ([62.13.148.111])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1V1Zf5-0007DZ-0U for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 10:17:44 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r6NAHZpN021537; Tue, 23 Jul 2013 11:17:35 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r6NAHSqP007157
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 23 Jul 2013 11:17:31 +0100 (BST)
Date: Tue, 23 Jul 2013 06:17:28 -0400
From: Peter Todd <pete@petertodd.org>
To: Andy Parkins <andyparkins@gmail.com>
Message-ID: <20130723101728.GA2116@savin>
References: <CAJHLa0Ou1xF=LeLVu_wH1-XgJ1PavDV7_NHoDevo3R9+4z-ZfQ@mail.gmail.com>
<201307231030.14139.andyparkins@gmail.com>
<20130723094703.GA25900@savin>
<201307231100.24538.andyparkins@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N"
Content-Disposition: inline
In-Reply-To: <201307231100.24538.andyparkins@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 16044722-f381-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdAEUEkAYAgsB AmUbWlVeUVp7WmE7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqB2Jw fn1fMhlycARDfzBx YkdiWj5aWkR+cUF/
QFMCFmUHeGZhPWIC AkFYJR5UcAFPdx9G aVd6AXFDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4rIgIE DyovJglnNHUkDys0
NVQsK0IXG0cXPi0A
X-Authentic-SMTP: 61633532353630.1019:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1V1Zf5-0007DZ-0U
Cc: 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:17:45 -0000
--fUYQa+Pmc3FrFX/N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jul 23, 2013 at 11:00:24AM +0100, Andy Parkins wrote:
> > Increasing the resource usage by SPV clients on full nodes is undesirab=
le;
>=20
> I don't think that's thinking big enough. What I imagine is that making =
it=20
> easier and easier to store a partial blockchain would result in lower dem=
and=20
> on full nodes.
Read my proposal for "Partial UTXO" mode:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02=
511.html
> I might run a client that has only fetched blocks that contain transactio=
ns=20
> needed to verify my balances, right back to the genesis block. That will=
be=20
> some small subset of the block chain and will take me very little resourc=
e to=20
> maintain. I join the network and am my client is willing to verify based=
on=20
> information I have, or supply (by REST or bitcoin protocol) blocks. Imag=
ine=20
> then that everyone with a wallet were doing this. The blockchain would b=
e=20
> distributed massively. Obviously the miners would still be keeping the e=
ntire=20
> chain, but we'd have a lot more nodes in the network, each contributing a=
=20
> little bit and so reducing the load on the full nodes.
Actually the really scary thing about partial UTXO mode is miners can
get away without keeping the entire chain provided they don't (often)
try to mine transactions spending UTXO's that they haven't verified
themselves.
They can get away with accepting blocks without checking that the UTXO's
exist, at least until enough miners do so that someone creates an
invalid block and the majority of hashing power never notices. Remember
that only with a complete UTXO set can you know that a UTXO *doesn't*
exist.
We're going to have to force miners to prove they possess the full UTXO
set in the future or the security of Bitcoin will be seriously
threatened.
> > 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.
>=20
> Almost; because you can go and ask someone else the same question, it's p=
retty=20
How do you know they actually are someone else?
> easy to check if you're being lied to. Also, it's far easier to maintain=
a=20
> headers-only block chain. When you fetch your relevant block subset, you=
can=20
> easily see that they are real blocks in your headers-only blockchain; and=
so=20
> it's pretty much impossible to lie to "give me the block containing=20
> transaction X".
Do you think you have SPV or full security in that situation?
Do you know the difference?
--=20
'peter'[:-1]@petertodd.org
0000000000000070f3d118303a611e1f44ea6482a3b59a16056e69af088b1ffa
--fUYQa+Pmc3FrFX/N
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR7lg4AAoJECSBQD2l8JH7jxAIALeLIQ14aDF1DXUur9EUSzPi
OKDIGeepsSV65Wqm5pX4u5NAMtkhIcqgFQVyHi7rfi3wfb0OuMYxyvqyZ68/A8hB
7WZB7G5BipBjuUPk/6rmh2JpaO0HBpo0I1Jl6LgqevBV/Hvdjn0HcSfoMNMTltsH
KaeIzWJ2Vf1IAw2XFTiFwkSDnoQ5Qv1Ec/i4hc5g8kQtZiasVpoqqYbS2kNBvrc4
XfDnOa/Ak5rMgruiB0wuY4mvUbbQpbwdwRMq5jWtaT/U9gcmyty+d6bxfHaYoImy
TPwAQMBwipnJDHUx9s9ZiOdSATfVybYEh1mpB7a17LT89jrmTNYf7tPzU55ACwg=
=3hUq
-----END PGP SIGNATURE-----
--fUYQa+Pmc3FrFX/N--
|
