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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1QeqiY-0000CZ-IU
for bitcoin-development@lists.sourceforge.net;
Thu, 07 Jul 2011 15:42:18 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.175 as permitted sender)
client-ip=209.85.220.175; envelope-from=mh.in.england@gmail.com;
helo=mail-vx0-f175.google.com;
Received: from mail-vx0-f175.google.com ([209.85.220.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QeqiX-0003Sa-L9
for bitcoin-development@lists.sourceforge.net;
Thu, 07 Jul 2011 15:42:18 +0000
Received: by vxa37 with SMTP id 37so1140311vxa.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 Jul 2011 08:42:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.173.84 with SMTP id bi20mr1278591vdc.69.1310053332157; Thu,
07 Jul 2011 08:42:12 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.52.164.225 with HTTP; Thu, 7 Jul 2011 08:42:12 -0700 (PDT)
In-Reply-To: <201107071049.48131.andyparkins@gmail.com>
References: <201107071049.48131.andyparkins@gmail.com>
Date: Thu, 7 Jul 2011 17:42:12 +0200
X-Google-Sender-Auth: ujSDH-k1fuxuyAw3_6VCPm2eA78
Message-ID: <CANEZrP0L-8PmwLma4DJdfoj+NefXS0kH8wvVFe-vuyRnpF-+mw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1QeqiX-0003Sa-L9
Cc: bitcoin-development@lists.sourceforge.net
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 15:42:18 -0000
On Thu, Jul 7, 2011 at 11:49 AM, Andy Parkins <andyparkins@gmail.com> wrote=
:
> Imagine this situation though. =C2=A0I am a light weight client. =C2=A0I =
store the block
> headers only. =C2=A0I 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. =C2=A0That transaction references other transactions (of cours=
e), but I
> haven't stored any transactions. =C2=A0So; I want to request those transa=
ctions and
> ensure they are all valid and in blocks. =C2=A0I can't.
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.
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:
http://code.google.com/p/bitcoinj/wiki/SecurityModel
Currently this is pretty safe due to the crazy speeds. In future when
speeds are likely to be lower, it will be less safe and you'd have to
wait longer or use a trusted node.
> It should be possible to request the current pending transaction list.
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 -
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.
|
