Bitcoin Improvement Proposals

@voisine

Here are my restrictions:

1. High priority on simple and common french words.
2. Only words with 5-8 letters.
3. A word is fully recognizable by typing the first 4 letters (special french characters "é-è" are considered equal to "e", for exemple "museau" and "musée" can not be together).
4. Only infinitive verbs, adjectives and nouns.
5. No pronouns, no adverbs, no prepositions, no conjunctions, no interjections (unless a noun/adjective is also popular than its interjection like "mince;chouette").
6. No numeral adjectives.
7. No words in the plural (except invariable words like "univers", or same spelling than singular like "heureux").
8. No female adjectives (except words with same spelling for male and female adjectives like "magique").
9. No words with several senses AND different spelling in speaking like "verre-vert", unless a word has a meaning much more popular than another like "perle" and "pairle".
10. No very similar words with 1 letter of difference.
11. No essentially reflexive verbs (unless a verb is also a noun like "souvenir").
12. No words with "ô;â;ç;ê;œ;æ;î;ï;û;ù;à;ë;ÿ".
13. No words ending by "é;ée;è;et;ai;ait".
14. No demonyms.
15. No words in conflict with the spelling corrections of 1990 (http://goo.gl/Y8DU4z).
16. No embarrassing words (in a very, very large scope) or belonging to a particular religion.
17. No identical words with the Spanish wordlist (as Y75QMO wants).

4 wordlists used:

• http://pastebin.com/Drs1HY0v (3726 words) from http://o.bacquet.free.fr/db2.htm
• http://goo.gl/ymSBeY (336531 words) from http://www.pallier.org/ressources/dicofr/dicofr.html
• http://dict.xmatiere.com/noms_communs_par_nombre_de_lettres.php
• Thomas Voegtlin's wordlist

Spelling verified with Hunspell French Dictionnary (1990 and Classique) in Notepad++, and meaning verified with https://fr.wiktionary.org and http://www.larousse.fr/ for hundreds words.

Guys can review: @ecdsa @NicolasDorier @EricLarch @nicolasbigot @pollastri-pierre

Thanks to Thomas Voegtlin for his wordlist!

Please wait before merging.

--- The following message is partially outdated because of the evolution of the wordlist. ---

J'ai défini un maximum de restrictions "raisonnables" pour qu'un individu puisse deviner le plus facilement possible un de ses mots en cas d'oubli (ou s'en souvenir facilement).

Pour les mots "embarrassants", il s'agit de mots qui peuvent être assimilés à une vilaine insulte, de certains mots relatifs à une maladie grave, à la mort, à la pauvreté, au crime, à la violence, au domaine médical, à des attitudes et bien d'autres.

J'ai fait de mon mieux pour supprimer les mots qui présentaient une ressemblance avec un autre mot, à l'oral comme à l'écrit. Plusieurs centaines de mots qui avaient une différence de 1 lettre (ou 1 lettre différente) avec un autre mot ont été supprimés. Je considère que le résultat est plutôt satisfaisant, loin d'être parfait, mais tout à fait correct. Aussi, les restrictions n°6 et 10 sont complémentaires à ce problème.

J'estime qu'il y a 1% de mots potentiellement inconnus du public (comme "quantum"), et 5% de mots avec des sens qui sont potentiellement incertains par le public (comme "fongible"). Je considère ces marges comme convenables.

Notez que certains éléments chimiques du tableau périodique sont présents, les plus populaires.

Pour une vérification plaisante, voici la version imprimable (5 pages PDF A4): https://www.dropbox.com/sh/xlq3x2anb706uw1/AADUYAqcBvkvUPdhwC2uLWmEa?dl=0

Si vous voulez vérifier en 1 lecture, focalisez-vous sur les restrictions n°2,3,5,8 et 11. Étant donné l'homogénéité de la liste (et le bon sens qu'elle doit avoir), les mots contraires aux restrictions n°1,4 et 13 devront vous sauter aux yeux. Comptez 15 minutes de lecture par page. Je recommande quand même une deuxième lecture.

