Re: [bitcoin-dev] BIP- & SLIP-0039 -- better multi-language support
> as it seems bad design to have to fix and maintain a wordlist for every language as the checksum depends on it. >From BIP39: > The conversion of the mnemonic sentence to a binary seed is completely independent from generating the sentence. This results in rather simple code; there are no constraints on sentence structure and clients are free to implement their own wordlists or even whole sentence generators, allowing for flexibility in wordlists for typo detection or other purposes. > > Although using a mnemonic not generated by the algorithm described in "Generating the mnemonic" section is possible, this is not advised and software must compute a checksum for the mnemonic sentence using a wordlist and issue a warning if it is invalid. So BIP39 states "no constraints on sentence structure and clients are free to implement their own wordlists or even whole sentence generators" and yet at the same time one paragraph later "this is not advised and software must compute a checksum for the mnemonic sentence using a wordlist and issue a warning if it is invalid"... My interpretation of this: 1. ChecksumCheck function attempts to 1. find the wordlist 2. calculate the checksum. 2. If it fails to find the wordlist, return false 3. If the checksum doesn't match return false 4. If ChecksumCheck returns false, "issue a warning" but do not block seed generation. "We couldn't check if your phrase is correct... you're on your own" 99.99% of implementing apps interpretation: (remember, error handling for userspace is not done by the BIP39 library, but the app that uses it) 1. Run ChecksumCheck 2. If False, hard fail, do not allow seed generation. If more apps would implement to the word of the BIP39 spec, multiple languages make sense, but since reality is no one follows the spec (/the spec is way too open to interpretation) then expecting every app to load every language is unreasonable. Electrum actually handles BIP39 recovery the way the BIP specifies. I can restore random strings if I want, and it warns me, and I can ignore it if I wish. Anywho. The BIP39 multi-language feature is crucial for non-English speakers especially from Asia. Maybe northern Europeans have no problem with English word spelling, but watching a normal Japanese person write down their English mnemonic is painful. One letter at a time, worried they wrote it wrong... still make mistakes... lose money because of it. Whereas users of Copay etc. that support Japanese wordlist write down their seed easily, and I have never heard of a Japanese newbie complaining about "but I'm writing it just how I have it written down" about their Japanese seed... only English. Not trying to give anyone a hard time, just telling the facts: lack of localized words for recovery phrase causes more money loss than supporting it. (When push comes to shove, at the very least Electrum will always support their recovery because it lets you hash anything) This is all anecdotal of course. Just sharing my experience evangelizing in Japan. Thanks, Jon 2018年11月8日(木) 21:16 SomberNight via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > Do you specifically want to support changing the language of seed > words, while keeping the bip32 root seed they generate unchanged? > What is the usecase for this? > > You mention that BIP39 already supports a few different languages. > While this is true, many (I would guess most!) wallets only > support the English wordlist. > There are doubts even from the authors of the BIP whether it was > a good idea in the first place to support multiple languages [0]. > I don't find this surprising as it seems bad design to have to fix and > maintain a wordlist for every language as the checksum depends on it. > The supported wordlists are effectively a part of the specification, > and every new list would just make that specification larger. > > If changing the language of seeds is not a requirement, then look > into Electrum seeds. They are language/wordlist agnostic. > > Mnemonic Sentence => PBKDF2 => BIP-0032 Seed > > The bip32 seed is derived by hashing the normalized mnemonic, and the > checksum is derived the same way but by using a different cheaper > hash (single round of HMAC-SHA512; generation grinds until it matches > a pattern) [1]. For example, "9dk" is a valid segwit electrum seed. > > > [0]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015507.html > [1]: http://docs.electrum.org/en/latest/seedphrase.html > > > > Date: Wed, 7 Nov 2018 00:16:41 +0800 > > From: Weiji Guo weij...@gmail.com > > Subject: [bitcoin-dev] BIP- & SLIP-0039 -- better multi-language > > support > > > > Hello everyone, > > > > I just realized that BIP-0039 is language dependent. I was assuming the > > other way till I looked closer. The way the seed is derived from a > BIP-0039 > > entropy, as is shown below, depends on which language to generate the > > mnemonic sentence: > > > > Entropy <=> Mnemonic Sentence =>
Re: [bitcoin-dev] BIP Proposal - Address Paste Improvement
> > Do you know any reasonably convenient mechanism for end user to > > transfer an address from, say, a web page to the wallet address > > input field ? > > - QR code scanning of a Bitcoin URI > - On Android: A "bitcoin:" URI intent or a BIP70 payment message > intent > - On desktop OSes there are similar mechanisms to launch Apps from the > browser (e.g. for mailto: links) This works if the author of the web page thought about this, and created appropriate liks/qr codes. In many cases, addresses are just presented for users as text, to copy. People also send addresses in message apps and emails. Maybe if applications start to autodetect bitcoin addresses and convert them to bitcoin: links, there will be less need to copy-paste. But I suspect that this feature will not be quickly adopted by applications. > For cases where the payee is a well-known entity the BIP70 payment > protocol has authentication via certificates. That doesn't work for > the "the person in front of you is the only trust anchor you have" > usecase though. There are also BIP75 and BIP47 that may help, but the number of wallets that support these protocols is small (I think in part because of relative complexity of these protocols). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal - Address Paste Improvement
>The problem will be to come up with an address authentication procedure that will be convenient for users and widely supported, as a result. You could locally hash the destination address and from the hash derive a BIP39 style list of 12 words for visual comparison. I would advise against using color or graphics -- the brain is too good at "snapping" to an expected perception when it is running in graphics mode instead of symbolic mode. On Thu, Nov 8, 2018 at 4:41 AM Dmitry Petukhov via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > Copying addresses to the clipboard should be discouraged, rather than > > supported. > > Do you know any reasonably convenient mechanism for end user to > transfer an address from, say, a web page to the wallet address > input field ? > > The clipboard is just a low-hanging fruit for malware, anyway. It just > the most easy point to replace an address. If the computer is > compromized, malware can edit the web page in the memory of the browser > process, for example. If it shown as QR code, malware can decode, > detect that it is an address, and replace the image of QR code. > > I think that the only way to protect from this is to add some form of > authentication for an address - 2fa (transfer checksum via second > channel), visual fingerprints for addresses, that will are hard to > detect (and hence, replace) for malware, signing the destination address > with the key of an address that is already known and checking the > signature, etc. > > The problem will be to come up with an address authentication procedure > that will be convenient for users and widely supported, as a result. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal - Address Paste Improvement
> On Nov 7, 2018, at 13:28, Andreas Schildbach via bitcoin-dev > wrote: > > Copying addresses to the clipboard should be discouraged, rather than > supported. > > It is an inherently insecure mechanism. Regardless of the OS used, any > application can monitor the clipboard for Bitcoin addresses and replace > any address with their own, usually without any specific permission or > confirmation by the user. Effectively this steals Bitcoins if the user > doesn't compare addresses manually. > > This is a real risk, as this kind of malware has already been seen. One can also make the argument that if the user's clipboard is able to be read/modified, then their working environment is already compromised and that the responsibility is already not upon specific application software, but the user or OS. Down here in the real world, an application that does not support copying and pasting of addresses is not an application that is very useful (to say the least) to many people who want to manage their own wallet, though I understand your desire to avoid such. Perhaps offering alternatives such as supporting signed BIP70 payment requests is what you mean to do. That said, I still think working around specific malware threats and vectors isn't the application's job, especially when doing so for a tiny, tiny fraction of users that have malware outweighs the needs of the 95%+ that need to support the "I have an address on my clipboard I need to pay" case. Best, -jp -- Jeffrey Paul +1 312 361 0355 +49 176 8058 2122 (signal) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal - Address Paste Improvement
On 08/11/2018 09.11, Dmitry Petukhov via bitcoin-dev wrote: >> Copying addresses to the clipboard should be discouraged, rather than >> supported. > > Do you know any reasonably convenient mechanism for end user to > transfer an address from, say, a web page to the wallet address > input field ? - QR code scanning of a Bitcoin URI - On Android: A "bitcoin:" URI intent or a BIP70 payment message intent - On desktop OSes there are similar mechanisms to launch Apps from the browser (e.g. for mailto: links) > The clipboard is just a low-hanging fruit for malware, anyway. It just > the most easy point to replace an address. If the computer is > compromized, malware can edit the web page in the memory of the browser > process, for example. If it shown as QR code, malware can decode, > detect that it is an address, and replace the image of QR code. For editing the clipboard your computer doesn't need to be compromised! *Any* app can do it, without special permission. > I think that the only way to protect from this is to add some form of > authentication for an address - 2fa (transfer checksum via second > channel), visual fingerprints for addresses, that will are hard to > detect (and hence, replace) for malware, signing the destination address > with the key of an address that is already known and checking the > signature, etc. For cases where the payee is a well-known entity the BIP70 payment protocol has authentication via certificates. That doesn't work for the "the person in front of you is the only trust anchor you have" usecase though. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP- & SLIP-0039 -- better multi-language support
Do you specifically want to support changing the language of seed words, while keeping the bip32 root seed they generate unchanged? What is the usecase for this? You mention that BIP39 already supports a few different languages. While this is true, many (I would guess most!) wallets only support the English wordlist. There are doubts even from the authors of the BIP whether it was a good idea in the first place to support multiple languages [0]. I don't find this surprising as it seems bad design to have to fix and maintain a wordlist for every language as the checksum depends on it. The supported wordlists are effectively a part of the specification, and every new list would just make that specification larger. If changing the language of seeds is not a requirement, then look into Electrum seeds. They are language/wordlist agnostic. Mnemonic Sentence => PBKDF2 => BIP-0032 Seed The bip32 seed is derived by hashing the normalized mnemonic, and the checksum is derived the same way but by using a different cheaper hash (single round of HMAC-SHA512; generation grinds until it matches a pattern) [1]. For example, "9dk" is a valid segwit electrum seed. [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015507.html [1]: http://docs.electrum.org/en/latest/seedphrase.html > Date: Wed, 7 Nov 2018 00:16:41 +0800 > From: Weiji Guo weij...@gmail.com > Subject: [bitcoin-dev] BIP- & SLIP-0039 -- better multi-language > support > > Hello everyone, > > I just realized that BIP-0039 is language dependent. I was assuming the > other way till I looked closer. The way the seed is derived from a BIP-0039 > entropy, as is shown below, depends on which language to generate the > mnemonic sentence: > > Entropy <=> Mnemonic Sentence => PBKDF2 => BIP-0032 Seed > > Therefore when a user choose a non-English mnemonic code he or she is stuck > with that language. Meanwhile only a few native languages are supported. > > SLIP-0039 does not solve this issue in a user friendly way by providing > only an English wordlist. That's understandable as it aims to provide SSS > capability. However those users who do not speak English or recognize > English words will suffer. > > What I am trying to bring to attention of the community is that, no matter > if we make a new version of BIP-0039, or a new BIP (with SSS support), or > to enhance SLIP-0039, we really need to address this language issue. > > Here are what I propose: > > 1. The mnemonic code should be only a representation of underlying entropy > or (pre) master secret, seed, whatever. In this way, the same seed/secret > could be displayed in English or in Chinese or other languages. Then there > could be 3rd party conversion tools to support translations in case any > wallet software or device does not support all specified languages. Now it > looks like: > > Mnemonic Sentence <=> Entropy => PBKDF2 => BIP-0032 Seed > > > 2. Given that only 8 languages are supported in BIP-0039, we should allow > the seed/secret to be represented in decimal numbers, each ranging from 0 > to 2047. So those who cannot find a native language support yet having > difficulty coping words in other languages could choose to just use numbers. > > So far I don't have a preference how this should be implemented. I'd like > to hear from community first. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal - Address Paste Improvement
> Copying addresses to the clipboard should be discouraged, rather than > supported. Do you know any reasonably convenient mechanism for end user to transfer an address from, say, a web page to the wallet address input field ? The clipboard is just a low-hanging fruit for malware, anyway. It just the most easy point to replace an address. If the computer is compromized, malware can edit the web page in the memory of the browser process, for example. If it shown as QR code, malware can decode, detect that it is an address, and replace the image of QR code. I think that the only way to protect from this is to add some form of authentication for an address - 2fa (transfer checksum via second channel), visual fingerprints for addresses, that will are hard to detect (and hence, replace) for malware, signing the destination address with the key of an address that is already known and checking the signature, etc. The problem will be to come up with an address authentication procedure that will be convenient for users and widely supported, as a result. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
