path: root/15/03940c2536b674c0bea4cf6cff0ed4909744c5

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