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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YVsps-0000aX-Cm for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 02:26:56 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of niftybox.net designates 95.142.167.147 as permitted sender) client-ip=95.142.167.147; envelope-from=c1.sf-bitcoin@niftybox.net; helo=i3.hyper.to; Received: from i3.hyper.to ([95.142.167.147]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YVspq-0007aL-Qf for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 02:26:56 +0000 Received: from localhost (localhost [127.0.0.1]) by i3.hyper.to (Postfix) with ESMTP id 27A00E0030; Thu, 12 Mar 2015 03:26:48 +0100 (CET) Received: from i3.hyper.to ([127.0.0.1]) by localhost (i3.hyper.to [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id slJI1fcx00Bf; Thu, 12 Mar 2015 03:26:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by i3.hyper.to (Postfix) with ESMTP id 942F6E0035; Thu, 12 Mar 2015 03:26:47 +0100 (CET) X-Virus-Scanned: amavisd-new at i3.hyper.to Received: from i3.hyper.to ([127.0.0.1]) by localhost (i3.hyper.to [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id b2LYYyK34U4P; Thu, 12 Mar 2015 03:26:47 +0100 (CET) Received: from [10.1.10.188] (142-254-47-143.dsl.dynamic.sonic.net [142.254.47.143]) by i3.hyper.to (Postfix) with ESMTPSA id D62BCE0030; Thu, 12 Mar 2015 03:26:46 +0100 (CET) Message-ID: <5500F965.1010604@niftybox.net> Date: Wed, 11 Mar 2015 19:26:45 -0700 From: devrandom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Thy Shizzle References: <372541993.4372759.1426123313134.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <372541993.4372759.1426123313134.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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_PASS SPF: sender matches SPF record X-Headers-End: 1YVspq-0007aL-Qf Cc: "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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 02:26:56 -0000 On 2015-03-11 06:21 PM, Thy Shizzle wrote: > Hmmmm I don't think it's fair to say that there has been a failure to > standardise. From what I read earlier among the wallets, mostly it came > down to if a version was noted and the date. Assuming no date is > provided, it just means you are scanning the block chain from day 0 for > transactions right? Hardly a big deal as you will still recover funds right? Unfortunately there's more incompatibility than just the date issue: * seed: some follow BIP39, and some roll their own * HD structure: some follow BIP44, some BIP32 derivation, and some roll their own So actually very few wallets are seed-compatible, even ignoring the date question. > > Version right now is irrelevant as there is only one version of BIP39 > currently, probably this will change as 2048 iterations of HMACSHA512 > will likely need to be up scaled in the future, I thought about adding > one extra word into the mnemonic to signify version, so if you have a 12 > word mnemonic then you have 12 words + 1 word version. Version 1 has no > extra word, version 2 uses the first word on the list, version 3 uses > the second word on the wordlist, so on and so forth. Least that's what I > was thinking of doing if I ever had to record a version, won't effect > anything because entropy increases in blocks of 3 words so one extra > word can simply be thrown on the end. That's a reasonable solution. > > So in summary I feel that date can be handled by assuming day 0, and > version is not an issue yet but may become one and probably it is a good > idea to think about standardising a version into BIP39, I have > provided a seed idea for discussion. > > I don't think it is quite the doom and gloom I'm reading :) > > > devrandom: > "I'd like to offer that the best practice for the shared wallet use case > should be multi-device multi-sig. The mobile has a key, the desktop has > a key and a third-party security oracle has a third key. The oracle > would have different security thresholds for countersigning the mobile. > > This way you can have the same overall wallet on all devices, but > different security profiles on different keys. > > 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." -- devrandom / Miron