From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YVqiv-0004cB-OJ for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 00:11:37 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.169 as permitted sender) client-ip=209.85.223.169; envelope-from=gmaxwell@gmail.com; helo=mail-ie0-f169.google.com; Received: from mail-ie0-f169.google.com ([209.85.223.169]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YVqiu-0007W8-Tl for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 00:11:37 +0000 Received: by iegc3 with SMTP id c3so4363596ieg.3 for ; Wed, 11 Mar 2015 17:11:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.43.70.10 with SMTP id ye10mr46162988icb.66.1426119084169; Wed, 11 Mar 2015 17:11:24 -0700 (PDT) Received: by 10.107.6.133 with HTTP; Wed, 11 Mar 2015 17:11:24 -0700 (PDT) In-Reply-To: <5500D4C3.4090207@niftybox.net> References: <54F32EED.6040103@electrum.org> <550057FD.6030402@electrum.org> <1426100677.1908596.239033309.7C4F8D47@webmail.messagingengine.com> <5500D4C3.4090207@niftybox.net> Date: Thu, 12 Mar 2015 00:11:24 +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 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YVqiu-0007W8-Tl 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 00:11:37 -0000 On Wed, Mar 11, 2015 at 11:50 PM, devrandom wrote: > That said, I do agree that mnemonic phrases should be portable, and find > it unfortunate that the ecosystem is failing to standardize on phrase > handling. The fact remains that there are several apparently unresolvable well-principled perspectives on this subject. (And I can speak to this personally: There are several BIPs in this space that I'd rather not see in product with my name on it.) Unless two wallets have exactly the same feature set, cross importing keys is going to confuse or break something. Even if you're trying to be fairly generic the testing overhead for all possible strategies and structures is large. Expecting compatibility here would be like expecting two large commercial accounting packages to support the same internal file formats. Compatibility is only straight forward when the feature set is as limited as possible. The space for weird behavior to harm users is pretty large... e.g. you could load a key into two wallets, such that one can see all the funds by the other, but not vice versa and and up losing funds by incorrectly assuming you had no coins; or inadvertently rip of your business partners by accounting for things incorrectly. Even ignoring compatibility, most demanded use cases here are ones that create concurrent read/write use of single wallet without some coordinating service is inherently somewhat broken because you can double spend yourself, and end up with stalled and stuck transactions and causing people to think you tried ripping them off. I certainly recognize the desirable aspects of just being able to load a common wallet, and that inexperienced users expect it to just work. But I don't think that expectation is currently very realistic except within limited domains. It may be more realistic in the future when the role of wallets is better established. I don't see any _harm_ in trying to standardize what can be, I just don't expect to see a lot of success. Ultimately, the most fundamental compatibility is guaranteed: you can always send your funds to another wallet. This always works and guarantees that you are never locked in to a single wallet. It is well tested and cannot drive any software in to weird or confused states.