合并矿池小额支付：何时合并 UTXO，代价是多少

每一笔矿池支付都会以单独的输出到账，而你为它付费的时间是花掉它的那天，而不是收到它的那天。按 POOL BTC 的计算，0.1 BTC 如果是以 200 笔 0.0005 BTC 的支付到账的，在 20 sat/vB 的费率下花掉它需要 272,830 聪，而同样的 0.1 BTC 如果是单个输入，只需 2,190 聪。两者相差 124.6 倍，而根源完全在于你一年前在矿池后台设置的支付门槛。

我们 pool-btc.com 既不是矿池，也不是钱包。下面给出的是算术，在任何运营方那里结果都一样，另附协议常量及其定义出处的链接。下文所有数字都基于我们明确给出的费率，而不是基于预测。发布当天的实际费率单独列出，并附链接和快照时间。

什么是 UTXO，为什么 200 笔 0.0005 BTC 的支付比一个 0.1 BTC 的输入花起来更贵？

UTXO 就是每笔支付产生的独立未花费输出。比特币按交易重量收费，而不是按金额收费。一个 P2WPKH 输入重 68 个虚拟字节，无论里面是 0.0005 BTC 还是 10 BTC。所以同样的钱，200 个输入的重量接近单个输入的 200 倍。

两笔交易的完整计算，使用 Bitcoin Optech 交易大小计算器：

```

花费 200 个输入到 1 个输出： 10.5 + 200 x 68 + 31 = 13,641.5 vB

花费 1 个输入到 1 个输出： 10.5 + 1 x 68 + 31 = 109.5 vB

```

两种情况下余额完全相同。唯一的区别是它被切成了多少块，而这个选择是你在告诉矿池按什么门槛给你付款时做出的。

老实说有一点需要说明：你很少会一次性花掉全部 200 个输入。转出 0.01 BTC 时，钱包会选用其中二十个，而不是两百个。但你终究会把每一个都花掉，一年下来的总手续费是一样的。

以 vByte 计的输入大小如何变成提现手续费？

手续费等于交易的虚拟字节大小乘以你选择的 sat/vB 费率。大小是交易开销，加上所有输入的大小，再加上所有输出的大小。地址格式会让输入重量相差两倍以上，所以它比大多数人以为的更重要。

协议常量来自 Bitcoin Optech 交易大小计算器，核对日期 12.09.2026：

由此立刻得出两点。传统输入要 148 vB，而 bech32 输入只要 68，所以发往 1 开头地址的支付，日后花费的成本大约是两倍。而且公式根本不看金额，这就是为什么"小额支付"和"便宜的支付"是两回事。

```

手续费 = (10.5 + 输入总 vB + 输出总 vB) x 费率（sat/vB）

```

专门说说粉尘。Bitcoin Core 拒绝中继低于某个门槛的输出，该门槛由 3,000 sat/kvB 的 dustRelayFee 推导而来：P2PKH 为 546 聪，P2WPKH 为 294 聪，P2TR 和 P2WSH 为 330 聪，见 Bitcoin Core 代码库中的 policy.cpp。这是中继策略，不是共识规则，所以包含此类输出的区块完全有效。矿池支付几乎不会低到这个程度，这意味着矿工真正的问题是经济上的，而不是形式上的：一个 50,000 聪的输出按策略不算粉尘，但在 100 sat/vB 下花掉它要 6,800 聪，相当于它自身价值的 13.6%。

费率达到多少时，合并才真正划算？

几乎只要未来费率不低于今天就划算。按 POOL BTC 的计算，把 200 个输入合并成一个，今天需要 13,641.5 vB，日后则省下 199 个多余的输入，即 13,532 vB。因此盈亏平衡点只是未来费率比当前高 0.8%。

换算成钱，以这 200 个 0.0005 BTC 的输出为例：

这样省下 202,432 聪，也就是在 0.1 BTC 中省下 0.00202 BTC。整笔资金的百分之二，取决于一次点击。

