@um6uih 区块应该不用删，可以新建一个钱包重新扫描对应范围的区块试试。

@um6uih 我猜，说不定 2021.10.21 的那笔当时就没能进链确认，本来就在今年 1.18 号才进链确认的？

像交易所那种，你自己不掌控私钥，叫做“托管钱包”（ custodial wallet ）。

自己掌控私钥的就叫做“非托管钱包”（ non-custodial wallet ），无论是冷热都算。

“冷钱包”……哎还是不吐不快

bitcoin core 一般情况下，私钥是保存在联网的环境的，所以它叫做热钱包。

如果把私钥从生成到后续使用都从不联网，这才叫做冷钱包。不过冷钱包其实只不过是不直接联网而已，还是需要二维码、蓝牙等方式传递交易数据的。联网的是没私钥的“仅观察”钱包，起草交易后，传递给冷端，冷端检查交易内容并签名后，再传递出去。bitcoin core 原先不支持冷热分离；在支持 PSBT （一种通用的标准交易格式）、并且大改钱包底层为基于输出描述符后，也开始支持冷热分离了。

@litesoar 所以 walletsrecovery 上也说了，其实只拿着一个助记词是不够的，“一个助记词就够了”这个理想很美好但不接地气，作为用户你其实是还得知道这个助记词是哪个钱包（甚至是哪个版本）生成的，否则未来恢复钱包可能遇到问题不能正常或完整恢复。

像提出 aezeed 的开发者（也是 LND 的开发者）就认为，最终还是每个钱包自己做一套助记词格式。（所以呢？难道“不如干脆弃疗”？😂）
嘛……怎么说呢，毕竟每一家钱包都各有各的想法（摊手）。

@litesoar

我记得 walletsrecovery 里还列出有些钱包，乍一看好像遵守 BIP44 这些，但他自己有一些小动作实际上偏离了标准（比如 gap limit 过大之类的），反正是挺蛋疼。

@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 的替死鬼。