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 ) 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 ; 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: References: Date: Tue, 3 Dec 2013 21:16:18 -0800 Message-ID: From: Casey Rodarmor To: =?UTF-8?Q?D=C3=A2niel_Fraga?= 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
On T= ue, Dec 3, 2013 at 11:59 AM, D=C3=A2niel Fraga <fragabr@gmail.com><= /span> wrote:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Today, when a user uses bitcoin-qt client, it c= an 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 w= ith bitcoin-qt =E2=80=93 and, to be totally fair, a whole bunch of other wa= llet programs.

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.

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.

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?

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.
--047d7b6d95ee5089be04ecae8375--