“也许楼主不是先同步完区块再加载 wallet.dat 的，而是先加载 wallet.dat ，然后同步区块”这种情况下，也有可能不是 Bitcoin Core 的软件 bug （我其实不太相信 Bitcoin Core 会有这种恶性 bug ），而是楼主自己的操作失误，比如实际存币的交易其实不在那个 wallet.dat 里面，是需要导入进去的，但楼主忘了导入，这样能扫描出来反而就有鬼了。
在这个“实际存币的私钥不在 wallet.dat 里，需要导入进去”基础上，还可以脑补其他情况，比如同一个私钥其实是对应压缩和非压缩两种公钥的，压缩公钥功能一样，字节数更少，所以现在一般都用压缩公钥了。但是这样的话，一个私钥就可以对应两种 1 开头的地址，一个是压缩的，另一种是非压缩的。一般私钥都是 WIF 格式，为了避免这个问题，WIF 格式规定了一个标志位来区分压缩和非压缩，比特币的压缩私钥开头的 K/L，非压缩私钥开头是 5，但是有些工具也提供这两种格式的转换……也有可能楼主是掉进这个“压缩 /非压缩”的坑里了。

非开发者，来啰嗦几句……

Bitcoin Core 全节点钱包的工作原理我记得非常简单粗暴、也非常低效：直接扫描几十上百 GB 的区块文件，从里面匹配过滤出与自己有关的交易，然后保存到 wallet.dat 里面。
这某种程度上也是无奈之举，因为如果要编制索引的话（ txindex 那个太简陋了，完全不够用），虽然可以达到在线区块浏览器那种几乎是秒速查到结果的速度，但是占硬盘又太大——比特币不是讲究去中心化嘛……于是，实际上还是这个最简单粗暴也是最低效的办法来维护钱包交易记录。

所以，如果 wallet.dat 里面漏了什么交易没扫描进去，那就比较麻烦，需要重新把几十上百 GB 的区块扫描一遍。

于是我啰嗦了那么半天，才终于触及到楼主的问题（应该是这样）：为啥 wallet.dat 里会漏掉一些交易没扫描呢？

额，坦白说，我也不是很清楚。


按理说，wallet.dat 里也会记录上次扫描到的区块位置，这样下一次打开钱包进行同步（扫描区块），就不需要重复扫描那个时间点之前了，毕竟之前已经扫过了嘛。

“重新把几十上百 GB 的区块扫描一遍”——具体要扫多少，就取决于钱包里标记的时间点，时间点距离现在越久远，涉及的区块就越多，扫描量当然就更大、更费时了。


所以……也许楼主是触发了什么 bug 吧。

比如，如果是区块同步已经完成后加载 wallet.dat ，那按理说应该会有一个耗时挺久的区块扫描过程，几分钟到几十分钟不等。也许就是这里触发了 bug，明明还没扫完新区块，钱包文件里却标记了新的时间点，结果就是跳过了这些区块，压根没扫描……

再比如，也许楼主不是先同步完区块再加载 wallet.dat 的，而是先加载 wallet.dat ，然后同步区块——这样的话，bug 性质就更严重了，说明 Bitcoin Core 明明睁着眼扫描过了所有新区块，却仍然对区块中与自己有关的交易视而不见。


还有一种可能，并不是 Bitcoin Core 软件的 bug，而是楼主自己操作失误，跳过了自动扫描、又忘记执行手动扫描。
也许楼主用 JSON-RPC 命令行控制台进行过 importprivkey 之类导入操作。导入私钥 /公钥 /地址之后，当然也需要重新扫描区块，不扫描区块就无法恢复出正确的交易记录和余额；但是扫描区块又很费劲，所以这些导入命令也提供参数，可以跳过自动的、从创世块开始的扫描（然后用户可以手动指定一个比较小的范围来扫描）。如果楼主也是这样，导入私钥时设置了不自动扫描，然后完全忘记了手动执行区块扫描，那也会出现钱包漏掉交易的情况。


啰嗦这么多，如果楼主只是想解决问题，那我推荐楼主用命令行控制台执行 rescanblockchain 命令来重新扫描区块（就如上文所说，这个命令可以指定扫描范围，这样扫描起来就会轻松一些）。

