Neutrino

Anna 打开钱包，希望看到刚收到的付款。应用要显示正确状态，就必须获取并处理 Bitcoin 网络的数据。Neutrino 可以负责这部分工作，而不必让手机长期保存整条区块链。区块是一组记录在 Bitcoin 网络共同历史中的交易。在程序中，这项服务称为 ChainService，负责连接、本地数据库以及区块头的同步。区块头是区块基本信息的简短摘要。私钥是一个秘密数值，用来生成授权花费资金的数字签名。不过，使用 Neutrino 本身并不能说明谁掌握 Anna 的私钥、谁批准发送付款。密钥管理、界面和用户备份仍由采用该软件库的钱包负责。 [1]

可以把紧凑过滤器理解为一个区块的小型检索索引。钱包下载后，在自己的设备上检查它是否与要找的内容匹配。实际比较的是脚本，也就是花费特定 Bitcoin 输出所需满足的条件。输出是交易的一部分，规定了金额以及以后花费这笔钱需要满足的条件。钱包不必把完整地址列表交给对方。一旦匹配，就下载相应区块，寻找真正的交易。即使过滤器构造正确，也可能出现误报：下载后才发现区块里并没有要找的项目，白下载了一次。因此，仅有匹配不能证明收到付款、付款金额，或钱包能否花费这笔钱。 [1] [2] [3]

Anna 更换手机并恢复钱包。如果她以前收过款，只从今天的区块开始找显然不够。应用必须提供正确的监控脚本，以及足够早的搜索起点。文档说明，没有指定起始区块时，Rescan 从最新已知区块开始，而不是自动扫描全部历史。正常工作的过滤器也找不到钱包根本没在搜索的地址，更找不到被跳过时段中的旧付款。因此，要区分恢复已经完成，还是扫描仍在进行。恢复过程中暂时空白的收款列表，本身并不意味着资金丢失。 [1]

Neutrino 同步区块头和过滤器头。通过区块头，可以检查前后链接以及 Proof of Work，即计算工作量的证明，并跟踪累计工作量最大的链。这比盲目接受服务器给出的余额可靠得多，但仍不等于像 Full Node 那样独立检查每笔交易和每条规则。此外，这里有两条不同的头链。Bitcoin 区块头并不直接承诺这些过滤器的正确性。只检查哈希这种密码学指纹，无法排除一组内部一致却造假的过滤器。减少验证工作，伴随着明确的信任边界。 [2] [4]

Peer 是网络中为客户端提供数据的另一台计算机。BIP 157 依靠比较回复，并要求至少有一个诚实的 peer，来发现错误过滤器。如果所有连接都被同一个攻击者控制，连接数量本身就没有帮助。这些机器可以一致给出虚假答案，或隐瞒更新的状态。这种切断诚实数据来源的情况与 Eclipse Attack 有关。钱包需要可用且足够独立的数据来源，而不仅是一些连接。绿色连接图标不能证明付款记录已经完整且最新。 [2]

假设 Jan 刚给 Anna 转钱。交易可能先在某个节点的 Mempool 中等待；Mempool 是该节点本地保存的未确认交易集合。随后，矿工才可能把它纳入区块。Neutrino 文档中的 recvtx 和 redeemingtx 通知是在区块确认时发出，而不是交易刚进入 Mempool 时。应用若想展示尚未确认的入账，需要另外合适的机制。一个区块尚不存在时，它的过滤器不可能提供这类消息。发送、被 peer 接受、获得确认是不同事件；没收到通知，还不能证明 Jan 根本没发钱。 [1]

过滤器匹配只有在客户端还能取得所需区块时才有用。如果网络暂时无法提供区块，正确结论是“数据尚未取得”，而非“余额为零”。链重组也可能改变状态：网络接受累计工作量更大的另一条分支，原先接上的部分区块会被断开。Rescan 会报告区块接入和断开，让应用重新计算记录。隐私同样不是绝对的：peer 虽然没有拿到被搜索的地址列表，仍能看到请求了哪些区块，以及连接的网络信息。因此，如何取得数据依然重要。 [1] [2]

Lightning Network 是建立在 Bitcoin 之上的支付网络。在一个支付通道中，双方不断更新通道内共同资金的分配，而不必把每笔付款都写入 Bitcoin 区块。Neutrino 提供链上数据；它本身不会替用户保管恢复通道最新状态所需的数据。因此，恢复钱包的交易历史与恢复通道是两件不同的事。README 描述了保存所请求的过滤器、获取区块但不永久保存的方式；实际需求还要结合应用版本与配置判断。在依赖这样的钱包之前，应了解它自己的备份与恢复流程，以及数据源失效时的表现。手机上的数据库更小，不意味着这些责任消失了。 [1] [4]