From: nerdyrugbyguy <nerdyrugbyguy@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] BIP39 Extension for Manual Seed Phrase Creation
Date: Sun, 25 May 2025 07:26:52 -0700 (PDT) [thread overview]
Message-ID: <4c376336-1fe3-4b1c-b13b-8dcc2075e758n@googlegroups.com> (raw)
In-Reply-To: <20250524205608.D723F7C1191@smtp.postman.i2p>
[-- Attachment #1.1: Type: text/plain, Size: 6495 bytes --]
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
On Sunday, May 25, 2025 at 5:44:44 AM UTC-6 pithosian wrote:
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
> 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.
>
--
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+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4c376336-1fe3-4b1c-b13b-8dcc2075e758n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 7764 bytes --]
next prev parent reply other threads:[~2025-05-25 15:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250523131541.1521C7C0DB0@smtp.postman.i2p>
2025-05-24 20:56 ` pithosian
2025-05-25 14:26 ` nerdyrugbyguy [this message]
2025-05-23 11:25 Eric Kvam
2025-05-23 14:29 ` Kyle Honeycutt
[not found] ` <09A940A2-122A-445E-82EA-1B4E32AC7E34@gmail.com>
2025-05-23 20:45 ` 'Russell O'Connor' via Bitcoin Development Mailing List
2025-05-24 12:33 ` Eric Kvam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4c376336-1fe3-4b1c-b13b-8dcc2075e758n@googlegroups.com \
--to=nerdyrugbyguy@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox