summaryrefslogtreecommitdiff
path: root/7f/94082d85a2fabac1f8167624c5fe3962bd9578
blob: 4a3e58d0f5e877c1077827cba47a41a2713e54d1 (plain)
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1RR2xC-0005H5-4e
	for bitcoin-development@lists.sourceforge.net;
	Thu, 17 Nov 2011 14:28:38 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.161.47 as permitted sender)
	client-ip=209.85.161.47; envelope-from=gavinandresen@gmail.com;
	helo=mail-fx0-f47.google.com; 
Received: from mail-fx0-f47.google.com ([209.85.161.47])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1RR2x8-0000St-Bq
	for bitcoin-development@lists.sourceforge.net;
	Thu, 17 Nov 2011 14:28:38 +0000
Received: by faat2 with SMTP id t2so4252632faa.34
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 17 Nov 2011 06:28:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.109.33 with SMTP id hp1mr23396921lab.36.1321540108007;
	Thu, 17 Nov 2011 06:28:28 -0800 (PST)
Received: by 10.152.30.69 with HTTP; Thu, 17 Nov 2011 06:28:27 -0800 (PST)
Date: Thu, 17 Nov 2011 09:28:27 -0500
Message-ID: <CABsx9T2vRq++uqu=23YG86uQ=9ZpwjYv_8hOinWRyrd9YLv_PQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.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
	(gavinandresen[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-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
	0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RR2x8-0000St-Bq
Subject: [Bitcoin-development] There will be a release candidate 6...
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, 17 Nov 2011 14:28:38 -0000

I got email from a tester who gave this feedback:

> I think that user behaviour: encrypt wallet -> backup -> do some activity ->
> restore backup -> BOOM. Is perfectly natural user behaviour and it will
> happen. For example when generating a wallet on a secure computer and then
> moving it to an insecure one.

I agree that is likely to happen and, when it does, will be disastrous.
So I'll be reworking the wallet encrypt/rewrite code today and
creating a release candidate 6.

My previous attempt (encrypt, invalidating keypool, then unlock and write
a new keypool) resulted in unencrypted private keys in the new wallet.

I think this will work, I'll implement and test today.

Invalidate all the old keypool keys in the old wallet.Write new
keypool keys to the old wallet.Encrypt all the keys in the old
wallet.Rewrite the old wallet to create a new wallet.Shutdown/restart.
IF ANYBODY IS WILLING TO HELP:

There is still a mysterious problem with bdb throwing an exception
when dbenv.close(0) is called during shutdown. If you can compile
a -g version of bdb and then step through DbEnv::close in a debugger
and tell me why it is throwing an exception that would be
extremely helpful.
-- 
--
Gavin Andresen