反过来的情况同样真实。以 60 sat/vB 合并，日后以 5 sat/vB 花费，你今天付出 818,490 聪，日后只省下 67,660 聪：净亏 750,830 聪。合并是在押注日后的手续费比现在高。内存池清闲时，这个赌注几乎没有成本。费率飙升时，这是一个必输的赌注。

13.09.2026 UTC 时间 14:59，mempool.space 对所有优先级都推荐 1 sat/vB，过去 24 小时和过去一周区块中的费率中位数也都是 1 sat/vB（mempool.space，fee-rates）。这就是清闲的内存池：按这个费率合并 200 个输入大约花 13,642 聪。费率几小时内就会变化，所以在点击发送之前，请自己查看当前数值。

你今天选择的支付门槛，如何决定一年后的花费成本？

门槛决定了你一年的产出分成多少块到账。门槛越低，积累的输入越多，日后花费的成本就越高。按 POOL BTC 的计算，100 TH/s 算力、0.0001 BTC 门槛时，一年会以 177 个输出到账，以 20 sat/vB 花掉需要 241,550 聪，占全年产出的 13.6%。

计算基于每太哈每日收益 0.00000048671 BTC，采用 08.09.2026 的网络参数，矿池费率 2%，因此 100 TH/s 每天为 0.000048671 BTC，一年为 0.017765 BTC。难度上升会让每一行的支付次数减少。

在算力和矿池费率完全相同的情况下，第一行和最后一行每年相差 239,360 聪。作为对比：同样 100 TH/s，2% 费率的矿池和 3% 费率的矿池之间一年大约相差 0.00018 BTC，约 18,000 聪。支付门槛让你付出的比费率百分比更多，而人们讨论它的次数却少了一个数量级。

0.01 BTC 这一行看起来很理想，直到你注意到它的代价：一年两次支付，意味着你几乎全部的收入都作为矿池对你的负债留在矿池的账上，而不是作为你持有的币。如何结合自己的算力权衡这一点，详见最低支付门槛；支付应该发往哪里，才能让钱包显示出每个单独的输入，详见挖矿支付钱包。请在计算器中按当前网络参数重新计算你自己的每日产出；一篇一个月前文章里的数字是不够用的。

合并会暴露你的哪些信息？

它会公开证明所有被合并的地址属于同一个所有者。这就是共同输入所有权启发式，而且它在构造上就成立：只有持有全部一百个私钥的人，才能签署包含这一百个输入的交易。合并之前，这种关联只是推测。合并之后，它就成了记录在链上的事实。

对矿工来说，后果很具体。你的矿池向一个或几个地址付款，它们之间的联系只有你自己知道。把一年的支付合并成一笔交易，你就把它们永久焊接成了一个集群。从那以后，只要这个集群中的一个地址进入经过实名认证的交易所账户，链上分析数据库就足以把你的名字，连同你全部的挖矿历史，与之关联起来。

实际中人们的做法：

1. 按用途分组合并，而不是一次全部合并：一组准备转去交易所，另一组留在冷存储中。
2. 绝不在同一笔交易中把矿池支付和在实名交易所买来的币混在一起。这一笔交易就会把你的挖矿与你的身份绑定。
3. 为支付单独准备一个钱包或账户，而不是复用存放购买所得币的那个。
4. 如果钱反正会分批转出，就避免合并成单个输出，因为大额输入产生的找零本身也会形成关联。

你无法完全消除这种暴露：任何花费多个输入的交易都会泄露同样的信号。合并只是一次性、以最大规模做了这件事。作为交换，它节省了手续费。这是在隐私和金钱之间做选择，而不是在对错之间做选择。

为什么交易所和托管钱包没有这个问题？

它们有这个问题。只是你不直接为此付费。交易所余额是数据库里的一行记录，而不是链上的一个输出。交易所自己决定何时合并它的输出，在清闲时段批量处理，并通过固定的提现手续费把成本分摊给所有客户。

