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
|
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 <casey@rodarmor.com>) id 1Vo5Ia-0003eN-Lu
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Dec 2013 05:47:00 +0000
X-ACL-Warn:
Received: from mail-ve0-f177.google.com ([209.85.128.177])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Vo5IZ-0003hw-F9
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Dec 2013 05:47:00 +0000
Received: by mail-ve0-f177.google.com with SMTP id db12so11186282veb.8
for <bitcoin-development@lists.sourceforge.net>;
Tue, 03 Dec 2013 21:46:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=aergrlxd+oinOawB+HtJF9uArLeLkND8XX3bs70/f0U=;
b=IjZ065yK8wuSb3Nlq+AW406xSX3SEJRAdgulIUwt9ZyNXVuE/jcWbBmQ56ge5o7c/k
ZWkVQ5yUe8S2+uEbHOqF7zdpG0Y03rO4XiIbYwsbRWEwXhNQWqJBVShmGXf3MhqMsWv0
T3knQW4vPT8VBMgeNP8CCJAhguSEVvFjQweevDI7wmBNQtXtOjwjvcZ6dNT6/UF++e7p
l6Tjz97sPZB8Gp8CzzUMmyQVsphFDD07sGn34LLvPH71nuCV8mnEnSOTVLVLstayWQ/w
g63LgitdGBGeYlp+c4lhkXc7UXdu9d9QqHmQ0R7jCsPwhQwHm9OLTOcbZKqGPAcoi5rJ
irkQ==
X-Gm-Message-State: ALoCoQkbqTuPhFdcpZU1cVehbcYB2N0yDhsfoOVjfORjozo1VCb6WllDgTRIbL9AvMLBY/lXCh9F
MIME-Version: 1.0
X-Received: by 10.58.143.17 with SMTP id sa17mr59369181veb.14.1386134178368;
Tue, 03 Dec 2013 21:16:18 -0800 (PST)
Received: by 10.220.172.200 with HTTP; Tue, 3 Dec 2013 21:16:18 -0800 (PST)
In-Reply-To: <l7ld63$25l$2@ger.gmane.org>
References: <l7ld63$25l$2@ger.gmane.org>
Date: Tue, 3 Dec 2013 21:16:18 -0800
Message-ID: <CANLPe+Ox4zsQQ2nYshtzOHj9biK=YK3C+dcGZ3L_+Tj_HAQv3A@mail.gmail.com>
From: Casey Rodarmor <casey@rodarmor.com>
To: =?UTF-8?Q?D=C3=A2niel_Fraga?= <fragabr@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b6d95ee5089be04ecae8375
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Vo5IZ-0003hw-F9
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Suggestion: easy way to restore
wallet.dat backup
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: Wed, 04 Dec 2013 05:47:00 -0000
--047d7b6d95ee5089be04ecae8375
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Dec 3, 2013 at 11:59 AM, D=C3=A2niel Fraga <fragabr@gmail.com> wrot=
e:
>
> Today, when a user uses bitcoin-qt client, it can make a backup
> of wallet.dat easily through menu, but when he/she needs to restore
> this backup, he/she must copy the file to the correct folder and
> execute "bitcoin-qt -rescan".
>
I actually think this is part of a larger and somewhat subtle UX problem
with bitcoin-qt =E2=80=93 and, to be totally fair, a whole bunch of other w=
allet
programs.
I think the issue is that bitcoin-qt should have a document-oriented
approach to wallets. It should make you select a location to store your
wallet, just like a word processor, when you create a new wallet. It could
open the most recent wallet when you run the program, or allow you to open
a wallet by double-clicking it directly in the OS.
I think this would solve this particular issue nicely, just double click
the wallet file. Also, the menu item can just be labeled "Open Wallet". It
might also prevent those kind of heartbreaking posts which read something
like, "I just wiped my hard drive and reinstalled bitcoin-qt, where are my
coins?" People don't have the expectation that if they get Word on a new PC
that their documents will somehow magically be available, I think in part
because Word forces you to deal with the documents and the save location
yourself.
I know that this would bring with it a host of other considerations: Can
multiple wallets be open at the same time? What happens if a wallet file is
moved while it's open? What happens when there are two versions of the same
wallet? Will users understand that they need to backup their wallets
periodically?
But, I think it would be a big enough usability win that it should be
considered. Also, if at the same time bitcoin-qt were to adopt BIP 32 style
deterministically derived private keys from a single seed, a bunch of the
issues above would also go away: There are never two versions of the same
wallet, since they're the same seed, and periodic backups are unnecessary.
--047d7b6d95ee5089be04ecae8375
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 3, 2013 at 11:59 AM, D=C3=A2niel Fraga <span dir=3D"ltr"><<a hre=
f=3D"mailto:fragabr@gmail.com" target=3D"_blank">fragabr@gmail.com</a>><=
/span> wrote:=C2=A0<blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Today, when a user uses bitcoin-qt client, it c=
an make a backup<br>
of wallet.dat easily through menu, but when he/she needs to restore<br>
this backup, he/she must copy the file to the correct folder and<br>
execute "bitcoin-qt -rescan".<br></blockquote><div><br></div><div=
>I actually think this is part of a larger and somewhat subtle UX problem w=
ith bitcoin-qt =E2=80=93 and, to be totally fair, a whole bunch of other wa=
llet programs.<br>
</div><div><div><br></div><div>I think the issue is that bitcoin-qt should =
have a document-oriented approach to wallets. It should make you select a l=
ocation to store your wallet, just like a word processor, when you create a=
new wallet. It could open the most recent wallet when you run the program,=
or allow you to open a wallet by double-clicking it directly in the OS.</d=
iv>
<div><br></div><div>I think this would solve this particular issue nicely, =
just double click the wallet file. Also, the menu item can just be labeled =
"Open Wallet". It might also prevent those kind of heartbreaking =
posts which read something like, "I just wiped my hard drive and reins=
talled bitcoin-qt, where are my coins?" People don't have the expe=
ctation that if they get Word on a new PC that their documents will somehow=
magically be available, I think in part because Word forces you to deal wi=
th the documents and the save location yourself.</div>
</div><div><br></div><div>I know that this would bring with it a host of ot=
her considerations: Can multiple wallets be open at the same time? What hap=
pens if a wallet file is moved while it's open? What happens when there=
are two versions of the same wallet? Will users understand that they need =
to backup their wallets periodically?</div>
<div><br></div><div>But, I think it would be a big enough usability win tha=
t it should be considered. Also, if at the same time bitcoin-qt were to ado=
pt BIP 32 style deterministically derived private keys from a single seed, =
a bunch of the issues above would also go away: There are never two version=
s of the same wallet, since they're the same seed, and periodic backups=
are unnecessary.</div>
</div></div></div>
--047d7b6d95ee5089be04ecae8375--
|
