Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id B5908C0037 for ; Sat, 13 Jan 2024 14:12:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 8AC0283F55 for ; Sat, 13 Jan 2024 14:12:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8AC0283F55 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=satoshilabs.com header.i=@satoshilabs.com header.a=rsa-sha256 header.s=google header.b=L2LtdScW X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdfdPV3r8mI7 for ; Sat, 13 Jan 2024 14:12:25 +0000 (UTC) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by smtp1.osuosl.org (Postfix) with ESMTPS id 9BB1E83F50 for ; Sat, 13 Jan 2024 14:12:24 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9BB1E83F50 Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-40e7065b692so1048915e9.3 for ; Sat, 13 Jan 2024 06:12:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=satoshilabs.com; s=google; t=1705155142; x=1705759942; darn=lists.linuxfoundation.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=FB+F5aUkuPN8fbVEeeg2aabjg8fMl+1q0VqLOd7muBg=; b=L2LtdScWKhaxWhlIFntrEomjkV3CfwO21bPs0HTqoJOQDFEieItLMgAL6ex5ZcUuSy 2NpxPa3Sd9Fu+Ms7pBXRVK2aZjascqy6YYyI6KL4IQKp6YnV3/q7vP0JKNalsTh7a0kR koP1uOIpMTZnJ1tH6hcPcKwUg7OPfWdwZFl+ypEug3e3O+UXMXpF6/3HLvOF7OkMDU4p OvDgMa1EoP2LTh61otOqVKD+zPI8YDr8/8TRmJgrP6w8Uhe4K8vC3JvRResQUqqabyve qw8mKkKCTGMFEfeugHXMYctZA64VQnqW3kP8w8HnNHYY/+EQbwMleWXaQF6OSm90oWsG omXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705155142; x=1705759942; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FB+F5aUkuPN8fbVEeeg2aabjg8fMl+1q0VqLOd7muBg=; b=WwtxhRiBOmfBI/+QIsilANn2lpt1uSHh04AYQN/Lo+cHh+VtE7Yl4DGJ7KNwk8DTG5 STFp7eG4z0N2r9gnZM7x45bLH7ik+mL+Uh+Uj1vfaTpzcYOVRxawmfUgI/75o/Wu+a2P NQ/SzK0RxAr5rF9UVIIFOR3nSo07sCYKPFxgxIujxFs5DgDC9uuGGCox8pzLJHv6g0oE pSkiWhWLyGrwwOc0pVHV4l0IMDlJgfMwbvsQHPvX7EwgX1anB2w1g3SUr5tmH6kesdsS 2KzrZd2Dk/opweBUWsD1iYwI4P/7UmitacLQ2rwh9MlJaETHyjn0wHaoylXpJjfLavZj dKeg== X-Gm-Message-State: AOJu0YyrsahHi1jJ1VK6hRVsUW154P7yrMfxj3Y2nhnznJPu8l5SOvNd roroVufv2U40FPIEJeleNx3D7hOaOLfj1+/18G6UqXc72W3+TWXfxH0NzLrRdto= X-Google-Smtp-Source: AGHT+IE1/DpxEmLXZwE0Z/V4O8/qgs+vm9hHAUH9oNat6+8LTy99e/cDGTjJcdRszZQYACSroU2RlBUzH/8VKQ/txm4= X-Received: by 2002:a05:600c:1f95:b0:40e:6207:2ecf with SMTP id je21-20020a05600c1f9500b0040e62072ecfmr1585546wmb.10.1705155142245; Sat, 13 Jan 2024 06:12:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pavol Rusnak Date: Sat, 13 Jan 2024 09:12:10 -0500 Message-ID: To: Bitcoin Protocol Discussion , Leslie <0300dbdd1b@protonmail.com> Content-Type: multipart/alternative; boundary="0000000000008a7b4d060ed45ea6" Subject: Re: [bitcoin-dev] Introducing a version field to BIP39 mnemonic phrases X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2024 14:12:26 -0000 --0000000000008a7b4d060ed45ea6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Leslie, hi list! BIP39 author here. Not having version was a design decision, not accidental omission. When designing BIP39 we were striving for maximum interoperability. There are thousands of BIP39 applications and all of them have 100% interoperable way how to share entropy using a single seed. If there was a version field involved in BIP39 allowing different key stretching methods, all these implementations would choose to implement only different subsets which would lead to interoperability disaster. To give some examples of what I mean: - there is no way hardware wallets would be able to keystretch using Argon2 or other methods that require lot of memory and/or CPU bandwidth - having version paves the way to proprietary key stretching algorithms BIP39 is the universal base layer for sharing entropy. Everything else is delegated to upper layers. Adding version that encodes derivation paths is making the scheme less future proof, not more future proof. Imagine you created the seed in 2014 that includes version that prescribes using BIP44 as a derivation path. Now everytime there is a new standard (Segwit, Compat Segwit, Taproot, etc.). You need to generate (and backup!) the new seed. What if you want to use the seed for Nostr? Lightning? Cashu? Ark? User would be forced to backup multiple seeds for every single application, leading to sloppy backups. With BIP39 you can just use the single seed for everything. =E2=80=94 Best Regards / S pozdravom, Pavol "Stick" Rusnak Co-Founder, SatoshiLabs On Thu 11. 1. 2024 at 6:17, Leslie via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 
>   BIP:
>   Layer: Applications
>   Title: Versioned BIP39 Mnemonic Phrases
>   Author: Leslie <0300dbdd1b@protonmail.com>
>   Status: None
>   Type: Standards Track
>   Created: 2024-01-10
>
> > ## Abstract > > This BIP proposes an enhancement to the BIP39 mnemonic phrases by > introducing a version field. > The version field will be a 32-bit field, prepended to the entropy of the > BIP39 mnemonic phrase. > The first 24 bits are for general purposes, and the subsequent 8 bits are > for defining the version used. > > ## Motivation > The current implementation of BIP39 mnemonic phrases lacks a crucial > feature: versioning. > This omission has been identified as a significant design flaw, affecting > the robustness and future-proofness of the mnemonic phrase generation and > usage. > Notable community members and projects have expressed concerns over this > shortcoming: > > >The lack of versioning is a serious design flaw in this proposal. On thi= s > basis alone I would recommend against use of this proposal. > > \- [Greg Maxwell 2017-03-14]( > https://github.com/bitcoin/bips/wiki/Comments:BIP-0039/fd2ddb6d840c6a91c9= 8a29146b9a62d6a65d03bf > ) > > > Furthermore, the absence of a version number in BIP39 seed phrases poses > risks and inefficiencies in wallet software development and backward > compatibility: > > >BIP39 seed phrases do not include a version number. This means that > software should always know how to generate keys and addresses. BIP43 > suggests that wallet software will try various existing derivation scheme= s > within the BIP32 framework. This is extremely inefficient and rests on th= e > assumption that future wallets will support all previously accepted > derivation methods. If, in the future, a wallet developer decides not to > implement a particular derivation method because it is deprecated, then t= he > software will not be able to detect that the corresponding seed phrases a= re > not supported, and it will return an empty wallet instead. This threatens > users funds. > > > >For these reasons, Electrum does not generate BIP39 seeds. > > \- [Electrum Documentation 2017-01-27]( > https://electrum.readthedocs.io/en/latest/seedphrase.html#motivation) > > The proposed BIP aims to address these concerns by introducing a version > field in the BIP39 mnemonic phrases. > The introduction of versioning is expected to enhance the mnemonic's > adaptability to future changes, improve the efficiency of wallet software > in handling different derivation methods, and secure users funds by > reducing the risk of incompatibilities between mnemonic phrases and walle= t > implementations. > > ## Generating the Mnemonic > > In this proposal, we build upon the structure of BIP39 to include a > versioned enhancement in the mnemonic generation process. The mnemonic > encodes entropy, as in BIP39, but with a flexible approach to the size of > the initial entropy (ENT). > > ### Version Field Inclusion: > > 1. **Initial Entropy Generation:** > The initial entropy of ENT bits is generated, where ENT can be any siz= e > as long as it is a multiple of 32 bits. > > 2. **Version Field Prepending:** > A crucial addition to this process is the prepending of a 32-bit > version field to the initial entropy. This field is composed of: > - The first 24 bits are reserved for general purposes, which can be > utilized for various enhancements or specific wallet functionalities. > - The remaining 8 bits are designated for specifying the version of th= e > BIP39 standard. > > 3. **Checksum Calculation:** > A checksum is generated following the BIP39 method: taking the first > (ENT + VF ) / 32 bits of the SHA256 hash of the combined entropy (initial > entropy plus the 32-bit version field). This checksum is then appended to > the combined entropy. > > 4. **Concatenation and Splitting:** > The combined entropy, including the initial entropy, version field, an= d > checksum, is split into groups of 11 bits. Each group of bits corresponds > to an index in the BIP39 wordlist. > > 5. **Mnemonic Sentence Formation:** > The mnemonic sentence is formed by converting these 11-bit groups into > words using the standard BIP39 wordlist. > > > ## Compatibility Considerations > > - **Backward Compatibility:** Systems designed for BIP39, unaware of the > 32-bit extension, will interpret the mnemonic as a 'Legacy' BIP39 phrase. > - **Forward Compatibility:** The versioning mechanism prepares systems fo= r > future modifications to the BIP39 standard, facilitating seamless > integration. > > ## Dictionary Dependency > > Wallets will still require access to the predefined BIP39 dictionary to > retrieve the version of the mnemonic seed and validate the checksum. > > > =F0=9F=92=A1 It's noteworthy that the BIP39 English wordlist includes s= pecific > words that software can use to identify the mnemonic's version number in = a > user-friendly manner, reducing dependence on the wordlist for version > recognition. > > > > One way to achieve this is by assigning the first 22 > > bits of the reserved field to match these words. > > > > 11110010110 11111111101 : version zero > > 11110010110 10011010101 : version one > > 11110010110 11101011101 : version two > > 11110010110 11100001000 : version three > > ... > > 11110010110 01101111001 : version hundred > > > ## Changing Derivation Methods > > The introduction of mnemonic versioning provides the flexibility to adopt > alternative entropy derivation methods in the future. While BIP39 current= ly > uses PBKDF2 for key stretching, future versions could employ different > mechanisms to meet evolving cryptographic standards and requirements. > > > =F0=9F=92=A1 Changing the derivation method in versioned mnemonics coul= d lead to > compatibility issues with older software. > > ## References > 1. [Bitcoin Improvement Proposals. BIP39: Mnemonic code for generating > deterministic keys]( > https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) > 2. [bip39-versioned](https://github.com/lukechilds/bip39-versioned) > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000008a7b4d060ed45ea6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Leslie, hi list!

