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? ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
