@litesoar

这块其实蛮混乱的，有一家做硬件钱包的厂商就出于公益目的稍微总结了一下： https://walletsrecovery.org/

1.助记词本身其实只是最根源的随机种子。
2.然后 HD 是需要指定推导路径的。

首先第 1 个环节，助记词：
BIP39 可能算是业界最通行的，但不少开发者讨厌 BIP39 ，想取而代之。
更蛋疼的是他们甚至没换一套新的单词表、没考虑怎么跟 BIP39 区分开来。
于是光是作为随机种子的助记词就已经产生混淆了，有时候可能一个助记词既可以按照 BIP39 来解，也可以按照 Electrum2.0 、aezeed 等其他格式来解，所以如果解法不对，结果自然是驴头不对马嘴。

然后第 2 个环节更是不用多说……
虽然不少钱包还是遵守 BIP44/49/84/86 这些的，但其实……就像 BIP44 ，当时好像有像 bread 这样的钱包，在这个标准出来之前就支持 HD 了，所以它的推导路径很自然是跟 BIP44 不符的……

（还有，打错字纠正一下：扫完了也不会 [自动把] 扫描结果加入钱包）

（当然，严格来讲，如果输入的 UTXO 正好被花完，那就不需要找零输出）

啊对了，bitcoin core 还有个控制台命令 scantxoutset ，它的功能就是直接扫 UTXO ，扫一遍也只需要几分钟左右吧。
这个 scantxoutset 我记得钱包不会自动调用，是手动调用的，而且扫完了也不会把自动扫描结果加入钱包（实际上随便输入任何地址，包括不属于你钱包的地址，也可以扫）。

要说找零，首先比特币的交易数据格式本来就必须有找零。

找零是可以找零到原地址的，但 bitcoin core 一向都是遵守中本聪当年在白皮书里说的，“一个地址只用一次、不重复使用，这样能一定程度上保护隐私”，所以可想而知……一个地址 A 收到币后，如果你又转出了，就会找零到新地址 B 上，于是你（在交易确认进链之后）如果还拿着地址 A 去手动扫 UTXO 集合，当然就扫不到 B 地址上的币。

还有一些没 x 用的废话，毕竟楼主也问了“为啥”：

首先其实不确定你钱包是什么情况……bitcoin core 的钱包功能本身其实并不好用，而且历史烂摊子蛮多……
虽然最新版默认也改成输出描述符模式了，遵守 BIP44/49/84/86 ，而且还有 PSBT 这个通用的交易格式，有了挺大的改善，但还是没支持业界通行的 BIP39 助记词（而且一直以来其实都是因为有开发者反对才不支持）。


根本原因，应该是 bitcoin core 的工作方式一直以来都是非常低效的，同时也很简单，就是笨扫区块，区块就是账本，从账本里一页一页翻，把那些跟你有关的交易找出来。

就像一本没有检字表的字典，其实你要查的某个字里面（可能）有，但你不知道在哪一页（而且很显然交易不会像字典里那样按照读音排序），只能一页一页笨翻。

因为查一次成本很高，很慢，所以有时候没扫全，你也不知道。
（按理说开发者也有在钱包里标记上次扫描到的位置，也就是扫到了哪个区块，于是下次同步时就从这个地方继续往后扫，这样的话按理说应该是不会遗漏的。但实际上……嘛我也不是很清楚楼主的钱包是啥情况）
像区块浏览器，还有楼上说的 electrum ，他们是在服务器上开了甚至可能比区块数据体积还要大好几倍的索引，所以才能秒查出结果。你要是在本地生成那么多索引你也能秒查，但 bitcoin core 是没这个功能的。

不过 bitcoin core 现在有个功能 blockfilterindex ，把这个开启后就能生成相当于区块数据 1%这个数量级的索引。
但是！很遗憾我看了最新出的 24.0 仍然是只能生成这个数据（还能通过 P2P 网络喂给轻钱包），但他自己反而无法利用这个索引。
现在我看已经把 pr #25957 合进去了，所以未来发布的下一个版本的 bitcoin core 应该就能利用这个索引了，大概几分钟左右就能把区块全扫完。

除了这个之外还有一个很早以前就有的功能 txindex ，这个索引只能根据 txid 查到交易在哪个区块，然后就能快速找到一笔交易；然后根据一笔交易的输入（ prev out 也是 txid ），就可以继续往上追溯查询它的资金是从哪来的，如此还能继续往上追溯，但也只能查这个。至于转到一个地址的钱后来（输出）去哪了，以及一个地址有哪些交易之类的，靠 txindex 都是查不了的。

