1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
|
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 <pw@vps7135.xlshosting.net>) 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 <pieter.wuille@gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Message-ID: <20130723093759.GB6198@vps7135.xlshosting.net>
References: <CAJHLa0Ou1xF=LeLVu_wH1-XgJ1PavDV7_NHoDevo3R9+4z-ZfQ@mail.gmail.com>
<kslep0$hq7$1@ger.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <kslep0$hq7$1@ger.gmane.org>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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
|
