BIP39 Extension for Manual Seed Phrase Creation

[Eric Kvam]

Motivation

Make it easy for users to manually create their seed phrase so that they don't have to trust a "black box" and allow for encoding derivation path in seed phrase to simplify recovery

How

Use every eighth word from the wordlist to generate 16 word phrases with 128 bits of entropy (no checksum).  The most significant eight bits of each word are used as entropy.  The least significant three bits of each word specify the derivation path.

• 000 Derivation Path Not Specified
• 001 m/44'/0'/0'
• 010 m/49'/0'/0'
• 011 m/84'/0'/0'
• 100 m/48'/0'/0'/2'
• 101 m/86'/0'/0'

Up to seven derivation paths can be specified if all words have the same least significant bits.  If the least significant bits of each word vary, there are 48 bits that can be used to encode meta-data.  As long as meta-data is limited to certain allowable values, this provides a mechanism for error detection, similar to a checksum.

Benefits of Suggested Implementation

• The word length determines how the seed phrase should be interpreted.  User only needs to know how many words they have and how many words the wallet supports to check for compatibility with this extension
• Uses same wordlist to represent the same entropy as a 12 word phrase (could be a revision to BIP39 instead of a new BIP)
• Manual procedure is very simple, each derivation path can use a shortened 256 word list which enjoys improved alphabetical separation of words
• May prevent naive word selections which aren't limited to every eighth word (similar to what checksum does)
• Can be extended further.  For example, a 32 word phrase with the same entropy as a 24 word phrase could also be added.  We can keep adding formats with unique word length and keep adding uses for the meta data as needed.

[Kyle Honeycutt]

Respectfully, a "black box" is not trusted to generate mnemonic passphrases, the standard is well-defined and generally followed across wallets.

https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#Generating_the_mnemonic

Users can create their own mnemonics in a trustless way following the BIP39 standard published in 2013. 

Using any entropy source a user can perform a SHA256 hash on the entropy to get a 256 bit string, then convert that to binary. Perform another SHA256 hash on the binary, take the first 8 bits and solve for checksum and then solve the rest of mnemonic words.

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a139ee2e-473c-487b-a9b0-e68013fdb7cen%40googlegroups.com.

[Eric]

Quoting BIP39: "This guide is meant to be a way to transport computer-generated randomness with a human-readable transcription."

BIP39 was meant to capture computer generated randomness.  Manually calculating the sha256 hash is not practical.

Using a separate tool to compute the checksum or last word is cumbersome and requires users to have a more advanced understanding of cryptography.

