AUG56 bitcoin body 259: listchaintxns 台账四参数

闪电节点既要记通道的账，也要记链上的账。lncli listchaintxns 是后者的主命令：列出钱包地址参与过的链上交易。命令帮助里有一行容易被跳过的话——默认行为会一直取到链尖、包含未确认交易。这行字加上四个参数，决定了这台节点的财务台账能不能翻对。

命令的另一半：钱包侧的 GetTransactions

协议定义里这条命令对应钱包服务的 GetTransactions 接口，返回与该钱包相关的全部已知交易：付给本钱包地址的、以及花掉了本钱包持有输出的，双向都算。所以它既是收入台账也是支出台账，对账脚本拿它做底账时，要按金额正负或类别字段把两个方向分开统计，别把清扫支出混进充值流水。

高度区间：默认到链尖，含未确认

start_height 从哪个高度开始列，含该高度；end_height 到哪结束，也含该高度，默认值为负一，含义是直到链尖，未确认交易包括在内。校验规则写得具体：两个参数同时给出且 end_height 不为负一时，起始高度必须小于等于结束高度，倒着写直接报错；start_height 为负同样报错。要查“最近这段有没有到账款”，把 end_height 留默认最稳；要做固定区间审计，就别偷懒用负一，否则每次重跑结果都可能因新区块而不同，对账基线漂移。

分页两参数：偏移量与上限

index_offset 是分页游标，按交易序号往后挪；max_transactions 是单次返回上限，默认值为零，零的含义不是返回零条，而是不限数量全量返回。两种用法都有坑：全量返回在老节点上可能一次拖出成千上万条记录，内存和终端都吃得住才敢这么用；用游标分页时，新确认的交易会改变列表的位置序号，靠偏移量翻页的脚本在高活跃期容易重复计数或漏条——对账以交易哈希为键去重，比信任偏移量的稳定性要可靠得多。

一次典型的月结对账姿势

先记下调用时刻的链尖高度（getinfo 或后端节点读一次都行），把 end_height 钉在这个值上，start_height 设成上个账期的界外区块，然后用 index_offset 与 max_transactions 小步翻页拉全，落盘后按 txid 去重、按高度排序。整个过程 end_height 不再变，账期就是一个闭合窗口，脚本重跑幂等。需要单独盯未确认到账时，再来一次默认调用，把确认数为零的记录摘出来单独跟踪。台账命令不难，难的是每次都给它一个定义明确的查询区间——参数留白，账目就跟着留白。

台账之外的姊妹字段

列表里的每条记录自带确认数、时间戳与金额，未确认交易的确认数为零或为负，这是区分在途与落袋最快的判据，不必另发查询。另一个易被忽略的点：这条命令的账本以地址归属为视角，lnd 的链上钱包只管自己派生地址收付的钱，通道内余额的变动不会出现在这里——通道关闭清扫回来的交易在确认前会先以未确认形态入列，随后才转为普通记录，清扫动作的完整轨迹要配合清扫台账命令一起看才闭环。把链上流水、通道余额、清扫队列三份名单各自建页，月末交叉勾稽，是闪电节点财务对账最扎实也最朴素的形态。

与图谱命令的一次交叉核对

链上台账的另一重用法是解释通道行为：pendingchannels 卡在某段时，回到 listchaintxns 找对应出资交易的确认进度，两边高度一致才算正常排队；如果台账显示交易早已确认而通道仍悬置，问题在 lnd 的后端监听层而不是链本身。清扫交易迟迟不确认时同理——先确认它出现在台账里、拿到交易哈希，再去区块浏览器看费率和内存池状态，责任链条一段一段切开，每一步都有命令输出做证据，而不是在猜是哪一层掉链子。

风险提示：链上交易列表反映的是节点钱包视角，私有托管或其他地址的收支不在此列，对账口径务必先划清；本文为机制说明，不构成投资建议。