J'espère que vous apprécierez cette wordlist, c'est un travail de plus de 70 heures que je n'envisageais pas de faire au début, étant donné l'ampleur et la responsabilité de la tâche.

Si un mot vous semble inapproprié, ou si vous avez des remarques à faire par rapport aux restrictions, vous pouvez m'en faire part.

Sachez aussi que si elle vous convient, elle sera intégrée dans une des prochaines versions de breadwallet avec les autres wordlists étrangères.

Adds mainnet and testnet3 activation parameters. This uses the "speedy trial" approach [0] with some refinements to the exact mechanism [1], as implemented in bitcoin/bitcoin#21377 . Parameters are selected based on previous discussions [2] [3] [4]. The parameters are:

• starttime = 2021-04-24 00:00 UTC
• timeout = 2021-08-11 00:00 UTC
• min_activation_height = 709632 (est mid November 2021, mainnet only)
• threshold = 1815 / 2016 blocks (90%, mainnet only)

In terms of block heights, that will likely mean the first signalling period for mainnet should start at height 681408, approximately April 29th UTC, and will likely mean signalling will continue for 8 retarget periods until height 697536 (which if blocks arrived at 10 minute intervals, would be due around 2021-08-20).

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html [1] https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-814494847 [2] (90%) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018425.html [3] (May/August/Nov) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018715.html [4] (specific parameters) https://github.com/bitcoin/bips/pull/1081

Adds a global type for xpubs as discussed on the bitcoin-dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016894.html

#478 added a label to BIP 90 that I disagree with. While the term "hard fork" is sometimes used in the way defined in BIP 123, it also is used by many -- including the BIP 123 author -- to refer to consensus changes that require network-wide coordination in deployment to avoid a chain split[1], which is untrue for BIP 90.

As the whole purpose of this BIP is explain the type of consensus change that was made and point out that the network split risk is minimal, I don't accept the label "hard fork" as a useful or correct designation, and I think it does a disservice to our collective understanding of consensus changes to try to apply a label like this.

--

[1] From https://medium.com/@elombrozo/forks-signaling-and-activation-d60b6abda49a:

Since hard forks loosen or eliminate existing rules, blocks which would have been rejected by the old rules are now accepted by nodes using the new rules. Examples include increasing the block reward, increasing the maximum base block size, changing the block header format, or changing the proof of work function. Nodes that do not update their rules will reject these blocks and will continue to follow only chains that enforce the old rules. This means that unless all nodes update, we will get a chain split.

Hello,

BIP39 is already implemented in Trezor, Multibit HD and bitcoinj 0.11. Other projects also agreed to eventually implement it (Electrum). Please merge the latest version of BIP39 and change status from Draft to Accepted.

Thanks, Marek

This proposed BIP was posted to the mailing list just under two months ago. As there has been no serious objections, (unfortunately no mailing list feedback at all), I wish to formally ask for a BIP number to be assigned to our proposal.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014396.html

This BIP defines logical hierarchy for deterministic wallets based on algorithm described in BIP-0032. It is a particular application of the general idea described there.

