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--