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
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1YW7pY-0001oC-OV
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Mar 2015 18:27:36 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.178 as permitted sender)
client-ip=74.125.82.178; envelope-from=natanael.l@gmail.com;
helo=mail-we0-f178.google.com;
Received: from mail-we0-f178.google.com ([74.125.82.178])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YW7pS-00050i-Kz
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Mar 2015 18:27:36 +0000
Received: by wesu56 with SMTP id u56so18245142wes.12
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Mar 2015 11:27:24 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.104.99 with SMTP id gd3mr86952065wjb.114.1426184844636;
Thu, 12 Mar 2015 11:27:24 -0700 (PDT)
Received: by 10.194.28.170 with HTTP; Thu, 12 Mar 2015 11:27:24 -0700 (PDT)
Received: by 10.194.28.170 with HTTP; Thu, 12 Mar 2015 11:27:24 -0700 (PDT)
In-Reply-To: <CANEZrP2AhCfks7Q+16PHGB0ZEeWwbdbbQM_xj3ebrkgDBgbosg@mail.gmail.com>
References: <54F32EED.6040103@electrum.org>
<CANEZrP23buJF0ENfrKGRuzpQ3Uod09s-kRcb3CBw1-OmUxEyZg@mail.gmail.com>
<550057FD.6030402@electrum.org>
<CANEZrP2UrRYG2wh3DHHj9B3Sp1X=n+gPCRcoj1Fouu4Lg157UA@mail.gmail.com>
<CAJna-HhHkmOTqNW2R6=Cih+tM_Eeu5o1LBxA4ZNzp-6vm1p6fg@mail.gmail.com>
<CANEZrP2AhCfks7Q+16PHGB0ZEeWwbdbbQM_xj3ebrkgDBgbosg@mail.gmail.com>
Date: Thu, 12 Mar 2015 19:27:24 +0100
Message-ID: <CAAt2M1_zVXnp_EjtZHiP9wSq+cERgibZ_C992zZHtv+Lpmgsfw@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e010d879c0c7a8a05111b89aa
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(natanael.l[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YW7pS-00050i-Kz
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
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: Thu, 12 Mar 2015 18:27:36 -0000
--089e010d879c0c7a8a05111b89aa
Content-Type: text/plain; charset=UTF-8
Den 12 mar 2015 17:48 skrev "Mike Hearn" <mike@plan99.net>:
>>
>> b) "Creation date" is just a short-term hack.
>
>
> I agree, but we need things to be easy in the short term as well as the
long term :)
>
> The long term solution is clearly to have the 12 word seed be an
encryption key for a wallet backup with all associated metadata. We're
heading in that direction one step at a time. Unfortunately it will take
time for wallets to start working this way, and all the pieces to fall into
place. Restoring from the block chain will be a semi regular operation for
users until then.
This have been mentioned a few times before, and what I think is necessary
is to create a common file format that can be interpreted by a library
which all wallets can use. I see it as similar as the work to create
libconsensus for parsing the blockchain.
We need something extensible that can describe how to derive all addresses
used by the user. What HD branches to derive and how, with block numbers
(or bloom filters of block hashes or similar) to note where all previously
known transactions related to the wallet have occurred, and the last known
block (so only new blocks need to be scanned).
A way to describe one HD tree as a multisignature wallet tied to a hardware
wallet if you have that (could include serial number or MAC of the device
for simple identification by the wallet client). A way to describe another
set of addresses as using a custom extension. A way to denote one private
key as being used for stealth addresses together with details for how to
identify the transactions (prefix, mailbox to look in, etc). Labels for
transactions. P2SH script templates so those addresses can be recovered. A
way to describe Copay style multisignature wallets and what server to use
for coordinating with the other coowners. A way to describe threshold
crypto group signature wallets and how to coordinate. Computer parsable
descriptions of HD branches as change addresses, as being used for
receiving payments in merchant payment systems, etc... Also, you should
really be talking to people like accountants and auditors to see what
features they'd like to see when it comes to things like how company
wallets could have rules defined for how to use the various HD branches.
And so on... I think you get my point by now.
The basic idea is that the wallet uses the library to parse the wallet file
and tells the user which sections it understands (can't expect all wallets
to handle custom extensions or stealth addresses, etc), then proceeds to
scan the blockchain for those addresses. Then the user also won't be
surprised that not all funds are found and won't think they're lost.
I think it should be referred to as an import/export format, more than as a
backup format.
You always want the most recent metadata the wallet of origin can provide
when importing, to reduce unnecessary extra work. You don't want really old
backup files. If people add new seeds and various new extensions that can't
be automatically recovered from old wallet backups, they need new backups.
You might as well use the wallet's own internal formats for backup, as the
wallet developer might better know how to optimize for the use cases he
have designed for. But at the same time we should ask wallet developers to
offer conversion tools to generate export format files from custom wallet
data files.
--089e010d879c0c7a8a05111b89aa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Den 12 mar 2015 17:48 skrev "Mike Hearn" <<a href=3D"mailto:mi=
ke@plan99.net">mike@plan99.net</a>>:<br>
>><br>
>> b) "Creation date" is just a short-term hack. <br>
><br>
><br>
> I agree, but we need things to be easy in the short term as well as th=
e long term :)=C2=A0<br>
><br>
> The long term solution is clearly to have the 12 word seed be an encry=
ption key for a wallet backup with all associated metadata. We're headi=
ng in that direction one step at a time. Unfortunately it will take time fo=
r wallets to start working this way, and all the pieces to fall into place.=
Restoring from the block chain will be a semi regular operation for users =
until then.</p>
<p dir=3D"ltr">This have been mentioned a few times before, and what I thin=
k is necessary is to create a common file format that can be interpreted by=
a library which all wallets can use. I see it as similar as the work to cr=
eate libconsensus for parsing the blockchain. </p>
<p dir=3D"ltr">We need something extensible that can describe how to derive=
all addresses used by the user. What HD branches to derive and how, with b=
lock numbers (or bloom filters of block hashes or similar) to note where al=
l previously known transactions related to the wallet have occurred, and th=
e last known block (so only new blocks need to be scanned).</p>
<p dir=3D"ltr">A way to describe one HD tree as a multisignature wallet tie=
d to a hardware wallet if you have that (could include serial number or MAC=
of the device for simple identification by the wallet client). A way to de=
scribe another set of addresses as using a custom extension. A way to denot=
e one private key as being used for stealth addresses together with details=
for how to identify the transactions (prefix, mailbox to look in, etc). La=
bels for transactions. P2SH script templates so those addresses can be reco=
vered. A way to describe Copay style multisignature wallets and what server=
to use for coordinating with the other coowners. A way to describe thresho=
ld crypto group signature wallets and how to coordinate. Computer parsable =
descriptions of HD branches as change addresses, as being used for receivin=
g payments in merchant payment systems, etc... Also, you should really be t=
alking to people like accountants and auditors to see what features they=
9;d like to see when it comes to things like how company wallets could have=
rules defined for how to use the various HD branches. </p>
<p dir=3D"ltr">And so on... I think you get my point by now. </p>
<p dir=3D"ltr">The basic idea is that the wallet uses the library to parse =
the wallet file and tells the user which sections it understands (can't=
expect all wallets to handle custom extensions or stealth addresses, etc),=
then proceeds to scan the blockchain for those addresses. Then the user al=
so won't be surprised that not all funds are found and won't think =
they're lost. </p>
<p dir=3D"ltr">I think it should be referred to as an import/export format,=
more than as a backup format.</p>
<p dir=3D"ltr">You always want the most recent metadata the wallet of origi=
n can provide when importing, to reduce unnecessary extra work. You don'=
;t want really old backup files. If people add new seeds and various new ex=
tensions that can't be automatically recovered from old wallet backups,=
they need new backups. You might as well use the wallet's own internal=
formats for backup, as the wallet developer might better know how to optim=
ize for the use cases he have designed for. But at the same time we should =
ask wallet developers to offer conversion tools to generate export format f=
iles from custom wallet data files.</p>
--089e010d879c0c7a8a05111b89aa--
|