行业做法是这样的：据 Spark 的 UTXO 管理指南介绍，托管机构 BitGo 每小时运行一次任务，一旦低于 100,000 聪的输出累积超过 200 个，就将其合并，目标费率约为 1 sat/vB。这是转述 BitGo 做法的二手资料；我们未能在 BitGo 自己的文档中核实，所以请把它当作这种思路的示例，而不是确切的政策。

家庭矿工可以手动复制同样的逻辑。"当我持有超过 200 个输出且费率低于 X 时就合并"这样的规则，不需要任何基础设施，也不需要任何人的许可。唯一的区别是，没有人会替你执行它。

如何计算你自己的盈亏平衡点？

你需要四个数字：有多少个输入、它们是什么格式、今天的费率，以及你预计花费时的费率。然后比较两个数额：现在合并全部输入的成本，与日后多余输入的成本。一个公式就够了，不需要计算器。

```

今天合并的成本 = (10.5 + N x 输入重量 + 31) x 今天的费率

日后花费时的节省 = (N - 1) x 输入重量 x 未来费率

如果节省大于成本，就合并

```

步骤：

1. 打开一个支持币控制的钱包，查看输入列表。桌面端的 Sparrow 和移动端的 BlueWallet 会直接显示；普通钱包只会显示总余额。
2. 数一数你真正打算合并的输入。不是整个余额，只算那些小于一次典型花费的输入。
3. 根据地址格式确定输入重量：bc1q 为 68 vB，bc1p 为 57.5，1 开头地址为 148。
4. 从内存池读取当前费率，而不是用钱包的建议值。"快、中、慢"选择器恰恰隐藏了你需要的那个数字。
5. 把你对未来费率的估计代入公式。如果不想猜，就用今天的费率：在费率相同时，合并 200 个输入已经超过盈亏平衡点 0.8%。
6. 如果算出来的差额上下只有几个百分点，那就什么都不做。内存池还会再次清空。

一个计算示例：50 个 P2WPKH 输入，今天 4 sat/vB，预计日后 25 sat/vB：

```

今天： (10.5 + 50 x 68 + 31) x 4 = 3,441.5 x 4 = 13,766 sat

节省： (50 - 1) x 68 x 25 = 3,332 x 25 = 83,300 sat

净收益：领先 69,534 聪

```

把费率反过来再算一遍，今天 25、日后 4，你就会落后 72,710 聪。同样的操作，同样的 50 个输入，结果正负相反。

合并时常见的错误有哪些？

一共有四个，每一个损失的都是钱，而不仅仅是耐心：在手续费飙升时合并，构建超过标准大小限制的交易，低估对这笔交易做 RBF 加价的成本，以及直接发送到交易所充值地址。每一个都附有你可以核对的数字：

1. 在费率飙升时合并。内存池会定期清空，清闲的夜晚和高峰之间的差距很容易超过一个数量级。按日历安排合并毫无意义；唯一合理的触发条件是低费率。

1. 构建过大的交易。Bitcoin Core 不会中继重于 100,000 vB 的交易，即 400,000 重量单位，也就是 policy.h 中的常量 MAX_STANDARD_TX_WEIGHT。按 POOL BTC 的计算，一笔标准交易最多容纳 1,469 个 P2WPKH 输入：10.5 + 1,469 x 68 + 31 = 99,933.5 vB，而 1,470 个输入达到 100,001.5 vB，将无法广播。对于 148 vB 的传统输入，上限降到大约 675 个。如果你持有更多，就拆分成几笔交易。

1. 低估 RBF。自 Bitcoin Core 28.0 起，full RBF 默认开启，这意味着任何未确认的交易都可以被替换。但替换交易必须支付更高的绝对手续费，并且还要按 1 sat/vB 的 incrementalrelayfee 额外覆盖自身的大小。对于一笔 13,641.5 vB 的合并交易，这意味着每次加价尝试至少要在已付费用之外再多付 13,642 聪。实用规则：大额合并的费率设低一些，留出等待的余地，而不是计划加价两次。

