path: root/50/33152406fe1a43982f29b0f6b8b99cabc1ef48

Return-Path: <bitplates@marketnetworks.co.uk>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 206A0C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 May 2021 08:29:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 075D2606DF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 May 2021 08:29:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level: 
X-Spam-Status: No, score=-2.588 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_PASS=-0.001, T_SPF_PERMERROR=0.01]
 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 3-tC-gpjNiJF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 May 2021 08:29:22 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtp.hosts.co.uk (smtp.hosts.co.uk [85.233.160.19])
 by smtp3.osuosl.org (Postfix) with ESMTPS id BE55F605E0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 May 2021 08:29:21 +0000 (UTC)
Received: from mail-lf1-f52.google.com ([209.85.167.52])
 by smtp.hosts.co.uk with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256)
 (Exim) (envelope-from <bitplates@marketnetworks.co.uk>)
 id 1lfeoQ-0009Dh-7E
 for bitcoin-dev@lists.linuxfoundation.org; Sun, 09 May 2021 09:29:19 +0100
Received: by mail-lf1-f52.google.com with SMTP id x20so18957621lfu.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 09 May 2021 01:29:17 -0700 (PDT)
X-Gm-Message-State: AOAM530ttaXxw5JYWGOzcwvK6/sSEDjfIjYNMygOuRJp6m/KFQWhXRnx
 dt5VYENMB/WzIBZl21/fbuyD38pZgpBHlKxP4GM=
X-Google-Smtp-Source: ABdhPJwg+UCIPsdr+ERwU+B0Tv0bMevAC7O8IJZlTAA61IjISv0HU+0q0EFEYXzgr3tGG9JKQfiveV34yhGVgupfnGQ=
X-Received: by 2002:a05:6512:104d:: with SMTP id
 c13mr13029420lfb.59.1620548957041; 
 Sun, 09 May 2021 01:29:17 -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>
In-Reply-To: <CAPyCnfsRhF-X792cFUAcWj2DK=3WE_LYMX-eFO2A-U7aA81btQ@mail.gmail.com>
From: "BitPLATES (Chris)" <bitplates@marketnetworks.co.uk>
Date: Sun, 9 May 2021 09:29:05 +0100
X-Gmail-Original-Message-ID: <CAAvTZ658FN2++znPjWim+cf=Xfgq7ycWqyZLbjKyizorkxv0ww@mail.gmail.com>
Message-ID: <CAAvTZ658FN2++znPjWim+cf=Xfgq7ycWqyZLbjKyizorkxv0ww@mail.gmail.com>
To: Tobias Kaupat <Tobias@kaupat-hh.de>
Content-Type: multipart/alternative; boundary="000000000000ecf83c05c1e1742b"
X-Mailman-Approved-At: Sun, 09 May 2021 08:40:58 +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 08:29:24 -0000

--000000000000ecf83c05c1e1742b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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' leading
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 layer
passphrase is very dangerous, whereby, an unfortunate accident 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 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 recognised
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 could
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 seed
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 coul=
d
> use the restore feature to work around this - but it's one step more that
> should be mentioned.
>
>
> Kind regards
> Tobias
>
>
>
>
> BitPLATES=C2=AE (Chris) via bitcoin-dev <bitcoin-dev@lists.linuxfoundatio=
n.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 produci=
ng
>> 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, an=
d
>> 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 Bitcoin
>> wallet; inversely, the 2nd Bitcoin wallet is protected by the seed words=
 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 b=
y
>> 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, shoul=
d
>> 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-compatible
>> 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 fun=
ds
>> 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 extreme=
ly
>> safe and secure 'low-tech' option, that requires minimal (non-destructiv=
e)
>> adjustments to the seed words.
>>
>> Furthermore, the 'quantum' passphrase offers a number advantages over th=
e
>> 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 case=
 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 lev=
