sendmany 不是批量魔法：多收款人一笔转账的账怎么算

sendmany 到底做了什么

sendmany 的语义很朴素：从一个钱包出发，一次指定多个收款地址和各自金额，钱包把这些输出装进同一笔交易，选一些自己控制的 UTXO 作输入，算一次手续费，签一次名，广播一次。它和逐笔发送的差别不在”能不能付”，而在”账怎么记”：一笔交易的固定开销（版本、锁时间、输入指针、见证结构等）只付一次，多个收款人是同一份公共开销上的多行输出。因此收款人多、单笔金额小的场景里，批量方式几乎总更省；只有一两个收款人时，差距就很小了。

字节的账本：什么时候真的划算

比特币交易的体积由输入、输出和见证数据共同决定，手续费按虚拟字节的费率收取。逐笔发送时，每笔都要带一套交易头和一套自己的找零输出；批量一笔时这些公共部分被摊薄。但”摊薄”有个前提：输入集合要能高效合并。如果钱包的 UTXO 本来就碎，逐笔发和批量发选中的输入总量差不多，批量省下的大约只是几个输出条目和几十字节的头部；如果钱包里有大额的、正好的输入，批量一次挑中，比逐笔分别把大输入切碎要省得多，还能少制造一堆找零 UTXO。

隐私这条线要讲清楚

批量交易把所有收款人摆在同一条链上记录里：谁和谁恰好同批，对链上分析是公开事实。对个人发薪、给一堆供应商打款的场景这可能无所谓；对不想暴露关联关系的场景，逐笔发送甚至配合不同的钱包与时间窗，结构上更难被一次看全。另一面是找零：一笔多输出交易只有一个找零输出（或少数几个），比逐笔各带找零更整洁，这本身对地址簿的整洁是好事，但也让”哪一笔出自同一个钱包”更容易被归组。别期待批量带来隐私——它是费率的优化，不是混币。

参数历史：0.19 之后少了什么

老教程里的 sendmany 调用常带一个 minconf 参数（要求至少几个确认才能花对应的币）。Bitcoin Core 0.19 的发行说明明确：sendmany 不再有这个参数；较新版本的源码里它虽然还出现在参数表里，但帮助文本注明只是”被忽略的占位值”，仅为兼容旧调用保留。现在的费率与确认目标改由 conf_target、fee_rate、replaceable 一类选项控制，语义比原来”全局固定几个确认”更贴近需要。照着旧文章敲命令却发现行为对不上，多半是这个原因。

实操清单

1. 先核对每个地址的格式与网络前缀，批量交易里一个地址错就是全部人陪你排查。
2. 确认费率策略：钱包自动估算还是手动设定，与前面聊过的 settxfee 有关。
3. 大额批量前先用同一流程做一笔两三个收款人的小额演练。
4. 发送即不可逆：交易一旦进入网络，撤回手段只有费率足够低时的 RBF 一类机制，而对方一旦确认花费就彻底结束，事前对账比对事后补救可靠。

批量工具优化的是手续费结构，不是隐私结构。本文不构成投资建议。

一个被低估的运维收益：状态收敛

逐笔发送时，你要跟踪 N 个交易哈希、N 条确认进度、N 次可能的加急；批量发送把状态收敛成一个哈希、一条时间线。对账系统、客服话术、审计凭证都因此简单得多。但硬币的另一面是故障半径：一笔失败就是全员未到账，一次加急就是全员一起动。如果你的组织没有能力在”全量失败”时快速沟通，那把批量拆成几组小批量，是介于两者之间更稳的形态。规模不大、收款人不多、又都在同一个组织内部消化的场景，甚至可以考虑”先建 PSBT、内部会签、再广播”的批处理：walletcreatefundedpsbt 生成半成品，相关负责人先核对输出表，确认后走签名广播。多花一轮沟通，换一次不可逆操作的确定性，通常是划算的。