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: 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>
Subject: Re: [Bitcoin-development] Protocol extensions
Precedence: list

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