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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1Qdpvr-0008Qz-SZ
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Jul 2011 20:39:51 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bluematt.me
designates 208.79.240.5 as permitted sender)
client-ip=208.79.240.5; envelope-from=bitcoin-list@bluematt.me;
helo=smtpauth.rollernet.us;
Received: from smtpauth.rollernet.us ([208.79.240.5])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Qdpvp-0004LH-0F
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Jul 2011 20:39:51 +0000
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id E596859400E
for <bitcoin-development@lists.sourceforge.net>;
Mon, 4 Jul 2011 13:39:27 -0700 (PDT)
Received: from mail.bluematt.me (unknown
[IPv6:2001:470:9ff2:2:20c:29ff:fe16:f239])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
(Authenticated sender: @bluematt.me)
by smtpauth.rollernet.us (Postfix) with ESMTPSA
for <bitcoin-development@lists.sourceforge.net>;
Mon, 4 Jul 2011 13:39:27 -0700 (PDT)
Received: from [IPv6:2001:470:9ff2:1:2c0:caff:fe33:858b] (unknown
[IPv6:2001:470:9ff2:1:2c0:caff:fe33:858b])
by mail.bluematt.me (Postfix) with ESMTPSA id 3BBE9536F
for <bitcoin-development@lists.sourceforge.net>;
Mon, 4 Jul 2011 22:39:35 +0200 (CEST)
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development <bitcoin-development@lists.sourceforge.net>
In-Reply-To: <CABsx9T31ZuQHKwcNnb9-NpaCA6c43PXVZ+Tc+GZ=2Wkz08enHw@mail.gmail.com>
References: <1309801974.3423.80.camel@Desktop666>
<CABsx9T31ZuQHKwcNnb9-NpaCA6c43PXVZ+Tc+GZ=2Wkz08enHw@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1";
protocol="application/pgp-signature";
boundary="=-Uuw8UCt08zvsmAYW5PUF"
Date: Mon, 04 Jul 2011 22:39:32 +0200
Message-ID: <1309811972.29355.19.camel@Desktop666>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2
X-Rollernet-Abuse: Processed by Roller Network Mail Services. Contact
abuse@rollernet.us to report violations. Abuse policy:
http://rollernet.us/abuse.php
X-Rollernet-Submit: Submit ID 44e5.4e1224ff.a1b04.0
X-Spam-Score: -1.5 (-)
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 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1Qdpvp-0004LH-0F
Subject: Re: [Bitcoin-development] Encrypted Wallet Backward Compatibility
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: Mon, 04 Jul 2011 20:39:51 -0000
--=-Uuw8UCt08zvsmAYW5PUF
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
For some reason my mail client let me respond off-list here, didnt mean
to...
On Mon, 2011-07-04 at 14:23 -0400, Gavin Andresen wrote:
> RE: "You have some unencrypted keys, should I encrypt them for you?"
>=20
> That re-opens an "attacker packs the keypool with keypairs that they
> know about" (if I can read/write wallet.dat, then I can delete
> encrypted keypool keys and insert a bunch of unencrypted keypool keys
> that I know how to spend, and rely on the user to click "OK" because
> users are trained to just click "OK").
Not strictly true, if the keys are loaded, but not added to
mapAddressBook or setKeyPool, they wont be used for any new
transactions, or shown to the user, but the user is still able to
receive Bitcoins to those keys.
> RE: breaking backup scripts: if they use the backupwallet RPC
> command, then they will Just Work.
Not really, most backupwallet-based scripts will backup wallet.dat,
encrypt wallet.dat, upload wallet.dat. Now it backups up wallet.dat and
the encrypt part fails because there is no wallet.dat, only
wallet_e.dat. If we rename to wallet.dat on output, now the user's
restore might not work...
>=20
> 0.4 and later could, on wallet encryption, create a wallet_e.dat
> (encrypted wallet). Then truncate wallet.dat and set its
> file-permissions to 000, so if old versions of bitcoin OR any dumb
> wallet backup scripts try to read it they fail.
True, but that is only a solution for Linux and Mac and then you are
back to unreadable error on Windows load and other unforeseeable errors
for odd scripts.
I suppose I just really dont like the idea of renaming wallet.dat,
everything knows the filename and is used to it.
>=20
> RE: future-proofing: wallet.dat contains nFileVersion (version of
> bitcoin that last wrote the wallet). Adding a nMinVersion that
> specifies "you must be at least THIS version to read this file" seems
> like a good idea so if you have version 0.4 or later future wallet
> upgrades give you a reasonable message if you try to downgrade after
> an incompatible change.
Yep, just something simple that says, no reading this to old versions is
needed, IMO the older version should freak out if it sees keys that it
doesn't know about (as it could also indicate wallet corruption in some
rare cases), but nMinVersion works just as well, in any case this should
only very rarely be a problem...how often will we change the wallet
format?
--=-Uuw8UCt08zvsmAYW5PUF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJOEiTvAAoJEBrh01BD4I5UHyIP/0V6riJFFFHkRSI3uUe+biJF
Eqt+tZG2tA/xrEre2UZZAtaf6OhlRfLu/akd3VJ6DxcUF8W6oP4SOt1pj+9nkbhe
zMxxKt0S1g5ygJzdKyapYiNbUi9XtyE5YYc4GOC0+UkdLF3U9qrGRzTiKIUEhJMI
P4yEVmP2X6PUUL+cNWLxQHpqKj+M7Hcj8ERhrwV3d+M7z7Hg5aLMA82XkfVAGYCn
mzeGTUGu67Yg9Z5Al7STGBpD3RRea1D5FhrsKrzi+ntZ5moTMAK+vxsRMbxA+EMY
sLunnpyOWGOl3W+XK10pdLJ/QimQgP+n6aw6LxAHFCMVeZ6EWGUb0E1ZUE/8bpaN
cGlr4lIkv6xIPrDXtzpYflewsaXUtZglr40DLlxAUqU449MSxsUSz+OZz2rWFdHt
HREPv+WpQ+6TjY86mDfsHZWosMuMWpILwOMhDuvWzcou/846/nTbcgEQweysDNSM
Ef1AHoN490Kw0nQQ6duPc9USmaNJJQoM3WPOq5vDLiG1EbyzZESXgtx51bWkO8SK
kShVec9bAWTzrEo6xECUSFpaz0kTHPx31hQkujXHKSZjVxEZJw0OMm57qYEw9Pfm
90vEQf8xxBUuPRTJRDRbynlbozbRH8NpY4gS92CeiEFyoCKXUfWa2pPLoxWtNQou
5UOGIb0G4oPsd+WE+xLb
=J2ia
-----END PGP SIGNATURE-----
--=-Uuw8UCt08zvsmAYW5PUF--
|
