path: root/53/695ab1bb3268f2df98a63ce455f329eb9c00bb

Return-Path: <gcbd-bitcoin-development-2@m.gmane.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8D2AF308
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Aug 2016 14:02:31 +0000 (UTC)
X-Greylist: delayed 00:15:04 by SQLgrey-1.7.6
Received: from blaine.gmane.org (unknown [195.159.176.226])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4250CFD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Aug 2016 14:02:27 +0000 (UTC)
Received: from list by blaine.gmane.org with local (Exim 4.84_2)
	(envelope-from <gcbd-bitcoin-development-2@m.gmane.org>)
	id 1bcYWR-0008El-4P for bitcoin-dev@lists.linuxfoundation.org;
	Wed, 24 Aug 2016 15:47:15 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-dev@lists.linuxfoundation.org
From: Andreas Schildbach <andreas@schildbach.de>
Date: Wed, 24 Aug 2016 15:47:08 +0200
Message-ID: <npk8gr$shs$1@blaine.gmane.org>
References: <201608232012.12588.luke@dashjr.org>
	<90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@blaine.gmane.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
	Thunderbird/45.2.0
In-Reply-To: <90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL,
	RDNS_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP Status updates (including to Active/Final
 Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2016 14:02:31 -0000

FWIW, BIP44 also doesn't encode a seed birthday. This needed so that SPV
wallets do not need to scan from the beginning of the blockchain.

That doesn't mean BIP44 could not be final. There are some wallets that
interoperate on that standard and that's fine. The whole reason I
insisted on separating BIP43 from BIP44 is that someone else can come up
with a better "BIP44+" standard and not get into the way of existing
standards. I think BIP43 should be made final as well, if it isn't already.


On 08/24/2016 02:51 PM, Thomas Voegtlin via bitcoin-dev wrote:
> Le 23/08/2016 à 22:12, Luke Dashjr via bitcoin-dev a écrit :
>> BIP 39: Mnemonic code for generating deterministic keys
>> - Used by many wallets and hundreds of thousands of users.
>>
>> BIP 44: Multi-Account Hierarchy for Deterministic Wallets
>> - Appears to be implemented by multiple wallets.
>>
> 
> I personally believe that BIP39/BIP44 is a bad design. There is limited
> support for these BIPs in Electrum, in order to provide compatibility
> with hardware wallets. However, I do not plan to use BIP39/BIP44 for
> default Electrum wallets, for the following reasons.
> 
> (Note that it does not make sense to consider BIP39 and BIP44
> independently. Any wallet that decides to implement one without the
> other would be considered as broken.)
> 
> Here is why I rejected this design:
> 
> 1 - BIP44 uses multiple accounts. This means that in order to be
> compatible with the standard, a wallet *must* implement multiple
> accounts. A wallet that decides to keep things simple and use only one
> account, will not allow users to recover all their funds when they
> restore from a BIP39 seed, and will be considered as broken.
> 
> 2 - An appealing feature of deterministic wallets is that you can use
> the same instance of your wallet on different devices. Two instances of
> your wallet can automatically synchronize their Bitcoin addresses, and
> display the same balance. The problem is that hardened derivations break
> this property. Indeed, with hardened derivations, software wallets need
> to ask the user's password in order to derive new accounts. Therefore,
> in order to implement automated detection of newly created accounts, a
> BIP44-compatible software wallets would need to ask the user's password
> whenever a new account is detected. This means that the wallet would ask
> the password without the user initiating any action. This seems to be an
> avenue for malware.
> 
> Of course, hardware wallets do not have that issue, because they can
> derive new accounts without requesting a password from the user. BIP44
> is a standard that has been designed for hardware wallets, but that
> makes things really difficult for software wallets.
> 
> 3 - Unneeded complexity. From an end user perspective, the multiple
> accounts in BIP44 achieve the same result as using different derivation
> passphrases with the same BIP39 seed phrase. The only real difference is
> that BIP44 accounts can be enumerated deterministically, while
> passphrases in general cannot. However, this property is of limited
> interest, because automatic synchronization of multiple accounts cannot
> be guaranteed for bip44 software wallets, as explained in 2.
> 
> 4 - BIP39 is inconsistent. It uses a hash of the utf8 encoded 'seed
> phrase' in order to derive the BIP32 seed. This hash-based derivation
> was added on my suggestion, in order to make the BIP independent from
> the particular wordlist used to generate the seed phrases. However,
> BIP39 also requires the implementation of a checksum, in order to verify
> that a seed phrase is valid. Suprisingly, the specification of the
> checksum involves wordlist indices. This means the checksum (and thus
> the BIP) requires a fixed wordlist. This defeats the purpose of using a
> hash for the derivation of the seed.
> 
> The authors of the BIP should either have used hash functions for both
> the seed AND the checksum (that is what Electrum does), or for none of
> them (in that case case, you can have a bidirectional function between
> seed phrases and entropy, which is nice if you want to perform Shamir
> secret sharing of seed phrases, at the expenses of a fixed wordlist). In
> its current state, BIP39 takes the worst of both worlds.
> 
> 5 - The fact that the wordlist must be part of BIP39, and cannot be
> changed in the future, seems a terrible idea to me. I believe that a
> specification should always try to be minimal. In that case, the
> specification includes a 2000+ words dictionary, when it could have
> avoided that.
> 
> Even if you decide that BIP39 is final, there will always be users
> requiring the addition of wordlists for new languages. So, in practice,
> this BIP will never be final.
> 
> 6 - Finally, and most importantly, BIP39 seed phrases do not have a
> version number. Without a version number, how are you going to derive
> addresses from a BIP39 seed phrase, when wallets start to use to new
> derivation methods (such as SegWit, or Schnorr signatures)? Does it mean
> that a BIP39 compatible wallet will have to check addresses from all the
> derivation methods that ever existed in the past, in order to ensure
> that all coins are correctly retrieved? Or will there be users that
> cannot access their coins because their BIP39 seed phrase is too old for
> newer software?
> 
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>