summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTobias Kaupat <Tobias@kaupat-hh.de>2021-05-10 00:53:51 +0200
committerbitcoindev <bitcoindev@gnusha.org>2021-05-09 22:54:13 +0000
commit235c8b5d71ca448dbe6feba9069a45cc37c7bb27 (patch)
tree1657115ca5acf9ff458135e5055c379f719ea3ec
parent6f1fbe2cac3807fa64acf84392e9590751220fa9 (diff)
downloadpi-bitcoindev-235c8b5d71ca448dbe6feba9069a45cc37c7bb27.tar.gz
pi-bitcoindev-235c8b5d71ca448dbe6feba9069a45cc37c7bb27.zip
Re: [bitcoin-dev] Proposal for an Informational BIP
-rw-r--r--15/03940c2536b674c0bea4cf6cff0ed4909744c5576
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 &quot;chicken - egg&quot; problem:</div><div dir=3D"auto">When you=
+ generate a BIP39 mnemonic &quot;A&quot; without password, you get a Seed &=
+quot;As&quot; 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 =
+&quot;As*&quot; 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&#39;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&#39;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) &lt;<a href=3D"mailto:bitplates@marketnetworks.co.uk">bitplates@market=
+networks.co.uk</a>&gt; 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">&quot;Isn&#39;t your =
+suggestion already covered by BIP39 since there is not restriction in how y=
+ou choose your passphrase?&quot;</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 &#39;quantum&#39; passphrase as an optional &#39;so=
+ft fork&#39; 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">&quot;It&#39;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 &#39;q=
+uantum&#39; 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 &#39;quantum&#39; passphrase.</div><div dir=3D"auto"><br></div><=
+div dir=3D"auto">&quot;Don&#39;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?&quot;</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 &#39;quantum&#39; 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 &#39;=
+quantum&#39; 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&#39;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">&quot;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&#39;s one step more that should be mentioned.&quot;</div><div =
+dir=3D"auto"><br></div><div dir=3D"auto">- I&#39;m not sure that I fully un=
+derstand this last paragraph of your email, but just to be clear, the &#39;=
+quantum&#39; 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=
+ &#39;quantum&#39; passphrase, containing the seed words of the 2nd Bitcoin=
+ wallet; inversely, the 2nd Bitcoin wallet is protected by a &#39;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, &lt;<a href=3D"mailto:Tobias@kaupat=
+-hh.de" target=3D"_blank" rel=3D"noreferrer">Tobias@kaupat-hh.de</a>&gt; 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&#39;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&#39;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&#39;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&#39;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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
+tion.org" rel=3D"noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists=
+.linuxfoundation.org</a>&gt; 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&#39;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 &#39;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&#39;ve sugge=
+sted the name &#39;quantum&#39; 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 &#39;quantum&#39; passphrase, is simultaneously the minimum re=
+quired data for reproducing a BIP39-compatible 24-word seed mnemonic... hen=
+ce, the name &#39;quantum&#39; 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 &#39;25th-word&#39; BIP39-compatible =
+&#39;quantum&#39; 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 &#39;quantum&#39; 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 &#39;quan=
+tum&#39;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 &#39;qua=
+ntum&#39; 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 &#39;low-tech&#39; 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 &#39;quantum&#39; 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 &#39;brain-wallets&#39;), 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 &#39;quantum&#39; 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 =
+&#39;multi-sig&#39; 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 &#39;quant=
+um&#39; 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 &#39;quantum&#39; 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 &#39;quantum&#39; 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--
+