diff options
author | Paul Sztorc <truthcoin@gmail.com> | 2022-07-08 05:12:06 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-07-08 09:12:23 +0000 |
commit | 81005569e7e8cc9138318f795e841e6027ff3bd9 (patch) | |
tree | 9192a15a0d7643872ade3fbf72abfdddc726095e | |
parent | 6c1225d7876195d615364867d81d4a3bb70f1301 (diff) | |
download | pi-bitcoindev-81005569e7e8cc9138318f795e841e6027ff3bd9.tar.gz pi-bitcoindev-81005569e7e8cc9138318f795e841e6027ff3bd9.zip |
Re: [bitcoin-dev] No Order Mnemonic
-rw-r--r-- | a6/06f3402ed80955de51a087f4942be97bc9e572 | 294 |
1 files changed, 294 insertions, 0 deletions
diff --git a/a6/06f3402ed80955de51a087f4942be97bc9e572 b/a6/06f3402ed80955de51a087f4942be97bc9e572 new file mode 100644 index 000000000..547bd60e3 --- /dev/null +++ b/a6/06f3402ed80955de51a087f4942be97bc9e572 @@ -0,0 +1,294 @@ +Return-Path: <truthcoin@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id DABB8C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 8 Jul 2022 09:12:23 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id B3F4A424B3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 8 Jul 2022 09:12:23 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B3F4A424B3 +Authentication-Results: smtp4.osuosl.org; + dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com + header.a=rsa-sha256 header.s=20210112 header.b=qsCCeb/Z +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.098 +X-Spam-Level: +X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id kI2ATpJAeQvu + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 8 Jul 2022 09:12:20 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 363F9424AB +Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com + [IPv6:2a00:1450:4864:20::12d]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 363F9424AB + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 8 Jul 2022 09:12:20 +0000 (UTC) +Received: by mail-lf1-x12d.google.com with SMTP id m18so16857500lfg.10 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 08 Jul 2022 02:12:19 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=FB1MNKjSOw2IfazrPnPYwfkp9zvEW+8QEhgQCIAniYI=; + b=qsCCeb/ZHnhwTFNrZhWw0zmKTbiPzhE2Cdiex4ZqJJWpBIsbCo0O8ZwEHz0H6R276K + amlnBFx6TRGWRfN6JHjkLImRwEokAqV6KE2gao0sLhDgk8oxGbaKe+VF4EZSYyZdSnHP + FsQJx9IxICh5TaXZnLCn1tkaICi1nEuqzabAFvm1p79zRCBnufYHLu1boJwJJLcBIw7P + 7uHUCCVr9lkRia6GKPaLsFLZ0gA+LI9O7O82zCK+d6tHLgCIi0lSghX9foZrv1NMjhgF + rwlShATX3c5hpPM40bZYUsGLDoHjO6LKq4uOPX23Y8yUglmuTft3OFUl6hK/8PJRJMPI + K/TQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=FB1MNKjSOw2IfazrPnPYwfkp9zvEW+8QEhgQCIAniYI=; + b=xXF8wRTasdk6S5J2q9i8f1V/XE9VLO7sJgtjvlzSUfmVIN2zkCsCsTvbg49HQAwcV5 + HKv1asf0MrK4oZEE7eZb09+qX8SSYvl/y5xxSDBdxmc58hVUHRzo2AksRyvEeR88gCob + RnUMMLQ8sBYEur+6t08iJPQ+cRTzQAEnegqzk7uzgfWUremYOX7YMccbqfchCe7cBIDo + sr0OoTHLHABh+lbIsecUrBdL48hfI5Bjoqmeuvhx3JBgMD5BxOd9BULz/SKjOkienM7R + YzqADy7rQYtgkMvirNek0hVns7rnmgn5bqT/fVnlyw7U/hd9HrHLsceVqreNT+Kumq4z + x3tA== +X-Gm-Message-State: AJIora9VF+b1XR3hLgPvh6cCyrpGkoAuPVUQLujDf5g+OtL2ne59TpJX + jHd1VpWOI0ZseDQlOgh+DN42WIR0/NpvVFs9Wb2ibnR2 +X-Google-Smtp-Source: AGRyM1uLjtWmZAdeLuJjOQbMpOgOkogtdiD01LdU63n/+CmIe0pqArteZzByon66gi8RHbqKVpTAo2c6uBPZQg50xmw= +X-Received: by 2002:ac2:54a2:0:b0:489:57b0:7adc with SMTP id + w2-20020ac254a2000000b0048957b07adcmr1760420lfk.271.1657271537926; Fri, 08 + Jul 2022 02:12:17 -0700 (PDT) +MIME-Version: 1.0 +References: <3D3BFE9C-CFF3-49FF-840F-063B52C69A42@voskuil.org> + <164256450-0ee6752f92c0be297952fc72b59076df@pmq5v.m5r2.onet> +In-Reply-To: <164256450-0ee6752f92c0be297952fc72b59076df@pmq5v.m5r2.onet> +From: Paul Sztorc <truthcoin@gmail.com> +Date: Fri, 8 Jul 2022 05:12:06 -0400 +Message-ID: <CA+XQW1iKVRmEnyP-CGM2Fo4qHi3SQHUfjEmKftDdju-uxHViJg@mail.gmail.com> +To: vjudeu@gazeta.pl, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="0000000000005084fb05e347990c" +X-Mailman-Approved-At: Fri, 08 Jul 2022 09:26:42 +0000 +Subject: Re: [bitcoin-dev] No Order Mnemonic +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +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: Fri, 08 Jul 2022 09:12:23 -0000 + +--0000000000005084fb05e347990c +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +What do you do if the "first" word (of 12), happens to be the last word in +the list alphabetically? So that seems like a dead end. + +Since users are never expected to memorize the "whole list" (of 2048 words) +in any case, it seems that the smarter thing to do (if this "order" +criterion is desirable) may have been to just make the whole list 12x +longer and cut it into 12 sections. Each of the 12 slots would have 2048 +distinct words. Then the computer would handle the order; the user could +neglect it. + +I can guess why people weren't particularly interested in this: words +always have to be written down in some order or another. Even if you write +them down in a 3x4 grid, there are very few combinations needed to guess +the one true ordering. I wonder how obscure the words would have to be, by +the 12th list of 2048? But still it might be fun - the 4th word might +always be a nautical word, the 5th word a farm word, etc. And no one would +confuse it with a bip39 phrase -- in fact since they are just lists of +integers 1 to 2048, it would be pretty easy to make them interoperable. +Very easy but perhaps still not worth doing. + +Paul + +On Fri, Jul 8, 2022, 4:48 AM vjudeu via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Isn't it enough to just generate a seed in the same way as today, then +> sort the words alphabetically, and then use that as a seed? I know, the +> last word is a checksum, but there are only 2048 words, so it is not a bi= +g +> deal to get any checksum we want. If that is insecure, because of lower +> possible combinations, then it is always possible to increase the number = +of +> words to compensate that. +> +> +> On 2022-07-08 04:27:21 user Eric Voskuil via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +> +> Without a performance requirement there is no reason you can=E2=80=99t st= +ore the +> BIP39 words in any order you want. So it=E2=80=99s certainly possible, ju= +st brute +> force the recovery. If you have less than a second vs. a few days then it= +=E2=80=99s +> a different question. +> +> +> e +> +> +> On Jul 7, 2022, at 18:48, Bram Cohen via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> Part of the rules of my challenge is that the 'new' words need to be in +> the same pool as the 'old' words, so any ordering is okay. Without that +> requirement it's mathematically very straightforward. +> +> +> On Thu, Jul 7, 2022 at 10:52 AM Pavol Rusnak <stick@satoshilabs.com> +> wrote: +> There is. Just encode the index of permutation used to scramble the +> otherwise sorted list. For 12 words you need to store 12! =3D ~32 bits so= + 3 +> words should be enough. +> +> +> Repetitions make this more difficult, though. +> +> +> On Thu 7. 7. 2022 at 19:41, Bram Cohen via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> On Thu, Jul 7, 2022 at 7:43 AM Anton Shevchenko via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> I made a python implementation for a different mnemonic encoding. The +> encoding requires user to remember words but not the order of those words= +. +> The code is open (MIT license) at https://github.com/sancoder/noomnem +> +> +> +> Thanks Anton. There's an interesting mathematical question of whether it'= +s +> possible to make a code like this which always uses the BIP-39 words for +> the same key as part of its encoding, basically adding a few words as err= +or +> correction in case the order is lost or confused. If the BIP-39 contains = +a +> duplicate you can add an extra word. +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--0000000000005084fb05e347990c +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"auto">What do you do if the "first" word (of 12), hap= +pens to be the last word in the list alphabetically? So that seems like a d= +ead end.<div dir=3D"auto"><br></div><div dir=3D"auto">Since users are never= + expected to memorize the "whole list" (of 2048 words) in any cas= +e, it seems that the smarter thing to do (if this "order" criteri= +on is desirable) may have been to just make the whole list 12x longer and c= +ut it into 12 sections. Each of the 12 slots would have 2048 distinct words= +. Then the computer would handle the order; the user could neglect it.</div= +><div dir=3D"auto"><br></div><div dir=3D"auto">I can guess why people weren= +'t particularly interested in this: words always have to be written dow= +n in some order or another. Even if you write them down in a 3x4 grid, ther= +e are very few combinations needed to guess the one true ordering. I wonder= + how obscure the words would have to be, by the 12th list of 2048? But stil= +l it might be fun - the 4th word might always be a nautical word, the 5th w= +ord a farm word, etc. And no one would confuse it with a bip39 phrase -- in= + fact since they are just lists of integers 1 to 2048, it would be pretty e= +asy to make them interoperable. Very easy but perhaps still not worth doing= +.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Paul</div></div><br><d= +iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul = +8, 2022, 4:48 AM vjudeu via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@l= +ists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wro= +te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= +order-left:1px #ccc solid;padding-left:1ex">Isn't it enough to just gen= +erate a seed in the same way as today, then sort the words alphabetically, = +and then use that as a seed? I know, the last word is a checksum, but there= + are only 2048 words, so it is not a big deal to get any checksum we want. = +If that is insecure, because of lower possible combinations, then it is alw= +ays possible to increase the number of words to compensate that.<br> +<br> +<br> +On 2022-07-08 04:27:21 user Eric Voskuil via bitcoin-dev <<a href=3D"mai= +lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"norefer= +rer">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +<br> +<br> +Without a performance requirement there is no reason you can=E2=80=99t stor= +e the BIP39 words in any order you want. So it=E2=80=99s certainly possible= +, just brute force the recovery. If you have less than a second vs. a few d= +ays then it=E2=80=99s a different question.<br> +<br> +<br> +e<br> +<br> +<br> +On Jul 7, 2022, at 18:48, Bram Cohen via bitcoin-dev <<a href=3D"mailto:= +bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"noreferrer"= +>bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +Part of the rules of my challenge is that the 'new' words need to b= +e in the same pool as the 'old' words, so any ordering is okay. Wit= +hout that requirement it's mathematically very straightforward.<br> +<br> +<br> +On Thu, Jul 7, 2022 at 10:52 AM Pavol Rusnak <<a href=3D"mailto:stick@sa= +toshilabs.com" target=3D"_blank" rel=3D"noreferrer">stick@satoshilabs.com</= +a>> wrote:<br> +There is. Just encode the index of permutation used to scramble the otherwi= +se sorted list. For 12 words you need to store 12! =3D ~32 bits so 3 words = +should be enough.=C2=A0<br> +<br> +<br> +Repetitions make this more difficult, though.=C2=A0<br> +<br> +<br> +On Thu 7. 7. 2022 at 19:41, Bram Cohen via bitcoin-dev <<a href=3D"mailt= +o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"noreferre= +r">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +On Thu, Jul 7, 2022 at 7:43 AM Anton Shevchenko via bitcoin-dev <<a href= +=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"= +noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +I made a python implementation for a different mnemonic encoding. The encod= +ing requires user to remember words but not the order of those words.<br> +The code is open (MIT license) at <a href=3D"https://github.com/sancoder/no= +omnem" rel=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/s= +ancoder/noomnem</a><br> +<br> +<br> +<br> +Thanks Anton. There's an interesting mathematical question of whether i= +t's possible to make a code like this which always uses the BIP-39 word= +s for the same key as part of its encoding, basically adding a few words as= + error correction in case the order is lost or confused. If the BIP-39 cont= +ains a duplicate you can add an extra word.<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" = +rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati= +on.org/mailman/listinfo/bitcoin-dev</a><br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" = +rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati= +on.org/mailman/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--0000000000005084fb05e347990c-- + |