@lhx2008 果然，无线耳机才是正解么😂

也许可以换个思路，用 autohotkey 监听按键来“改键”

@Sekai bitcoin core 同步区块，最慢的一般不是下载本身，而是下载后验证区块内容、根据区块内容对 UTXO 进行查询和增删。尤其是机械硬盘，慢到令人发指，主要就是 chainstate 这个目录，UTXO 集合就保存在这里。

这个问题的对策，就是把 UTXO 集合全部放到内存里。
如果是从头开始同步，直接把 dbcache （也就是图形界面设置里的“数据库缓存”）调大就可以了，上次我记得得调到 8GB 左右。
如果不是从头开始同步，我没找到能“预加载”到内存里的办法，后来我就想了个能奏效的 trick，也就是利用操作系统的磁盘（或者说文件系统？）缓存，用 cat （ linux/mac ）或 type （ windows cmd ）命令把 chainstate 里的东西读取出来然后重定向到 /dev/null （ linux/mac ）或 nul，也就是单纯读一遍，然后操作系统就会把文件读到内存里缓存起来。

另外还有一个问题不知道现在修正了没，就是开启修剪的时候，上述办法不奏效，每次删掉老区块文件时都会把内存里的 UTXO 数据写入磁盘，于是速度又显著拖慢了。对于这个，有个蛋疼的对策是用 ramdisk 和 ntfs junction （ windows，linux 的话整个 tmpfs 然后 ln -s 更简单），但这样加一层 ramdisk 有性能开销（尤其是受 spectre 漏洞影响的老 CPU……）。

如果单单说闪电网络我印象里 ACINQ 开发的 Phoenix 钱包是比较省心的。闪电网络固有的备份难等问题也被服务器包揽了。不过无法离线收款这个我记得还是没有好办法，Phoenix 也顶多是开个后台服务这样。

说那么多，我个人比较推荐的钱包还是 electrum，它的钱包服务器有完善的索引，很快。支持 RBF，支持隔离见证，支持多重签名，支持冷热分离，支持 PSBT （可以和其他支持 PSBT 的钱包混搭使用）。支持对接硬件钱包。配合 electrum personal server 或 bwt 还支持对接 bitcoin core 全节点。甚至还支持闪电网络。

啊，其实吧，“就来问问哪个平台比较稳？”——这话本身就是个政治不正确的槽点😂

比特币可是去中心化的，交易所是随时可能跑路的，只有菜鸟才会依赖“平台”交易所，真正的比特币用户就是要自己跑全节点自己同步交易记录自己管理自己的私钥（笑）

钱包就是个工具，一个工具他就不存在跑路问题（虽然还是可能存在开发者作恶或被黑然后植入恶意代码的问题），跑路了大不了私钥 /HD 种子导出来，迁移到另一个钱包就好。

@acess “很早很早以前 bitcoin core 就有一些开发者非常非常 [抵制] 现在是“业界事实标准”的 BIP39”
打字又打漏了，纠正一下。

还有，bitcoin core 的钱包最近貌似也要换代来着，数据库从 Berkeley DB 换成 SQLite，另外生成私钥 /地址的方式也要改，之前生成地址的时候也用了 hardened derivation，现在应该是要改成遵守 BIP44/49/84 了。

在推上看到正在搞这块的开发者 achow101 还提到以后可能要彻底淘汰掉 Berkeley DB 的老式钱包，只留一个转换工具。

但是我记得 bitcoin core 到现在仍然没有助记词。没错，并不是只有 12 个单词才是 HD 钱包，bitcoin core 就是不走寻常路，没有 12 个单词方便用户备份 HD 种子，但他仍然是 HD……😂
很早很早以前 bitcoin core 就有一些开发者非常非常现在是“业界事实标准”的 BIP39……主要理由是 BIP39 本身其实并没有规定 HD 派生路径，BIP44/49/84 这些都是后来才有的，于是就会导致：A 钱包的路径和 B 钱包不一样、然后 A 钱包的助记词导入给 B 钱包后，B 钱包显示余额为 0 、并且生成一堆崭新又陌生的地址这个问题。（另外即便是有了 BIP44/49/84 之后，具体要用这三个里的哪一个，一般仍然需要用户手动指定或切换，于是用户仍然可能惊呼“欸怎么币丢了、余额是 0 ？”——实际上并没丢，只是忘了切换、只是“打开的文件夹路径不对”而已）
结果依我看放弃 BIP39 而另起炉灶搞出其他的乱七八糟的助记词格式其实只会让情况变得更糟糕更混乱。

