getdescriptoractivity怎么用？

Bitcoin Core 31 的 getdescriptoractivity 可按描述符和指定区块核对收款、花费及可选内存池事件。本文给出区块预筛、范围描述符和事件验收的完整流程。

getdescriptoractivity 适合回答一个很具体的问题：给定一组输出描述符和一组主链区块，哪些交易向这些脚本付款，哪些交易又花费了它们？它不是自动遍历全链的钱包恢复按钮；输入范围决定了能看到什么。

先做“区块候选集”，再取活动

getdescriptoractivity接收主链blockhash列表、描述符scanobjects和可选include_mempool参数。调用前先明确起止高度和目标描述符。若区间很大，可用 scanblocks 一类过滤能力找出可能相关的区块，再把候选主链区块交给 getdescriptoractivity。这样把“寻找可能命中”与“提取具体事件”分成两步，既便于复核，也避免误以为接口会替你扫描全部历史。

描述符 + 高度范围
       ↓
scanblocks 预筛可能相关区块
       ↓
确认区块仍在主链
       ↓
getdescriptoractivity 提取收款/花费事件
       ↓
按 txid、vout、blockhash 对账

区块集合必须记录高度和哈希。只保存高度会在短重组后失去上下文；只保存哈希而不记扫描边界，也无法证明有没有漏掉前后区间。

描述符范围是最容易漏账的地方

官方文档建议把该RPC与scanblocks返回的relevant_blocks配合使用，调用可能持续数分钟。范围描述符需要覆盖真实派生索引。范围太窄会漏掉已使用地址，范围无限放大又会增加扫描成本和误操作风险。先用 getdescriptorinfo 校验 checksum、是否为范围描述符及类型，再按钱包备份、地址生成记录和 gap 规则设定最小充分范围。

输入项	验收问题	失败后动作
descriptor	checksum和网络是否正确	停止，修正来源
range	是否覆盖已知派生游标	对照备份扩展
blockhashes	是否属于目标主链区间	重建候选集
include_mempool	是否明确需要未确认事件	与确认记录分栏

不要在普通日志中复制含私钥的描述符。活动核对只需要公开脚本材料时，应使用脱敏、无私钥版本，并限制输出记录的访问权限。

怎样读收款与花费事件

activity数组区分spend与receive；确认事件包含blockhash和height，未确认事件省略这两个字段。事件要落成可对账的账本，而不是只显示“收到/发出”。RPC 的 amount 是以BTC计的numeric；每行应先保存这个原始值及其单位，再用确定的十进制规则转换为聪整数落账，同时保存 descriptor 指纹、txid、输入或输出位置、blockhash、高度、确认状态和发现来源。收款事件说明交易创建了匹配输出；花费事件说明后续输入消费了匹配的既有输出，两者应通过 outpoint 关联。

一个输出先在内存池出现、随后进入区块，可能被接口观察两次。数据层用 txid+vout 作为业务对象，再给它附上 mempool、confirmed 或 conflicted 状态，不能把两次观察累加成两笔收入。

include_mempool是一条独立证据轨

spend事件给出spend_txid、spend_vin和prevout信息，receive事件给出txid、vout和output_spk。选择包含内存池后，结果会受本节点当前内存池影响。RBF替换、交易过期、节点策略和重启都可能让未确认事件消失。页面应把未确认区域与指定区块的已确认区域视觉分开，并注明观测时刻。

建议验收顺序：