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; 
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)
Cc: bitcoin-development@lists.sourceforge.net,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] HTTP REST API for bitcoind
Precedence: list


--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--