最近用比特币核心 v31.0 查一笔已确认转账到底被哪笔交易花掉时，你可能会发现一个变化：以前要逐块扫描、耗时很不稳定的 gettxspendingprevout，现在快了很多，而且多了一个能直接带回花费交易全文的开关。这背后是 v31.0 引入的一个新索引选项 -txospenderindex。这篇把它的机制、默认值、适用边界和运维代价讲清楚，顺便回答”要不要为它开新索引”这个实际问题。
先说这个 RPC 本身解决什么问题。给定一个前次输出（outpoint，即”交易哈希加输出序号”），gettxspendingprevout 回答两个问题：这笔输出现在还能不能花；如果已经被花掉，是哪笔交易花的。在 v31 之前，它的实现只有两条路：在内存池里找，或者在已确认链上从该输出被创建的高度往后逐块扫描交易。对老地址、老 UTXO 做这种查询，扫描几百上千个区块是常态，节点忙的时候一次查询耗几十秒也不奇怪。
v31.0 加上了第三条路：txospenderindex。按 v31.0 源码 index/txospenderindex.h 的定义，它的默认值是 false，也就是默认不建这个索引；它是一个 LevelDB 形式的”输出到花费交易”映射，节点在验证区块时顺带把每个被花费的 outpoint 和花费它的交易区块位置记下来。开了之后，gettxspendingprevout 在内存池里找不到花费者时，就能直接查这个索引定位已确认的花费交易，不再逐块扫描。v31.0 同时给 RPC 加了两个可选参数：mempool_only 强制只在内存池里找（即使索引存在也不查索引），return_spending_tx 为 true 时直接返回花费交易的完整数据；并且当索引命中已确认的花费时，返回值里会带上所在区块哈希。
要看清默认关着的理由，得看它的成本。第一是磁盘：这是一份随全节点数据目录增长的新索引，规模与历史被花费的输出数量同阶，量级上以 GB 计，且默认关闭意味着你不能指望别人的节点都有它。第二是缓存预算：v31.0 的 node/caches.cpp 里，这个索引的缓存被限制在总 dbcache 的八分之一、且不超过 1024 MiB，也就是说它和区块树、过滤索引等共享同一块内存预算，小内存机器上分给它一份，别处就少一份。第三是回填：索引启用后需要从创世开始补历史映射才能完全可用，新建期间的查询会回退到逐块扫描的老路，这个过程占用一次完整的历史遍历时间，具体快慢取决于机器与 dbcache 配置。
什么场景值得开？如果你运营的是需要高频回答”这笔 UTXO 被谁花了”的后端——比如对账系统、钱包服务的风控模块、链上分析脚本——并且经常查的是链上存在多年的老输出，索引带来的延迟改善是数量级的。反过来，如果只是偶尔手动查一两笔新近的输出，逐块扫描距离当前区块头很近，几秒钟就能出结果，完全没有必要为它多养一份 GB 级索引和一份回填时间。
操作上有三点边界值得记住。其一，它是共识无关的本地索引：开或关不改变你验证的链，不影响与其他节点的兼容性，随时可以在配置里加 -txospenderindex=1 重启启用，删掉则回到默认。其二，mempool_only 参数的存在说明索引和内存池是两条独立通道：想只看”还没被花、只在内存池排队”的场景，用它显式限定，避免索引给出一个已确认答案而你以为还是零确认。其三，索引数据只覆盖你这台节点验证过的链；重组期间它的回滚逻辑由节点内部处理，但如果你在重组窗口里拿 return_spending_tx 做自动化决策，仍应像所有链上查询一样，按确认数政策复核后再行动。
最后是版本事实的边界：本文所有默认值与参数行为都以 Bitcoin Core v31.0 源码为准——索引默认关闭（txospenderindex.h 中 DEFAULT_TXOSPENDERINDEX 为 false）、缓存上限常量与两个新 RPC 参数都在该版本源码中可查。更早版本没有这个索引选项，也没有这两个参数；升级节点后行为请以你所运行版本的发行说明和 RPC 帮助输出为准。
风险提示：本文只讨论节点软件的技术参数与运维取舍，不构成投资建议；自动化脚本依据链上查询做资金决策前，请自行设计确认数与重组容错策略。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。