还有就是手续费的问题……众所周知 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 的自我保护（“防篡改”）再组策略

（我是双硬盘，系统是 SSD，但也有一些程序在 HDD 上）

我记得微软有个奇葩的 CompatTelRunner.exe ，说难听点跟木马似的，扫硬盘，说是检查程序兼容性。
还有 chrome 也有个类似的东西 software reporter tool，可能是扫毒用的。
一开始我还懒得管，后来实在是烦了，用火绒加规则把这俩禁了。

除此之外就是 TiWorker.exe ，不太懂具体在干啥，但好像和更新有关，不知道是扫描组件完整性还是整理 /清理旧版组件什么的。

有点好奇是不是 SMR 叠瓦盘

procmon 我记得可以从启动开始抓取事件。

@wondering 谢谢，还没试 BSG 这边的 Gcam，不过 Nikita 这边的 changelog 页面上有提到：
“Based on: B-S-G and Arnova8G2 GCam 7.4.104”
……
“• Fixed AUX video crash, need enabled restart first (Thanks tigr)”
换句话说，应该是原先 BSG 的版本至少在 7.4.104 还没修正辅助摄像头录像的问题……

@HankAviator 我这边试了，可能还是我没找到正确姿势？ QQ 消息弹出来的时候，往下拖动就是直接把通知栏拖下来展开了。
在女娲石里加了 QQ 通知进化，然后貌似有改善了，可以点右上角三角按钮展开多条通知了，但如果想继续往上翻历史消息之类的好像还是不行。

@starcraft
其实我发这个基本没什么抱怨的意思（抱怨也没用啊），大致就是说说我自己的踩坑经历。我并不是没有心理准备，只是知识方面确实比较脱节……

@jerryjhou 也许皮套才是真正靠谱的办法……