如果楼主还有兴趣帮 Bitcoin Core 找 bug，那可以回忆一下操作流程，试试看是不是能发现 bug 并稳定重现，然后可以去 Github 上报告。

@1up 但是比特币把以太之类能用显卡挖的币也带起来了啊……

关于 BIP39 助记词，这个最好不要自己瞎折腾，钱包安全的“根”就在这里，如果助记词泄露，或者在生成的时候用了恶意的钱包或工具软件，那一切都完蛋。


还有矿工手续费，可能网上还有不少过时的信息，在说比特币几乎是零手续费……现在很显然不是这样，因为区块大小有限，而且最近市场热度又起来了，最近比特币一直是拥堵状态，只有矿工费给得最高的交易才能优先确认到账，否则就会一直排队卡在零确认状态。如果你的矿工费给的不够多，那可能几个星期几个月都确认不了。

更蛋疼的是……广为流传的说法“确认不了就会退回自己的钱包”是错的，理论上即便卡了几个月甚至几年，仍然有可能随时确认到账（虽然矿工存放待打包交易的内存池确实是有超时时间的，但是交易本身没有超时时间，即便从内存池里踢出去了，也随时可以重新广播重新加入内存池，而且理论上任何人都可以进行这个重新广播的动作）。理论上最保险的做法就是等到它真正确认，以及，用 RBF 或 CPFP 追加更高的矿工费来“插队”到别人前面、加速确认。
Electrum 最近还加了一个“撤销交易”功能，实际上还是用 RBF 追加了更高的矿工费，只不过这次是改变了交易的真正内容 /意图，把币转回自己的钱包（而不是转到之前的目标地址）。

最后……最关键的，cash out，有不少地方可以场外 OTC 卖币，localbitcoins 、huobi 、okex 、binance 、bitpie 、bixin……

不过问题也不小，主要是一直以来都陆陆续续有人因为收到 黑 钱 而遭到冻卡。

而且，国家的态度大家都知道……

还有，按照 BTC 社区的理念，即便个人用户也要跑自己的全节点，这样可以完整验证区·块·链账本的内容，而且不依赖中心化服务器来查询钱包历史记录和余额，不会把自己的地址信息（比特币的隐私性很差，地址与个人信息不挂钩、而且可以用一次换一个，就是仅有的一点点隐私了）提交泄露给钱包服务器。

（不过很显然，跑一个全节点的负担也不小，很折腾很麻烦；而且因为缺乏完善的索引，可用性易用性很差……）

Electrum 钱包也是可以对接自己的全节点的，用 bwt 或 Electrum Personal Server 就可以。
不过因为 Bitcoin Core 全节点的索引功能几乎等于没有，一但需要扫描区块（这样才能找回历史交易记录，从而找回正确的最终余额），就很麻烦。
目前的话，如果不开启区块修剪功能，就要占 300GB 的硬盘来保存比特币十年以来的区·块·链账本，从头扫描一遍的话需要接近一个小时；如果开启了修剪，那就直接失去扫描历史区块的功能。
未来借助 blockfilterindex 应该可以缓解这方面的问题。

Electrum 现在还支持闪电网络，不过有一说一对闪电网络还是不要报太高的期望……
如果真要尝试，我建议用 ACINQ 公司的 Phoenix，用很少的、丢了也不心疼金额玩一玩。Phoenix 还是非托管的，理论上还是相当于用户自己掌控私钥；除此之外也有不少中心化托管的闪电网络钱包，比如 Wallet of Satoshi 、BlueWallet 之类的。

个人比较推荐 Electrum，支持冷热分离（热端永远不碰私钥，冷端永不联网），支持原生（ Bech32 ）隔离见证（不过开发者脑子比较轴，拒绝创建 3 开头的 P2SH 隔离见证钱包），支持 RBF 和 CPFP 两种方式追加矿工手续费，支持对接硬件钱包，支持多重签名。

不过有一说一 Electrum 前几年爆过几个影响很大的安全漏洞，影响最大的是钓鱼漏洞，虽然钓鱼漏洞不能直接偷币，但是因为欺骗性太强还是有不少人中招。而且 Electrum 的服务器不是官方维护的，也是像比特币 P2P 网络一样自由进出的，所以即便新版已经修补了漏洞，老版本还没升级的话，还是有可能收到钓鱼信息。除了钓鱼漏洞，还有理论上同一台机器浏览器点开恶意网站就能偷币的 RPC 漏洞，不过没听说过有几个人因为这个丢币。

