@KillPaul 还有 Ian Coleman 的 BIP39 工具威力更强大，但是这玩意跑在浏览器里，说不定一不小心就给上传了呢，还是小心，最好不要折腾这个。
github . com /iancoleman/bip39
而且一般 HD 钱包还分两条链呢，一条链收款一条链找零……只把收款地址导入进去，找零很显然就给遗漏了。

@KillPaul
导入给 Electrum 就可以……作为 BIP39 导入，然后手动指定推导路径 m/0' 即可。
这方面有人还做了一个总结 walletsrecovery . org

另外即便技术简单可靠（所以排除智商税）又如何……
1.首先，至少 BTC 这样，币混没混过是公开的（虽然在混过的币里还是分不清具体谁是谁），于是小到交易所扣押资金要求提供资金来源证明，大到……额，我都不敢多想。
2.很容易犯一些低级错误就导致混币效果丧失，比如混完了又归并到一起；再比如用轻钱包，大多数轻钱包都会把地址信息透露给服务器（很显然，相当于匿名上网的马甲信息，如果大家知道 N 个小号马甲其实都是同一个人，那很显然就不匿名了啊）。wasabi 可以对接全节点，也可以是脱离全节点的纯轻钱包模式，轻钱包模式用的是 Neutrino 协议并且会走不同的 tor 回路下载区块（如果我没记错的话）。neutrino 协议是把索引下载到本地（任何人去下载都是同一份一模一样的数据），然后根据索引找出相关的区块，再去下载这些区块，所以结合下载区块时走不同 tor 回路，理论上基本没有泄露隐私信息给钱包服务器的问题，但是以后 Neutrino 协议需要下载的索引应该也会变大不少。

wasabi wallet，这个感觉是“早就应该有但迟迟没出现的东西”，原理貌似也不复杂，社区声望很高，蛮靠谱。

还有 join market 貌似更早？


其他的混币器就不好说了。

本来打了挺多字，感觉很容易就太长不看，所以就删了。

简单说，用 HD 钱包，其实还要注意一个私钥泄露后威胁更大的问题：单个私钥泄露+xpub 主公钥泄露=所有私钥泄露。

像 Bitcoin Core 那样，生成地址的时候用 hardened derivation，就规避了这个问题。

但是！规避了这个问题，我觉得其实得不偿失，为啥呢，因为这样就几乎做不了冷热分离了。
冷热分离，“热”端只知道 xpub，不知道私钥，无法推导任何私钥，但可以推导出地址（包括收款和找零）。


BIP44 呢，其实就是结合使用了 hardened derivation 和 normal derivation，在不同币种 /地址类型（用途）/子账户层级上利用 hardened 来隔离（于是理论上 A 币种私钥泄露完全不会影响 B 币种这样），然后到了生成地址这个层级时就改用 normal，这样就还可以有 xpub 。

BIP48 我搜了一下，好像并不是真正官方分配的 BIP 提案号码？只是 Trezor 等钱包用来指代一种多重签名的 HD 路径之类的协议吧。（话说助记词格式大战还不涉及多重签名呢，多重签名貌似也是没有统一的标准）

可能很多年前币圈里 BTC 对其他山寨币的态度还不是很坏，于是 BIP39 结合 BIP44 能一个助记词搞定多个币种，这个功能还是蛮有市场的。
现在呢……BTC 圈子自己都经常自称 toxic maximalist，对山寨币是很排斥的，于是支持多币种反倒还可能成为一种原罪（笑）。

个人看法，Electrum 为了抵制 BIP39，自己把 BIP39 又魔改出来一种长得很像、技术上也存在混淆的助记词格式（英文单词表是一模一样的同一份，而且还有千分之一到百分之一量级的概率会生成出“二义性”的助记词，按照 BIP39 和 Electrum 的 checksum 检验规则都是有效的），美其名曰是“解决 BIP39 设计上缺失标准 HD 派生路径的问题”（ Electrum 规定了一套版本号系统，这个版本号是通过类似虚荣地址挖矿的方式嵌入到助记词里的，然后版本号就和他们规定的标准 HD 派生路径绑定了），实际上这不仅没有解决问题，反而让整个生态更混沌，让问题更恶化。

另外……我也忍不住想放个暴论：其实我（而且貌似不只是我一个人？）经常感觉，可能 HD 钱包本身就是过度设计的产物，只是听起来很好很强大很厉害，但实际上带来的隐私性好处还是很有限的（而且大多数用户应该都会把 xpub 直接交给钱包服务器，这样一来地址一用一换的隐私优势至少在钱包服务器面前是荡然无存的），反倒是大大增加了钱包的复杂度。

抵制 BIP39 最大的理由，其实也是它最大的功能特点：一个种子就可以支持所有的币种，包括像 BTC 的 N 种不同地址格式，未来出现更多新币种 /新地址格式也不怕，所以 BIP39 助记词是“一劳永逸”的，一个备份可以一直用下去。

这确实很方便，但另一方面，这样不限制种子的用途，就会带来混乱。

具体来说，从 HD 种子派生出收款和找零地址，需要指定一个“派生路径”——找错了派生路径，就会生成之前没用过的陌生地址，于是就会出现“欸，这个助记词上面有币啊，怎么导入到钱包里余额是 0 呢”的问题。

