Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <andyparkins@gmail.com>) id 1UXGCu-0000bs-6X
	for bitcoin-development@lists.sourceforge.net;
	Tue, 30 Apr 2013 19:27:20 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.41 as permitted sender)
	client-ip=74.125.82.41; envelope-from=andyparkins@gmail.com;
	helo=mail-wg0-f41.google.com; 
Received: from mail-wg0-f41.google.com ([74.125.82.41])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1UXGCt-00026a-AE
	for bitcoin-development@lists.sourceforge.net;
	Tue, 30 Apr 2013 19:27:20 +0000
Received: by mail-wg0-f41.google.com with SMTP id e11so3348825wgh.2
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 30 Apr 2013 12:27:13 -0700 (PDT)
X-Received: by 10.180.21.167 with SMTP id w7mr26828984wie.2.1367350033190;
	Tue, 30 Apr 2013 12:27:13 -0700 (PDT)
Received: from momentum.localnet ([91.84.15.31])
	by mx.google.com with ESMTPSA id q13sm31046979wie.8.2013.04.30.12.27.11
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 30 Apr 2013 12:27:12 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Tue, 30 Apr 2013 20:27:10 +0100
User-Agent: KMail/1.13.7 (Linux/3.8-trunk-686-pae; KDE/4.8.4; i686; ; )
References: <CAPg+sBjSe23eADMxu-1mx0Kg2LGkN+BSNByq0PtZcMxAMh0uTg@mail.gmail.com>
	<CAFBxzACmpODv-zvDb39TBpydSinwQ__BaPJfoVBeg==m7RLwrA@mail.gmail.com>
	<CA+8xBpcoTRfp=HFs4PdWAx1k_bZKRfopcTgeUpjPWSHRXv5qUA@mail.gmail.com>
In-Reply-To: <CA+8xBpcoTRfp=HFs4PdWAx1k_bZKRfopcTgeUpjPWSHRXv5qUA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201304302027.10247.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: 1UXGCt-00026a-AE
Subject: Re: [Bitcoin-development] Fwd: Service bits for pruned nodes
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: Tue, 30 Apr 2013 19:27:20 -0000

On Tuesday 30 April 2013 19:04:59 Jeff Garzik wrote:

> The format currently used by bitcoind would be just fine --
> blocks/blkNNNN.dat for raw data, size-limited well below 1GB.  Just
> need to add a small metadata download, and serve the raw block files.

That doesn't seem very generic.  It's tied far too much to the current storage 
format of bitcoind.

Wouldn't it be better to add support for more bitcoin-protocol-oriented HTTP 
requests?  Then any client can supply the same interface, rather than being 
forced to create blkNNNN.dat on the fly?

 http://bitcoind.example.com/block/BBBBBBBBBBBBBBBBBBBBBBB
 http://bitcoind.example.com/tx/TTTTTTTTTTTTTTTTTTTTTTTT
 http://bitcoind.example.com/block/oftx/TTTTTTTTTTTTTTTTTTT
 http://bitcoind.example.com/peers
 http://bitcoind.example.com/peer/nnn

Essentially: block explorer's raw mode but in every bitcoind.  The hardest 
operation for light clients is finding out the block that contains a 
particular transaction -- something that bitcoind already knows.

I'd like to see support for HTTP POST/PUT of signed transactions and block 
announcements too.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com