BIP 0039: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
← Older editNewer edit →
Slush (talk | contribs)
Editors
103 edits
Added seed stretching algo
934 (talk | contribs)
Editors
882 edits
Update BIP text with latest version from https://github.com/bitcoin/bips/blob/c134a853a9fc0657/bip-0039.mediawiki
(8 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{bip}}
{{bip}}
{{BipMoved|bip-0039.mediawiki}}


<pre>
<pre>
   BIP:     BIP-0039
   BIP: 39
   Title:   Mnemonic code for generating deterministic keys
  Layer: Applications
   Author: Pavol Rusnak <stick@gk2.sk>
   Title: Mnemonic code for generating deterministic keys
          Marek Palatinus <info@bitcoin.cz>
   Author: Marek Palatinus <slush@satoshilabs.com>
          Aaron Voisine <voisine@gmail.com>
          Pavol Rusnak <stick@satoshilabs.com>
   Status: Draft
          Aaron Voisine <voisine@gmail.com>
   Type:   Standards Track
          Sean Bowe <ewillbefull@gmail.com>
   Created: 10-09-2013
  Comments-Summary: Unanimously Discourage for implementation
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0039
   Status: Proposed
   Type: Standards Track
   Created: 2013-09-10
</pre>
</pre>


==Abstract==
==Abstract==


This BIP proposes a scheme for translating binary data (usually master seeds
This BIP describes the implementation of a mnemonic code or mnemonic sentence --
for deterministic keys, but it can be applied to any binary data) into a group
a group of easy to remember words -- for the generation of deterministic wallets.
of easy to remember words also known as mnemonic code or mnemonic sentence.
 
It consists of two parts: generating the mnemonic, and converting it into a
binary seed. This seed can be later used to generate deterministic wallets using
BIP-0032 or similar methods.


==Motivation==
==Motivation==


Such mnemonic code or mnemonic sentence is much easier to work with than working
A mnemonic code or sentence is superior for human interaction compared to the
with the binary data directly (or its hexadecimal interpretation). The sentence
handling of raw binary or hexadecimal representations of a wallet seed. The
could be writen down on paper (e.g. for storing in a secure location such as
sentence could be written on paper or spoken over the telephone.
safe), told over telephone or other voice communication method, or memorized
 
in ones memory (this method is called brainwallet).
This guide is meant to be a way to transport computer-generated randomness with
a human readable transcription. It's not a way to process user-created
sentences (also known as brainwallets) into a wallet seed.
 
==Generating the mnemonic==


==Backwards Compatibility==
The mnemonic must encode entropy in a multiple of 32 bits. With more entropy
security is improved but the sentence length increases. We refer to the
initial entropy length as ENT. The allowed size of ENT is 128-256 bits.


As this BIP is written, only one Bitcoin client (Electrum) implements mnemonic
First, an initial entropy of ENT bits is generated. A checksum is generated by
codes, but it uses a different wordlist than the proposed one.
taking the first <pre>ENT / 32</pre> bits of its SHA256 hash. This checksum is
appended to the end of the initial entropy. Next, these concatenated bits
are split into groups of 11 bits, each encoding a number from 0-2047, serving
as an index into a wordlist. Finally, we convert these numbers into words and
use the joined words as a mnemonic sentence.


For compatibility reasons we propose adding a checkbox to Electrum, which will
The following table describes the relation between the initial entropy
allow user to indicate if the legacy code is being entered during import or
length (ENT), the checksum length (CS) and the length of the generated mnemonic
it is a new one that is BIP-0039 compatible. For exporting, only the new format
sentence (MS) in words.
will be used, so this is not an issue.
 
<pre>
CS = ENT / 32
MS = (ENT + CS) / 11
 
|  ENT  | CS | ENT+CS |  MS  |
+-------+----+--------+------+
|  128  |  4 |  132  |  12  |
|  160  |  5 |  165  |  15  |
|  192  |  6 |  198  |  18  |
|  224  |  7 |  231  |  21  |
|  256  |  8 |  264  |  24  |
</pre>


==Rationale==
==Wordlist==


Our proposal is inspired by implementation used in Electrum, but we enhanced
An ideal wordlist has the following characteristics:
the wordlist and algorithm so it meets the following criteria:


a) smart selection of words
a) smart selection of words
   - wordlist is created in such way that it's enough to type just first four
   - the wordlist is created in such way that it's enough to type the first four
     letters to unambiguously identify the word
     letters to unambiguously identify the word


b) similar words avoided
b) similar words avoided
   - words as "build" and "built", "woman" and "women" or "quick" or "quickly"
   - word pairs like "build" and "built", "woman" and "women", or "quick" and "quickly"
     not only make remembering the sentence difficult, but are also more error
     not only make remembering the sentence difficult, but are also more error
     prone and more difficult to guess (see point below)
     prone and more difficult to guess
  - we avoid these words by carefully selecting them during addition


c) sorted wordlists
c) sorted wordlists
   - wordlist is sorted which allow more efficient lookup of the code words
   - the wordlist is sorted which allows for more efficient lookup of the code words
     (i.e. implementation can use binary search instead of linear search)
     (i.e. implementations can use binary search instead of linear search)
   - this also allows trie (prefix tree) to be used, e.g. for better compression
   - this also allows trie (a prefix tree) to be used, e.g. for better compression


d) localized wordlists
The wordlist can contain native characters, but they must be encoded in UTF-8
  - we would like to allow localized wordlists, so it is easier for users
using Normalization Form Compatibility Decomposition (NFKD).
    to remember the code in their native language
  - by using wordlists with no colliding words among languages, it's easy to
    determine which language was used just by checking the first word of
    the sentence


e) mnemonic checksum
==From mnemonic to seed==
  - this leads to better user experience, because user can be notified
    if the mnemonic sequence is wrong, instead of showing the confusing
    data generated from the wrong sequence.


f) seed stretching
A user may decide to protect their mnemonic with a passphrase. If a passphrase is not
  - before the encoding and after the decoding the input binary sequence is
present, an empty string "" is used instead.
    stretched using a symmetric cipher (Blowfish) in order to prevent
    brute-force attacks in case some of the mnemonic words are leaked


==Specification==
To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic
sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again
in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as
the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).


<pre>
This seed can be later used to generate deterministic wallets using BIP-0032 or
Our proposal implements two methods - "encode" and "decode".
similar methods.


The first method takes a binary data which have to length (L) in bytes divisable
The conversion of the mnemonic sentence to a binary seed is completely independent
by four and returns a sentence that consists of (L/4*3) words from the wordlist.
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.


The second method takes sentences generated by first method (number of words in
Although using a mnemonic not generated by the algorithm described in "Generating the
the sentence has to be divisable by 3) and reconstructs the original binary data.
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.


Words can repeat in the sentence more than one time.
The described method also provides plausible deniability, because every passphrase
generates a valid seed (and thus a deterministic wallet) but only the correct one
will make the desired wallet available.


Wordlist contains 2048 words (instead of 1626 words in Electrum), allowing
==Wordlists==
the code to compute the checksum of the whole mnemonic sequence.
Each 32 bits of input data add 1 bit of checksum.


See the following table for relation between input lengths, output lengths and
* [[bip-0039/bip-0039-wordlists.md|Moved to separate document]]
checksum sizes for the most common usecases:


+--------+---------+---------+----------+
==Test vectors==
| input  |  input  | output  | checksum |
| (bits) | (bytes) | (words) |  (bits)  |
+--------+---------+---------+----------+
|  128  |    16  |    12  |    4    |
|  192  |    24  |    18  |    6    |
|  256  |    32  |    24  |    8    |
+--------+---------+---------+----------+
</pre>


===Algorithm:===
The test vectors include input entropy, mnemonic and seed. The
passphrase "TREZOR" is used for all vectors.


<pre>
https://github.com/trezor/python-mnemonic/blob/master/vectors.json
Encoding:
1. Read input data (I).
2. Make sure its length (L) is divisable by 64 bits.
3. Encrypt input data 1000x with Blowfish (ECB) using the word "mnemonic" as key.
4. Compute the length of the checkum (LC). LC = L/32
5. Split I into chunks of LC bits (I1, I2, I3, ...).
6. XOR them altogether and produce the checksum C. C = I1 xor I2 xor I3 ... xor In.
7. Concatenate I and C into encoded data (E). Length of E is divisable by 33 bits.
8. Keep taking 11 bits from E until there are none left.
9. Treat them as integer W, add word with index W to the output.


Decoding:
Also see https://github.com/bip32JP/bip32JP.github.io/blob/master/test_JP_BIP39.json
1. Read input mnemonic (M).
2. Make sure its wordcount is divisable by 6.
3. Figure out word indexes in a dictionary and output them as binary stream E.
4. Length of E (L) is divisable by 33 bits.
5. Split E into two parts: B and C, where B are first L/33*32 bits, C are last L/33 bits.
6. Make sure C is the checksum of B (using the step 5 from the above paragraph).
7. If it's not we have invalid mnemonic code.
8. Treat B as binary data.
9. Decrypt this data 1000x with Blowfish (ECB) using the word "mnemonic" as key.
10. Return the result as output.
</pre>
 
==Test vectors==


See https://github.com/trezor/python-mnemonic/blob/master/vectors.json
(Japanese wordlist test with heavily normalized symbols as passphrase)


==Reference Implementation==
==Reference Implementation==
Line 139: Line 135:


