Received-SPF: pass (sog-mx-3.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:17:33 +0200
Message-ID: <ksll7m$o9u$1@ger.gmane.org>
References: <CAJHLa0Ou1xF=LeLVu_wH1-XgJ1PavDV7_NHoDevo3R9+4z-ZfQ@mail.gmail.com>
	<kslep0$hq7$1@ger.gmane.org>
	<20130723093759.GB6198@vps7135.xlshosting.net>
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: <20130723093759.GB6198@vps7135.xlshosting.net>
Subject: Re: [Bitcoin-development] HTTP REST API for bitcoind
Precedence: list

On 07/23/2013 11:37 AM, Pieter Wuille 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).
>
> Depends what you mean by expose.
>
> Maintaining an address/script-indexed UTXO is generally useful, in
> particular for things like sweeping addresses. I certainly have
> less problems with 'exposing' this than exposing a fully-indexed
> block chain history.
>
> However, and I expect that's what your question is about, this isn't
> really useful for SPV (or less) nodes, as there is no way to
> authenticate this data. If you can fake a UTXO entry, you can make
> a peer believe anything about their balance, potentially resulting
> in creating a valid transaction that sends change it didn't know
> was there as fee to miners. Other than for normal block chain data,
> there is no way to detect this without at least partial validation.
>
> The only way to do this safely at an SPV security assumption, is by
> having an address-indexed committed merkle UTXO-set tree, like the
> one proposed by Alan Reiner, and being implemented by Mark
> Friedenback. I know Michael Gronager has something similar implemented,
> but I don't know whether it is script-indexed. To be actually useful,
> it likely needs to be enforced by miners - putting a significant
> burden on validation nodes. Still, if it can be done efficiently,
> I think this would be worth it, but more research is needed first in
> any case.
>
> Regarding sweeping keys in the first place - I think using those,
> and relying on address-indexed UTXO sets or blockchains to import
> them, is an idea that doesn't scale very well in the first place.
> If it is for things like scratch card or physical coins, with a
> pre-set value, the obvious solution IMHO is storing the crediting
> transaction with its merkle path together with the key. If that's
> not possible, just the txid:vout of the credit output can suffice.
> Yes, that's more data than is necessary now, but it's so much more
> trivial to use.

I certainly don't want to push ideas that won't work for whatever
reason. So I fully respect whatever you decide regarding that feature.
Personally I have never felt any need for being able to sweep paper
wallets, I am more or less just relaying the need of users.

Let me just say this:

Sweeping paper wallets is a common feature request. People switch to
centralized services just for getting that.

It is my understanding that for the usecase, an address-indexed UXTO is
enough. So you probably don't need to worry about script-indexed for now.

Security issues could be mitigated by applying trust to the REST server,
e.g. because its your own or the one of your apps vendor. Of course,
link-level security would be needed for this (e.g. SSL).

Paper wallets that include the necessary additional information is
something I have been thinking about. I see some issues:

- Paper wallets are already quite widespread. You still won't be able to
sweep those.
- Some people like to "top up" a paper wallet or even just sweep a
portion of it. That would not be possible, and in some cases even lead
to loss of coins because of the "involuntary fee" you described.
- Does the necessary info fit into a QR code?