（这里就不提更古早的、连 HD 都不支持的上古 wallet.dat 不会自动升级到 HD （于是 bitcoin core 钱包界面右下角会显示一道斜杠划掉的“HD 已禁用”图标）、而且即便升级到 HD 其实本质上也是新建了一个既不和业界事实标准兼容又不方便备份更不兼容冷热分离的新 HD 钱包这个老梗了；哦还有一个老梗，就是这个蛋疼的既不和业界事实标准兼容又不方便备份更不兼容冷热分离的的 HD 钱包一开始甚至都没把找零和收款分离到不同的 BIP32 key chain 或者说 derivation path 上，是后来才做的分离，但做了分离也不能抛弃之前的 wallet.dat 不管，于是这里又产生了一个难懂的术语“HD-split wallet”……😂🤦‍♂️）

还有就是手续费的问题……众所周知 BTC 链上交易是经常出现拥堵的，美其名曰“手续费市场”（ fee market ）。如果你付出更多手续费（矿工费），你就可以在矿工的内存池里插队到别人前面，更优先打包。
bitcoin core 我记得 RBF 一开始还不是默认启用，后来（额，反对 RBF 的大区块派也大多分裂出去跑去支持 BCH 、BSV 什么的了）改成默认启用 RBF 了。
（还有，注意 RBF 是发出交易时启用的，如果交易发出去之前没启用 RBF，虽然原理上还是可以插队，但一般钱包不直接提供这样的“插队”、矿工的内存池可能也在一段时间内不接受）

bitcoin core 的 RBF 我记得右键菜单里就有，一键完成，但我感觉还是不够灵活。

相比而言，Electrum 钱包就可以自己指定 RBF 具体要把矿工费追加到什么费率（ sat/vB，费率越高越优先打包），而且还有除了 RBF 之外的备用选项 CPFP （不过 CPFP 需要多产生一笔交易，所以很显然矿工费要花更多）。

有了 RBF 其实就不用找矿池买什么“加速器”了，根本原理其实是没多大区别。

可能很多人压根就不在乎“隐私”，地址复制粘贴到区块浏览器，或者说 HD 种子导入到 XX 轻钱包，秒速得到查询结果，能用，就完事，压根不会考虑到什么去不去中心化、隐私不隐私什么的。

另外如果你说我用 XX 在线区块浏览器、XX 轻钱包（比如 Electrum ）查询不是一直秒速完成么？
（顺便说一下 Android 上很有“官方”范儿的 schildbach wallet，这个钱包用的是 BIP37 bloom filter 协议，挺老了，而且一样很低效，是客户端这边提交一个“特征”给全节点，然后全节点这边……额……如果要恢复交易历史的话，还是得进行低效的区块扫描动作）
这还涉及到有点 political 的社区争议。bitcoin core 这边其实认为轻钱包是“不安全”的，因为没有完整验证账本内容、单纯跟随算力（ SPV 就是这样），甚至连 SPV 验证都不做、纯粹跟随（中心化的）服务器。
对于 BIP37 协议，（其实还有一个理由，就是认为 BIP37 的 bloom filter 在对客户端比特币地址的模糊化上做的不够，隐私性欠佳）之前甚至一直都想彻底把它从 bitcoin core 里逐步淘汰掉。
我记得按照 schildbach 的观点，BIP37 也有其他协议提供不了的功能，但没人志愿去做这个费力不讨好的活儿……

@acess 啊，我好像又不小心打错了，“第 61-70 号”应该是“第 51-70 号”

有意思的是 bitcoin core 其实很早就支持生成 Neutrino 的 block filter index 了，然后就可以作为服务端给 Neutrino 轻钱包提供服务；只是它自己还不能利用 block filter index 改善扫描区块低效的问题。

我记得之前也有开发者把 BIP157/158 （又名 Neutrino ）也在 bitcoin core 上实现，Neutrino 在我理解，就是在 bitcoin core 目前这个没索引、就硬扫，与区块浏览器 /钱包服务器的索引完备、但占用硬盘空间巨大，这两个中间取了一个折衷，只需要占用完整区块账本的 2%左右（虽然这样很显然还是随时间线性增长、越攒越多……），就可以实现更快的扫描，我记得目前只要几分钟就可以扫完整条链。但上次看好像就说代码里还有 bug 没修好，所以一直就没合并进来。

