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 ) id 1V1Z2k-0007Sy-QZ for bitcoin-development@lists.sourceforge.net; Tue, 23 Jul 2013 09:38:06 +0000 X-ACL-Warn: Received: from vps7135.xlshosting.net ([178.18.90.41]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1V1Z2j-0006Fa-PD for bitcoin-development@lists.sourceforge.net; Tue, 23 Jul 2013 09:38:06 +0000 Received: by vps7135.xlshosting.net (Postfix, from userid 1000) id E726733C87D; Tue, 23 Jul 2013 11:37:59 +0200 (CEST) Date: Tue, 23 Jul 2013 11:37:59 +0200 From: Pieter Wuille To: Andreas Schildbach Message-ID: <20130723093759.GB6198@vps7135.xlshosting.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 1.2 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-Headers-End: 1V1Z2j-0006Fa-PD Cc: bitcoin-development@lists.sourceforge.net 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 09:38:07 -0000 On Tue, Jul 23, 2013 at 10:27:19AM +0200, Andreas Schildbach wrote: > On 07/22/2013 09:42 PM, Jeff Garzik wrote: > > > The general goal of the HTTP REST interface is to access > > unauthenticated, public blockchain information. There is no plan to > > add wallet interfacing/manipulation via this API. > > 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. -- Pieter