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; 
MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
Precedence: list

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.