<unnamed>

Public Key

npub1tgll045nvu5aty3pg4mhzpns75u2eqe2uyw665yvskc6erutptcsa0avyr

Profile Code

nprofile1qqs950lh66fkw2w4jgs52am3qec02w9vsv4wz8dd2zxgtvdv379s4ugpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsgnjcvv

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:07:59 UTC

- reply

📅 Original date posted:2013-10-24
📝 Original message:I would like to propose a new BIP, that replaces BIP0039.
My initial problem was that BIP0039 is not backward compatible with Electrum. When trying to solve that, I realized that the seed encoding used in Electrum does not help, because it does not contain a version number information. However, BIP0039 suffers the same shortcoming: it does nothing to help a future replacement, it wants to be final. My first recommendation is to allocate a few bits of the mnemonic, in order to encode a "version number" along with the checksum bits.
The second problem is the wallet structure. There are multiple ways to use a BIP32 tree, and each client will certainly handle this differently. For Electrum, it is important to be able to recover an entire wallet from its mnemonic, using no extra information. Thus, the client needs to know which branches of the BIP32 tree are populated by default. This means that the "version number" I mentioned will not only be about the seed encoding, but it should also give some information about the wallet structure, at least in the case of Electrum.
The third problem is the dictionary. I do not like the dictionary proposed in BIP0039, because it contains too many short words, which are bad for memorization (I explained here how I designed the dictionary used by Electrum: https://bitcointalk.org/index.php?topic=153990.msg2167909#msg2167909). I had some discussions with slush about this, but I do not think it will ever be possible to find a consensus on that topic.
BIP0039 also suggests to use localized dictionaries, with non-colliding word lists, but it is not clear how that will be achieved; it seems to be difficult, because languages often have words in common. It looks like a first-come-first-served aproach will be used.
For these reasons, I believe that we need a dictionary-independent solution. This will allow developers to use the dictionary they like, and localization will be easy.
I would like to suggest the following solution:
1. Define a target of k bits: this target contains the metadata ("version number"), plus some extra bits for the checksum. For example, with k=16, we can allocate 8 bits for the version number, and 8 bits for checksum.
2. Pick a random number of length n+k bits, where n is the desired entropy of the seed, and k is the number of bits needed for the metadata (checksum, version number)
3. Translate this random number to a mnemonic string, using a dictionary.
4. Compute a hash of the mnemonic string (utf8 encoded).
5. Repeat steps 2, 3 and 4 until the k first bits of the hash are equal to the target defined in 1.
6. Use the final hash as input for bip32 (as the master seed)
This means that we "mine" for the seed, until the desired metadata is obtained in the hash. This "mining" also adds a bit of difficulty to the process of finding a seed (on average, it will require 2^k iterations). The entropy of the final hash is n, the number of unconstrained bits.
This solution makes it possible for developers to define new dictionaries, localized or adapted to a particular need.
The resulting mnemonics will always be usable with other clients, even if they do not know the dictionary.
I am willing to write a new BIP where this proposal is specified in detail.

2023-06-07 10:21:19 UTC

- reply

📅 Original date posted:2012-07-09
📝 Original message:I agree with Alan.
I too am happy to see my client listed on bitcoin.org, and I don't mind Bitcoin-Qt being listed first. I have no problem with a "czar" approach if it can solve conflicts.
I believe that it is useful to keep the 'clients' page on bitcoin.org, because it contributes to clarifying the difference between the Bitcoin client and Bitcoin as a protocol/network/ecosystem. It shows that Bitcoin is much more than its original implementation. It is a sign of health.
Thomas
-------- Original-Nachricht --------
> Datum: Mon, 9 Jul 2012 14:03:55 -0400
> Von: Alan Reiner <etotheipi at gmail.com>
> An: Gregory Maxwell <gmaxwell at gmail.com>
> CC: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
> Betreff: Re: [Bitcoin-development] Random order for clients page
> I generally agree with Greg. I don't see anything he's said or done as
> anti-alt-client.
>
> As an alt-client developer, I'm happy to see my client on the main page,
> but I'm also happy if that "clients" page is simply an acknowledgement
> that
> there's more to the Bitcoin world than just the Bitcoin-Qt client, and a
> link of where to find more information (i.e. the wiki). I would still *
> prefer* to have the page the way it is, because I think alt clients should
> be more accessible and word will spread better where it is now -- but I
> also recognize the inherent difficulty of gaining any kind of consensus of
> how it should be organized, what goes on the list, etc, and no matter how
> you do it, someone will complain about it being unfair or not right.
>
> We either have to have a "czar" who is trusted to make responsible
> decisions, and complaints of being unfair or recommendations for
> improvements can go through that person, but ultimately it is that person
> who makes the call. Or we just move it to another page that is less
> strictly controlled and where these things matter less. Trying to gain
> consensus among an amalgamation of developers all with competing
> priorities
> and "products" is a terrible way to try to agree on stuff.
>
> -Alan
>
>
>
>