再有就是 Electrum 开发者一直以来都抵制业界通行的 BIP39 助记词，他们自己搞了另一套极为相似（实际上单词表都是一样的）的助记词格式（单词数量也是一样的 12 个，所以和 BIP39 存在混淆问题），但很显然和 BIP39 互不兼容，这一点也要注意。不过 Electrum 是可以导入 BIP39 助记词的，只是创建钱包的时候不是 BIP39 而已。

bitcoin . com 这个是 Roger Ver 的地盘吧，Roger Ver 是大区块党，BCH 支持者，在 BTC 这边算政治不正确吧……（笑）

Guarda 这个没听说过。

Web 钱包实际上就是用 JS 把钱包软件跑在浏览器里，个人不推荐用，万一浏览器里有个什么恶意插件，可能就 GG 了。

bitcoin . org 官网不是有钱包推荐么？（额，这个官网基于去中心化的精神，自称不是官网）

@est 玩币的大概有不少都听说过 shamir's secret sharing 。Trezor 就制订了一个 SLIP39 标准，用 sss 来生成分割成多份的钱包种子助记词。Ian Coleman 还做了一个实验性的工具。

按照标准的流程，解锁 bootloader 是需要恢复出厂清空数据的。

即便你真不幸被黑了，也很难说对方会不会“守信用”。你压根不知道对方是谁，其实这压根就不存在什么信用。

类似这种是广撒网的钓鱼邮件吧。真有本事黑你，应该会像勒索软件一样直接搁你电脑上弹窗，把你的系统搅得一团糟了。

@liliclinton rufus 我记得有个问题，就是它为了支持 NTFS 、exFAT 等 UEFI 标准不包括的文件系统，自己搞了一个引导器，放在一个 FAT32 小分区里，但是这个引导器没有数字签名，在 SecureBoot 默认开启时不能用。

@frienmo 我不算大佬……只能算话痨。
不止 Eclair，Phoenix 也是 ACINQ 出的，你可以试试，不过目前拥堵貌似还是蛮严重，矿工费蛮高，最好还是等等。

走闪电网络收·款的 invoice （应该是你说的“地址”，但它不叫“地址”）好像也不太好翻译，直译应该是“发·票”，但是貌似很多时候说“发·票”都是“收·据”的意思，是钱已经收到了；而 invoice 实际上是请求付·款的，付·款还没发生。
invoice 确实是有过期时间的，不过我刚刚去 bitcoin stackexchange 看了一下，这个过期时间其实没有特别硬性的技术理由，只是为了规避一些可能存在的问题（比如币价波动，毕竟绝大多数时候还是法币标价）才设计成这样。
还有，invoice 是不能重复使用的，这也是闪电网络的一个不方便之处。开发者有在研究解决这个问题，比如 keysend，但是我记得仍然不能离线收·款——所以没错，eclair 在收·款时确实必须开着。
还有，如果你没有公网 IP，即便钱包 /节点开着（ eclair 或 phoenix 本身也算一个闪电网络节点，只不过它不广播自己的存在），我记得也无法付款，这个问题可以通过在 invoice 里加 routing hint，指定和自己开通道的其他节点 IP 来解决，eclair 默认就加了 routing hint 。

你说的支·付通道刚打开时，只有付·款额度没有收·款额度，导致只能付·款、不能收·款——Phoenix 用户就不会受这个问题打扰，它是“纯闪电网络”钱包，完全不需要手动管理通道，直接拿着 invoice 就可以收·款，收·款过来的时候，ACINQ 公司的节点会自动开一个通道给你，而且在打开通道的 funding tx 还是零确认状态的时候，你也可以直接走闪电网络把刚刚收到的币花出去。

不过很显然，Phoenix 钱包的种种便利，包括自动通道管理（尤其是自动提供有收·款额度的新通道），无需自己操心通道数据备份（ ACINQ 的服务器负责随时备份），其实都依赖于 ACINQ 的服务器，包括支·付寻路也是交给 ACINQ 的服务器完成的，所以理论上隐私性也存在问题，去中心化程度也大大降低。不过我记得 ACINQ 也没有打算垄断 Phoenix 的钱包服务器，他们打算把这种钱包服务器搞成公开的技术标准。