/rest/spenttxouts：用区块撤销数据查一笔区块花掉了哪些输出

一、这个端点从哪来

比特币核心的 REST 接口在 v30 的发布说明”New RPCs”一节里挂了一条新能力：/rest/spenttxouts/区块哈希，说明写得直白——利用区块的撤销数据（undo data）高效获取该区块花掉的全部交易输出。v31.0 源码 src/rest.cpp 里它有独立的处理函数并注册进路由表。这个端点回答的是一个过去只能靠”重放区块对比”回答的问题：某个区块里被当作输入消费掉的那批 prevout，到底是什么。本文按 v31.0 源码核对。

二、撤销数据是怎么把答案存下来的

全节点为了让链尖能后退（重组、invalidateblock、快照回滚），除区块正文外还保存一份 undo 文件：每个区块对应一条记录，记下这个区块里每笔被花费输入的金额、scriptPubKey 等信息——回滚时好把 UTXO 集合原样放回。spenttxouts 做的事本质上就是读出对应区块的 CBlockUndo 并序列化返回，因此它的开销与区块大小成正比，却不需要扫全盘、也不需要 txindex 参与：撤销数据本来就在数据目录的 blocks 子目录里和区块文件并列存放。

请求形态很短：/rest/spenttxouts/哈希.json（也支持二进制或文本扩展名），哈希指向目标区块。响应就是撤销数据的序列化结构，逐条对应区块内被花费的非 coinbase 输入。

三、三种失败形态

源码处理函数按顺序立了三道闸门。其一，哈希不是合法十六进制，返回 400，附带 Invalid hash 提示；其二，哈希在链上查不到对应区块索引，返回 404 加 not found；其三，区块找到了但撤销数据读不出来，返回 404 加 undo not available。第三种值得展开：默认全节点会保留撤销数据，但如果节点开过修剪（prune）或者数据目录不完整，历史较老区块的 undo 可能已不可读，这时端点给的就是这句 not available——它在提示你”本地账本有这个区块，但没有回滚所需的配套”。创世块不携带撤销记录，对高度零的区块同样拿不到内容。

四、什么场景真正用得上

第一类是审计与校验：验证某个浏览器宣称”这些输出在该区块被花掉”，不必信任何第三方，直接向自己的节点按区块拉撤销数据交叉比对。第二类是重组取证：比较两个分叉区块各自花掉了哪些 prevout，撤销数据是最权威的一份记录。第三类是自建索引器：给 UTXO 集合做增量维护的程序，处理新区块时本就需要这批被花输出，与其从交易输入逐个回查 UTXO 集，不如一次读撤销记录连金额和脚本一起拿到。

反过来说，它不回答”某笔交易为什么被拒""某枚币现在还在不在”——那些问题属于 gettxout、gettxspendingprevout 与交易索引的领地。spenttxouts 是面向区块的批量导出，不是面向单枚 UTXO 的查询。

五、开启与边界

REST 服务默认关闭，与其余端点共用同一个开关：启动参数加 -rest 或在配置文件写 rest=1，监听在 RPC 同端口上；它没有鉴权，开给公网等于公开整个账本的只读快照，通常只应绑定回环地址供本机程序使用。返回的撤销数据里含每笔被花输入的 scriptPubKey 与金额，隐私敏感场景注意别把它接到日志或外部采集里。最后，端点依赖的 undo 文件是本地存储实现细节，不同版本、不同修剪策略下的可得性会变，把它写进长期运维脚本前，先在目标部署形态上验证一遍历史区块的读回。

六、与 getblock 系的组合拳

把 spenttxouts 放回核心自带的查询族里看，它的分工立刻清楚：getblock 给区块正文，列的是每笔交易的输入引用；gettxout 查单枚 UTXO 此刻在不在集合里；spenttxouts 则按区块一次给出这个区块花掉的每一枚输出连金额带脚本。三者的信息本可互相推导，差别在成本——逐枚 gettxout 适合抽查，整区块核算用 spenttxouts 一次读完。一个实用的对账练习：任选一个近期区块，用 getblock 抽出全部非 coinbase 输入，再用 spenttxouts 读回同一区块的撤销记录，两边按输出点一一对齐，金额与脚本应当完全一致——不一致说明本地数据或所用浏览器有出入。这个练习同时验证了 undo 管道的完好，比单跑 verifychain 更贴近业务口径。

风险提示：本文仅描述节点接口行为，不构成投资建议。