BIP39 author here. Not having version was a design decision, = not accidental omission.

When designing BIP39 we were striving for maximum interoperability. There = are thousands of BIP39 applications and all of them have 100% interoperable= way how to share entropy using a single seed.

<= /div>
If there was a version field involved in BIP39 allow= ing different key stretching methods, all these implementations would choos= e to implement only different subsets which would lead to interoperability = disaster.

To give some e= xamples of what I mean:
- there is no way hardware w= allets would be able to keystretch using Argon2 or other methods that requi= re lot of memory and/or CPU bandwidth
- having version paves the way to proprietary key stre= tching algorithms

BIP39 is the univ= ersal base layer for sharing entropy. Everything else is delegated to upper= layers.

Adding version = that encodes derivation paths is making the scheme less future proof, not m= ore future proof.

Imagin= e you created the seed in 2014 that includes version that prescribes using = BIP44 as a derivation path. Now everytime there is a new standard (Segwit, = Compat Segwit, Taproot, etc.). You need to generate (and backup!) the new s= eed.

What if you want to= use the seed for Nostr? Lightning? Cashu? Ark? User would be forced to bac= kup multiple seeds for every single application, leading to sloppy backups.=

With BIP39 you can just= use the single seed for everything.


=E2=80=94

Best Regards / S pozdravom,

