From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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> <550057FD.6030402@electrum.org> <1426100677.1908596.239033309.7C4F8D47@webmail.messagingengine.com> <5500D4C3.4090207@niftybox.net> <5500FCDA.8050407@niftybox.net> Date: Thu, 12 Mar 2015 04:09:44 +0000 Message-ID: From: Gregory Maxwell To: devrandom 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 04:09:51 -0000 On Thu, Mar 12, 2015 at 2:41 AM, devrandom 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.