el
>> 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 passphrase=
.
>>
>> 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), do=
es
>> not always equal increased complexity (orderly, and more human-friendly)=
,
>> or increased security.
>>
>> As previously mentioned, a two-wallet configuration provides the user an
>> opportunity to safely split the two factors of protection (equivalent to=
 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 see=
d
>> 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 24
>> 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
>>
>

--000000000000ecf83c05c1e1742b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<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 cover=
ed by BIP39 since there is not restriction in how you choose your passphras=
e?&quot;</div><div dir=3D"auto"><br></div><div dir=3D"auto">- Correct, my i=
dea is covered by BIP39, and therefore compatible with BIP39... I see the &=
#39;quantum&#39; passphrase as an optional &#39;soft fork&#39; leading towa=
rds a more restricted choice of characters, rather than the fuller, less re=
strictive choice of characters.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">&quot;It&#39;s up to any user to choose his password like you pro=
pose. I see your proposal more like a way to choose my password rather than=
 anything that needs to be implemented somewhere.&quot;</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">- Correct also, my proposal is for an Infor=
mational BIP to educate users how to create a &#39;quantum&#39; passphrase,=
 which provides the same high degree of protection (2048^23 combinations) a=
s 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 &#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 add=
ress?&quot;</div><div dir=3D"auto"><br></div><div dir=3D"auto">- No, becaus=
e an unrestricted passphrase may contain characters different to those allo=
wed by the &#39;quantum&#39; passphrase. Memorisation of the 2nd layer pass=
phrase is very dangerous, whereby, an unfortunate accident 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 disguised as a 24 word seed. =
Therefore, discovery of a backup device with the extra, unrestricted charac=
ters that don&#39;t also open a (sacrificial) wallet, will be recognised as=
 a 2nd layer passphrase... This is when the $5 wrench is brought to the tab=
le 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 passphrase to generate the co=
mplete mnemonic (changing the password does change the resulting seed). Thu=
s you get a chicken-egg problem, at least for some implementations. Probabl=
y you could use the restore feature to work around this - 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 understand this last para=
graph 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 t=
he 2nd layer (or 2nd signing key) to add to the 1st layer (or 1st signing k=
ey) required to complete the full mnemonic, which then provides access to t=
he passphrase-protected wallet.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">eg. The 1st Bitcoin wallet is protected by a &#39;quantum&#39; pa=
ssphrase, containing the seed words of the 2nd Bitcoin wallet; inversely, t=
he 2nd Bitcoin wallet is protected by a &#39;quantum&#39; passphrase, conta=
ining 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">On Sun, 9 May 2021, =
08:24 Tobias Kaupat, &lt;<a href=3D"mailto:Tobias@kaupat-hh.de">Tobias@kaup=
at-hh.de</a>&gt; wrote:<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 cove=
red by BIP39 since there is not restriction in how you choose your passphra=
se?</div><div dir=3D"auto"><br></div><div dir=3D"auto">It&#39;s up to any u=
ser 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 implement=
ed somewhere.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><span styl=
e=3D"font-family:sans-serif">Don&#39;t I have plausible deniability already=
 with any other password that I keep in mind, since the seed without the pa=
ssword is already a valid address?</span><br></div><div dir=3D"auto"><br></=
div><div dir=3D"auto">One issue might be, that the passphrase is part of th=
e 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 =
could use the restore feature to work around this - but it&#39;s one step m=
ore that should be 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">Tobia=
s</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">B=
itPLATES=C2=AE (Chris) via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; schrieb am Sa., 8. Mai 2021, 17:21:<br></d=
iv><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"><b=
r></div><div dir=3D"auto">I&#39;d like to submit an idea for review, as a p=
otential informational BIP (Bitcoin Improvement Proposal), describing an op=
tional method of producing a BIP39 passphrase, using only BIP39 &#39;mnemon=
ic&#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 authenticati=
on, to protect a Bitcoin wallet using only 24 seed words, and therefore, pr=
oviding plausible deniability about the existence of this separate 2nd laye=
r passphrase.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;ve s=
uggested the name &#39;quantum&#39; passphrase to be used casually as a uni=
que identifier.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The data=
 stored within a &#39;quantum&#39; passphrase, is simultaneously the minimu=
m required data for reproducing a BIP39-compatible 24-word seed mnemonic...=
 hence, the name &#39;quantum&#39; seems fitting, to reflect the multiple s=
imultaneous 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=
 generated BIP39 seed words, to produce a &#39;25th-word&#39; BIP39-compati=
ble &#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 b=
e implemented with a two-wallet setup:</div><div dir=3D"auto"><br></div><di=
v dir=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 increa=
se in the level of protection, as that offered by the original BIP39 mnemon=
ic seed words (=E2=89=882048^23 possible combinations).</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">ie. A Bitcoin wallet with a 2nd layer &#39;=
quantum&#39;passphrase is protected by 2048^23 to the power of 2048^23 poss=
ible combinations.</div><div dir=3D"auto"><br></div><div dir=3D"auto">With =
existing computer capabilities, this level of protection is far greater tha=
n required; however, this does provide a sufficient level of protection for=
 each separate layer of a two-factor Bitcoin wallet, should any one layer b=
e accidentally 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"auto"><br></div><div dir=3D"auto">1st - generating the BIP39 mnemonic s=
eed words, using a BIP39-compatible hardware wallet.</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">2nd - Converting these seed words into the &#3=
9;quantum&#39; passphrase, following four simple rules, which most importan=
tly, do not destroy the integrity of the initial data.</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">Motivation...</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">The well established practice of preserving up to 24 s=
eed words for the purpose of reproduction of a Bitcoin wallet, suffers from=
 a major flaw... Exposure of these mnemonic seed words can cause catastroph=
ic loss 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=
 multi-factor solutions are available (including the standard BIP39 passphr=
ase, and hardware wallet multi-signature functionality), this proposal aims=
 to provide an extremely safe and secure &#39;low-tech&#39; option, that re=
quires minimal (non-destructive) adjustments to the seed words.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">Furthermore, the &#39;quantum&#39; =
passphrase offers a number advantages over the existing methods of multi-fa=
ctor protection:</div><div dir=3D"auto"><br></div><div dir=3D"auto">Firstly=
, this method of creating a passphrase leaves no evidence of its existence =
on any backup devices, providing plausible deniability in case of coercion.=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">This is because the pas=
sphrase 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.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">It presents a way of discouraging user-created words or sentences=
 (also known as &#39;brain-wallets&#39;), which often provide a drastically=
 reduced level of passphrase security, unbeknown to many users.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">The large amount of data required t=
o produce a &#39;quantum&#39; passphrase (up to 96 characters long), encour=
ages the physical backup of the passphrase.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Furthermore, the use of BIP39-only words provides a hig=
her degree of standardization, which can help to avoid potential mistakes m=
ade 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.</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">As previously mentioned, a two-wallet configuration provides the user an =
opportunity 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 di=
r=3D"auto">If a BIP39-compatible passphrase is created using a new set of 2=
4 seed words, it provides 76 degrees of extra complexity (ie. 1 with 76 zer=
os, 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 solut=
ion, provides adequate risk-management, when considering the production of =
multiple backup devices, strategically stored in multiple geographical loca=
tions.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Generating the &#=
39;quantum&#39; passphrase...</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">Following just four (non-destructive) BIP39-compatible rules, the 24 =
seed words can also function as a &#39;quantum&#39; passphrase:</div><div d=
ir=3D"auto"><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 =
compatible)</div><div dir=3D"auto"><br></div><div dir=3D"auto">2 . Only the=
 first four letters of each word</div><div dir=3D"auto">(BIP39 words requir=
e only this data for reproduction)</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">3 . Only upper case letters</div><div dir=3D"auto">(All alphabet=
 references use this standard format)</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">4 . No spaces between words</div><div dir=3D"auto">(Spaces re=
present an 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; passphr=
ase is simply 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 prod=
uctive technical discussion.</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">Thanks,</div><div dir=3D"auto"><br></div><div dir=3D"auto">Chris Johns=
ton</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div></div></di=
v>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"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" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
</blockquote></div>

--000000000000ecf83c05c1e1742b--