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
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1V1ZfF-00043G-4G for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 10:17:53 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of m.gmane.org
designates 80.91.229.3 as permitted sender)
client-ip=80.91.229.3;
envelope-from=gcbd-bitcoin-development@m.gmane.org;
helo=plane.gmane.org;
Received: from plane.gmane.org ([80.91.229.3])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1V1ZfD-00084q-J2
for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 10:17:53 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1V1Zf5-0003EE-A3 for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 12:17:43 +0200
Received: from e179075185.adsl.alicedsl.de ([85.179.75.185])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Tue, 23 Jul 2013 12:17:43 +0200
Received: from andreas by e179075185.adsl.alicedsl.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-development@lists.sourceforge.net>;
Tue, 23 Jul 2013 12:17:43 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Tue, 23 Jul 2013 12:17:33 +0200
Message-ID: <ksll7m$o9u$1@ger.gmane.org>
References: <CAJHLa0Ou1xF=LeLVu_wH1-XgJ1PavDV7_NHoDevo3R9+4z-ZfQ@mail.gmail.com>
<kslep0$hq7$1@ger.gmane.org>
<20130723093759.GB6198@vps7135.xlshosting.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: e179075185.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/20130623 Thunderbird/17.0.7
In-Reply-To: <20130723093759.GB6198@vps7135.xlshosting.net>
X-Spam-Score: -0.4 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [80.91.229.3 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.1 DKIM_ADSP_ALL No valid author signature,
domain signs all mail
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1V1ZfD-00084q-J2
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 10:17:53 -0000
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?
|
