diff options
author | Tobias Kaupat <Tobias@kaupat-hh.de> | 2021-05-10 00:53:51 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2021-05-09 22:54:13 +0000 |
commit | 235c8b5d71ca448dbe6feba9069a45cc37c7bb27 (patch) | |
tree | 1657115ca5acf9ff458135e5055c379f719ea3ec | |
parent | 6f1fbe2cac3807fa64acf84392e9590751220fa9 (diff) | |
download | pi-bitcoindev-235c8b5d71ca448dbe6feba9069a45cc37c7bb27.tar.gz pi-bitcoindev-235c8b5d71ca448dbe6feba9069a45cc37c7bb27.zip |
Re: [bitcoin-dev] Proposal for an Informational BIP
-rw-r--r-- | 15/03940c2536b674c0bea4cf6cff0ed4909744c5 | 576 |
1 files changed, 576 insertions, 0 deletions
diff --git a/15/03940c2536b674c0bea4cf6cff0ed4909744c5 b/15/03940c2536b674c0bea4cf6cff0ed4909744c5 new file mode 100644 index 000000000..e571d3a24 --- /dev/null +++ b/15/03940c2536b674c0bea4cf6cff0ed4909744c5 @@ -0,0 +1,576 @@ +Return-Path: <Tobias@kaupat-hh.de> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id BA535C0001 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 9 May 2021 22:54:13 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id A1988605F7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 9 May 2021 22:54:13 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.595 +X-Spam-Level: +X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, + RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, + SPF_NONE=0.001] autolearn=ham autolearn_force=no +Received: from smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id TZ-yj7jf9iK5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 9 May 2021 22:54:11 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +Received: from mail.worldserver.net (mail.worldserver.net [217.13.200.37]) + by smtp3.osuosl.org (Postfix) with ESMTPS id 3E715605D2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 9 May 2021 22:54:10 +0000 (UTC) +Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com + [209.85.219.49]) (Authenticated sender: tobias@kaupat-hh.de) + by mail.worldserver.net (Postfix) with ESMTPSA id B7CFF26A9A + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 10 May 2021 00:54:05 +0200 (CEST) +Received: by mail-qv1-f49.google.com with SMTP id u7so7475557qvv.12 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 09 May 2021 15:54:05 -0700 (PDT) +X-Gm-Message-State: AOAM531W35m7J9A8CZSu1zhfLRrpEONm3uFxXng/IuOYMq8i8YSDHSDU + pROQzo5feyqvg5KBnjNEBz7YIHiIZQYZa3beMlM= +X-Google-Smtp-Source: ABdhPJz1KM3kIvUI2c65SVhzWEPMFy3wwpebBQLSVtL+gGsDetO1HtjC5gJFEvLMdcwtrJpT3IMZwOK24qSSmnSf5mI= +X-Received: by 2002:a0c:eec7:: with SMTP id h7mr11657533qvs.45.1620600844067; + Sun, 09 May 2021 15:54:04 -0700 (PDT) +MIME-Version: 1.0 +References: <CAAvTZ6546k0Rx2ODQ7EHJWV=F-DU-kQEg=Qh6yK6WNH-dmgv8w@mail.gmail.com> + <CAPyCnfsRhF-X792cFUAcWj2DK=3WE_LYMX-eFO2A-U7aA81btQ@mail.gmail.com> + <CAAvTZ658FN2++znPjWim+cf=Xfgq7ycWqyZLbjKyizorkxv0ww@mail.gmail.com> +In-Reply-To: <CAAvTZ658FN2++znPjWim+cf=Xfgq7ycWqyZLbjKyizorkxv0ww@mail.gmail.com> +From: Tobias Kaupat <Tobias@kaupat-hh.de> +Date: Mon, 10 May 2021 00:53:51 +0200 +X-Gmail-Original-Message-ID: <CAPyCnfu32KKmrmDEmx5QNNnzifNE_J5Sfi2uWoPZo0NA4ruqgg@mail.gmail.com> +Message-ID: <CAPyCnfu32KKmrmDEmx5QNNnzifNE_J5Sfi2uWoPZo0NA4ruqgg@mail.gmail.com> +To: "BitPLATES (Chris)" <bitplates@marketnetworks.co.uk> +Content-Type: multipart/alternative; boundary="000000000000a2275405c1ed895a" +X-Mailman-Approved-At: Sun, 09 May 2021 23:01:19 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Proposal for an Informational BIP +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: Sun, 09 May 2021 22:54:13 -0000 + +--000000000000a2275405c1ed895a +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi Chris, +thanks for the clarification. It makes sense so far. + +About the "chicken - egg" problem: +When you generate a BIP39 mnemonic "A" without password, you get a Seed +"As" from which you derive your private key. +Using the same mnemonic with a passphrase will give you a different seed +"As*" with a different private and public key. +Now your process must look like: +- Generate mnemonic A without password (will never be used) +- Generate mnemonic B* using words from A as password +- Generate mnemonic A* using words from B* as password + +That's just an implementation detail but might have impact on the actual +process, depending on the wallet you are using. + +Hope it's clear. + +Kind regards +Tobias + + + +BitPLATES (Chris) <bitplates@marketnetworks.co.uk> schrieb am So., 9. Mai +2021, 10:29: + +> Hi Tobias, +> +> In answer to your questions... +> +> "Isn't your suggestion already covered by BIP39 since there is not +> restriction in how you choose your passphrase?" +> +> - Correct, my idea is covered by BIP39, and therefore compatible with +> BIP39... I see the 'quantum' passphrase as an optional 'soft fork' leadin= +g +> towards a more restricted choice of characters, rather than the fuller, +> less restrictive choice of characters. +> +> "It's up to any user to choose his password like you propose. I see your +> proposal more like a way to choose my password rather than anything that +> needs to be implemented somewhere." +> +> - Correct also, my proposal is for an Informational BIP to educate users +> how to create a 'quantum' passphrase, which provides the same high degree +> of protection (2048^23 combinations) as the original 1st layer mnemonic +> seed words. Should their 24 seed words be compromised (or posted on the +> internet), this extreme level of protection would make it impossible to +> brute-force the wallet without the 'quantum' passphrase. +> +> "Don't I have plausible deniability already with any other password that = +I +> keep in mind, since the seed without the password is already a valid +> address?" +> +> - No, because an unrestricted passphrase may contain characters different +> to those allowed by the 'quantum' passphrase. Memorisation of the 2nd lay= +er +> passphrase is very dangerous, whereby, an unfortunate accident could leav= +e +> your family without access to their inherence. The 'quantum' passphrase +> encourages the use of multiple metal backup storage devices, but anything +> more that A-Z (upper case only), would not be disguised as a 24 word seed= +. +> Therefore, discovery of a backup device with the extra, unrestricted +> characters that don't also open a (sacrificial) wallet, will be recognise= +d +> as a 2nd layer passphrase... This is when the $5 wrench is brought to the +> table to extract the 1st layer seed words. +> +> "One issue might be, that the passphrase is part of the mnemonic. A +> hardware wallet needs the passphrase to generate the complete mnemonic +> (changing the password does change the resulting seed). Thus you get a +> chicken-egg problem, at least for some implementations. Probably you coul= +d +> use the restore feature to work around this - but it's one step more that +> should be mentioned." +> +> - I'm not sure that I fully understand this last paragraph of your email, +> but just to be clear, the 'quantum' passphrase is made from the 24 seed +> words of a separate wallet. This is essentially the 2nd layer (or 2nd +> signing key) to add to the 1st layer (or 1st signing key) required to +> complete the full mnemonic, which then provides access to the +> passphrase-protected wallet. +> +> eg. The 1st Bitcoin wallet is protected by a 'quantum' passphrase, +> containing the seed words of the 2nd Bitcoin wallet; inversely, the 2nd +> Bitcoin wallet is protected by a 'quantum' passphrase, containing the see= +d +> words of the 1st Bitcoin wallet. +> +> Thank you for your thoughts. +> +> Regards, +> +> Chris +> +> +> On Sun, 9 May 2021, 08:24 Tobias Kaupat, <Tobias@kaupat-hh.de> wrote: +> +>> Hello Chris, +>> Isn't your suggestion already covered by BIP39 since there is not +>> restriction in how you choose your passphrase? +>> +>> It's up to any user to choose his password like you propose. I see your +>> proposal more like a way to choose my password rather than anything that +>> needs to be implemented somewhere. +>> +>> Don't I have plausible deniability already with any other password that = +I +>> keep in mind, since the seed without the password is already a valid +>> address? +>> +>> One issue might be, that the passphrase is part of the mnemonic. A +>> hardware wallet needs the passphrase to generate the complete mnemonic +>> (changing the password does change the resulting seed). Thus you get a +>> chicken-egg problem, at least for some implementations. Probably you cou= +ld +>> use the restore feature to work around this - but it's one step more tha= +t +>> should be mentioned. +>> +>> +>> Kind regards +>> Tobias +>> +>> +>> +>> +>> BitPLATES=C2=AE (Chris) via bitcoin-dev <bitcoin-dev@lists.linuxfoundati= +on.org> +>> schrieb am Sa., 8. Mai 2021, 17:21: +>> +>>> Hi, +>>> +>>> I'd like to submit an idea for review, as a potential informational BIP +>>> (Bitcoin Improvement Proposal), describing an optional method of produc= +ing +>>> a BIP39 passphrase, using only BIP39 'mnemonic' seed words. +>>> +>>> The idea specifically refers to a method of introducing two-factor +>>> authentication, to protect a Bitcoin wallet using only 24 seed words, a= +nd +>>> therefore, providing plausible deniability about the existence of this +>>> separate 2nd layer passphrase. +>>> +>>> I've suggested the name 'quantum' passphrase to be used casually as a +>>> unique identifier. +>>> +>>> The data stored within a 'quantum' passphrase, is simultaneously the +>>> minimum required data for reproducing a BIP39-compatible 24-word seed +>>> mnemonic... hence, the name 'quantum' seems fitting, to reflect the +>>> multiple simultaneous states of data. +>>> +>>> Abstract... +>>> +>>> This improvement proposal describes the use of twenty four, newly +>>> generated BIP39 seed words, to produce a '25th-word' BIP39-compatible +>>> 'quantum' passphrase. +>>> +>>> Two-factor authentication (2FA) or (2 of 2 multi-signature) can be +>>> implemented with a two-wallet setup: +>>> +>>> The 1st Bitcoin wallet is protected by the seed words of the 2nd Bitcoi= +n +>>> wallet; inversely, the 2nd Bitcoin wallet is protected by the seed word= +s of +>>> the 1st Bitcoin wallet. +>>> +>>> The 'quantum' passphrase offers an exponential increase in the level of +>>> protection, as that offered by the original BIP39 mnemonic seed words +>>> (=E2=89=882048^23 possible combinations). +>>> +>>> ie. A Bitcoin wallet with a 2nd layer 'quantum'passphrase is protected +>>> by 2048^23 to the power of 2048^23 possible combinations. +>>> +>>> With existing computer capabilities, this level of protection is far +>>> greater than required; however, this does provide a sufficient level of +>>> protection for each separate layer of a two-factor Bitcoin wallet, shou= +ld +>>> any one layer be accidentally exposed. +>>> +>>> This method of passphrase generation, consists of two parts: +>>> +>>> 1st - generating the BIP39 mnemonic seed words, using a BIP39-compatibl= +e +>>> hardware wallet. +>>> +>>> 2nd - Converting these seed words into the 'quantum' passphrase, +>>> following four simple rules, which most importantly, do not destroy the +>>> integrity of the initial data. +>>> +>>> Motivation... +>>> +>>> The well established practice of preserving up to 24 seed words for the +>>> purpose of reproduction of a Bitcoin wallet, suffers from a major flaw.= +.. +>>> Exposure of these mnemonic seed words can cause catastrophic loss of fu= +nds +>>> without adequate multi-factor protection. +>>> +>>> Whilst it is recognised that a number of multi-factor solutions are +>>> available (including the standard BIP39 passphrase, and hardware wallet +>>> multi-signature functionality), this proposal aims to provide an extrem= +ely +>>> safe and secure 'low-tech' option, that requires minimal (non-destructi= +ve) +>>> adjustments to the seed words. +>>> +>>> Furthermore, the 'quantum' passphrase offers a number advantages over +>>> the existing methods of multi-factor protection: +>>> +>>> Firstly, this method of creating a passphrase leaves no evidence of its +>>> existence on any backup devices, providing plausible deniability in cas= +e of +>>> coercion. +>>> +>>> This is because the passphrase is easily created from a genuine 24 seed +>>> word mnemonic; therefore, the physical backup of the passphrase can be +>>> disguised as a simple Bitcoin wallet on a metal backup plate. +>>> +>>> It presents a way of discouraging user-created words or sentences (also +>>> known as 'brain-wallets'), which often provide a drastically reduced le= +vel +>>> of passphrase security, unbeknown to many users. +>>> +>>> The large amount of data required to produce a 'quantum' passphrase (up +>>> to 96 characters long), encourages the physical backup of the passphras= +e. +>>> +>>> Furthermore, the use of BIP39-only words provides a higher degree of +>>> standardization, which can help to avoid potential mistakes made by +>>> creating unnecessarily complicated combinations of letters, numbers and +>>> symbols. Increased complication (disorderly, and non-human-friendly), d= +oes +>>> not always equal increased complexity (orderly, and more human-friendly= +), +>>> or increased security. +>>> +>>> As previously mentioned, a two-wallet configuration provides the user a= +n +>>> opportunity to safely split the two factors of protection (equivalent t= +o a +>>> 2 of 2 'multi-sig' setup). +>>> +>>> If a BIP39-compatible passphrase is created using a new set of 24 seed +>>> words, it provides 76 degrees of extra complexity (ie. 1 with 76 zeros,= + or +>>> 10=E2=81=B7=E2=81=B6 possible combinations of words). +>>> +>>> The strength of this 2nd factor solution, provides adequate +>>> risk-management, when considering the production of multiple backup +>>> devices, strategically stored in multiple geographical locations. +>>> +>>> Generating the 'quantum' passphrase... +>>> +>>> Following just four (non-destructive) BIP39-compatible rules, the 24 +>>> seed words can also function as a 'quantum' passphrase: +>>> +>>> 1 . Only BIP39 words +>>> (Standard list of 2048 English words - other languages should be +>>> compatible) +>>> +>>> 2 . Only the first four letters of each word +>>> (BIP39 words require only this data for reproduction) +>>> +>>> 3 . Only upper case letters +>>> (All alphabet references use this standard format) +>>> +>>> 4 . No spaces between words +>>> (Spaces represent an additional unit of data, that is not recorded) +>>> +>>> In essence, the 'quantum' passphrase is simply a single string of all 2= +4 +>>> seed words, set out using the above rules. +>>> +>>> I welcome a productive technical discussion. +>>> +>>> Thanks, +>>> +>>> Chris Johnston +>>> +>>> +>>> _______________________________________________ +>>> bitcoin-dev mailing list +>>> bitcoin-dev@lists.linuxfoundation.org +>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>>> +>> + +--000000000000a2275405c1ed895a +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"auto">Hi Chris,<div dir=3D"auto">thanks for the clarification. = +It makes sense so far.</div><div dir=3D"auto"><br></div><div dir=3D"auto">A= +bout the "chicken - egg" problem:</div><div dir=3D"auto">When you= + generate a BIP39 mnemonic "A" without password, you get a Seed &= +quot;As" from which you derive your private key.</div><div dir=3D"auto= +">Using the same mnemonic with a passphrase will give you a different seed = +"As*" with a different private and public key.</div><div dir=3D"a= +uto">Now your process must look like:</div><div dir=3D"auto">- Generate mne= +monic A without password (will never be used)</div><div dir=3D"auto">- Gene= +rate mnemonic B* using words from A as password</div><div dir=3D"auto">- Ge= +nerate mnemonic A* using words from B* as password</div><div dir=3D"auto"><= +br></div><div dir=3D"auto">That's just an implementation detail but mig= +ht have impact on the actual process, depending on the wallet you are using= +.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Hope it's clear.</= +div><div dir=3D"auto"><br></div><div dir=3D"auto">Kind regards</div><div di= +r=3D"auto">Tobias</div><div dir=3D"auto"><br></div><br><br><div class=3D"gm= +ail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">BitPLATES (Ch= +ris) <<a href=3D"mailto:bitplates@marketnetworks.co.uk">bitplates@market= +networks.co.uk</a>> schrieb am So., 9. Mai 2021, 10:29:<br></div><blockq= +uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = +solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">Hi Tobias,</div= +><div dir=3D"auto"><br></div><div dir=3D"auto">In answer to your questions.= +..</div><div dir=3D"auto"><br></div><div dir=3D"auto">"Isn't your = +suggestion already covered by BIP39 since there is not restriction in how y= +ou choose your passphrase?"</div><div dir=3D"auto"><br></div><div dir= +=3D"auto">- Correct, my idea is covered by BIP39, and therefore compatible = +with BIP39... I see the 'quantum' passphrase as an optional 'so= +ft fork' leading towards a more restricted choice of characters, rather= + than the fuller, less restrictive choice of characters.</div><div dir=3D"a= +uto"><br></div><div dir=3D"auto">"It's up to any user to choose hi= +s password like you propose. I see your proposal more like a way to choose = +my password rather than anything that needs to be implemented somewhere.&qu= +ot;</div><div dir=3D"auto"><br></div><div dir=3D"auto">- Correct also, my p= +roposal is for an Informational BIP to educate users how to create a 'q= +uantum' passphrase, which provides the same high degree of protection (= +2048^23 combinations) as the original 1st layer mnemonic seed words. Should= + their 24 seed words be compromised (or posted on the internet), this extre= +me level of protection would make it impossible to brute-force the wallet w= +ithout the 'quantum' passphrase.</div><div dir=3D"auto"><br></div><= +div dir=3D"auto">"Don't I have plausible deniability already with = +any other password that I keep in mind, since the seed without the password= + is already a valid address?"</div><div dir=3D"auto"><br></div><div di= +r=3D"auto">- No, because an unrestricted passphrase may contain characters = +different to those allowed by the 'quantum' passphrase. Memorisatio= +n of the 2nd layer passphrase is very dangerous, whereby, an unfortunate ac= +cident could leave your family without access to their inherence. The '= +quantum' passphrase encourages the use of multiple metal backup storage= + devices, but anything more that A-Z (upper case only), would not be disgui= +sed as a 24 word seed. Therefore, discovery of a backup device with the ext= +ra, unrestricted characters that don't also open a (sacrificial) wallet= +, will be recognised as a 2nd layer passphrase... This is when the $5 wrenc= +h is brought to the table to extract the 1st layer seed words.=C2=A0</div><= +div dir=3D"auto"><br></div><div dir=3D"auto">"One issue might be, that= + the passphrase is part of the mnemonic. A hardware wallet needs the passph= +rase to generate the complete mnemonic (changing the password does change t= +he resulting seed). Thus you get a chicken-egg problem, at least for some i= +mplementations. Probably you could use the restore feature to work around t= +his - but it's one step more that should be mentioned."</div><div = +dir=3D"auto"><br></div><div dir=3D"auto">- I'm not sure that I fully un= +derstand this last paragraph of your email, but just to be clear, the '= +quantum' passphrase is made from the 24 seed words of a separate wallet= +. This is essentially the 2nd layer (or 2nd signing key) to add to the 1st = +layer (or 1st signing key) required to complete the full mnemonic, which th= +en provides access to the passphrase-protected wallet.</div><div dir=3D"aut= +o"><br></div><div dir=3D"auto">eg. The 1st Bitcoin wallet is protected by a= + 'quantum' passphrase, containing the seed words of the 2nd Bitcoin= + wallet; inversely, the 2nd Bitcoin wallet is protected by a 'quantum&#= +39; passphrase, containing the seed words of the 1st Bitcoin wallet.</div><= +div dir=3D"auto"><br></div><div dir=3D"auto">Thank you for your thoughts.</= +div><div dir=3D"auto"><br></div><div dir=3D"auto">Regards,</div><div dir=3D= +"auto"><br></div><div dir=3D"auto">Chris</div><div dir=3D"auto"><br></div><= +/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O= +n Sun, 9 May 2021, 08:24 Tobias Kaupat, <<a href=3D"mailto:Tobias@kaupat= +-hh.de" target=3D"_blank" rel=3D"noreferrer">Tobias@kaupat-hh.de</a>> wr= +ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= +border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">Hello Chris,= +<div dir=3D"auto">Isn't your suggestion already covered by BIP39 since = +there is not restriction in how you choose your passphrase?</div><div dir= +=3D"auto"><br></div><div dir=3D"auto">It's up to any user to choose his= + password like you propose. I see your proposal more like a way to choose m= +y password rather than anything that needs to be implemented somewhere.</di= +v><div dir=3D"auto"><br></div><div dir=3D"auto"><span style=3D"font-family:= +sans-serif">Don't I have plausible deniability already with any other p= +assword that I keep in mind, since the seed without the password is already= + a valid address?</span><br></div><div dir=3D"auto"><br></div><div dir=3D"a= +uto">One issue might be, that the passphrase is part of the mnemonic. A har= +dware wallet needs the passphrase to generate the complete mnemonic (changi= +ng the password does change the resulting seed). Thus you get a chicken-egg= + problem, at least for some implementations. Probably you could use the res= +tore feature to work around this - but it's one step more that should b= +e mentioned.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><= +div dir=3D"auto">Kind regards</div><div dir=3D"auto">Tobias</div><div dir= +=3D"auto"><br></div><div dir=3D"auto"><br></div><br><br><div class=3D"gmail= +_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">BitPLATES=C2=AE = +(Chris) via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfounda= +tion.org" rel=3D"noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists= +.linuxfoundation.org</a>> schrieb am Sa., 8. Mai 2021, 17:21:<br></div><= +blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= + #ccc solid;padding-left:1ex"><div dir=3D"auto">Hi,<div dir=3D"auto"><br></= +div><div dir=3D"auto">I'd like to submit an idea for review, as a poten= +tial informational BIP (Bitcoin Improvement Proposal), describing an option= +al method of producing a BIP39 passphrase, using only BIP39 'mnemonic&#= +39; seed words.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The idea= + specifically refers to a method of introducing two-factor authentication, = +to protect a Bitcoin wallet using only 24 seed words, and therefore, provid= +ing plausible deniability about the existence of this separate 2nd layer pa= +ssphrase.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I've sugge= +sted the name 'quantum' passphrase to be used casually as a unique = +identifier.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The data sto= +red within a 'quantum' passphrase, is simultaneously the minimum re= +quired data for reproducing a BIP39-compatible 24-word seed mnemonic... hen= +ce, the name 'quantum' seems fitting, to reflect the multiple simul= +taneous states of data.</div><div dir=3D"auto"><div dir=3D"auto"><br></div>= +<div dir=3D"auto">Abstract...</div><div dir=3D"auto"><br></div><div dir=3D"= +auto">This improvement proposal describes the use of twenty four, newly gen= +erated BIP39 seed words, to produce a '25th-word' BIP39-compatible = +'quantum' passphrase.</div><div dir=3D"auto"><br></div><div dir=3D"= +auto">Two-factor authentication (2FA) or (2 of 2 multi-signature) can be im= +plemented with a two-wallet setup:</div><div dir=3D"auto"><br></div><div di= +r=3D"auto">The 1st Bitcoin wallet is protected by the seed words of the 2nd= + Bitcoin wallet; inversely, the 2nd Bitcoin wallet is protected by the seed= + words of the 1st Bitcoin wallet.</div><div dir=3D"auto"><br></div><div dir= +=3D"auto">The 'quantum' passphrase offers an exponential increase i= +n the level of protection, as that offered by the original BIP39 mnemonic s= +eed words (=E2=89=882048^23 possible combinations).</div><div dir=3D"auto">= +<br></div><div dir=3D"auto">ie. A Bitcoin wallet with a 2nd layer 'quan= +tum'passphrase is protected by 2048^23 to the power of 2048^23 possible= + combinations.</div><div dir=3D"auto"><br></div><div dir=3D"auto">With exis= +ting computer capabilities, this level of protection is far greater than re= +quired; however, this does provide a sufficient level of protection for eac= +h separate layer of a two-factor Bitcoin wallet, should any one layer be ac= +cidentally exposed.</div><div dir=3D"auto"><br></div><div dir=3D"auto">This= + method of passphrase generation, consists of two parts:</div><div dir=3D"a= +uto"><br></div><div dir=3D"auto">1st - generating the BIP39 mnemonic seed w= +ords, using a BIP39-compatible hardware wallet.</div><div dir=3D"auto"><br>= +</div><div dir=3D"auto">2nd - Converting these seed words into the 'qua= +ntum' passphrase, following four simple rules, which most importantly, = +do not destroy the integrity of the initial data.</div><div dir=3D"auto"><b= +r></div><div dir=3D"auto">Motivation...</div><div dir=3D"auto"><br></div><d= +iv dir=3D"auto">The well established practice of preserving up to 24 seed w= +ords for the purpose of reproduction of a Bitcoin wallet, suffers from a ma= +jor flaw... Exposure of these mnemonic seed words can cause catastrophic lo= +ss of funds without adequate multi-factor protection.</div><div dir=3D"auto= +"><br></div><div dir=3D"auto">Whilst it is recognised that a number of mult= +i-factor solutions are available (including the standard BIP39 passphrase, = +and hardware wallet multi-signature functionality), this proposal aims to p= +rovide an extremely safe and secure 'low-tech' option, that require= +s minimal (non-destructive) adjustments to the seed words.</div><div dir=3D= +"auto"><br></div><div dir=3D"auto">Furthermore, the 'quantum' passp= +hrase offers a number advantages over the existing methods of multi-factor = +protection:</div><div dir=3D"auto"><br></div><div dir=3D"auto">Firstly, thi= +s method of creating a passphrase leaves no evidence of its existence on an= +y backup devices, providing plausible deniability in case of coercion.</div= +><div dir=3D"auto"><br></div><div dir=3D"auto">This is because the passphra= +se is easily created from a genuine 24 seed word mnemonic; therefore, the p= +hysical backup of the passphrase can be disguised as a simple Bitcoin walle= +t on a metal backup plate.</div><div dir=3D"auto"><br></div><div dir=3D"aut= +o">It presents a way of discouraging user-created words or sentences (also = +known as 'brain-wallets'), which often provide a drastically reduce= +d level of passphrase security, unbeknown to many users.</div><div dir=3D"a= +uto"><br></div><div dir=3D"auto">The large amount of data required to produ= +ce a 'quantum' passphrase (up to 96 characters long), encourages th= +e physical backup of the passphrase.</div><div dir=3D"auto"><br></div><div = +dir=3D"auto">Furthermore, the use of BIP39-only words provides a higher deg= +ree of standardization, which can help to avoid potential mistakes made by = +creating unnecessarily complicated combinations of letters, numbers and sym= +bols. Increased complication (disorderly, and non-human-friendly), does not= + always equal increased complexity (orderly, and more human-friendly), or i= +ncreased security.</div><div dir=3D"auto"><br></div><div dir=3D"auto">As pr= +eviously mentioned, a two-wallet configuration provides the user an opportu= +nity to safely split the two factors of protection (equivalent to a 2 of 2 = +'multi-sig' setup).</div><div dir=3D"auto"><br></div><div dir=3D"au= +to">If a BIP39-compatible passphrase is created using a new set of 24 seed = +words, it provides 76 degrees of extra complexity (ie. 1 with 76 zeros, or = +10=E2=81=B7=E2=81=B6 possible combinations of words).</div><div dir=3D"auto= +"><br></div><div dir=3D"auto">The strength of this 2nd factor solution, pro= +vides adequate risk-management, when considering the production of multiple= + backup devices, strategically stored in multiple geographical locations.</= +div><div dir=3D"auto"><br></div><div dir=3D"auto">Generating the 'quant= +um' passphrase...</div><div dir=3D"auto"><br></div><div dir=3D"auto">Fo= +llowing just four (non-destructive) BIP39-compatible rules, the 24 seed wor= +ds can also function as a 'quantum' passphrase:</div><div dir=3D"au= +to"><br></div><div dir=3D"auto">1 . Only BIP39 words</div><div dir=3D"auto"= +>(Standard list of 2048 English words - other languages should be compatibl= +e)</div><div dir=3D"auto"><br></div><div dir=3D"auto">2 . Only the first fo= +ur letters of each word</div><div dir=3D"auto">(BIP39 words require only th= +is data for reproduction)</div><div dir=3D"auto"><br></div><div dir=3D"auto= +">3 . Only upper case letters</div><div dir=3D"auto">(All alphabet referenc= +es use this standard format)</div><div dir=3D"auto"><br></div><div dir=3D"a= +uto">4 . No spaces between words</div><div dir=3D"auto">(Spaces represent a= +n additional unit of data, that is not recorded)</div><div dir=3D"auto"><br= +></div><div dir=3D"auto">In essence, the 'quantum' passphrase is si= +mply a single string of all 24 seed words, set out using the above rules.</= +div><div dir=3D"auto"><br></div><div dir=3D"auto">I welcome a productive te= +chnical discussion.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Than= +ks,</div><div dir=3D"auto"><br></div><div dir=3D"auto">Chris Johnston</div>= +<div dir=3D"auto"><br></div><div dir=3D"auto"><br></div></div></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer = +noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.= +org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">https= +://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br> +</blockquote></div></div> +</blockquote></div> +</blockquote></div></div> + +--000000000000a2275405c1ed895a-- + |