public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andreas Schildbach <andreas@schildbach.de>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] HTTP REST API for bitcoind
Date: Tue, 23 Jul 2013 12:17:33 +0200	[thread overview]
Message-ID: <ksll7m$o9u$1@ger.gmane.org> (raw)
In-Reply-To: <20130723093759.GB6198@vps7135.xlshosting.net>

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?





  parent reply	other threads:[~2013-07-23 10:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22 19:42 [Bitcoin-development] HTTP REST API for bitcoind Jeff Garzik
2013-07-22 22:06 ` Michael Hendricks
2013-07-23  8:27 ` Andreas Schildbach
2013-07-23  8:45   ` Michael Gronager
2013-07-23  9:37   ` Pieter Wuille
2013-07-23  9:53     ` Michael Gronager
2013-07-23 10:17     ` Andreas Schildbach [this message]
2013-07-23 10:27       ` Pieter Wuille
2013-07-23  9:30 ` Andy Parkins
2013-07-23  9:42   ` Pieter Wuille
2013-07-23  9:52     ` Andy Parkins
2013-07-23  9:56       ` Pieter Wuille
2013-07-23 10:02         ` Andy Parkins
2013-07-23 10:06           ` Pieter Wuille
2013-07-23  9:47   ` Peter Todd
2013-07-23 10:00     ` Andy Parkins
2013-07-23 10:17       ` Peter Todd
2013-07-23 11:45         ` Andy Parkins
2013-07-23 10:19       ` Pieter Wuille
2013-07-23 10:29     ` Andreas Schildbach
2013-07-23 10:36       ` Pieter Wuille
2013-07-23 15:48         ` Michael Hendricks
2013-07-23 19:36       ` Mark Friedenbach
2013-08-10 20:30         ` Rune Kjær Svendsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='ksll7m$o9u$1@ger.gmane.org' \
    --to=andreas@schildbach.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox