在一般数字货币中是使用 256 位的随机整数作为私钥的，但是这个记忆起来比较困难，所以为了解决记忆和易用性的问题 BIP39 规范提出了一种通过助记词来推算种子的算法，来帮助我们的降低使用门槛。/ I# d1 t4 F* h0 D
助记词的几种形式现在已经规范化的助记词词典有简体中文、繁体中文、英文、日文、法语、意大利语、韩语、西班牙语上述语言的助记词都可以生成，但大部分主流钱包做法还是只使用英文。
一般钱包的助记词个数是 12 或 24 个，但是这个标准也还可以生成 15、18、21 个数的助记词，甚至是低于 12 个词也可以。如果开发钱包时为了安全性考虑一般采用 24 个词，为了兼容其他主流钱包或易用性一般采用 12 个词。低于 12 个词的话碰撞几率太大、风险太高不建议使用。' f2 I) I5 v+ v* ], a3 Q) K$ b% A$ _
助记词的生成生成一个 128-256 Bit 的随机数，但是这个随机数的位数必须是 32 的倍数。将随机数进行 SHA256 然后取前 X 位当做校验位。具体几位需要看产生随机数的位数。( X = 随机数位数 / 32 )。将效验位添加到随机数后面。将添加效验位的随机数按位分成每 11 位为一组，分成若干组。那么每 11 位都可以得到值范围是 0~2047 的数，根据这些数去查助记词词典，就可以得到助记词了。
助记词词典就是一个 2048 个词的列表，具体可查看 英文词典示例
如果你的钱包需要支持相应语言的助记词请前往下载 各种语言助记词词典下载
| 随机数位数 | 校验位位数 | 随机数加校验位位数 | 助记词个数 |
| 128 | 4 | 132 | 12 |
| 160 | 5 | 165 | 15 |
| 192 | 6 | 198 | 18 |
| 224 | 7 | 231 | 21 |
| 256 | 8 | 264 | 24 |
产生12个助记词的示例
由助记词生成私钥对助记词和盐进行使用 NFKD 进行规范化编码。( 盐是 “mnemonic” + 密码 )使用 PBKDF2 算法获得 512 位的种子。PBKDF2 使用 HMAC-SHA512 作为哈希算法，并进行 2048 次计算。前 256 位就是我们的私钥，至于后 256 位的作用暂时不用知道，我们使用 BIP32 的时候才会用到。. N+ i5 e4 \. r A. {* c: r' t
助记词生成私钥的案例
验证助记词的正确性去词典查词，看看用户输入的词在不在词典里。把所有词的索引拿出来按顺序转成由位组成二进制数据然后进行拼接组合。把二进制数据再拆分成 随机数 和 校验位 ，把随机数进行 SHA256 然后对比校验位结果是否正确
验证助记词流程% X A/ L# L7 Y: l* Z2 V% r
助记词的一些特性由于使用了 HMAC-SHA512 的 PBKDF2 算法，所以无法由 512 位的种子反向推出助记词。助记词和 128 位的随机数是可以相互转换的，但是没有什么太大实际意义。助记词生成私钥的时候是可以加入自己的密码来降低碰撞率以及安全性的，但是国内大部分钱包都不支持这一特性。开发中需要注意的地方在开发中，如果你使用的是第三方的代码来生成 12 个词的助记词，然后再通过助记词产生私钥的时候，助记词可能会验证失败。但是使用 24 个词的助记词，验证就不会失败。为什么会这样的，一般我们在开发中会使用 byte 数组或 char 数组可以用来存储相关的数据，但是一个 byte 占空间最小也是一个字节(8 位)，除了 24 个助记词的校验位能占满 8 位，其他个个数的助记词都占不满 8 位，很多第三方库校验位都是存了1个字节，可助记词恢复出来的数据确是丢位的，然后进行校验也是按照字节对比，而不是对比每一位，所以会出现验证失败的问题。网上有人说助记词每一个词都是唯一不能重复出现的，但是我们根据具体生成过程发现，词重复是不可避免的，只不过是小概率事件。
