让 LND 盯住一枚不属于自己的 Taproot 地址：ImportTapscript 的四种知情深度

场景：钱在别人的脚本手里

闪电节点常见的观察需求是：一枚 Taproot 地址由外部协商的脚本树控制，私钥不在 LND 手里，但运营方希望 LND 把它的余额与收支记进自己的账本。lnrpc/walletrpc/walletkit.proto（v0.19.0-beta）里的 ImportTapscript 正是为此设计：注释写明它导入一个 Taproot 脚本与内部密钥，把由此得到的 Taproot 输出密钥作为 watch-only 输出脚本加进钱包。与之相对，ImportPublicKey 只观察 BIP-0086 风格的输出脚本——没有 root hash 承诺、没有脚本花费路径的纯密钥花费；源码注释直接指路：更高级的密钥花费或脚本花费输出，请用 ImportTapscript。

四种模式的选择逻辑

选择哪种知情模式的判断方法很直接：数一数自己手里有几个要素。完整树结构与全部叶子在手，选 full_tree，让钱包自己算承诺并自带一致性校验。只有一片叶子和它的证明路径，选 partial_reveal，此时包含证明的正确性直接决定算出的地址，导入前值得多方交叉验证。只有一个三十二字节哈希，选 root_hash_only。连内部密钥和承诺都没有、只有收款地址本身，选 full_key。前两种模式适合「将来可能自己花」的场景，后两种天然偏「只盯不花」。最常被误用的是把 full_key 当成可控地址——该模式下钱包不知道内部密钥与承诺，谈不上花费能力，只能报数。

导入后的验证动线

实操建议三步：导入响应里的 p2tr_address 先与账本上预期的地址逐字符核对，不一致立即排查输入再重新导入；确认一致后先转一小笔测试金额，观察钱包余额与交易记录是否出现这笔来款；再把这笔的确认数纳入常规监控。三步各花几分钟，能在生产金额进场之前暴露脚本树计算错误、模式选错、网络参数错配这三类典型事故。

四种知情深度，一个 oneof 装下

请求消息 ImportTapscriptRequest 的第一项是 internal_public_key，32 字节 x-only 序列化内部公钥。脚本承诺部分用 oneof 提供四种知情状态：full_tree 表示完整的脚本树和所有叶子都知道，根哈希可以直接从全树构造；partial_reveal 表示只知道一个脚本叶子，此时必须同时提供完整的包含证明（inclusion proof）才能还原根哈希；root_hash_only 表示只知道脚本树的根哈希，或者别的形式的 Taproot 承诺哈希；full_key 则更极端——只知道最终 tweaked 后的 Taproot 公钥，钱包把传入的密钥直接当作 Taproot 密钥使用，注释说明这适合追踪任意的 Taproot 输出，且并不打算以后通过内部钱包花出去。四种模式对应四种现实：从完整备份恢复、只拿到部分协议文档、只看到一个哈希、只看到一个收款地址。

响应 ImportTapscriptResponse 只有一个字段 p2tr_address：导入成功后算出的那枚 P2TR 地址，可立即用于对账。

三条明写在注释里的限制

其一，只盯不花：proto 注释强调，经此 RPC 导入的 Taproot 密钥当前不能用于出资 PSBT，钱包只跟踪它的余额与 UTXO。其二，只认将来：注释写明该密钥的存入与支出事件只有在导入之后才会被 LND 检测到，用于回溯历史事件的 rescan 机制留待后续支持——想补历史账，得另找索引渠道。其三，别把它当账户：full_key 模式下钱包连内部密钥都不知，自然谈不上花费能力。另外 0.19.0 发布说明记录了一个已修复的历史缺陷：通过 ImportTapscript 加入地址后，LND 此前会出现无法向该地址完成协商关闭的问题，运行旧版本的节点若在用这条接口，升级本身就是核对项。

运维提醒

补一个常见误解：Taproot 地址的可见性不等于可花费性。钱包把脚本哈希与地址关联后能展示余额，但余额只是账面数字——没有对应的密钥与脚本知识，钱照样取不出来。观察钱包适合审计和提醒，真正动钱仍要回到持有完整知识的一方。

导入 watch-only 地址不改变资金控制权归属，脚本路径的私钥与承诺数据仍在你自己的备份体系里；四类知情模式选错会直接导致算出的地址与实际不符，导入前先核对 p2tr_address 是否就是目标地址。涉及资产的脚本与通道资金存在丢失风险，本文描述接口行为，不构成投资建议。