Re: [bitcoin-dev] bip39

I agree removing any ambiguity would be good. I'd also like to see removal of words that are a strict subset of another word. Words like add (which is a subset of addict and address). As far as entropy loss, I think even with an 1000 word list and a 12 word seed, it would be unlikely in a time far

Re: [bitcoin-dev] bip39

Trezor recovery cards look like this what addresses the issue: https://wiki.trezor.io/images/Seed_card_example.jpg 1. Each word has a box around it. 2. You write the words one under the other, not next to each other. On Mon, 17 Jan 2022 at 23:38, Jeremy via bitcoin-dev < bitcoin-dev@lists.linux

Re: [bitcoin-dev] bip39

This is a good point, but can be addressed by having a non-void whitespace character (e.g., win x estate). changing BIP39 would be hard since software expects a standard list; it would also be possible to rejection sample for seeds that do not contain these pairs, unclear how much entropy would be

[bitcoin-dev] bip39

really don't like that art, work, and artwork are 3 different words would be nice to clean up adjacent ambiguity it's not a big deal, but it can lead to confusion when writing things down dup: ('canal', 'arm') ('can', 'alarm') dup: ('canal', 'one') ('can', 'alone') dup: ('canal', 'ready') ('can

Re: [bitcoin-dev] BIP39 seeds

What I have in mind is in my latest reply (difficult to have some kind of fluent discussions on this list given the moderation and delayed posts) I would just add that the derivation method (indeed something like what you are sketching below) should estimate that there is enough entropy from the s

Re: [bitcoin-dev] BIP39 seeds

On Wed, Jan 2, 2019 at 3:40 AM Alan Evans via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > I think any method that doesn't use real entropy, but some fake source of > randomness, such as a book is asking to be hacked and so is not a > reasonable idea. > > If an algorithm for boo

Re: [bitcoin-dev] BIP39 seeds

You are simplifying too much what I am suggesting What I am suggesting is: set a derivation method for BIP39 like for BIP32 (having the seed for BIP32 and not the derivation path is just like having nothing) and use this derivation method from a "book" (a "book" being a book, a document, a lin

Re: [bitcoin-dev] BIP39 seeds

> Using some algorithm to take some input and generate a bip39 phrase that you can use with any bip39 wallet sounds perfectly reasonable. I think any method that doesn't use real entropy, but some fake source of randomness, such as a book is asking to be hacked and so is not a reasonable idea. If

Re: [bitcoin-dev] BIP39 seeds

Le 26/12/2018 à 19:54, James MacWhyte a écrit : > > On Wed, Dec 26, 2018 at 11:33 AM Aymeric Vitte > wrote: > > 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 s

Re: [bitcoin-dev] BIP39 seeds

On Wed, Dec 26, 2018 at 11:33 AM Aymeric Vitte wrote: > 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 > Just a small

Re: [bitcoin-dev] BIP39 seeds

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 prob

Re: [bitcoin-dev] BIP39 seeds

On Mon, Dec 24, 2018 at 2:48 PM Aymeric Vitte via bitcoin-dev < 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 becau

Re: [bitcoin-dev] BIP39 seeds

Why is this a SLIP and not a BIP? Will it require a BIP39 seed, or will work with any seed format? On 12/23/18 19:46, Pavol Rusnak via bitcoin-dev wrote: On 22/12/2018 00:58, Aymeric Vitte via bitcoin-dev wrote: Has anybody already looked at this: given N randomly chosen words belonging to a B

Re: [bitcoin-dev] BIP39 seeds

Exactly This is surprising, I would have expected the probabilities to be much more lower It just means that scanning whatever (secret) book, document, link, etc, you will find easily BIP39 seeds, even of 24 words So, it just means that you don't have to write your seed since you can recover it

Re: [bitcoin-dev] BIP39 seeds

I believe it would depend upon the entropy used for the seed, as that would affect how many bits the checksum represents. https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#Generating_the_mnemonic So for a 24 word / 256 bit mnemonic the checksum is 8 bits, thus there are 8 valid checks

Re: [bitcoin-dev] BIP39 seeds

Quite interesting. Not familiar with prior art here, but would be interested in what your results are showing if you’re willing to share? On Sun, Dec 23, 2018 at 11:44 Aymeric Vitte via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Has anybody already looked at this: given N rando

Re: [bitcoin-dev] BIP39 seeds

On 22/12/2018 00:58, Aymeric Vitte via bitcoin-dev wrote: > Has anybody already looked at this: given N randomly chosen words > belonging to a BIP39 2048 words dictionary, what is the probability to > get a "valid" BIP39 seed (ie with the right checksum)? 1:256 for 24 words 1:16 for 12 words This

[bitcoin-dev] BIP39 seeds

Has anybody already looked at this: given N randomly chosen words belonging to a BIP39 2048 words dictionary, what is the probability to get a "valid" BIP39 seed (ie with the right checksum)? The result looks (very) surprising to me and might have some use cases, just would like to know if this to

[bitcoin-dev] BIP39 (mnemonic seeds) Unicode normalization compatibility issue

I am working on a replacement for BIP39 and noticed that the password section mandates a Unicode normalization pass but does not prohibit unassigned character points. I believe that this is problematic as newer drafts of Unicode alter the output of normalization passes. So if a user assigned a pa