[Russell O'Connor]

FWIW, BIP-93 (codex32) was designed for both human and computer generated randomness.  Codex32 also supports human and computer generated secret sharing.

See also <https://secretcodex32.com/>.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/09A940A2-122A-445E-82EA-1B4E32AC7E34%40gmail.com.

[Eric Kvam]

I dug up some past arguments regarding the BIP39 checksum.  Hopefully my proposal to import manually generated entropy with a 16 word seed phrase avoids controversy because it doesn't conflict with the existing 12/15/18/21/24 word seed phrase formats that are meant for transcribing computer generated entropy.  

• https://www.reddit.com/r/TREZOR/comments/1d47lxg/bip39_checksum_is_a_misfeature_trezor_should/
• https://www.reddit.com/r/Bitcoin/comments/k761mf/fck_the_mnemonic_sentence_checksum/
• https://bitcoin.stackexchange.com/questions/100376/should-the-bip-39-mnemonic-sentence-checksum-be-eliminated-from-the-standard-do
• https://www.reddit.com/r/Bitcoin/comments/wh0s11/bip39_whats_the_benefit_of_the_checksum_word/

Using BIP39 to import manually generated entropy into a computer is a work-around that has become a de-facto standard.  Some others, like me, have found that the checksum does more harm than good when importing manually generated entropy.  I can see that the checksum is quite helpful when transcribing seed phrases between two computing devices.  In lieu of a checksum, users transcribing their 16 word phrase could: select their input from the full 2048 word list, select their input from 256 words but do it twice, check the xpub derived from their seed phrase input.  Initial confirmation of the xpub is critical to ensure that a compromised computing device can not cause users to send funds to an address they don't control.  Users might store the 16 word phrase, or discard it once they have confirmed their xpub in favor of a format that is better for transcription (12 word phrase or seedQR).  

When I am onboarding no-coiners, getting them to create their seed phrase has been a stumbling block.  Any friction during onboarding reduces the conversion rate.  Most people will not bother to learn what a hash is but already understand randomness from games like poker and understand the need to keep their passphrase secret.  Just as BIP39 helped enable the proliferation of devices like Trezor/Ledger, a standardized format for import of manually generated entropy enables cheap and simple paper products to help users create their seed phrase.  A printout of the wordlist with paper masks that each cover half of the words would make it easy for users to perform a binary search.  The user could simply set a mask on top of the wordlist as odd or even based on the totals of dice rolls until only one word is showing.  Such a product can be bundled with steel plates for recording and storing the phrase.  Instead of the user having to learn about binary numbers, hashes, and checksums, no numbers are required at all.  The secure computing device and its ops can also be simplified (only needs to accept seedphrase, display xpub, scan unsigned TX, and display signed TX).

[pithosian]

BIP39 works fine with entropy generated without a computer. I
personally recommend using coinflips with Von Neumann skew correction.

Yes, you need to perform a SHA256 hash to calculate the checksum word.

You need to use SHA512 HMAC as the next step, and EC point
multiplication along with a host of other steps which are unrealistic
to expect a human to perform by hand to actually get child keys and
addresses out the other end, too.

I have a bootable UEFI application for generating a mnemonic with
skew-corrected coinflips (among other things), designed for airgapped
operation, lying around in my archive somewhere. I plan on
re-implementing it as part of a much larger, long-running project but
if there's interest I can go find it, clean it up and publish the
old version in the meantime.

The spec doesn't need to change; there's really no benefit to
generating a mnemonic without the SHA256 hash step, because again, you
can't do anything with that mnemonic without hashing.

As for encoding derivation paths in the mnemonic, Electrum's Seed
Version System achieves roughly the same thing, but descriptors are a
better solution for managing non-entropy metadata for wallets.

For those who really don't want to put in the small amount of additional
effort required to use descriptors, replying on the standard derivation
paths is sufficient, as long as they're made aware of their existence.
Educating your users is a better solution than attempting to abstract
away (aka hide) critical information from them.

On Fri, 23 May 2025 13:15:41 +0000 (UTC)
Eric Kvam <nerdyr...@gmail.com> wrote:

> *Motivation*

> Make it easy for users to manually create their seed phrase so that
> they don't have to trust a "black box" and allow for encoding
> derivation path in seed phrase to simplify recovery
>

> *How*

> Use every eighth word from the wordlist to generate 16 word phrases
> with 128 bits of entropy (no checksum). The most significant eight
> bits of each word are used as entropy. The least significant three
> bits of each word specify the derivation path.
>

> - *000* Derivation Path Not Specified
> - *001* m/44'/0'/0'
> - *010* m/49'/0'/0'
> - *011* m/84'/0'/0'
> - *100* m/48'/0'/0'/2'
> - *101* m/86'/0'/0'

>
> Up to seven derivation paths can be specified if all words have the
> same least significant bits. If the least significant bits of each
> word vary, there are 48 bits that can be used to encode meta-data.
> As long as meta-data is limited to certain allowable values, this
> provides a mechanism for error detection, similar to a checksum.
>

> *Benefits of Suggested Implementation*
>
> - The word length determines how the seed phrase should be

> interpreted. User only needs to know how many words they have and how
> many words the wallet supports to check for compatibility with this
> extension

> - Uses same wordlist to represent the same entropy as a 12 word

> phrase (could be a revision to BIP39 instead of a new BIP)

> - Manual procedure is very simple, each derivation path can use a

> shortened 256 word list which enjoys improved alphabetical
> separation of words

> - May prevent naive word selections which aren't limited to every

> eighth word (similar to what checksum does)

> - Can be extended further. For example, a 32 word phrase with the

[nerdyrugbyguy]

Greetings Pithosian,

Thank you (and everyone) for taking time to consider my suggestions.

I flipped coins to create my seed phrase ten years ago.  I founded a bitcoin club, created printed guides, and taught the procedure to others.  Even out of a group of people with engineering degrees, it was too much.  Many people have limited math ability and most will never learn binary math or checksums.  Unfortunately bitcoin "self custody" is typically based on trusting a black box.  The question is really whether bitcoin is for elites or plebs.

The UEFI application you're suggesting sounds like it might be similar to other existing tools that receive entropy input and output a seed phrase or last word.  What format should be used for the entropy input? Typically hex or binary is used because we lack a standard format (encoding entropy with words would be less error prone).  To be trustless and do what you suggest, it seems users would have to record their entropy in a non-standard format, obtain two independent tools, perform a non-standard import of their entropy into the first tool, record the seed phrase output, perform a non-standard import of their entropy into the second tool, then confirm that the output of the second tool matches. While not requiring the user to know binary math, this is too much for most users and is error prone.

I agree that the spec doesn't need to change, it's not broken and is well suited for its intended purpose.  I'm proposing an extension.

Here are the current options I'm aware of for seed generation:

#1 Use a "white box" tool (only an option for devs that can verify source and build their own tools)

#2 Trust a "black box" tool

#3 Non-standard entropy import into two independent "black box" tools and cross-check results

#4 Use binary math to determine initial words and most significant bits of last word.  Obtain least significant bits of last word by guessing or computing sha256 hash.

A standard for encoding entropy would make #3 easier (useful for things like seedQR) and enable #5:

#5 Record entropy in a standard format

As far as encoding derivation paths, I was trying to think of something useful that could be done with the extra bits being encoded.  I would defer this discussion for now and just ask for consideration of the case where derivation path is not specified.

Regards,

-Eric

[pithosian]

I'm not totally against thinking about different ways to (effectively)
represent the data you'd use a descriptor for for simple use-cases,
just not personally convinced on the utility of a purely
hand-calculated mnemonic given the requirement of running (off the top
of my head) SHA512 PBKDF2 for the BIP 32 seed, and a SHA512 HMAC for
going from that to the root priv.

> A standard for encoding entropy

In my view, this is exactly what BIP 39 already is. It's a
specification for encoding Base2048 numbers with a checksum, similar to
Base58. The character set is a list of words, but fundamentally the
only real difference between it, and Base2, Base10, Base16, etc is the
checksum.

The UEFI tool is an interactive TUI. You don't (necessarily) input
entropy you already generated elsewhere, you choose whether to use
skew-corrected coinflips, or raw coinflips, dice rolls etc, input how
many bits of entropy you want, then it asks you to input
coinflips/dicerolls one by one, displaying the entropy you're building
as you go. That entropy can then be used in various ways, including
creating a BIP 39 mnemonic. I had CKD implemented too, as well as a
bunch of simple more general 'security' standalone tools, but if I
throw together a release from the old code to just make something
available quickly, it'll be stripped down and streamlined for this one
use-case, eg:

1. Select desired mnemonic length.
2. Choose whether to use skew correction.
3. Input coinflips; display collected entropy in Base2 (intuitive
for coinflips) as you go so the user can observe the process. Maybe show
the current BIP39 Base2048 encoding of that entropy too.
4. Once the entropy requirement is met, display the entropy, its hash,
the checksummed mnemonic bits, and the actual mnemonic, so the user can
see exactly how it all fits together. They have to trust that the SHA256
implementation is correct, but if it isn't, the mnemonic will fail
checksumming when trying to use it in an actual wallet.

Maybe could have a second 'program' to input a mnemonic, validate it,
see its entropy, and derive the BIP 32 seed and root extended priv,
given SHA512 and PBKDF2 are fairly trivial if you already need a SHA256
implementation.

> *#1* Use a "white box" tool (only an option for devs that can verify

> source and build their own tools)

