Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2013-07-23 📝 Original message:On Tue, Jul 23, 2013 at ...

📅 Original date posted:2013-07-23
📝 Original message: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