From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <gcbd-bitcoin-development@m.gmane.org>) id 1V1ZfF-00043G-4G for bitcoin-development@lists.sourceforge.net; Tue, 23 Jul 2013 10:17:53 +0000 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; Received: from plane.gmane.org ([80.91.229.3]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1V1ZfD-00084q-J2 for bitcoin-development@lists.sourceforge.net; Tue, 23 Jul 2013 10:17:53 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from <gcbd-bitcoin-development@m.gmane.org>) id 1V1Zf5-0003EE-A3 for bitcoin-development@lists.sourceforge.net; Tue, 23 Jul 2013 12:17:43 +0200 Received: from e179075185.adsl.alicedsl.de ([85.179.75.185]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>; Tue, 23 Jul 2013 12:17:43 +0200 Received: from andreas by e179075185.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>; Tue, 23 Jul 2013 12:17:43 +0200 X-Injected-Via-Gmane: http://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 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: e179075185.adsl.alicedsl.de 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> X-Spam-Score: -0.4 (/) 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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.91.229.3 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.1 DKIM_ADSP_ALL No valid author signature, domain signs all mail -0.0 SPF_PASS SPF: sender matches SPF record 0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1V1ZfD-00084q-J2 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:17:53 -0000 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?