public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: nullius <nullius@nym.zone>
To: Sjors Provoost <sjors@sprovoost.nl>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: arachnid@notdot.net
Subject: Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists
Date: Fri, 5 Jan 2018 18:08:50 +0000	[thread overview]
Message-ID: <55374d9210feebf2f758d4e7b21849ee@nym.zone> (raw)
In-Reply-To: <BB3FA46E-AA09-4A60-9D0F-8E350015E107@sprovoost.nl>

[-- Attachment #1: Type: text/plain, Size: 5699 bytes --]

On 2018-01-05 at 16:04:10 +0000, Sjors Provoost <sjors@sprovoost.nl> 
wrote:
>I’m not a fan of language specific word lists within the current BIP-39 
>standard. Very few wallets support anything other than English, which 
>can lead to vendor lock-in and long term loss of funds if a rare 
>non-English wallet disappears.
>
>However, because people can memorize things better in their native 
>tongue, supporting multiple languages seems quite useful.
>
>I would prefer a new standard [...] A replacement for BIP-39 [...]
>
>[snip]
>For my above point and some related ideas, see: 
>https://github.com/satoshilabs/slips/issues/103

You present some interesting ideas; and I will be much interested in the 
Github issue you referenced—thanks for that.  However, this discussion 
is *far* beyond the scope of my simple proposal and request to add 
standardized native language and short-ASCII identifier strings to the 
BIP repository.  I suggest that readers solely interested in the 
existing BIP 39 standard and its direct application to Bitcoin should 
stop reading right here.

----

That being said, I should briefly address some of the issues you raise 
(with further discussion best continued elsewhere):

I *strongly* urge the importance of language-specific standardized 
wordlists.  Even an individual who has secondarily acquired reasonable 
fluency in English will most likely have the least difficulty 
memorizing, transcribing, and otherwise handling a “mother-tongue” 
mnemonic.  Such an advantage is important in applications whereby even 
slight errors can be fatal, and every bit counts.  This is to say 
nothing of persons who have limited or no English-language knowledge.

Yet for multiple reasons, multilanguage support is only feasible with 
standardization.  Wordlist creation is a highly specialized task.  
Independent implementation of standards is imperative for avoiding 
implementation lock-in; and independent implementors (such as I) would 
be unable to create sets multi-language wordlists on their own, anyway.  
For a view of the language-specific process involved in creating a 
wordlist, I invite everybody following this discussion to review BIP 
repository PRs #92, #130 (Japanese); #100 (Spanish); #114 (Chinese, both 
variants); #152 (French); #306 (Italian); #544 (Korean, rejected); and 
#570 (Korean).  The rejection of #544 for Korean, and its superseding 
with #570 is particularly instructive.

With standardized wordlists, independent implementation is easy.  In my 
own implementation, the language switching backend (excluding the UI[1]) 
for multilingual mnemonic generation required only relatively small C 
code changes, as seen here[0]:

[0] https://github.com/nym-zone/easyseed/commit/5b6a6668458d96d6ccc4bf19e4fd40fe6ea72fec#diff-20dcf1782b7568b85ea01ed695abeb02

[1] https://github.com/nym-zone/easyseed/commit/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6#diff-20dcf1782b7568b85ea01ed695abeb02

Admittedly, the multilingual requirements for seed generation will take 
a bit more; and my nonstandard, non-BIP39 ideas which require decoding 
words directly back to bits will take yet more.  But it is still not 
problematic.

I only began writing this tool one week ago, as of today; and it has 
been a side project requiring small amounts of time, not a full-time 
dedicated task.  When I fully complete all aspects of seed generation, 
then users will have the option of another simple open-source tool which 
*will* be able to output a binary or BIP-32-formatted (“xprv”) 512-bit 
seed, given input of an existing mnemonic in any language supported by 
official BIP 39 wordlists.  Output can then be imported to any wallet 
software which supports BIP 32, regardless of the wallet’s langauge 
support (and whether or not the wallet supports BIP 39 at all).