1. 直接发送到交易所充值地址。这看起来像是把问题交给交易所，但它一步就把你的整个集群焊接到一个实名账户上，还剥夺了你选择时机的权利。如果币反正要转去交易所，先合并到你自己的地址，再从那里发出一个已经合并好的输入。

关于找零的提醒。如果合并后留下的找零输出低于粉尘门槛（P2WPKH 为 294 聪），交易将不会被中继。支持币控制的钱包通常会发出警告；不支持的钱包会悄悄把余额并入手续费。

关于合并矿池小额支付的常见问题

怎么知道我积累的小额 UTXO 太多了？

打开一个支持币控制的钱包，数一数小于一次典型花费的输入。如果有几十个以上，而且在 50 sat/vB 下花掉每一个都要超过其价值的 5%，那么这堆输入已经在让你赔钱了。对于 68 vB 的输入，这条 5% 的线大约在 68,000 聪处被越过。

如果我没有花费计划，还应该合并吗？

应该，但不必着急。你会在决定花费的那天支付手续费，而没人能预测那天的费率。在清闲的内存池中合并，就能按今天的价格锁定成本。如果这些币确实多年都不会动，你可以等，但也没有理由无限期推迟。

我能不能改为让矿池少付款几次？

大多数矿池在账户设置中提供支付门槛选项，提高门槛是从根源上解决问题最便宜的方法。更高的门槛产生更少的输出，让日后的合并变得没有必要。代价是你的钱在运营方账上停留的时间更长。各矿池的具体门槛详见最低支付门槛。

Lightning 能避免这个问题吗？

能，因为 Lightning 支付根本不会产生链上输出。你持有的不是一百个 UTXO，而是通道余额，只有开启和关闭通道时才需要链上交易。代价是 Lightning 常见的那些：通道流动性、需要保持在线，以及金额限制。并非所有矿池都支持它。

合并会影响我的税务状况吗？

在大多数司法管辖区，在自己的地址之间转移币不算处置，但规则各不相同，合并手续费在一些国家可以抵扣，在另一些国家则不行。请对照当地法规或咨询税务顾问来确认具体处理方式，而不是依据一篇博客文章。

截至 12.09.2026 仍未证实的内容

1. 未来的手续费率。13.09.2026 的快照（mempool.space 上为 1 sat/vB）仅描述发布那一刻；其他所有计算都基于明确给出的假设费率。
2. BitGo 的合并政策（100,000 sat 门槛、200 个输出触发、1 sat/vB 目标费率）来自 Spark 的转述；未找到 BitGo 的一手资料。
3. 每太哈每日收益 0.00000048671 BTC 反映的是 08.09.2026 的网络参数，未针对 12.09.2026 重新计算。
4. 各个钱包在被要求构建超过 100,000 vB 的交易时如何表现，是提前警告还是显示节点的报错，未经测试。
5. 这里刻意没有列出具体矿池的门槛。其中有几个未经官方文档证实；详情见门槛相关文章。

简要总结

手续费按重量而不是按金额收取，所以小额支付是在花费时变贵，而不是在收到时。按 POOL BTC 的计算，0.1 BTC 如果是以 200 笔 0.0005 BTC 的支付到账的，在 20 sat/vB 下花掉需要 272,830 聪，而如果是单个输入，则只需 2,190 聪。

只要未来费率不低于今天，合并就划算；对于 200 个输入，费率上涨 0.8% 就足够了。请在内存池清闲时进行，每批不超过 1,469 个输入，并且要先确定你愿意公开地把这些地址关联成一个集群。

最便宜的解决办法发生在问题出现之前，就在门槛设置里。按 POOL BTC 的计算，在 100 TH/s 下，把门槛从 0.0001 BTC 改为 0.001 BTC，仅日后花费的手续费一年就能省下大约 217,600 聪。这比同样算力下 2% 费率矿池与 3% 费率矿池之间的差距还要大。请在矿池对比表中比较条件，在计算器中算出你自己的产出，并在支付钱包指南中挑选一个真正能显示输入列表的钱包。