sendall 命令拆解:把钱包里零散 UTXO 一次归集要付什么代价 图 1
sendall 命令拆解:把钱包里零散 UTXO 一次归集要付什么代价 · 图 1

钱包里的碎币从哪来,为什么要清

钱包地址被反复使用、多次网购零钱找零、接收过小额打赏,日积月累就会攒下一堆小额输出。每一笔将来花掉它们的操作都要为它们付签名费,碎 UTXO 越多,交易的字节越大、费用越高,某些场景下甚至会因为个别输出”值不回其费”而卡住选择逻辑。归集,就是把这堆零散输出合并成一两笔大额输出的维护动作。Bitcoin Core 提供了一个专门的实验性命令 sendall:把钱包里所有(或指定)已确认余额和未确认找零一次花干净,转给一个或多个目标地址。注意它的定位:官方文档标注该调用为实验性,未来版本可能调整参数行为,操作前应以你所用版本的帮助文本为准。

sendall 命令拆解:把钱包里零散 UTXO 一次归集要付什么代价 图 2
sendall 命令拆解:把钱包里零散 UTXO 一次归集要付什么代价 · 图 2

命令的三个关键旋钮

第一个是费率:sendall 支持直接用 fee_rate 指定每虚拟字节聪数,不指定则回落到钱包的自动估算。归集往往不着急,挑费率低谷时段做,同样的合并成本能省不少。第二个是”挑剩”逻辑:当钱包里碎到了一定程度,部分输出的价值可能覆盖不了自己的输入成本,文档建议这种情况下使用 send_max 选项,让命令跳过这些”负价值”输入、最大化净到账金额——被跳过的粉尘会留在钱包里继续占位。第三个是未确认与锁定:命令默认不花费未确认的进端输出,也不动被锁定的 UTXO,同时会遵守钱包的 avoid_reuse 标志,这意味着开了地址复用防护的钱包可能留下”故意不花”的旧地址余额。

归集的代价:手续费之外的两件事

一是隐私代价。把几百个输出并进一个地址,等于在链上向所有观察者确认”这些输出同属一人”,这类合并是聚类分析最乐于捕捉的交易形态。归集因此是一个用隐私换运维效率的动作,做之前想清楚钱包的地址使用历史是否敏感。二是自托管卫生:如果归集目标是交易所充值地址,那这一步实际上是在把自托管余额搬回托管,属于策略选择而非技术必需;纯钱包内整理则应转到自己的新接收地址或下一代的钱包描述符之下,并且先小额验证路径再全额搬运。

一次稳妥的归集流程

先摸清家底:listunspentgetreceivedbyaddress 统计碎输出的数量与金额分布,判断值不值得动手——碎到什么程度才划算,取决于当前费率与你未来预期的使用频率。然后在测试环境或小额状态下完整走一遍命令,确认输出组合、找零逻辑与费用符合预期;主网上执行时优先低费率窗口,勾选 send_max 处理粉尘,执行后核对新交易里的输入清单是否确实覆盖了目标集合。最后把这次归集交易编号记进你的钱包维护日志,方便未来对账与恢复演练。

归集频率与钱包形态的关系

需要归集的频率本身就是钱包使用方式的体检表。如果你的钱包每月都攒出新粉尘,说明接收习惯在制造成本:常见原因是同一个地址反复收小额、或者把钱包当零钱罐频繁进出。对策不在归集命令本身,而在上游——公开收款地址用一次一址、把高频小额收入导流到一个专用接收钱包再定期归集、或者开启批量接收工具让收款方直接构造组合交易。反过来,长期冷钱包几乎不需要主动归集:只要不动用,碎 UTXO 不产生任何费用,只在动用那一次统一处理,而且往往应该先查当时的费率环境再决定拆成几笔。把归集看作”钱包形态的反馈信号”而不是一条孤立的命令,能省掉大量无效合并:每一次合并都在链上多说了一句话,说多了,聚类画像自然更清晰。

风险提示:实验性命令的行为可能随版本变化,操作前请核对所用版本的官方文档;本文不构成投资建议。