更蛋疼的是，貌似 BIP44 这个规定标准派生路径的规范，出现时间又比 BIP39 迟了不少。
有些钱包，比如 bread，在 BIP44 出来之前就开始用 BIP39 了，所以 bread 的 HD 派生路径到目前为止仍然是和 BIP44 不兼容的，简单说，就是 bread 导入到其他 BIP39/44 的钱包里，BTC 这个币种一般会出现余额为零、交易记录为空、地址全是没见过的陌生地址这个问题，反之亦然。

BIP39/44……对比特币来说出现确实不早，但也早就不是啥新鲜玩意了吧，不是“近两年”才出现的啊。

BIP39 规定的是 HD 种子助记词（严格来说是助记词单向哈希成种子，并不能混为一谈，不过这里不要在意那么多细节）的标准，现在也是“事实上的标准”，但是很多开发者，尤其是 Electrum，那么多年以来都一直抵制 BIP39 。

有些其他的币种也把 electrum 的代码给 fork 过去了……但和 electrum 官方没啥关系。

@wangkun025 electrum 是 BTC 单币种的

@KillPaul BCH 当然可以，但是 BCH 后来不是又分出来 BSV 么，这个需要注意一下，要拆分，避免重放。
（而且分出 BSV 后我记得又搞出 BCHABC 和 BCHN，现在的 BCH 是 BCHN，BCHABC 虽然是原来的领衔开发者搞的，但现在存在感就比较稀薄了）
为了防止导入私钥折腾钱包的时候出岔子，可以把高价值的币先转到安全的地方（新的、备份好的钱包），然后再折腾低价值的币。

（至于 nLocktime，没记错的话是这样：两种币的区块高度一般是存在差异的，其中一种挖的比另一种“快一些”、区块高度攒到更高。于是就可以在发出交易时设定 nLocktime，nLockTime 根据数值大小有两种解读方式，数值比较大就当作 UNIX 时间戳解读，比较小就当作区块高度解读，在指定高度之前交易不能打包。所以就可以设定一个相对现在很近的未来的 nLockTime，然后“跑得快”的 A 币先挖到指定的高度，可以打包确认，这样就把 A 币转到 X 地址； B 币因为“比较慢”，同一时间还没挖到指定的高度，交易还不能在 B 币网络打包，所以就可以再发一笔只转账 B 币交易，把 B 币转到 Y 地址）

（啊，关于 coinbase 重放保护……其实这里也并不存在什么“纯度”，两种币还是两种币，问题只不过是 A 币的交易同时在 B 币上也有效，然后也得到打包确认了而已。分叉后新挖出来的 A 币（ coinbase 币），在 B 币那边肯定是不存在的，所以才有 coinbase 重放保护这么一说。其实要避免重放、分离两种币，未必需要是矿工新挖出来的币，只要是 A 币这边认为合法、B 币那边认为不合法的交易都可以实现重放保护。“混入”A 种 coinbase 币的交易，后续肯定也都“继承”一样的性质。如果是用了其他手段来拆分，比如用 nLockTime 分别把 A 币和 B 币转入不同的两个地址 X 和 Y，那很显然 X 地址上只有 A 币、Y 地址上只有 B 币，后续同样也“继承”了这个已经分开的状态）

走不同 HD 推导路径其实是派生出了不同的新钱包，钱包之间当然是可以互相转账的，只不过转账后，很显然，该是钱包 1 交易记录还是钱包 1 的，钱包 1 的交易记录很显然不会跑到钱包 2 上。

HD 推导与文件夹不同的是，文件夹里的东西可以移动，HD 推导路径里的地址、余额、交易记录很显然是不能“移动”的。

HD 推导路径可以大致想象成像文件夹路径一样，找错路径，就会推导出和之前不同的地址，于是就看不到正确的余额和交易记录（一般是变成余额 0 、交易记录空白）。

1.bread wallet 是 BIP39 助记词，但 HD 推导路径不是 BIP44/49/84 （貌似是因为这些标准产生其实比 bread wallet 用 BIP39 还迟），这个需要注意。

2.分叉出来的两个币当然都继承原来的余额。
分叉前，同一个地址收到的币，现在变成两种币，这个很正常；
主要是分叉后产生的交易可能有问题。
这里有个概念“重放保护”，简单说就是分叉出来的其中一种币修改交易格式，故意破坏兼容性，然后才能井水不犯河水——否则，就会产生问题：A 币的交易会有意无意地跑到 B 币的网络里，然后 A 币和 B 币的矿工（未必是同时！所以也可以用 nLockTime 来避免重放、实现拆分）都各自打包到 A 链和 B 链里面。简单说，本来只想转账 A 币的，一不小心把 B 币也给转账了。
BCH 对 BTC 做了重放保护，所以 BTC 和 BCH 分离问题不大。主要是 BCH 后来分出 BSV 的时候没做重放保护，不过 BCH 的 Schnorr 签名功能应该可以起到重放保护的作用。（因为 BSV 那边拒绝实现 Schnorr 签名功能，只有 BCH 那边有这个功能；除了这个使用不兼容的功能，以及上文提到的 nLockTime 之外，还有一个办法就是找矿工要 coinbase 交易挖出来的“纯”币，分叉后的 coinbase 交易肯定是“纯”的币，所以混入“纯”A 币的交易在 B 币那边一定是非法的，不会被重放）