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; 
Message-ID: <5500F965.1010604@niftybox.net>
Date: Wed, 11 Mar 2015 19:26:45 -0700
From: devrandom <c1.sf-bitcoin@niftybox.net>
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 <harro84@yahoo.com.au>
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
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
Precedence: list

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