1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
|
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 381D3C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 May 2021 06:30:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 198C560A4D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 May 2021 06:30:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 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.01, RCVD_IN_MSPIKE_WL=-0.01,
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 PF_sJGrJYV1Q
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 May 2021 06:30:38 +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 D0E596071C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 May 2021 06:30:37 +0000 (UTC)
Received: from mail-lf1-f41.google.com ([209.85.167.41])
by smtp.hosts.co.uk with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256)
(Exim) (envelope-from <bitplates@marketnetworks.co.uk>)
id 1lfzR4-000BtJ-73
for bitcoin-dev@lists.linuxfoundation.org; Mon, 10 May 2021 07:30:36 +0100
Received: by mail-lf1-f41.google.com with SMTP id 2so21708810lft.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 09 May 2021 23:30:33 -0700 (PDT)
X-Gm-Message-State: AOAM532mUQgTiRGXbVzZggQ+ksBPjgfiSERs5opb82Qa9cPYd/r2dSTg
hT0KYxOwNeZ/e4m9iNAH2af3sVeBs0EYSf8XzOY=
X-Google-Smtp-Source: ABdhPJwfNl8oFvr/TMcUN180hHOXoRqalSA4fEelfDgUt1mkdWOhUB2NXlQ1RSKA2aGiVqBmn+QLs3BZ69K5uxc3JCA=
X-Received: by 2002:a05:6512:203a:: with SMTP id
s26mr15268128lfs.252.1620628233060;
Sun, 09 May 2021 23:30:33 -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>
<CAPyCnfu32KKmrmDEmx5QNNnzifNE_J5Sfi2uWoPZo0NA4ruqgg@mail.gmail.com>
In-Reply-To: <CAPyCnfu32KKmrmDEmx5QNNnzifNE_J5Sfi2uWoPZo0NA4ruqgg@mail.gmail.com>
From: "BitPLATES (Chris)" <bitplates@marketnetworks.co.uk>
Date: Mon, 10 May 2021 07:30:22 +0100
X-Gmail-Original-Message-ID: <CAAvTZ65Rm4MMGnC=5AVDfMm7_jcmzdsVXXFBA2R3BBJi-2Xdyw@mail.gmail.com>
Message-ID: <CAAvTZ65Rm4MMGnC=5AVDfMm7_jcmzdsVXXFBA2R3BBJi-2Xdyw@mail.gmail.com>
To: Tobias Kaupat <Tobias@kaupat-hh.de>
Content-Type: multipart/alternative; boundary="00000000000025096105c1f3eaeb"
X-Mailman-Approved-At: Mon, 10 May 2021 07:41:02 +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: Mon, 10 May 2021 06:30:41 -0000
--00000000000025096105c1f3eaeb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thank you for your reply Tobias,
I don't think that the chicken-egg scenario is relevant, but please let me
explain why:
Wallet A =3D seed words (A) - add minimal funds as a canary/sacrificial wal=
let
Wallet B =3D seed words (B) - add minimal funds as a canary/sacrificial wal=
let
Wallet AB =3D seed words (A) + 'quantum' passphrase using seed words (B) -
add 1/2 of main funds
Wallet BA =3D seed words (B) + 'quantum' passphrase using seed words (A) -
add 1/2 of main funds
If the backup plate containing seed words (A) is compromised, then minimal
funds are taken.
If the backup plate containing seed words (B) is compromised, then minimal
funds are taken.
Both backup plates must remain geographically separated.
Furthermore, backup plate (A) could be held by a 1st party, whilst backup
plate (B) could be held by a 2nd party, as part of a 2 of 2 multi-factor
(or multi-sig) setup.
I hope this clarifies everything.
Regards,
Chris
On Sun, 9 May 2021, 23:54 Tobias Kaupat, <Tobias@kaupat-hh.de> wrote:
> 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' leadi=
ng
>> 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 degre=
e
>> 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 differen=
t
>> to those allowed by the 'quantum' passphrase. Memorisation of the 2nd la=
yer
>> passphrase is very dangerous, whereby, an unfortunate accident could lea=
ve
>> your family without access to their inherence. The 'quantum' passphrase
>> encourages the use of multiple metal backup storage devices, but anythin=
g
>> more that A-Z (upper case only), would not be disguised as a 24 word see=
d.
>> Therefore, discovery of a backup device with the extra, unrestricted
>> characters that don't also open a (sacrificial) wallet, will be recognis=
ed
>> as a 2nd layer passphrase... This is when the $5 wrench is brought to th=
e
>> 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 cou=
ld
>> use the restore feature to work around this - but it's one step more tha=
t
>> 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 se=
ed
>> 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 tha=
t
>>> 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 co=
uld
>>> use the restore feature to work around this - but it's one step more th=
at
>>> should be mentioned.
>>>
>>>
>>> Kind regards
>>> Tobias
>>>
>>>
>>>
>>>
>>> BitPLATES=C2=AE (Chris) via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> schrieb am Sa., 8. Mai 2021,
>>> 17:21:
>>>
>>>> Hi,
>>>>
>>>> I'd like to submit an idea for review, as a potential informational BI=
P
>>>> (Bitcoin Improvement Proposal), describing an optional method of produ=
cing
>>>> 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, =
and
>>>> 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 o=
f
>>>> 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 o=
f
>>>> protection for each separate layer of a two-factor Bitcoin wallet, sho=
uld
>>>> 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 th=
e
>>>> integrity of the initial data.
>>>>
>>>> Motivation...
>>>>
>>>> The well established practice of preserving up to 24 seed words for th=
e
>>>> purpose of reproduction of a Bitcoin wallet, suffers from a major flaw=
...
>>>> Exposure of these mnemonic seed words can cause catastrophic loss of f=
unds
>>>> 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 walle=
t
>>>> multi-signature functionality), this proposal aims to provide an extre=
mely
>>>> safe and secure 'low-tech' option, that requires minimal (non-destruct=
ive)
>>>> 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 it=
s
>>>> existence on any backup devices, providing plausible deniability in ca=
se of
>>>> coercion.
>>>>
>>>> This is because the passphrase is easily created from a genuine 24 see=
d
>>>> 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 (als=
o
>>>> known as 'brain-wallets'), which often provide a drastically reduced l=
evel
>>>> of passphrase security, unbeknown to many users.
>>>>
>>>> The large amount of data required to produce a 'quantum' passphrase (u=
p
>>>> to 96 characters long), encourages the physical backup of the passphra=
se.
>>>>
>>>> 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 an=
d
>>>> symbols. Increased complication (disorderly, and non-human-friendly), =
does
>>>> not always equal increased complexity (orderly, and more human-friendl=
y),
>>>> or increased security.
>>>>
>>>> As previously mentioned, a two-wallet configuration provides the user
>>>> an opportunity to safely split the two factors of protection (equivale=
nt 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
>>>> 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
>>>> 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
>>>>
>>>
--00000000000025096105c1f3eaeb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div dir=3D"auto">Thank you for your reply Tobias,</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">I don't think that the chi=
cken-egg scenario is relevant, but please let me explain why:</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Wallet A =3D seed words (A) - add min=
imal funds as a canary/sacrificial wallet</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">Wallet B =3D seed words (B) - add minimal funds as a cana=
ry/sacrificial wallet</div><div dir=3D"auto"><br></div><div dir=3D"auto">Wa=
llet AB =3D seed words (A) + 'quantum' passphrase using seed words =
(B) - add 1/2 of main funds</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">Wallet BA =3D seed words (B) + 'quantum' passphrase using seed =
words (A) - add 1/2 of main funds</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">If the backup plate containing seed words (A) is compromised, the=
n minimal funds are taken.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">If the backup plate containing seed words (B) is compromised, then minim=
al funds are taken.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Both=
backup plates must remain geographically separated.</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">Furthermore, backup plate (A) could be held by=
a 1st party, whilst backup plate (B) could be held by a 2nd party, as part=
of a 2 of 2 multi-factor (or multi-sig) setup.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">I hope this clarifies everything.</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><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sun, 9 May 2021, 23:54 Tobias Kaupat, <=
<a href=3D"mailto:Tobias@kaupat-hh.de">Tobias@kaupat-hh.de</a>> wrote:<b=
r></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 Chris,<div dir=
=3D"auto">thanks for the clarification. It makes sense so far.</div><div di=
r=3D"auto"><br></div><div dir=3D"auto">About the "chicken - egg" =
problem:</div><div dir=3D"auto">When you generate a BIP39 mnemonic "A&=
quot; without password, you get a Seed "As" from which you derive=
your private key.</div><div dir=3D"auto">Using the same mnemonic with a pa=
ssphrase will give you a different seed "As*" with a different pr=
ivate and public key.</div><div dir=3D"auto">Now your process must look lik=
e:</div><div dir=3D"auto">- Generate mnemonic A without password (will neve=
r be used)</div><div dir=3D"auto">- Generate mnemonic B* using words from A=
as password</div><div dir=3D"auto">- Generate 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 might have impact on the actual proces=
s, 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><di=
v dir=3D"auto">Kind regards</div><div dir=3D"auto">Tobias</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 (Chris) <<a href=3D"mailto:bitplate=
s@marketnetworks.co.uk" target=3D"_blank" rel=3D"noreferrer">bitplates@mark=
etnetworks.co.uk</a>> schrieb am So., 9. Mai 2021, 10:29:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">Hi Tobias,</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">In answer to your question=
s...</div><div dir=3D"auto"><br></div><div dir=3D"auto">"Isn't you=
r suggestion already covered by BIP39 since there is not restriction in how=
you choose your passphrase?"</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">- Correct, my idea is covered by BIP39, and therefore compatible=
with BIP39... I see the 'quantum' passphrase as an optional 's=
oft fork' leading towards a more restricted choice of characters, rathe=
r than the fuller, less restrictive choice of characters.</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">"It's up to any user to choose h=
is 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.&q=
uot;</div><div dir=3D"auto"><br></div><div dir=3D"auto">- 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. Shoul=
d their 24 seed words be compromised (or posted on the internet), this extr=
eme level of protection would make it impossible to brute-force the wallet =
without 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 passwor=
d is already a valid address?"</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">- No, because an unrestricted passphrase may contain characters=
different to those allowed by the 'quantum' passphrase. Memorisati=
on of the 2nd layer passphrase is very dangerous, whereby, an unfortunate a=
ccident could leave your family without access to their inherence. The '=
;quantum' passphrase encourages the use of multiple metal backup storag=
e devices, but anything more that A-Z (upper case only), would not be disgu=
ised as a 24 word seed. Therefore, discovery of a backup device with the ex=
tra, unrestricted characters that don't also open a (sacrificial) walle=
t, will be recognised as a 2nd layer passphrase... This is when the $5 wren=
ch 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, tha=
t the passphrase is part of the mnemonic. A hardware wallet needs the passp=
hrase 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."</div><div=
dir=3D"auto"><br></div><div dir=3D"auto">- I'm not sure that I fully u=
nderstand this last paragraph of your email, but just to be clear, the '=
;quantum' passphrase is made from the 24 seed words of a separate walle=
t. 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 t=
hen provides access to the passphrase-protected wallet.</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">eg. The 1st Bitcoin wallet is protected by =
a 'quantum' passphrase, containing the seed words of the 2nd Bitcoi=
n 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></di=
v></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">On Sun, 9 May 2021, 08:24 Tobias Kaupat, <<a href=3D"mailto:Tobias@kau=
pat-hh.de" rel=3D"noreferrer noreferrer" target=3D"_blank">Tobias@kaupat-hh=
.de</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: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 b=
y 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 t=
o 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 so=
mewhere.</div><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 password that I keep in mind, since the seed without the passwor=
d 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 the mne=
monic. A hardware wallet needs the passphrase to generate the complete mnem=
onic (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 t=
hat 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">Tobias</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><br><br><div clas=
s=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">BitPLA=
TES=C2=AE (Chris) via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" rel=3D"noreferrer noreferrer noreferrer" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>> schrieb am Sa., 8. Mai 20=
21, 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,<di=
v dir=3D"auto"><br></div><div dir=3D"auto">I'd like to submit an idea f=
or review, as a potential informational BIP (Bitcoin Improvement Proposal),=
describing an optional method of producing a BIP39 passphrase, using only =
BIP39 'mnemonic' seed words.</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">The idea specifically refers to a method of introducing two-fa=
ctor authentication, to protect a Bitcoin wallet using only 24 seed words, =
and therefore, providing plausible deniability about the existence of this =
separate 2nd layer passphrase.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">I've suggested 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 stored within a 'quantum' passphrase, is simulta=
neously the minimum required data for reproducing a BIP39-compatible 24-wor=
d seed mnemonic... hence, the name 'quantum' seems fitting, to refl=
ect the multiple simultaneous states of data.</div><div dir=3D"auto"><div d=
ir=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 '25th-word&=
#39; BIP39-compatible 'quantum' passphrase.</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Two-factor authentication (2FA) or (2 of 2 mult=
i-signature) can be implemented with a two-wallet setup:</div><div dir=3D"a=
uto"><br></div><div 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"au=
to"><br></div><div dir=3D"auto">The 'quantum' passphrase offers an =
exponential increase in the level of protection, as that offered by the ori=
ginal BIP39 mnemonic seed 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 'quantum'passphrase is protected by 2048^23 to the pow=
er of 2048^23 possible combinations.</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">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.</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">This method of passphrase generation, consists of two par=
ts:</div><div dir=3D"auto"><br></div><div dir=3D"auto">1st - generating the=
BIP39 mnemonic seed words, using a BIP39-compatible hardware wallet.</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">2nd - Converting these seed w=
ords into the 'quantum' passphrase, following four simple rules, wh=
ich most importantly, do not destroy the integrity of the initial data.</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">Motivation...</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">The well established practice of pres=
erving up to 24 seed words for the purpose of reproduction of a Bitcoin wal=
let, suffers from a major flaw... Exposure of these mnemonic seed words can=
cause catastrophic 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 stand=
ard BIP39 passphrase, and hardware wallet multi-signature functionality), t=
his proposal aims to provide an extremely safe and secure 'low-tech'=
; option, that requires minimal (non-destructive) adjustments to the seed w=
ords.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Furthermore, the &=
#39;quantum' passphrase offers a number advantages over the existing me=
thods of multi-factor 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 i=
s because the passphrase is easily created from a genuine 24 seed word mnem=
onic; 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 wor=
ds or sentences (also known as 'brain-wallets'), which often provid=
e a drastically reduced level of passphrase security, unbeknown to many use=
rs.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The large amount of =
data required to produce a 'quantum' passphrase (up to 96 character=
s long), encourages the 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 degree of standardization, which can help to avoid poten=
tial mistakes made by creating unnecessarily complicated combinations of le=
tters, numbers and symbols. Increased complication (disorderly, and non-hum=
an-friendly), does 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 provid=
es the user an opportunity to safely split the two factors of protection (e=
quivalent to a 2 of 2 'multi-sig' setup).</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">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 2n=
d factor solution, provides adequate risk-management, when considering the =
production of multiple backup devices, strategically stored in multiple geo=
graphical locations.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Gen=
erating the 'quantum' passphrase...</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Following just four (non-destructive) BIP39-compatible =
rules, the 24 seed words can also function as a 'quantum' passphras=
e:</div><div dir=3D"auto"><br></div><div dir=3D"auto">1 . Only BIP39 words<=
/div><div dir=3D"auto">(Standard list of 2048 English words - other languag=
es 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 require only this 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 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"aut=
o">(Spaces represent an 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 simply a single string of all 24 seed words, set out us=
ing the above rules.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I w=
elcome a productive technical discussion.</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">Thanks,</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></d=
iv></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer" target=3D"_b=
lank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br=
>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
--00000000000025096105c1f3eaeb--
|