Pavol "Stick&quo= t; Rusnak
Co-Founder, SatoshiLabs


On Thu 11. 1. 2024 at 6:17, Leslie via bitcoin-dev = <bitcoin-dev@li= sts.linuxfoundation.org> wrote:
<= pre>
=C2=A0 BIP:=C2=A0
=C2=A0 La= yer: Applications
=C2=A0 Title: Versioned BIP39 Mnem= onic Phrases
=C2=A0 Author: Leslie <0300dbdd1b@protonmail.com>
=C2=A0= Status: None
=C2=A0 Type: Standards Track
=C2=A0 Created: 2024-01-10
</pre>= ;

## Abstract

This BIP proposes an enhancement to the BIP39 mnemonic phras= es by introducing a version field.
The version field= will be a 32-bit field, prepended to the entropy of the BIP39 mnemonic phr= ase.
The first 24 bits are for general purposes, and= the subsequent 8 bits are for defining the version used.
=
## Motivation
The current imple= mentation of BIP39 mnemonic phrases lacks a crucial feature: versioning.
This omission has been identified as a significant des= ign flaw, affecting the robustness and future-proofness of the mnemonic phr= ase generation and usage.
Notable community members = and projects have expressed concerns over this shortcoming:

>The lack of versioning is a serious design flaw = in this proposal. On this basis alone I would recommend against use of this= proposal.


<= br>
Furthermore, the absence of a version number in BIP39 s= eed phrases poses risks and inefficiencies in wallet software development a= nd backward compatibility:

