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
|
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 1RcHXL-0000Rc-Pf
for bitcoin-development@lists.sourceforge.net;
Sun, 18 Dec 2011 14:16:23 +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-MD5:128)
(Exim 4.76) id 1RcHXL-0004Nk-3A
for bitcoin-development@lists.sourceforge.net;
Sun, 18 Dec 2011 14:16:23 +0000
Received: by wgbds1 with SMTP id ds1so8349580wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Sun, 18 Dec 2011 06:16:17 -0800 (PST)
Received: by 10.227.58.17 with SMTP id e17mr9937057wbh.12.1324217776914;
Sun, 18 Dec 2011 06:16:16 -0800 (PST)
Received: from grissom.localnet ([91.84.15.31]) by mx.google.com with ESMTPS id
hn15sm21592266wib.22.2011.12.18.06.16.13
(version=TLSv1/SSLv3 cipher=OTHER);
Sun, 18 Dec 2011 06:16:14 -0800 (PST)
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Sun, 18 Dec 2011 14:16:08 +0000
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-686-pae; KDE/4.6.4; i686; ; )
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
<1324158558.26106.140661012932641@webmail.messagingengine.com>
<4EED416E.3010902@parhelic.com>
In-Reply-To: <4EED416E.3010902@parhelic.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201112181416.10034.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
X-Headers-End: 1RcHXL-0004Nk-3A
Subject: Re: [Bitcoin-development] Protocol extensions
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: Sun, 18 Dec 2011 14:16:23 -0000
On Sunday 18 Dec 2011 01:27:10 Jordan Mack wrote:
> I don't like the idea of a header only client, unless this is just an
> interim action until the full block chain is downloaded in the
> background. Development of these types of clients is probably
> inevitable, but I believe that this breaks the most fundamental aspects
> of Bitcoin's security model. If a client has only headers, it cannot do
> full verification, and it is trusting the data from random anonymous
> peers.
I'm working on (slowly) making a client able to download-on-demand. That is
to say that the block chain headers would be downloaded and maintained, but
the block bodies would be downloaded as needed for full verification. It's
certainly not possible with the current protocol; but it's certainly a
conceivable application. I suppose it slots between headers-only and full
client conceptually.
Andy
--
Dr Andy Parkins
andyparkins@gmail.com
|
