04 篇的 Merkle 包含证明只说明叶与某个根相符。让一个轻客户端把这条证明当作支付完成依据，还要回答：根对应哪个区块、区块头链从哪里来、哪条链被选择、交易是否违反当前规则。全节点从可信软件规则与初始化起点出发，自行接收和验证区块；依赖他人提供头与路径的客户端缩小了下载范围，也扩大了必须明示的信任边界。

先修区块链（11）：重组时撤销的不是一个确认数字。完整验证需要按规则执行区块及 UTXO 状态变化；裁剪节点完成验证后可删除部分旧块体以节省本地空间，仍不等于停止验证新块。裁剪对历史重新提供、任意旧交易查询、重新扫描钱包和索引可用性有额外约束；不能承诺“开裁剪就有全部链上索引”。SPV 风格检查头链与包含路径，不运行所有交易脚本，因此其安全含义与完整节点检查不同。

flowchart TD
  P[网络提供头和块体] --> F[全节点: 规则执行与 chainstate]
  F --> K[裁剪: 已验部分旧块体可移除]
  P --> L[轻观察端: 头链与包含路径]
  L --> Q[条件: 根可信、链选择假设、重组策略]
  K --> I[旧历史查询或扫描能力另核配置]

轻客户端即使证明交易进入某个区块，也无法仅凭这条路径判断卖家是否实际发货；反过来，拥有全部区块字节的磁盘备份若未按规则重放，不能称为验证结果。接收来自单个 RPC 的 confirmations 数字还引入服务商正确性及可用性假设；远端能谎报、隐藏或延迟信息。本地验证的边界是软件实现与使用者选择的验证起点，而不是“节点跑得越久就天然可信”。

能检查什么、还能提供什么

拿到区块头、交易 T 和 Merkle 分支，轻观察端能核对 T 的哈希沿路径是否等于头内承诺的根。但如果头是攻击者编造的，完整路径仍无法证明它属于应采用的链。即使头经过某种工作量检查，客户端没有逐笔执行当前 UTXO 和脚本规则，仍无法仅凭 T 的包含证明排除其它无效转移。相反，裁剪全节点在删除旧块体前已验证相关历史并持有当前可花费状态；丢的是重新服务任意旧块体或无历史来源时从头扫描的能力，不是把自身降成只验头的轻节点。

按合成订单定位卖家一笔历史收款，可以提出四个不同查询：输入原文从哪里取得？当前规范块和确认策略谁来判断？输出是否仍有同一所有权含义？钱包/索引能否在裁剪后重扫旧地址？远程 RPC confirmations 把这些断言封成一个数字，无法说明其独立可核验程度。用户若确实需要过去的交易原文，应提前安排历史归档与快照核验；如果只要独立验证新块，则裁剪策略应以实测的同步和恢复条件来选择。既无真实节点，也无可信头链抓取，本篇的判断只限于验证范围对照。

练习一：有可信区块根与证明 T 包含，能得出 T 按最新链仍未被重组吗？答案：不能，须核对当前候选链与确认策略。练习二：关闭旧块保存后从一个高度很早的地址重新扫描，会缺什么？答案：可能缺旧块体，须使用能提供历史的来源或按支持的配置重建；具体能否查询须在冻结 Core 配置下测试。

节点同步、裁剪、重启索引与 SPV 头链 NOT_RUN。可迁移原则：先把“实际验证过什么”和“还保存什么数据”分别写出。参考入口：Bitcoin Core Configuration、Core 开发文档（未取得对应 release 和完整 SHA）；导航：区块链（11）：重组时撤销的不是一个确认数字 · 12 · 区块链（13）：沿交易和候选块追踪 Bitcoin 总体架构。