Aymeric Vitte [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-26 📝 Original message:Another drawback I think ...
📅 Original date posted:2018-12-26
📝 Original message: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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181226/e047093a/attachment-0001.html>;
📝 Original message: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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181226/e047093a/attachment-0001.html>;