From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 25 May 2025 08:12:45 -0700 Received: from mail-yb1-f186.google.com ([209.85.219.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uJD1o-0001Uc-J7 for bitcoindev@gnusha.org; Sun, 25 May 2025 08:12:45 -0700 Received: by mail-yb1-f186.google.com with SMTP id 3f1490d57ef6-e7d92c6ebbesf1536561276.0 for ; Sun, 25 May 2025 08:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1748185959; x=1748790759; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=kN2pXvelNsnelu6cA8GyELSirj9ArkYOYjW7kFWbhE4=; b=GU/lj3oMF6GsOw4uobOeYZ9hIs2F+W4dRfvrG/o07dM1jN+Gtk1mol8Zkc3tBbvnrN 0iAgDz+oFm2Y555V7kDEBYQ9bCfha/FSo8lTvUwVHwl9Cp6LKzwF7u2RynKfk6T2CE+r 2l3ZR5rGXXnhHhu9bfcEDSMZc4GvTi9wBSD2DCBYhTTO6sGIZVFA7XrMUn2oP3Nl+Rqj pexeLJVUAVUwfHi8BMiOGl7tG7+3ODAT1avDcxCNerDv2C+gVhZlADdzysDhqsR7jlkr LCW91xEVrR+PxWxXDGntbD+L+Yow29A2bHTZrFgdFoRNxra4sBP3DnhqFaXEgoC09fUq ONww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748185959; x=1748790759; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=kN2pXvelNsnelu6cA8GyELSirj9ArkYOYjW7kFWbhE4=; b=gun45XhVcULood5+u9KdgnwbqLqeJZiM8/JQXnYix8cYoI0yXd9QfCTizeBkaZzwBQ SHGk5ws6Ccy14FC6EcqWDRLJCvwVcfyCqsD+T18xWuycTbMsTUWX+CykkY+gW5uKu8Mp ++lP4Votg+QKoVvOAQvZA8lq9IMwX+g6GPQCdyRMUAf/TCTlfgcPv5MoPUANuWJ2QsbC TxuqnU+Uf4pIQwz5dXXQVb66N0cqgThdINDWGAzlejqkTJfdO2Q6gQ5o9FumfbdrJlYC qT7v6YsXf4P504Ci4f7VK9WAAt220EJi9Av9ugWVnkESLhOg0TMrXQkt2/SK84THjROj DhzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748185959; x=1748790759; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=kN2pXvelNsnelu6cA8GyELSirj9ArkYOYjW7kFWbhE4=; b=kBd2pxstScsA/p0asuSvSZb7E0NZqiKVqBhDy/ueUuTWa2Vvh4XBAe+rHaj6Sul3wx yNoWpXzwBIKJKEovJakjiabaUzm3lgP+mEzW6yMpI5fTgqQilmYWEkPV/P/vL1WptRoc dVB6n5buPwS605/dbFopqGxgg7J8KN5nHE5V/jVtQE/3UoCoIx9cgMOMAJ8EGwN1Fn3Z t6xD6yd2W/ODTHDeg+Yt3SgGV7AXLgtgp/T54zfFBn2Z6yJ0w2rqnh+9G6ikoPJEKdzq t25b4ZnQIbTd3Ii/OTM446/7avmIFg3LSWKjGI+sHp0k8t5Gu8//ljAVBogtqKi79Bty f5JQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCX4oK5lrRnUVzIEz8y+z/B9ud0zNeuKF/DwQk7UO32YFORQL74suqKJ7OJHPIE+izx7Nvb5LmYB+yng@gnusha.org X-Gm-Message-State: AOJu0YwzgHdmuQR+ZPPG1C2JZSr+SoPs21m57nDsB1QVOMX/V79jqmhU xwPrLHAwHv4Ha1OqlQlzYjbgRQn3uYnkxZbkpW2LIeFTgC75x+N7Qaai X-Google-Smtp-Source: AGHT+IGN76K4URJSSEuEtPj0J/j4ODSd9YRucjx41WxnIYdOa9TqVARCF2YzSkNYiDSfcuyeK11M+A== X-Received: by 2002:a05:6902:3382:b0:e79:e65:9169 with SMTP id 3f1490d57ef6-e7d919c3c63mr5009254276.20.1748185958680; Sun, 25 May 2025 08:12:38 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBEyQeDJ9284tgjFoNigAXWxVUGpfeK0/sYLhcbscP7zUQ== Received: by 2002:a25:3fc4:0:b0:e7a:63e6:d8ef with SMTP id 3f1490d57ef6-e7d92107abals1038564276.1.-pod-prod-09-us; Sun, 25 May 2025 08:12:34 -0700 (PDT) X-Received: by 2002:a05:690c:6e07:b0:70e:2168:7344 with SMTP id 00721157ae682-70e2dabc8efmr57310787b3.23.1748185954288; Sun, 25 May 2025 08:12:34 -0700 (PDT) Received: by 2002:a81:c949:0:b0:6ef:590d:3213 with SMTP id 00721157ae682-70ca9c0bd38ms7b3; Sun, 25 May 2025 07:26:53 -0700 (PDT) X-Received: by 2002:a05:690c:f10:b0:70d:f47a:7e21 with SMTP id 00721157ae682-70e2d9814admr62398337b3.1.1748183213134; Sun, 25 May 2025 07:26:53 -0700 (PDT) Date: Sun, 25 May 2025 07:26:52 -0700 (PDT) From: nerdyrugbyguy To: Bitcoin Development Mailing List Message-Id: <4c376336-1fe3-4b1c-b13b-8dcc2075e758n@googlegroups.com> In-Reply-To: <20250524205608.D723F7C1191@smtp.postman.i2p> References: <20250523131541.1521C7C0DB0@smtp.postman.i2p> <20250524205608.D723F7C1191@smtp.postman.i2p> Subject: Re: [bitcoindev] BIP39 Extension for Manual Seed Phrase Creation MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_580248_790184651.1748183212848" X-Original-Sender: nerdyrugbyguy@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_580248_790184651.1748183212848 Content-Type: multipart/alternative; boundary="----=_Part_580249_200760772.1748183212848" ------=_Part_580249_200760772.1748183212848 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=20 bitcoin club, created printed guides, and taught the procedure to others. = =20 Even out of a group of people with engineering degrees, it was too much. = =20 Many people have limited math ability and most will never learn binary math= =20 or checksums. Unfortunately bitcoin "self custody" is typically based on= =20 trusting a black box. The question is really whether bitcoin is for elites= =20 or plebs. The UEFI application you're suggesting sounds like it might be similar to= =20 other existing tools that receive entropy input and output a seed phrase or= =20 last word. What format should be used for the entropy input? Typically hex= =20 or binary is used because we lack a standard format (encoding entropy with= =20 words would be less error prone). To be trustless and do what you suggest,= =20 it seems users would have to record their entropy in a non-standard format,= =20 obtain two independent tools, perform a non-standard import of their=20 entropy into the first tool, record the seed phrase output, perform a=20 non-standard import of their entropy into the second tool, then confirm=20 that the output of the second tool matches. While not requiring the user to= =20 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= =20 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= =20 and build their own tools) *#2* Trust a "black box" tool *#3* Non-standard entropy import into two independent "black box" tools and= =20 cross-check results *#4* Use binary math to determine initial words and most significant bits= =20 of last word. Obtain least significant bits of last word by guessing or=20 computing sha256 hash. A standard for encoding entropy would make #3 easier (useful for things=20 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=20 useful that could be done with the extra bits being encoded. I would defer= =20 this discussion for now and just ask for consideration of the case where=20 derivation path is not specified. Regards, -Eric On Sunday, May 25, 2025 at 5:44:44=E2=80=AFAM UTC-6 pithosian wrote: BIP39 works fine with entropy generated without a computer. I=20 personally recommend using coinflips with Von Neumann skew correction.=20 Yes, you need to perform a SHA256 hash to calculate the checksum word.=20 You need to use SHA512 HMAC as the next step, and EC point=20 multiplication along with a host of other steps which are unrealistic=20 to expect a human to perform by hand to actually get child keys and=20 addresses out the other end, too.=20 I have a bootable UEFI application for generating a mnemonic with=20 skew-corrected coinflips (among other things), designed for airgapped=20 operation, lying around in my archive somewhere. I plan on=20 re-implementing it as part of a much larger, long-running project but=20 if there's interest I can go find it, clean it up and publish the=20 old version in the meantime.=20 The spec doesn't need to change; there's really no benefit to=20 generating a mnemonic without the SHA256 hash step, because again, you=20 can't do anything with that mnemonic without hashing.=20 As for encoding derivation paths in the mnemonic, Electrum's Seed=20 Version System achieves roughly the same thing, but descriptors are a=20 better solution for managing non-entropy metadata for wallets.=20 For those who really don't want to put in the small amount of additional=20 effort required to use descriptors, replying on the standard derivation=20 paths is sufficient, as long as they're made aware of their existence.=20 Educating your users is a better solution than attempting to abstract=20 away (aka hide) critical information from them.=20 On Fri, 23 May 2025 13:15:41 +0000 (UTC)=20 Eric Kvam wrote:=20 > *Motivation*=20 > Make it easy for users to manually create their seed phrase so that=20 > they don't have to trust a "black box" and allow for encoding=20 > derivation path in seed phrase to simplify recovery=20 >=20 > *How*=20 > Use every eighth word from the wordlist to generate 16 word phrases=20 > with 128 bits of entropy (no checksum). The most significant eight=20 > bits of each word are used as entropy. The least significant three=20 > bits of each word specify the derivation path.=20 >=20 > - *000* Derivation Path Not Specified=20 > - *001* m/44'/0'/0'=20 > - *010* m/49'/0'/0'=20 > - *011* m/84'/0'/0'=20 > - *100* m/48'/0'/0'/2'=20 > - *101* m/86'/0'/0'=20 >=20 > Up to seven derivation paths can be specified if all words have the=20 > same least significant bits. If the least significant bits of each=20 > word vary, there are 48 bits that can be used to encode meta-data.=20 > As long as meta-data is limited to certain allowable values, this=20 > provides a mechanism for error detection, similar to a checksum.=20 >=20 > *Benefits of Suggested Implementation*=20 >=20 > - The word length determines how the seed phrase should be=20 > interpreted. User only needs to know how many words they have and how=20 > many words the wallet supports to check for compatibility with this=20 > extension=20 > - Uses same wordlist to represent the same entropy as a 12 word=20 > phrase (could be a revision to BIP39 instead of a new BIP)=20 > - Manual procedure is very simple, each derivation path can use a=20 > shortened 256 word list which enjoys improved alphabetical=20 > separation of words=20 > - May prevent naive word selections which aren't limited to every=20 > eighth word (similar to what checksum does)=20 > - Can be extended further. For example, a 32 word phrase with the=20 > same entropy as a 24 word phrase could also be added. We can keep=20 > adding formats with unique word length and keep adding uses for the=20 > meta data as needed.=20 >=20 --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 4c376336-1fe3-4b1c-b13b-8dcc2075e758n%40googlegroups.com. ------=_Part_580249_200760772.1748183212848 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings Pithosian,

Thank you (and everyon= e) for taking time to consider my suggestions.

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

The UEFI applicatio= n 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.=C2=A0 Wh= at 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 b= e less error prone).=C2=A0 To be trustless and do what you suggest, it seem= s 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 impo= rt of their entropy into the second tool, then confirm that the output of t= he second tool matches. While not requiring the user to know binary math, t= his 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 wel= l suited for its intended purpose.=C2=A0 I'm proposing an extension.<= div>
Here are the current options I'm aware of for seed gen= eration:
#1 Use a "white box" tool (only an option for dev= s that can verify source and build their own tools)
#2 Tru= st 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.=C2=A0 Obtain least significant bits of last word by guessing or = computing sha256 hash.

A standard for encoding e= ntropy would make #3 easier (useful for things like seedQR) and enable #5:<= /div>
#5 Record entropy in a standard format

As far as encoding derivation paths, I was trying to think of somet= hing useful that could be done with the extra bits being encoded.=C2=A0 I w= ould defer this discussion for now and just ask for consideration of the ca= se where derivation path is not specified.

Regar= ds,
-Eric

On Sunday, May 2= 5, 2025 at 5:44:44=E2=80=AFAM 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, yo= u
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 additio= nal
effort required to use descriptors, replying on the standard derivati= on
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&g= t; wrote:

> *Motivation*
> Make it easy for users to manually create their seed phrase so t= hat
> they don't have to trust a "black box" and allow for encoding
> derivation path in seed phrase to simplify recovery
>=20
> *How*
> Use every eighth word from the wordlist to generate 16 word phra= ses
> with 128 bits of entropy (no checksum). The most significant ei= ght
> bits of each word are used as entropy. The least significant th= ree
> bits of each word specify the derivation path.
>=20
> - *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'
>=20
> Up to seven derivation paths can be specified if all words have = the
> same least significant bits. If the least significant bits of e= ach
> word vary, there are 48 bits that can be used to encode meta-dat= a.
> As long as meta-data is limited to certain allowable values, thi= s
> provides a mechanism for error detection, similar to a checksum.
>=20
> *Benefits of Suggested Implementation*
>=20
> - The word length determines how the seed phrase should be
> interpreted. User only needs to know how many words they have an= d how
> many words the wallet supports to check for compatibility with t= his
> extension
> - Uses same wordlist to represent the same entropy as a 12 wo= rd
> phrase (could be a revision to BIP39 instead of a new BIP)
> - Manual procedure is very simple, each derivation path can u= se a=20
> shortened 256 word list which enjoys improved alphabetical
> separation of words
> - May prevent naive word selections which aren't limited to e= very
> eighth word (similar to what checksum does)
> - Can be extended further. For example, a 32 word phrase wit= h the
> same entropy as a 24 word phrase could also be added. We can ke= ep
> adding formats with unique word length and keep adding uses for = the
> meta data as needed.
>=20

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/4c376336-1fe3-4b1c-b13b-8dcc2075e758n%40googlegroups.com.
------=_Part_580249_200760772.1748183212848-- ------=_Part_580248_790184651.1748183212848--