Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.53 as permitted sender)
	client-ip=74.125.82.53; envelope-from=andyparkins@gmail.com;
	helo=mail-ww0-f53.google.com; 
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Thu, 7 Jul 2011 17:19:39 +0100
User-Agent: KMail/1.13.6 (Linux/2.6.38-2-686; KDE/4.6.3; i686; ; )
References: <201107071049.48131.andyparkins@gmail.com>
	<CANEZrP0L-8PmwLma4DJdfoj+NefXS0kH8wvVFe-vuyRnpF-+mw@mail.gmail.com>
In-Reply-To: <CANEZrP0L-8PmwLma4DJdfoj+NefXS0kH8wvVFe-vuyRnpF-+mw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3210105.bXfVgRihYC";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201107071719.45416.andyparkins@gmail.com>
Subject: Re: [Bitcoin-development] Suggestion for enhancements to getblock
Precedence: list

--nextPart3210105.bXfVgRihYC
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On 2011 July 07 Thursday, Mike Hearn wrote:
> On Thu, Jul 7, 2011 at 11:49 AM, Andy Parkins <andyparkins@gmail.com> wro=
te:
> > Imagine this situation though.  I am a light weight client.  I store the
> > block headers only.  I am only interested in the history of my own
> > wallet addresses. I receive a block broadcast with a transaction that
> > sends coins to one of my addresses.  That transaction references other
> > transactions (of course), but I haven't stored any transactions.  So; I
> > want to request those transactions and ensure they are all valid and in
> > blocks.  I can't.
>=20
> Everyone writing an alternative client goes through this thought
> process :-) There's no point in doing it, you cannot prove your
> transaction is not a double spend. That requires knowledge (ie, an
> index) of all transactions.

Ah; you mistake me.  I'm not interested in double spend prevention, in this=
=20
case I'd be willing to trust the full node to return whatever block it thin=
ks=20
contains that transaction, and that it has already done double spend=20
prevention.

What I want to be able to do though is calculate a balance for an aribtrary=
=20
address.  Not every address; just the particular ones that the client is=20
interested in.  It's complete overkill to require the whole block chain jus=
t=20
to calculate the balance of a few addresses.

> You have to treat appearing deep in the chain as ipso-facto proof of
> validity. Lightweight/SPV clients simply must have that trust, it
> cannot be done any other way. See this article:

Not entirely.  If I ask for "the block that contains transaction with hash=
=20
12345678abcd..." then when I get that full block, I can verify the merkle t=
ree=20
myself.  I do have to trust that the peer hasn't been adding double spends =
in,=20
but not that the transaction is actually in the chain.

> > It should be possible to request the current pending transaction list.
>=20
> I think it'd be better to implement the filtering suggestions that
> have been made. It doesn't scale to download the entire memory pool -

I'm sorry, I've only started watching this list in the last few days.  I'm =
not=20
familiar with the filter suggestions.

I'm not entirely sure I see how a filter helps.  If I've been offline for t=
en=20
minutes then I need all the transactions pending in the last ten minutes.  =
No=20
amount of filtering makes that list any smaller.

> a better approach is to give the remote node a filter to match against
> transactions then have it only relay those. After setting a filter,
> transactions pending and matching would be sent in one big inv and you
> can then keep the connection open to learn about new transactions
> without needing to "drink from the firehose". Filters can be
> probabilistic and set on many different nodes to reduce the privacy
> implications.

That would be fine.  My reason for suggesting using getblocks was that it=20
didn't introduce a new command.


Andy

=2D-=20
Dr Andy Parkins
andyparkins@gmail.com

--nextPart3210105.bXfVgRihYC
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAk4V3JsACgkQwQJ9gE9xL22VkACgx/J/sUIn5Vuuoehh3VLzMewR
SKgAn3qgesWy6GzvBvrqlWTJ6k4syNoz
=j5wG
-----END PGP SIGNATURE-----

--nextPart3210105.bXfVgRihYC--