同一个助记词导入钱包为啥会变成新的地址

助记词生成地址的两个因素，助记词本身和 path
助记词没变，唯一的可能性就是 path 弄错了

助记词生成 seed ，由 path 来 devive 。那就怀疑 path 的标准不一致呗，本来 path 里很多东西都可以随便变得，version index 什么的。

作为一个老牌人士还是虽然会保存助记词，但还是会保存私钥。

肯定是没记错吗?
毕竟新地址稳定.

@subpo
Path 只设置了两个值，都不对
@jworg



@xarthur
私钥确实是唯一的

@ngn999
如果是错的，前端验证过不了，后端也有验证

@Turkestan 你如果只是一个词记错了, 或者顺序记反了, 当然会生成一个新的开 /私钥对. 前后端怎么验证?

@Turkestan m / purpose' / coin_type' / account' / change / address_index 里面除了 purpose change 有明确的含义，coin_type account address_index 那不是想怎么定就怎么定

@jworg
同一套代码，其他人没这个问题，而且，助记词并不会改变这些内容

这么说吧，只能是你助记词或者 path 搞错了，其他情况绝对不可能

@subpo

好像有重新创建账号的可能，有的钱包有这个 bug ，比如 Metamask 17 年就有这个 bug ，后来被 bounty 修复了

@Turkestan 我在 imtoken 用助记词恢复和你遇到同样的问题,后来实事证明就是自己搞错了.困扰 3 年之久的问题

@SuperXRay

同样的问题是指，助记词生成了新的地址吗

@Turkestan 是我以为同样的助记词生成了新的地址(一直那么认为的)
一直认为自己只有一个常用钱包且只备份了一份助记词,且这个助记词记录在 1password 里面

实际上就是我记错了

那我怎么找回来的呢,我去翻了 18 年的所有的云相册,果然有一个不一样的助记词截图

@SuperXRay

我翻了一下 metamask 的 issue 列表，发现很多人都有这个问题

基本没用过 metamask ，不过忍不住想挖个坟

BIP39 本身只是助记词标准，它被很多开发者抵制（是的，尤其是 bitcoin core 这边）的一大原因就是：
它只是一个 seed ，不包含或者说涉及后续的 derivation path 。

这个设计的好处就是同一个助记词不需要重新备份会修改即可支持新币种，
或者同一币种的新地址类型，比如：BTC 这边主要 3 种常用的，1 开头的 P2PKH 、3 开头的 P2SH-P2WPKH 和 bc1q 开头的 P2WPKH ，以后 bc1p 开头的 P2TR 也会越来越多。

“同一个助记词不需要重新备份 [和] 修改即可支持新币种”改正一下

还有，BIP44 是有规定 gap limit 的，也就是在某个位置（比如第 4 个地址）继续往后推导后续地址的个数是有限制的。这也很容易理解，因为你恢复钱包的时候，只给了一个助记词，又没告诉钱包软件你用过的是第 xx-xx 号地址，所以只能靠预先约定一个限制。
但实际上貌似挺多时候都可能超过这个限制（比如有些钱包软件无视这个限制，或者自己用 ian coleman 的工具之类自己推算）。还是满蛋疼的。

BTC 这边 BIP44/49/84/86 分别规定了 1/3/bc1q/bc1p 开头的 P2PKH/P2SH-P2WPKH/P2WPKH/P2TR 这几种地址类型的 derivation path 。
但其实 BIP44 诞生貌似比较晚，之前有钱包已经用了不符合 BIP44 的 path ，比如 bread wallet 。

而且还有其他钱包开发者制订的新助记词格式和 BIP39 共用同一套单词表，而且没有回避 BIP39 的校验规则。有比较小（但仍然可观）的几率会出现本来生成的不是 BIP39 ，但也能当 BIP39 用的助记词。

印象里这个问题闹地蛮僵的，历史遗留是一方面，开发者意见不合且拒绝妥协是另一方面。

@SuperXRay 云相册……额，有些钱包会反复劝诫用户不要这么做来着。

另外这其实也涉及 BIP39 另一个被诟病的地方，就是它的 checksum 太短了，12 单词只含有 4bit ，输错的时候有 1/16 的几率会把错的当成对的。24 单词有 8bit ，相对好了一些。

@jworg BIP44/49/84/86 等规定了几个 purpose 的含义，SLIP44 里有登记 coin_type ，address_index 在 BIP44 里也有 gap limit 约束。
不过这些很显然都不可能有强制约束力。