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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1QerJ0-000402-Fn
for bitcoin-development@lists.sourceforge.net;
Thu, 07 Jul 2011 16:19:58 +0000
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;
Received: from mail-ww0-f53.google.com ([74.125.82.53])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QerIx-0004r2-FG
for bitcoin-development@lists.sourceforge.net;
Thu, 07 Jul 2011 16:19:56 +0000
Received: by wwf26 with SMTP id 26so1013174wwf.10
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 Jul 2011 09:19:49 -0700 (PDT)
Received: by 10.216.54.197 with SMTP id i47mr6713177wec.48.1310055589292;
Thu, 07 Jul 2011 09:19:49 -0700 (PDT)
Received: from dvr.localnet (mail.360visiontechnology.com [92.42.121.178])
by mx.google.com with ESMTPS id c17sm7006305wbh.12.2011.07.07.09.19.46
(version=TLSv1/SSLv3 cipher=OTHER);
Thu, 07 Jul 2011 09:19:47 -0700 (PDT)
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>
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
(andyparkins[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
0.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service
X-Headers-End: 1QerIx-0004r2-FG
Subject: Re: [Bitcoin-development] Suggestion for enhancements to getblock
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: Thu, 07 Jul 2011 16:19:58 -0000
--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--
|
