AUG56 bitcoin body 251: LND debug package 三连

向闪电开发者求助的时候，最常被索要的材料不是截图，而是一个加密调试包。LND 为此准备了三个命令：getdebuginfo 负责采集单份诊断数据，encryptdebugpackage 把一批诊断数据采集后加密成文件，decryptdebugpackage 则让持有私钥的一方把包还原。看懂这三件套的边界，比会敲命令本身更重要。

getdebuginfo：单命令的原始读数

lncli getdebuginfo 返回与当前守护进程相关的调试信息，直接打印 JSON。它是一份快照，包含进程与节点运行状态的开发级细节，适合在故障发生的当口留档。开发者通常不满足于这一条命令，于是有了打包器。

encryptdebugpackage：默认装什么、可加装什么

lncli encryptdebugpackage 的第一个参数是接收方的十六进制公钥，由向你收材料的开发者提供。命令会采集以下三项的默认输出：lncli getinfo、lncli getdebuginfo、lncli getnetworkinfo。在此之外有三个可选开关：--peers 会额外加入 listpeers 的结果；--onchain 会加入 listunspent 与 listchaintxns，即链上余额与交易列表；--channels 会加入 listchannels、pendingchannels、closedchannels 三份通道台账。开发者会按问题类型指定要哪几个开关。输出默认打到标准输出，也可以用 --output_file 直接落盘，官方帮助里的写法是把重定向与公钥参数拼在一起。

因为文件在离开你的机器之前就已经加密，官方文档明确它可以通过不安全信道传输，甚至直接附在 GitHub issue 上。这句话的含金量在于：密文里含有你的通道与对端信息，但只有指定公钥对应的私钥能解开。反过来说，把加密包发给谁，就等于把这份快照的全部内容透露给了谁，开关开得越多，暴露面越大。--channels 会带出通道对手方与余额结构，这在隐私上并不轻。

decryptdebugpackage：私钥是唯一钥匙

解密端的写法是 lncli decryptdebugpackage 加十六进制私钥参数，输入从标准输入读，也可以用 --input_file 指定文件。包体本身是一个 JSON，字段里能看到临时公钥与加密载荷两项：加密过程为每个包生成一次性密钥对，接收方用自己的私钥协商出会话密钥来解密。也就是说密文里没有“找回”机制——公钥发错了人、私钥丢了，这份材料就永久不可读。

运维纪律三条

第一，加密包的采集发生在执行时刻，通道状态随后就会变化，它不是可回放的录像，问题复现后再补采可能已经看不到现场。第二，--onchain 与 --channels 打开时等于把财务侧台账交给远端，求助前先想清楚对方是谁；面向公共仓库的 issue 交流可以要求对方只收默认三项。第三，私钥只应存在于接收方，调试链条上任何一环把私钥贴进聊天窗口，加密的意义就归零。

采集时刻与传输边界

加密包的内容是执行瞬间的快照：通道状态随后即变，复现故障时再补采可能已经看不到现场，值班排障的第一动作应该是先打包留档再动手修复。三个可选开关对应三档暴露面：--peers 带出连接对端，--onchain 带出链上余额与交易列表，--channels 带出通道对手方与余额结构，越往后越接近财务报表。因为文件在离开机器前已按接收方公钥加密，官方帮助明确它可以通过不安全信道传输、甚至直接附在 GitHub issue 上；反过来说，把包发给谁就等于把这份快照透露给谁，面向公共仓库交流时可以要求只收默认三项。

三件套之外的两个习惯

一是留一份明文自档：给自己也采一次 getdebuginfo，密文发给开发者的同时，明文快照留在本地，事后复盘不必求人回传。二是把打包动作写进值班手册：谁有权采集、允许开到哪个开关、发给谁的公钥、留档多久，这四个问题在凌晨三点的故障现场靠临时决定必然出错。命令本身没有权限概念，加密只解决传输泄露，不解决你主动把财务快照交出去的那一步。

风险提示：调试包包含节点运行状态、通道结构与链上交易信息，可能涉及资金隐私；本文是机制说明，不构成投资建议。