>BIP39 = seed phrases do not include a version number. This means that software shou= ld always know how to generate keys and addresses. BIP43 suggests that wall= et software will try various existing derivation schemes within the BIP32 f= ramework. This is extremely inefficient and rests on the assumption that fu= ture wallets will support all previously accepted derivation methods. If, i= n the future, a wallet developer decides not to implement a particular deri= vation method because it is deprecated, then the software will not be able = to detect that the corresponding seed phrases are not supported, and it wil= l return an empty wallet instead. This threatens users funds.
<= div>>
>For these reasons, Electrum does = not generate BIP39 seeds.


The proposed BIP aims to= address these concerns by introducing a version field in the BIP39 mnemoni= c phrases.
The introduction of versioning is expect= ed to enhance the mnemonic's adaptability to future changes, improve th= e efficiency of wallet software in handling different derivation methods, a= nd secure users funds by reducing the risk of incompatibilities between mne= monic phrases and wallet implementations.

<= span>## Generating the Mnemonic

In th= is proposal, we build upon the structure of BIP39 to include a versioned en= hancement in the mnemonic generation process. The mnemonic encodes entropy,= as in BIP39, but with a flexible approach to the size of the initial entro= py (ENT).

### Version Field Inclusio= n:

1. **Initial Entropy Generation:**=
=C2=A0 =C2=A0The initial entropy of ENT bits is gen= erated, where ENT can be any size as long as it is a multiple of 32 bits. <= /span>

2. **Version Field Prepending:**
=C2=A0 =C2=A0A crucial addition to this process is the p= repending of a 32-bit version field to the initial entropy. This field is c= omposed of:
=C2=A0 =C2=A0- The first 24 bits are res= erved for general purposes, which can be utilized for various enhancements = or specific wallet functionalities.
=C2=A0 =C2=A0- T= he remaining 8 bits are designated for specifying the version of the BIP39 = standard.

3. **Checksum Calculation:*= *
=C2=A0 =C2=A0A checksum is generated following the= BIP39 method: taking the first (ENT + VF ) / 32 bits of the SHA256 hash of= the combined entropy (initial entropy plus the 32-bit version field). This= checksum is then appended to the combined entropy.

4. **Concatenation and Splitting:**
= =C2=A0 =C2=A0The combined entropy, including the initial entropy, version f= ield, and checksum, is split into groups of 11 bits. Each group of bits cor= responds to an index in the BIP39 wordlist.

5. **Mnemonic Sentence Formation:**
=C2=A0 = =C2=A0The mnemonic sentence is formed by converting these 11-bit groups int= o words using the standard BIP39 wordlist.

=
## Compatibility Considerations

<= /div>
- **Backward Compatibility:** Systems designed for BIP39, u= naware of the 32-bit extension, will interpret the mnemonic as a 'Legac= y' BIP39 phrase.
- **Forward Compatibility:** Th= e versioning mechanism prepares systems for future modifications to the BIP= 39 standard, facilitating seamless integration.

=
## Dictionary Dependency

W= allets will still require access to the predefined BIP39 dictionary to retr= ieve the version of the mnemonic seed and validate the checksum.

> =F0=9F=92=A1 It's noteworthy that the = BIP39 English wordlist includes specific words that software can use to ide= ntify the mnemonic's version number in a user-friendly manner, reducing= dependence on the wordlist for version recognition.
>
> One way to achieve this is by assigning = the first 22
> bits of the reserved field to matc= h these words.
>
> =C2= =A0 =C2=A0 11110010110 11111111101 : version zero
&g= t; =C2=A0 =C2=A0 11110010110 10011010101 : version one
> =C2=A0 =C2=A0 11110010110 11101011101 : version two
> =C2=A0 =C2=A0 11110010110 11100001000 : version three
> =C2=A0 =C2=A0 ...
> =C2=A0 = =C2=A0 11110010110 01101111001 : version hundred


## Changing Derivation Methods
=
The introduction of mnemonic versioning provides the f= lexibility to adopt alternative entropy derivation methods in the future. W= hile BIP39 currently uses PBKDF2 for key stretching, future versions could = employ different mechanisms to meet evolving cryptographic standards and re= quirements.

> =F0=9F=92=A1 Changin= g the derivation method in versioned mnemonics could lead to compatibility = issues with older software.

## Refere= nces
1. [Bitcoin Improvement Proposals. BIP39: Mnemo= nic code for generating deterministic keys](https://github.com/bitcoin/bips/blob/master/bip-003= 9.mediawiki)
2. [bip39-versioned](https://github.com/lukechilds/bip39-versioned)_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000008a7b4d060ed45ea6--