Taproot证据：可见公钥不揭示全部花费路径
可见Taproot输出公钥不会揭示全部花费条件。一条公开带时间锁脚本可以真实存在，同时另有其他合法授权路线。因此，在称资金“普遍锁定若干区块”之前，应分开某条已展示路径的条件，与覆盖所有可能路线的完整政策。
本题交付路径证据登记：注资时能看到什么、花费时揭露什么，以及要判断更广控制声明还缺什么。不能从地址格式直接推签署人数，也不能从一条复杂脚本推断全部资产均受同样约束。
把控制声明拆成确切命题
例如“财库资金需要两次批准并等待三十块”，应先问它指恢复路径、日常路径、一组地址全部输出，还是某个指定输出的一切花费。范围不同，需要的证据不同。
BIP341的Motivation及Constructing and spending Taproot outputs部分说明有限揭露设计，以及key path与script path的区别。脚本路径见证提供当前脚本和承诺核验所需控制块，却不会自动公开兄弟哈希背后每一条脚本的内容与条件。
保留资金来源outpoint、scriptPubKey、输出公钥和网络。已有花费交易时，取得原始见证并按适用规则分类路径。浏览器写“多签”，不证明这笔花费使用了所显示数量的脚本签名要求。
按观察阶段组织材料
注资时，输出承诺有关公钥与脚本树构造，但不会把全部条件展开。除非另外取得足够材料，登记表应把完整政策标为未知，而非默认只有项目页面展示的那一条。
key path花费支持检查有关公钥授权，却不揭露它来自一个人的密钥、某种聚合安排，还是其他链下控制关系，也不会枚举未使用脚本。公钥看起来只有一个，不能据此认定只有一名独立决策者。
script path花费则需要解析实际脚本与控制块，核对其与原输出的连接，再评价这条路线的要求。“这条条件被使用”不同于“其他条件均不可能使用”，后者要更多材料。
无法识别的见证结构应留原样，不能强行套熟悉模板。解析失败是研究能力边界，不是资金没有限制的证据；它应触发更窄结论或进一步核验。
假设的双脚本财库
设虚构、兼容比特币规则的环境中，一个输出在高度五千创建。为演示而规定，构造者有两片脚本叶：第一叶L一要求假定的双签授权，且候选花费高度H不低于五千零三十；恢复叶L二采用不同授权，且H不低于五千一百。这个构造中还存在可用key path授权。
上述高度条件是明确假设，不是通用于所有sequence字段或所有共识时间规则的解码捷径。项目公开材料仅展示L一，却称三十块条件覆盖整个输出。
| 可用材料 | 支持观察 | 不能扩张为 |
|---|---|---|
| 只有注资输出 | 指定输出公钥存在 | 恰好两个人控制全部花费 |
| L一及已验证承诺路径 | 此叶被输出构造承诺 | 此叶是唯一可用路径 |
| 高度五千零四十使用L一的有效花费 | 该笔满足适用路径规则 | 一切更早花费都不可能 |
| 另一假设历史中五千零五的有效key path花费 | 该构造公钥授权可在此时花费 | 这条路线也受L一三十块条件限制 |
对L一复算，五千零四十减五千等于四十，满足假设三十块要求。五千零五的key path花费则在注资后五块发生。它没有破坏L一时间锁，而是使用另一条授权路线。
两次花费是同一输出的替代历史，不能同时消费同一有效选定链中的outpoint。比较用来检验控制政策，而不是在财库流水中新增两笔完成提款。研究者必须保留这种“可能路线”与“实际发生”的区别。
读者知道假设构造中有L二，不代表现实链上观察者从L一证明就能看出L二。发布材料应把演示者掌握的完整构造，与公众实际取得的那一部分分列，避免在推理中偷渡隐藏信息。
重建承诺后，再评价完整性
有脚本路径材料时，保留控制块中的内部公钥、叶版本、当前脚本和有序兄弟哈希，用实现相应Taproot规则的验证器连接输出，包括所需公钥检查。不能只比较脚本名称或截图中参数。
树路径认证当前叶属于该输出构造。兄弟哈希承诺隐藏材料，却不说明材料文本与条件。看到一个兄弟哈希，不证明另一叶与L一采用相同门槛、相同等待期，甚至不证明其承担同类用途。
项目若提供所谓完整树，使用给定叶和内部公钥重建承诺并与注资输出比较。需要问“在这份构造下是否完整且匹配”，而非“列出的每条脚本是否看起来严格”。保留包版本、提交人和取回日期，才能比较后续更正。
即使完整树给出，也不单独解决key path控制。若声明该路径故意不可用，还需解释内部公钥构造与假设。一个未公开私钥的点，并不等于证明没有任何人知道相应秘密。不能把“未见私钥”升级为不可花费性证明。
重建失败时，先检查叶版本、字节、排序和控制块对象身份，再判断项目声明是否缺少材料。把同名脚本从另一版本拼进来可能产生合理但错误的树，不能用“逻辑看起来一样”替代实际承诺匹配。
不同机制边界：使用不证明必需
操作者可能主动选用脚本路线，即使另有合法路线可用。因此，看到一次script path花费不证明当时key path不可能使用。它只说明这条路线在相关核验中被使用，替代控制仍需另证。
三十块条件也可能本来只用于恢复，而非日常解锁。应读清运营声明：恢复机制的真实描述，只有在无支持地扩张到全部花费时才产生范围问题。研究不必否定真实叶，只需纠正过宽结论。
机构持有多个输出时还要检查覆盖。一条正确审过的路径不能认证全部财库UTXO。列出哪些outpoint共享已核构造、哪些未查，不从一个样本推成机构统一控制政策。
什么新证据改变判断
新增揭露叶可能增加已知路线；后续花费说明实际选用了哪条路线；更正后的完整树可能修复承诺不匹配。所有变化都应保留发生日期，不能回填为公众在披露前已经知道的事实。
两份文档若对同一输出声称不同内部公钥或树，保留双方并做承诺核验。与真实输出匹配是收窄争议的具体办法。缺失包就是缺失，不应由营销图自行补全。
还要区分密码学匹配与组织控制。设备共享、托管协议及受益控制可能仍不明，即便链上条件清楚。应数已验证公开条件，不能把公钥、签名设备或角色名称都当作彼此独立的决策人。
以路径而非地址分配状态
若研究要估计某期限内可动用数量，不要给一个地址统一贴“已锁”标签。先按outpoint和已知路线列条件，再说明替代路线未知的数量。无法建立所有路径条件时，该部分应为可用性未确定，不能由一片已知带锁叶计算一个貌似精确的全财库等待期。
例如两个输出各五BTC，仅第一个拥有核对完整的声明材料，第二个只见注资公钥；不能将两个相加后称十BTC都受三十块条件约束。证据覆盖数量五BTC与总名义数量十BTC可以并列，但覆盖比率不是资产安全概率。
可执行路径登记
| 操作 | 保存证据 | 最多支持的说法 |
|---|---|---|
| 固定输出 | 网络、注资outpoint、公钥 | 这是被研究对象 |
| 解析实际花费 | 原始字节、见证、选定链 | 本历史使用了此路线 |
| 验证揭露叶 | 脚本、控制块、验证结果 | 该叶属于输出构造 |
| 解码限制 | 公钥、签名规则、时间条件 | 条件适用于此路径 |
| 评估替代路线 | 完整树与密钥构造材料 | 仅在已核覆盖内描述更广政策 |
| 对照公开声明 | 原句、日期和输出范围 | 列出支持范围与未解决扩张 |
最终可以说：某已承诺恢复脚本要求规定等待，但所读材料尚不能建立每条路线或每个财库输出都相同。这样的边界保留了已证事实，也避免把地址类型或单片严格脚本夸大成完整控制审计。
常见问题
Taproot地址是否证明特定多签门槛？
不是。可见公钥不枚举链下参与者，也不揭示全部脚本替代路线。
观察到延迟脚本花费，能否证明更早花费不可能？
不能。它表明使用路径满足规则，全部替代路线还需脚本树和key path材料。