From: Aymeric Vitte <vitteaymeric@gmail•com>
To: James MacWhyte <macwhyte@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP39 seeds
Date: Wed, 26 Dec 2018 12:33:27 +0100 [thread overview]
Message-ID: <743fb106-977e-1f34-47af-9fb3b8621e72@gmail.com> (raw)
In-Reply-To: <CAH+Axy6dKDOkE6cQYZUusTUxxOSwWchOWxYh6ZkhnOgXuELaYg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2935 bytes --]
Another drawback I think is that people are not using it as seeds, they
just go to a wallet sw which proposes a new seed, write it somewhere, do
something with the wallet and forget about it, go to another one, create
another wallet, etc
Apparently it is not very well known even here that the probabilities
are very high to get a valid BIP39 seed even with 24 words, so, even
with a tool like yours, they can be misleaded, for example trying a few
words to replace the missing/incorrect one, get a valid seed and stay
stuck with it forever trying to play with BIP44/49 to find their keys
Probably what I am suggesting is not new (and therefore maybe not a good
suggestion): given a secret seed (a book, a document, a link, etc) and a
derivation path (an algo with secret parameter(s) to derive/order the
words and select the valid bip39 sequences), you get your BIP39 seeds
and don't have to write them
Of course we don't have to use necessarilly BIP39 for this but this is
what we have everywhere and this is what is compatible with it, then you
could use the same or a fake written "not very well hidden" BIP39 seed
to plausibly deny your real wallet
Le 25/12/2018 à 01:30, James MacWhyte a écrit :
>
>
> On Mon, Dec 24, 2018 at 2:48 PM Aymeric Vitte via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
>
> I don't see very well why it's easier to write n words that you
> cannot choose rather than a 32B BIP32 hex seed, and I have seen
> many people completely lost with their wallets because of this
>
>
> In practice it has quite a few qualities that make it a bit more
> resilient for physical (written) storage.
>
> If a few letters of a word get rubbed off or otherwise become
> illegible, it is pretty easy for a native speaker to figure out what
> the word is supposed to be. Even a non-native speaker could look
> through the word list and figure out which word fits. Missing
> characters in a hex string require more advanced brute force
> searching, which the average user isn't capable of.
>
> Additionally, having the bits grouped into words makes a more serious
> recovery easier. If you lose one entire word, it can be brute forced
> in about 5 minutes on a normal pc, even if you don't know which
> position the missing word is in (I have published a tool that does
> just this: https://jmacwhyte.github.io/recovery-phrase-recovery). If
> you are missing two words, you can brute force it in about a week
> (napkin math).
>
> If you were missing a random chunk of a hex string, I don't know how
> you'd go about brute forcing that in a timely manner.
>
> As an aside, from a UX standpoint we've seen that the 12 words don't
> *look* important so people don't take them seriously (and they get
> lost). A hex string or equivalent would look more password-y, and
> therefore would most likely be better protected by users.
>
> James
[-- Attachment #2: Type: text/html, Size: 4784 bytes --]
next prev parent reply other threads:[~2018-12-26 11:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-21 23:58 Aymeric Vitte
2018-12-23 18:46 ` Pavol Rusnak
2018-12-23 22:41 ` Aymeric Vitte
2018-12-25 0:30 ` James MacWhyte
2018-12-26 11:33 ` Aymeric Vitte [this message]
2018-12-26 18:54 ` James MacWhyte
2018-12-27 11:04 ` Aymeric Vitte
2018-12-31 16:52 ` Alan Evans
2019-01-01 19:44 ` Aymeric Vitte
2019-01-02 18:06 ` James MacWhyte
2019-01-04 0:02 ` Aymeric Vitte
2018-12-24 14:58 ` Tiago Romagnani Silveira
2018-12-23 20:55 ` Eric Scrivner
2018-12-23 21:08 ` Jameson Lopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=743fb106-977e-1f34-47af-9fb3b8621e72@gmail.com \
--to=vitteaymeric@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=macwhyte@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox