区块链（13）：沿交易和候选块追踪 Bitcoin 总体架构沿单笔交易区分了钱包、全节点、矿工与矿池。回看历史，旧脚本用途难拓展、签名相关序列化、私钥多方协作与高频小额付款分别是不同层的问题；不应把它们压成“一次比特币升级”。Bitcoin 早期方案先用 UTXO、Script 与累计工作形成基础边界，之后的软分叉改变验证条件但要求仍参与验证的节点依自身版本判断规则。 
flowchart LR
  A[早期: 交易/Script + PoW + 钱包] --> B[P2SH: 用脚本承诺封装花费条件]
  B --> C[SegWit: 见证分离及身份/容量相关语义]
  C --> D[Taproot: 新输出与签名/脚本路径能力]
  D --> E[当下分层: 描述符/PSBT 协作、钱包恢复]
  E --> L[Lightning: 链外通道，必要时链上退出]
  A --> P[矿池/专业矿工: 模板与工作分配]

P2SH 让接收地址承诺脚本而不是在收款时公开全部赎回条件，花费阶段仍要满足脚本；SegWit 让 txid/wtxid 与见证规则需要分开处理，旧版软件不应靠猜测识别新版本输出；Taproot 的 Schnorr 签名和不同支出路径也不能与所有 UTXO 花费方式等同。描述符解决钱包准确表达要扫描的脚本范围，PSBT 解决离线协同签名所需信息传递，均不改变全节点的验证职责。矿池可以改变工作组织方式，不会使普通节点必须相信矿池的“已验证”说法。Lightning 支付依赖通道状态、在线监控和可执行的链上争议窗口，绝非一次新共识升级。

一笔款项经过不同版本的钱包

收款前，描述符决定钱包究竟跟踪哪些脚本和派生路径；备份若只包含种子而丢失脚本策略、派生范围及联合签名参与者的信息，恢复后的扫描可能漏掉合法收款。收款输出使用 P2SH 时，付款人只需把款打到脚本承诺；花费者须提交匹配的赎回脚本及有效输入，矿工与全节点仍执行花费条件。SegWit 输出则要求客户端理解见证程序与花费见证：对一个签名参数只改见证的场景，旧交易标识与包含见证的标识不能混成一个数据库键，钱包/索引升级必须处理兼容索引的迁移。Taproot 输出也不表示所有花费都变成同一种脚本：密钥路径与脚本路径暴露的数据不同，签名域和叶版本由对应规则决定。

联合签名时，PSBT 承载待签输入来源、部分签名和协调所需上下文；watch-only 设备可选币却不该获得签名密钥。签完 PSBT 还需要最终化、节点接受、纳入有效链与重组观察。候选块从钱包交易池取得交易，并由模板构建者考虑可用块空间与奖励；矿工找到目标哈希后，验证节点仍要逐笔执行脚本和 UTXO 检查。矿池内部收益分配不是链上所有权证明。Lightning 则将日常付款移到通道内，参与者必须保留最新通道状态并能在争议窗口内广播退出；通道交易最终仍要由链上节点验证。

时间维度须分开：BIP 提案状态、Core release 包含支持代码、测试网行为及特定主网激活是四种不同证据。本环境无法核对冻结 Core 和网络状态，因此图只表示机制因果；未来脚本提案或具体钱包默认值不标成已激活路线图。

练习一：收款人有一份 P2SH 地址，能直接从地址读出完整赎回脚本吗？答案：不能，地址承诺脚本，花费时才提供相应条件。练习二：升级钱包支持 PSBT 后，发送请求是否等于交易已确认？答案：不能；PSBT 最终化、广播、入块与链选择仍是不同阶段。BIP 向量与 regtest 软分叉、钱包/矿池实测均 NOT_RUN。

可迁移原则：区别协议规则演进、客户端实现演进与链外网络演进。参考：BIP 16、BIP 141、BIP 341、Core releases（原文/激活证据待读）；导航：区块链（39）：按证明对象分类，而非排列“新一代共识” · 40 · 区块链（41）：Ethereum 从 PoW/EVM 到分离执行、权益共识与 blob。