http://github.com/trezor/python-mnemonic
http://github.com/trezor/python-mnemonic
==Other Implementations==
Go:
* https://github.com/tyler-smith/go-bip39
Elixir:
* https://github.com/aerosol/mnemo
Objective-C:
* https://github.com/nybex/NYMnemonic
Haskell:
* https://github.com/haskoin/haskoin
.NET C# (PCL):
* https://github.com/Thashiznets/BIP39.NET
.NET C# (PCL):
* https://github.com/NicolasDorier/NBitcoin
JavaScript:
* https://github.com/bitpay/bitcore-mnemonic
* https://github.com/bitcoinjs/bip39 (used by [[https://github.com/blockchain/My-Wallet-V3/blob/v3.8.0/src/hd-wallet.js#L121-L146|blockchain.info]])
Java:
* https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/crypto/MnemonicCode.java
Ruby:
* https://github.com/sreekanthgs/bip_mnemonic
Rust:
* https://github.com/maciejhirsz/tiny-bip39/
Swift:
* https://github.com/CikeQiu/CKMnemonic
* https://github.com/yuzushioh/WalletKit
* https://github.com/matter-labs/web3swift/blob/develop/Sources/web3swift/KeystoreManager/BIP39.swift
C++:
* https://github.com/libbitcoin/libbitcoin-system/blob/master/include/bitcoin/system/wallet/mnemonic.hpp
C (with Python/Java/Javascript bindings):
* https://github.com/ElementsProject/libwally-core

Revision as of 07:37, 2 August 2020

This page describes a BIP (Bitcoin Improvement Proposal).
Please see BIP 2 for more information about BIPs and creating them. Please do not just create a wiki page.

Please do not modify this page. This is a mirror of the BIP from the source Git repository here.

 
  BIP: 39
  Layer: Applications
  Title: Mnemonic code for generating deterministic keys
  Author: Marek Palatinus <slush@satoshilabs.com>
          Pavol Rusnak <stick@satoshilabs.com>
          Aaron Voisine <voisine@gmail.com>
          Sean Bowe <ewillbefull@gmail.com>
  Comments-Summary: Unanimously Discourage for implementation
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0039
  Status: Proposed
  Type: Standards Track
  Created: 2013-09-10

Abstract

This BIP describes the implementation of a mnemonic code or mnemonic sentence -- a group of easy to remember words -- for the generation of deterministic wallets.

It consists of two parts: generating the mnemonic, and converting it into a binary seed. This seed can be later used to generate deterministic wallets using BIP-0032 or similar methods.

Motivation

A mnemonic code or sentence is superior for human interaction compared to the handling of raw binary or hexadecimal representations of a wallet seed. The sentence could be written on paper or spoken over the telephone.

This guide is meant to be a way to transport computer-generated randomness with a human readable transcription. It's not a way to process user-created sentences (also known as brainwallets) into a wallet seed.

Generating the mnemonic

The mnemonic must encode entropy in a multiple of 32 bits. With more entropy security is improved but the sentence length increases. We refer to the initial entropy length as ENT. The allowed size of ENT is 128-256 bits.

First, an initial entropy of ENT bits is generated. A checksum is generated by

taking the first 

ENT / 32

bits of its SHA256 hash. This checksum is

appended to the end of the initial entropy. Next, these concatenated bits are split into groups of 11 bits, each encoding a number from 0-2047, serving as an index into a wordlist. Finally, we convert these numbers into words and use the joined words as a mnemonic sentence.

The following table describes the relation between the initial entropy length (ENT), the checksum length (CS) and the length of the generated mnemonic sentence (MS) in words. 

CS = ENT / 32
MS = (ENT + CS) / 11

|  ENT  | CS | ENT+CS |  MS  |
+-------+----+--------+------+
|  128  |  4 |   132  |  12  |
|  160  |  5 |   165  |  15  |
|  192  |  6 |   198  |  18  |
|  224  |  7 |   231  |  21  |
|  256  |  8 |   264  |  24  |

Wordlist

An ideal wordlist has the following characteristics:

a) smart selection of words 

  - the wordlist is created in such way that it's enough to type the first four
    letters to unambiguously identify the word

b) similar words avoided 

  - word pairs like "build" and "built", "woman" and "women", or "quick" and "quickly"
    not only make remembering the sentence difficult, but are also more error
    prone and more difficult to guess

c) sorted wordlists 

  - the wordlist is sorted which allows for more efficient lookup of the code words
    (i.e. implementations can use binary search instead of linear search)
  - this also allows trie (a prefix tree) to be used, e.g. for better compression

The wordlist can contain native characters, but they must be encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD).

From mnemonic to seed

A user may decide to protect their mnemonic with a passphrase. If a passphrase is not present, an empty string "" is used instead.

To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).

This seed can be later used to generate deterministic wallets using BIP-0032 or similar methods.

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.

The described method also provides plausible deniability, because every passphrase generates a valid seed (and thus a deterministic wallet) but only the correct one will make the desired wallet available.

Wordlists

Test vectors

The test vectors include input entropy, mnemonic and seed. The passphrase "TREZOR" is used for all vectors.

https://github.com/trezor/python-mnemonic/blob/master/vectors.json

Also see https://github.com/bip32JP/bip32JP.github.io/blob/master/test_JP_BIP39.json

(Japanese wordlist test with heavily normalized symbols as passphrase)

Reference Implementation

Reference implementation including wordlists is available from

http://github.com/trezor/python-mnemonic

Other Implementations

Go:

Elixir:

Objective-C:

Haskell:

.NET C# (PCL):

.NET C# (PCL):

JavaScript:

Java:

Ruby:

Rust:

Swift:

C++:

C (with Python/Java/Javascript bindings):

Retrieved from "https://en.bitcoin.it/w/index.php?title=BIP_0039&oldid=68103"