> *#2* Trust a "black box" tool
> *#3* Non-standard entropy import into two independent "black box"
> tools and cross-check results
> *#4* Use binary math to determine initial words and most significant

> bits of last word. Obtain least significant bits of last word by
> guessing or computing sha256 hash.
>
> A standard for encoding entropy would make #3 easier (useful for
> things like seedQR) and enable #5:

> *#5* Record entropy in a standard format

>
> As far as encoding derivation paths, I was trying to think of
> something useful that could be done with the extra bits being
> encoded. I would defer this discussion for now and just ask for
> consideration of the case where derivation path is not specified.
>
> Regards,
> -Eric
>
> On Sunday, May 25, 2025 at 5:44:44 AM UTC-6 pithosian wrote:
>

[er...@voskuil.org]

> > A standard for encoding entropy
>
> In my view, this is exactly what BIP 39 already is. It's a specification for
> encoding Base2048 numbers with a checksum, similar to Base58. The
> character set is a list of words, but fundamentally the only real difference
> between it, and Base2, Base10, Base16, etc is the checksum.

I'm not following the thread, but I'd like to lend full support to the above statement.

base 2^n, 10, 16, 32, 58, 64, 85, 2048:

https://github.com/libbitcoin/libbitcoin-system/tree/master/src/radix
https://github.com/libbitcoin/libbitcoin-system/tree/master/include/bitcoin/system/impl/radix

specifically base_2048:

https://github.com/libbitcoin/libbitcoin-system/blob/master/src/radix/base_2048.cpp

base_2048 encodings with checksum applied:

https://github.com/libbitcoin/libbitcoin-system/tree/master/src/wallet/mnemonics

specifically bip39:

https://github.com/libbitcoin/libbitcoin-system/blob/master/src/wallet/mnemonics/mnemonic.cpp

best,
e

[Russell O'Connor]

On Wed, Jun 4, 2025 at 3:57 AM pithosian <pith...@i2pmail.org> wrote:

I'm not totally against thinking about different ways to (effectively)
represent the data you'd use a descriptor for for simple use-cases,
just not personally convinced on the utility of a purely
hand-calculated mnemonic given the requirement of running (off the top
of my head) SHA512 PBKDF2 for the BIP 32 seed, and a SHA512 HMAC for
going from that to the root priv.

 

IMHO, the difference is that it is at least possible to cross-check the derivation of pubkeys and addresses from the master seed using hardware from different vendors.  However it isn't really possible to cross-check the quality of the initial random generation.  Some people are going to prefer to generate that randomness by hand in a fully transparent process and not hidden within some computer chip using a noisy transistor or whatever.

Once again, I want to reiterate for this thread that there already exists a BIP for a hand-computable friendly master secret format, which is BIP-93 (codex32).  Yes, hand computing the checksum for BIP-93 is a pain, but unlike BIP-39's checksum, it is actually doable.  And unlike BIP-39's checksum, the checksum for codex32 is actually an error-correcting code, so you can actually repair errors and erasures in the data.  It is even possible to use an untrusted computer to repair your codex32 string so that the computer learns practically zero information about your secret or secret share.