I left it unclear / open to interpretation on whether to use ideographic spaces, but realized that without being specific on its necessity, developers may implement something that would cause trouble with the Japanese user. (two words looking like one word, or phrase verification failing because it can't handle ideographic spaces, etc.)

Hopefully, this will clear up any mis-understandings.

• Increase the maximum length of an address from 32 to 512 bytes and clarify that the entire message should be rejected if it contains a longer address. (from https://github.com/bitcoin/bips/pull/766#issuecomment-519248699)

• Remove a contradiction about unknown address types - "MUST ignore" VS "MAY store and gossip".

• Recommend gossiping addresses for unknown network ID and for networks to which the node is not currently connected to. (from https://github.com/bitcoin/bips/pull/766#issuecomment-545067608)

• Clarify that the entire message should be rejected if it contains an address with unexpected size (e.g. IPv4 address with length 5).

This adds a German word list with the following properties:

• Only ASCII letters (no äöüß, no dashs or apostrophes)
• Only nouns in nominative case (no plurals, no genitives), i.e. all startig with an uppercase letter
• At least 4, at most 6 letters
• First 4 letters identify the word uniquely
• No offensive words
• Tried to avoid words with ambiguous spelling (Delphin, Delfin)

I have been testing with some colleagues to create a wordlist for BIP0039 for the Japanese language.

We have decided on the current word list for the following reasons:

1. Japanese borrowed Chinese symbol character set (Kanji) are filled with homonyms that are often only discernible via the Kanji used, we thought that would lower memorability (as the words are random, and context is not possible). This is why we chose to use only the hiragana phonetic character set.
2. If the user inputs any character outside of the hiragana character set (such as katakana character set) the developer may automatically replace with the hiragana to check validity of the words.
3. Hiragana is easier to write down by hand than Kanji and Katakana, and will be easy for all ages (both young and old)

We are anxious for any comments or criticisms that you may have.

According to the psbt Input Finalizer spec "All other data except the UTXO and unknown fields in the input key-value map should be cleared from the PSBT. The UTXO should be kept to allow Transaction Extractors to verify the final network serialized transaction." In Bip78, the receiver clears this data after it finalizes its inputs, even if the utxo belongs to the sender which will need that data.

I ran into a problem where LND's FinalizePsbt gRPC fails when this utxo data is missing. I see no good reason to remove this utxo information from the PSBT. I think LND's RPC should also succeed regardless of this data being present because it can look it up with the unsigned_tx's input outpoint (that's what bitcoind's finalizePsbt rpc does). Still I think LND's RPC is technically BIP-0174 spec-compliant while BIP-0078 seems not to be.

https://github.com/lightningnetwork/lnd/blob/cf9a9864cf253dbbcac5904d360bbbde763e1ebe/lnwallet/rpcwallet/rpcwallet.go#L270-L286 According to the psbt Input Finalizer spec "All other data except the UTXO and unknown fields in the input key-value map should be cleared from the PSBT. The UTXO should be kept to allow Transaction Extractors to verify the final network serialized transaction."

I ran into a problem where an LND acting as sender FinalizePsbt gRPC fails when sender utxo information is missing. I see no good reason to remove utxo information from the PSBT.

tagging this issue in the rust-payjoin library

@nickfarrow @kixunil @nicolasdorier

Many wordlists were proposed here, but they were closed with the following note:

For now, the author(s) of BIP 39 have decided not to accept any further word lists into BIP 39 itself, and encourage adding new ones to the WLIPs repo here: https://github.com/p2w34/wlips

I have added the note to the BIP's wiki so that people will know where to open these PRs going forward.

There is currently no African language supported in the available set of wordlists used for generating mnemonics. With this PR, we are creating a wordlist for the swahili language. Swahili has an estimate of 200 million speakers in the whole world. We believe this will increase bitcoin adoption as some wallets (Etta Wallet) are looking forward to implement this wordlist.

The Swahili words were selected with the following rules:

1. Words can be uniquely determined typing the first 4 characters.
2. No accents or special characters.
3. No words with double spelling.
4. No offensive words.
5. No words already used in other language mnemonic sets.
6. No words with double spelling.
7. Words are 4-8 letters long.
8. No plural words.

The wordlist used for this implementation were derived from https://packetstormsecurity.com/files/32019/swahili.gz.html

All words have been carefully cross-checked by Swahili language experts.

Thanks to @extheoisah @vladimirfomene @brandonodiwuor (faith [email protected]) (Paul Warambo) for their contribution to this project.

Initial version posted to bitcoin-dev in May.

Wallet policies are implemented in the Ledger bitcoin app (in the upcoming version 2.1.0).

The following PR experimenting with an HWI integration might provide more context and an end-to-end demo:

• https://github.com/bitcoin-core/HWI/pull/647