“右边提供了官方客户端”？

你说 bitcoin core 么？

其实 bitcoin core 这个本身的钱包功能我记得挺弱的。最近挺久没用了，不知道有没有改进。

主要是索引不完备（ txindex 那个完全不够用，只能根据 txid 查交易，连币花掉后去了哪都不能直接追踪，还得扫区块）

于是你导入一个私钥或地址，他还得扫描扫个几十分钟（如果你指定一个扫描范围那很显然会快不少，然并 X，前提是你得知道范围啊），扫描上百 GB 的区·块·链账本，扫完了才能把交易记录恢复出来、进而算出现在的最终余额。

更坑爹的是如果你开了区块修剪（ pruning ），（实际上这个“修剪”就是简单粗暴地删掉老区块文件，和比特币白皮书的修剪并没有半毛钱关系，而且白皮书的修剪其实也没多大意义，因为“剪枝”后账本就不完整了，丧失了“自证清白”的能力），那么，我记得你甚至不能导入私钥 /地址 /钱包，因为很显然，老区块已经被删了，无米之炊。

用 scantxoutset 命令可以直接扫 UTXO，也就是直接扫描“最终余额”、跳过对“交易历史”的扫描，这样一般比扫区块更快（很显然也取决于你扫的区块多不多），而且可以绕开上述修剪的影响。但对于 HD 钱包来说也有个潜在问题，差不多就是 gap limit 的问题。

什么是 gap limit 呢？
HD 钱包其实也蛮蛋疼的，并不是你给了一个 xprv 或 xpub，你就能据此立即知道某个地址是不是这个 xprv 或 xpub 能派生出来的，于是 BIP44 就规定了，钱包生成未使用地址最多只能 20 个（虽然这也然并 X，还是有不少钱包出于各种理由打破这个限制）。
如果打破 gap limit 会发生什么？比如你之前用到了第 50 号地址，然后后面 20 个地址你都跳过了、没有产生交易记录，直接开始用第 71 号地址（虽然守规矩的钱包会禁止你这么做，但很显然有的钱包不守规矩，而且还有其他的工具比如 ian coleman bip39 tool 更是可以不守这个规矩，如果你自己想往后多派生没人拦得住你），
那么当你用 HD 种子 /xprv/xpub 恢复钱包的时候，从第 71 号开始往后，可能就会恢复不出来。
为啥呢？因为钱包软件“顺藤摸瓜”到了第 50 号地址后，按照 gap limit 只继续恢复到了后面的第 61 号到 70 号，第 61-70 号地址因为没有交易记录，所以就不能继续“顺藤摸瓜”了。（钱包软件对付这个问题的对策顶多只能是多留一手，多往后派生一些地址，比如 1000 个而不是标准规定的 20 个，很显然还是很难彻底避免这个问题）

如果是老老实实扫区块，也就是扫描（全网所有人的）“交易历史”的话，那好歹还有从第 0 号地址开始顺藤摸瓜的可能；如果是直接扫 UTXO 也就是直接扫（全网所有人的）“最终余额”，那么问题很显然更严重，你更不知道现在已经用到第多少号地址了。

另外并不是有了更完备的索引（比如在线区块浏览器以及钱包服务器）这个问题就不存在，但是有了更完备的索引，至少查询会比扫区块这种极度低效的方式快不少。

如果你想要更完备的索引，那么也有开源的钱包服务器 /区块浏览器软件可以用，但我自己没有使用经验。

另外只要不是特别频繁地需要查询 /扫描，其实没有完备的索引也不是不能用，毕竟新区块产生速度又不是那么快，跟着扫描不是啥问题。

软件 NAT 本来转发性能就不好吧

@kebamt 重点不是弹窗，而是各种各样的墙

关 active probing 没解决（包括组策略）
重新打开 active probing，然后 ActiveWebProbeHost(v6)改成 www(ipv6) . msftncsi . com，ActiveWebProbePath(v6)改成 ncsi.txt 就好了

先关 WD 的自我保护（“防篡改”）再组策略