（啊还有，P2SH-P2WPKH 其实是经过 4 次哈希了，P2WPKH 和 P2SH 都是一次 SHA256 一次 RIPEMD160 ）

1.一个私钥只对应一个公钥（其实还可能是非压缩公钥，但现在一般不用了。另外 segwit 是禁止用非压缩公钥的，如果用非压缩公钥生成地址就无法转出）。

BIP39：助记词，可以用一串单词表示随机种子，方便保管。
BIP32：HD 钱包，可以从一个随机种子分层推导派生一堆公钥私钥，但需要指定一个路径。
BIP44/49/84/86：规定 4 种标准的推导路径，地址分别是 1 、3 、bc1q 、bc1p 开头，脚本类型是 P2PKH 、P2SH-P2WPKH 、P2WPKH 、P2TR 。
最后一种 P2TR 是最新的技术，taproot+schnorr 签名+mast 多合一统称叫做 taproot ，虽然已经激活一年了、而且要说提出其实早得多……但很遗憾到现在还不怎么普及。P2TR 是裸公钥，没有经过哈希。

2.BIP44 不止规定路径，还有在 HD 内进一步定义“账户”。还有就是 gap limit 。
除了盲猜 index 暴力搜索比对（ index 有 32bit ），确实是没办法直接知道一个地址是不是属于你。所以钱包只能是从 index=0 开始往后多生成几个地址就停，只扫这些地址有没有交易，扫到了再继续往后推。
从助记词恢复钱包的时候，钱包软件怎么知道你当初是往后生成到第几个地址了？它不知道。
所以 BIP44 就规定了一个 gap limit ，从上一个有交易的地址开始，限制只能继续往后生成 20 个地址，只有这 20 个地址里产生交易了，才能继续往后生成（而且还是限制到 20 个）。
不过确实，这个规则是没办法强制约束钱包遵守的，所以有些钱包是约束自己不要坏了规矩，但导入助记词时就把别人尽量想得没素质一点、多往后派生地址、多扫描一些，仅此而已（虽然即便如此，能扫的范围也总是有限的，没办法 100%覆盖）。

手续费的话……首先要开启 RBF ，就是手续费追加。

然后可以直接去查内存池，johoe 做的内存池监视器：
https://core.jochen-hoenicke.de/queue/#24h
鼠标浮在图表上，看 1MvB 内的手续费率（是比率，相当于单价）是多少，按这个给就可以。

不够的话可以通过 RBF 追加，右键菜单里就有追加手续费。

（话说我看最近其实内存池都没满，也就是没拥堵，所以其实最低 1sat/vB 也应该能很快确认的）

“但是冷钱包里就是没有 10.21 号转账的 0.019 的记录,我从区块链网站是能查询到这个记录的”
你可以看区块浏览器里说这个交易是打包到哪个区块的（区块高度），比如是 12345 ，然后手动在 bitcoin core 里的控制台用 rescanblockchain 12345 12345

不太清楚。楼上说是读卡器+TF 卡就不行，但我几年前经常用这个组合启动，legacy/uefi 都可以，而且不是封装成 U 盘形式的产品，就是自己买的读卡器+TF 卡。

@willgyw 比如想要在重启后更快恢复之前的工作状态？

再扯远点，我记得像 chkdsk 也有强制卸除卷的选项，这也是在其他程序没有主动配合的情况下强行进行的，“会让已打开的句柄无效”

@geelaw 但我觉得有时候用户也未必在乎要不要 graceful shutdown ，结束进程就是很粗暴的动作。

svchost 这个听起来好像影响可能扩大到很严重，但反过来我也在想如果真是这样那是不是应该尽量避免影响扩大呢？我记得 oldnewthing 博客里也说过 com surrogate 就是 explorer 的替死鬼。

其实说到 oldnewthing 我有点想起 youtube 上 NCommander 讲的三维弹球的故事（虽然我是在 B 站看的汉化搬运），其实背后并不像 oldnewthing 里说的那么简单。

知乎答案里提到的“示例代码”，其实是 oldnewthing 博客里的一篇。不过看着感觉奇怪，因为 oldnewthing 博客文章里说没有追踪所以查不到，但知乎答案里却说“NT/2000 时代起就可以用 NtQuerySystemInformation 查到系统打开的所有句柄及其对应的 PID”（相当于 lsof 吧？）

另外其实不需要 process explorer 等工具，其实系统自带的资源监视器里就能查句柄。

当系统提示文件被占用时，为何不顺便告诉用户文件被什么进程占用呢？ - 知乎用户的回答 - 知乎
https://www.zhihu.com/question/31614421/answer/52718104

还是想办法把尾插修好吧，不然万一碰到问题了你也没救砖的手段。

B 站又是哪个？