照理说钱包不应该是能随便挑的，应该是挑最有声望最公开透明最可信的，因为如果钱包自己都不可信，没错，冷热分离并不是万能的，冷热分离也防不了钱包后门。ECDSA 数字签名就存在一个 k 值侧信道泄露问题（这类不知不觉地泄露问题在密码学里貌似叫做 kleptography ）。
（有一说一，ECDSA 也有 anti-kleptography 的方案，但是那个方案我感觉有点蛋疼，需要另一台设备验证，很显然另一台设备需要是干净可信的）

“感觉 TokenPocket 也没有限制是否冷热钱包都要用它，似乎是开放的”

额，这涉及到另一个“早就该有却迟迟没出现的东西”，BIP174 PSBT 。（貌似现在又提出了 BIP370 PSBTv2 ？）
PSBT 的制订，就是为了统一未签名交易的格式，如果不统一，钱包就不能“混搭”使用。

另外提到离线签名，我还想到一个蛋疼的老问题，不知道解决了没：单张二维码承载的数据量很显然很有限，只有不到 4KB，所以如果是交易数据比较大（尤其是发现矿工费超付漏洞后，隔离见证交易输入和非隔离见证输入一样需要把前一笔交易也容纳进来），很容易就超出这个限制了。容易想到的办法是拆分，但是 PSBT 本身并没有规定这方面的细节（于是又是一团互不兼容的混沌），我记得 electrum 之前甚至是直接拒绝生成二维码，要求用户直接传文件，不知道现在改进了没。

（修正一下，“然后你用这第 141 个地址去收款了”应该是“然后你用这第 140 个地址去收款了”，应该是 140 而不是 141，下同）

说着说着我又想起来 HD 钱包的一个蛋疼问题：gap limit 。

简单说，HD 钱包并没有那么神奇，它还是必须老老实实一个一个把地址推算出来，然后才能用这些地址去匹配 /查询交易是否与自己有关，然后才能知道余额。

BIP44 规定的 gap limit 是 20，说让钱包软件不要往后生成多于 20 个地址（比如之前用过的地址有 100 个，那么就只生成到第 120 个，不再继续往后生成第 121 个）。但是很显然这并没有解决根本上的问题……

比如，如果你之前用过的地址有 100 个，然后你又一直点“生成新地址”、一直点一直点，然后生成了 40 个地址，这样你就有一共 140 个地址，其中前 100 个是用过的，第 101-140 个是还没用过的。

然后你用这第 141 个地址去收款了。

再然后，你导入 HD 种子给另一个钱包时，这个钱包 gap limit 是 20，只往后生成 20 个地址，于是这样就只能扫描到第 1-120 个地址，第 141 个地址上虽然有币，但是因为 gap limit 没覆盖到，所以不在扫描范围内。这样看上去就像是“丢币”了一样（实际上没丢）。

对于钱包来说，很容易想到一个缓解策略，就是提供给用户的地址限制在 20 个以内，但实际上后台扫描的地址远不止 20 个，比如 1000 个这样。但归根到底这只是缓解策略。
另外……貌似在类似商户收款这种场景下，地址某种程度上可能被拿来当订单号用（这本来就算是一个槽点吧……），每个顾客的每一笔订单，都要用不同的地址，要求唯一（而且很显然，顾客很可能索要了地址，但最后没支付，然后地址要不要“回收”呢，额，这又纠结了）……那么 20 个地址的 gap limit 更是远远不够用……

@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 币，后续同样也“继承”了这个已经分开的状态）