**The ease of creating such tools squarely answers your concerns about 
vendor lock-in.**  And yes, it’s easy.  I can attest as a lone coder, 
it’s easy for me to create “easyseed” as a side project!

Finally, aside:  In the discussion at SLIP repository issue #103, I see 
mention of m-of-n SSSS.  I have been mentally whiteboarding just such an 
application involving mnemonics.  Watch for it.  <g>  It is likely that 
I will crib the BIP 39 wordlists, given the impossibility that I could 
create my own set of wordlists in many languages.  I only wish that the 
BIP repository had support for more languages.  More!  Adding each new 
language to my implementation(s) will require approximately one-line 
code changes for me.

(Aside further:  Why is there not a Dutch wordlist?  I should like to 
add that, please—meneer Provoost.  More wordlists!)

Aside still yet further:  Should you be interested in more general 
applications of mnemonic phrases for pseudorandom strings, I think you 
will like this future feature which currently exists only as an Easter 
egg, (un)documented in my commit log:

https://github.com/nym-zone/easyseed/commit/ba77be1b1a1f0c6af50ceba5c89f4adece7e5dff

Further discussion is invited by private mail, in an appropriate public 
venue, or otherwise not on a bitcoin-dev thread which makes a simple 
request and proposal as to the existing BIP 39 standard—thanks.

-- 
nullius@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No!  Because I do nothing wrong, I have nothing to show.” — nullius

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2018-01-05 18:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-05 13:58 [bitcoin-dev] BIP 39: Add language identifier strings for wordlists nullius
2018-01-05 16:04 ` Sjors Provoost
     [not found]   ` <CALPhJax=53dLL9+JDKJC7NdEFFRB2kgKiECSh8PUMzrr2KxWuQ@mail.gmail.com>
2018-01-05 17:13     ` Sjors Provoost
2018-01-05 18:08       ` Aymeric Vitte
     [not found]         ` <CALPhJaxzayykMMxaa421kfu6QQ77JD7bZJk8+dXT4qSqK_eABg@mail.gmail.com>
2018-01-05 19:56           ` Aymeric Vitte
     [not found]             ` <CALPhJawP7hjucR6X3gpTxCxK+awMT9iArELZYFy_zffCGgVMEw@mail.gmail.com>
     [not found]               ` <58C8F1BA-B9A1-4525-BCC9-BF4CEDC87E1B@sprovoost.nl>
     [not found]                 ` <a3e10fe7-ed9c-bb58-bf12-d0aeda2827e4@gmail.com>
     [not found]                   ` <a2e8b3e2-b444-039c-c51e-43294a3437c9@gmail.com>
     [not found]                     ` <CALPhJaz1wU8y6KxZipREjus8WbHpwpyYjyMwgj5x-tTodxpjCQ@mail.gmail.com>
2018-01-06 17:40                       ` Aymeric Vitte
     [not found]                         ` <CALPhJaw8_wpPCRj58JcZqLnEvOtLoo=U_VBYRLSKTCeN7TFB6A@mail.gmail.com>
2018-01-06 19:46                           ` Aymeric Vitte
2018-01-05 18:08   ` nullius [this message]
2018-01-07 15:16 ` Pavol Rusnak
2018-01-08  7:35   ` 木ノ下じょな
2018-01-08 11:13     ` nullius
2018-01-08 14:34       ` Greg Sanders
2018-01-08 14:52         ` Matias Alejo Garcia
2018-01-08 14:54           ` Greg Sanders
2018-01-08 15:23             ` Matias Alejo Garcia
2018-01-08 15:26               ` AJ West
2018-01-08 15:32                 ` Greg Sanders
2018-01-08 16:02             ` Aymeric Vitte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55374d9210feebf2f758d4e7b21849ee@nym.zone \
    --to=nullius@nym.zone \
    --cc=arachnid@notdot.net \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=sjors@sprovoost.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox