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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1YVuRT-0001OP-84
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Mar 2015 04:09:51 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.173 as permitted sender)
client-ip=209.85.223.173; envelope-from=gmaxwell@gmail.com;
helo=mail-ie0-f173.google.com;
Received: from mail-ie0-f173.google.com ([209.85.223.173])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YVuRS-0001ps-4q
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Mar 2015 04:09:51 +0000
Received: by ieclw3 with SMTP id lw3so14838413iec.2
for <bitcoin-development@lists.sourceforge.net>;
Wed, 11 Mar 2015 21:09:44 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.7.1 with SMTP id f1mr70190913iga.8.1426133384848; Wed, 11
Mar 2015 21:09:44 -0700 (PDT)
Received: by 10.107.6.133 with HTTP; Wed, 11 Mar 2015 21:09:44 -0700 (PDT)
In-Reply-To: <5500FCDA.8050407@niftybox.net>
References: <54F32EED.6040103@electrum.org>
<CANEZrP23buJF0ENfrKGRuzpQ3Uod09s-kRcb3CBw1-OmUxEyZg@mail.gmail.com>
<550057FD.6030402@electrum.org>
<CANEZrP2UrRYG2wh3DHHj9B3Sp1X=n+gPCRcoj1Fouu4Lg157UA@mail.gmail.com>
<1426100677.1908596.239033309.7C4F8D47@webmail.messagingengine.com>
<CALC81CPonBX5pGucU9Pu7P7S042c+h8=vNvocX=7f9Yi_kqv5w@mail.gmail.com>
<CAAS2fgRuBwn6HXeZeth+x-R8DAdsVZmYy4nMA3kN+oJaURftgw@mail.gmail.com>
<CACq0ZD64rZAQs1mWQdwgx1WJq2btAVs3GbegPpkO-Wh49SoGeA@mail.gmail.com>
<CANEZrP3ri6QDqomWKMnLqj_ZJxVDOY4QRvWa=L4RzdKFzz+WsQ@mail.gmail.com>
<5500D4C3.4090207@niftybox.net>
<CAAS2fgRVNAPRO5F7yzAv8g-yehgEJ8VoFXapxWmHqnN9-wdq=A@mail.gmail.com>
<5500FCDA.8050407@niftybox.net>
Date: Thu, 12 Mar 2015 04:09:44 +0000
Message-ID: <CAAS2fgSesKYwn1B=o1uxXG7hkGKF8f5e0jZ1eRWQpMSkMBp1EA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: devrandom <c1.sf-bitcoin@niftybox.net>
Content-Type: text/plain; charset=UTF-8
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
(gmaxwell[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
X-Headers-End: 1YVuRS-0001ps-4q
Cc: Bitcoin Dev <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 04:09:51 -0000
On Thu, Mar 12, 2015 at 2:41 AM, devrandom <c1.sf-bitcoin@niftybox.net> wrote:
> I think there are some important advantages to not being forced to use
> the old wallet to send coins when switching wallets. The three I can
> think of right now are: maintaining transaction history,
Just loading a key doesn't keep transaction history however, if the
loading wallet can't understand or infer metadata about the
transactions. You get some mass of data but to tell actually what the
transactions are, or what they were for, forensic accounting is
required and some data will be potentially unrecoverable.
The best way to preserve historical information is to use reporting
from the wallet in question; which will accurately record the best
available output for this. (E.g. Bitcoin-qt has a CSV export or you
can take a json list-transactions out of it).
> emergency transition when a wallet has a serious (e.g. money losing) bug
This cuts both ways, we've seen significant losses for users in
Bitcoin Core where they've used the console to import keys that they
also used in other insecure clients.
For an emergency transition the user is probably better off with an
explicit unstructured mass private key export, and a sweep function;
and guaranteeing compatibility with that is much easier; and because
it moves funds in one direction there is much less chance of going
from secure to insecure.
> and web
> wallet with server down.
I suppose it would be too much to ask that these web wallets actually
not be totally centrally controlled and have the potential of just
having someone else stand up a server. I guess not. :(
Emergencies being what the are you do with what you can... indeed, I
agree thats a reason that better compatibility is better. (But perhaps
best is that its insane to use software to handle your money that can
just be taken away from you like that...)
> Another important reason to standardize is to reduce the "roll your own
> crypto" temptation on the wallet creator part, where the wallet-specific
> algorithm is more likely to contain weaknesses.
> I do agree that trying to come up with one uber standard will likely
> fail and is probably counter productive.
Careful with this line of thinking: We have no mechanism in the BIP
process to exclude weak cryptography.
A BIP is not a measure of cryptographic integrity. There are existing
BIPs which I consider flawed and would not use or recommend.
It result in some level of review, maybe, and so it can be productive
to at least have more eyes on fewer things; which is a reason I
wouldn't say don't bother trying.
And indeed, I do think that what can be standardized should be, my
words weren't intended to dismiss anyone's efforts, only to encourage
realistic (I think) expectations around what will come of it.
And while I hope for no gratuitous incompatibility, I also hope that
no one working on a wallet hesitates for a minute to offer a new and
interesting functionality just because it doesn't fit into a prefab
shape.
|
