Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <andyparkins@gmail.com>) id 1V1ZOV-0000QB-6Z
	for bitcoin-development@lists.sourceforge.net;
	Tue, 23 Jul 2013 10:00:35 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.50 as permitted sender)
	client-ip=74.125.82.50; envelope-from=andyparkins@gmail.com;
	helo=mail-wg0-f50.google.com; 
Received: from mail-wg0-f50.google.com ([74.125.82.50])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1V1ZOT-0007O2-BI
	for bitcoin-development@lists.sourceforge.net;
	Tue, 23 Jul 2013 10:00:35 +0000
Received: by mail-wg0-f50.google.com with SMTP id m15so1498778wgh.5
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 23 Jul 2013 03:00:27 -0700 (PDT)
X-Received: by 10.180.11.146 with SMTP id q18mr21288013wib.50.1374573627210;
	Tue, 23 Jul 2013 03:00:27 -0700 (PDT)
Received: from momentum.localnet ([91.84.15.31])
	by mx.google.com with ESMTPSA id fb2sm4720238wic.4.2013.07.23.03.00.25
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 23 Jul 2013 03:00:26 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: Peter Todd <pete@petertodd.org>
Date: Tue, 23 Jul 2013 11:00:24 +0100
User-Agent: KMail/1.13.7 (Linux/3.9-1-686-pae; KDE/4.8.4; i686; ; )
References: <CAJHLa0Ou1xF=LeLVu_wH1-XgJ1PavDV7_NHoDevo3R9+4z-ZfQ@mail.gmail.com>
	<201307231030.14139.andyparkins@gmail.com>
	<20130723094703.GA25900@savin>
In-Reply-To: <20130723094703.GA25900@savin>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201307231100.24538.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: 1V1ZOT-0007O2-BI
Cc: bitcoin-development@lists.sourceforge.net,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] HTTP REST API for bitcoind
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, 23 Jul 2013 10:00:35 -0000

On Tuesday 23 July 2013 10:47:03 Peter Todd wrote:
> On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote:
> > One additional URL makes this pretty much perfect:
> >   GET /rest/block-with-tx/TX-HASH
> > 
> > Construction of the transaction-hash-to-block database is something the
> > full client's have to do anyway, so this query is no harder than the
> > others for them to supply; but suddenly makes it possible for an SPV
> > client to trace the providence of any transaction without needing to
> > maintain the entire chain.

> The REST API has nothing to do with SPV clients; it's similar to the RPC
> interface and won't be exposed to the network as a whole.

Yes; I know that.  I'm saying that it would make it easier for SPV (and other 
lightweight clients) for that matter.

> Increasing the resource usage by SPV clients on full nodes is undesirable;

I don't think that's thinking big enough.  What I imagine is that making it 
easier and easier to store a partial blockchain would result in lower demand 
on full nodes.

I might run a client that has only fetched blocks that contain transactions 
needed to verify my balances, right back to the genesis block.  That will be 
some small subset of the block chain and will take me very little resource to 
maintain.  I join the network and am my client is willing to verify based on 
information I have, or supply (by REST or bitcoin protocol) blocks.  Imagine 
then that everyone with a wallet were doing this.  The blockchain would be 
distributed massively.  Obviously the miners would still be keeping the entire 
chain, but we'd have a lot more nodes in the network, each contributing a 
little bit and so reducing the load on the full nodes.

> In any case UTXO data currently requires you to have full trust in
> whomever is providing you with it, and that situation will continue
> until UTXO commitments are implemented - if they are implemented.

Almost; because you can go and ask someone else the same question, it's pretty 
easy to check if you're being lied to.  Also, it's far easier to maintain a 
headers-only block chain.  When you fetch your relevant block subset, you can 
easily see that they are real blocks in your headers-only blockchain; and so 
it's pretty much impossible to lie to "give me the block containing 
transaction X".


Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com