Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of m.gmane.org
	designates 80.91.229.3 as permitted sender)
	client-ip=80.91.229.3;
	envelope-from=gcbd-bitcoin-development@m.gmane.org;
	helo=plane.gmane.org; 
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Tue, 23 Jul 2013 12:29:34 +0200
Message-ID: <ksllu7$9i$1@ger.gmane.org>
References: <CAJHLa0Ou1xF=LeLVu_wH1-XgJ1PavDV7_NHoDevo3R9+4z-ZfQ@mail.gmail.com>
	<201307231030.14139.andyparkins@gmail.com>
	<20130723094703.GA25900@savin>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130623 Thunderbird/17.0.7
In-Reply-To: <20130723094703.GA25900@savin>
Subject: Re: [Bitcoin-development] HTTP REST API for bitcoind
Precedence: list

On 07/23/2013 11:47 AM, Peter Todd wrote:

>> Is it planned to expose the UXTO set of a given address? That would be
>> useful for SPV wallets to be able to swipe a previously unknown private
>> key (e.g. paper wallet).
> 
> 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.
> 
> Increasing the resource usage by SPV clients on full nodes is undesirable; we
> have a lot of work to do regarding DoS attacks.

Yes, I understand that. For this reason, I would vote for adding the
usual HTTP authentication/SSL stuff to the REST API. That way, SPV users
can decide to run their own instance of the API (providing the needed
resources themselves).

Or, a trusted party can set up a server. For example, I would be willing
to set it up for users of Bitcoin Wallet. I don't expect shitloads of
paper wallets sweeps for the forseeable future.