From: Pieter Wuille <pieter.wuille@gmail•com>
To: Andreas Schildbach <andreas@schildbach•de>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] HTTP REST API for bitcoind
Date: Tue, 23 Jul 2013 11:37:59 +0200 [thread overview]
Message-ID: <20130723093759.GB6198@vps7135.xlshosting.net> (raw)
In-Reply-To: <kslep0$hq7$1@ger.gmane.org>
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
next prev parent reply other threads:[~2013-07-23 9:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-22 19:42 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 [this message]
2013-07-23 9:53 ` Michael Gronager
2013-07-23 10:17 ` Andreas Schildbach
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=20130723093759.GB6198@vps7135.xlshosting.net \
--to=pieter.wuille@gmail$(echo .)com \
--cc=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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