Consolidating small mining pool payouts: when to merge UTXOs and what it costs

Every pool payout arrives as a separate output, and you pay for it on the day you spend it, not the day you receive it. By POOL BTC's calculation, spending 0.1 BTC that arrived as 200 payouts of 0.0005 BTC costs 272,830 satoshis at 20 sat/vB, while the same 0.1 BTC held as a single input costs 2,190 satoshis. That is a factor of 124.6, and it traces back entirely to the payout threshold you set in your pool dashboard a year ago.

We at pool-btc.com are not a pool and not a wallet. What follows is the arithmetic, which works identically at any operator, plus the protocol constants with links to where they are defined. Every figure below runs from a fee rate we name explicitly rather than from a forecast. The actual rate on the publication date is given separately, with a link and a snapshot time.

What is a UTXO, and why do 200 payouts of 0.0005 BTC cost more to spend than one input of 0.1 BTC?

A UTXO is the separate unspent output that each payout creates. Bitcoin charges fees by transaction weight, not by amount. One P2WPKH input weighs 68 virtual bytes whether it holds 0.0005 BTC or 10 BTC. So 200 inputs weigh close to 200 times what a single input weighs, for the same money.

Both transactions in full, using the Bitcoin Optech size calculator:

```

spending 200 inputs into 1 output: 10.5 + 200 x 68 + 31 = 13,641.5 vB

spending 1 input into 1 output: 10.5 + 1 x 68 + 31 = 109.5 vB

```

The balance is identical in both cases. The only difference is how many pieces it is cut into, and you made that choice when you told the pool what threshold to pay you at.

One honest caveat: you rarely spend all 200 inputs at once. Send 0.01 BTC and the wallet picks up twenty of them, not two hundred. But you will spend every one of them eventually, and the total fee across a year comes out the same.

How does input size in vBytes turn into a withdrawal fee?

The fee equals the transaction size in virtual bytes multiplied by the sat/vB rate you choose. Size is the transaction overhead plus the sizes of every input plus the sizes of every output. Address format changes input weight by more than a factor of two, so it matters more than most people assume.

Protocol constants from the Bitcoin Optech size calculator, checked 12.09.2026:

Two things follow immediately. A legacy input costs 148 vB against 68 for bech32, so payouts sent to a 1-address will cost roughly twice as much to spend later. And the formula never looks at the amount, which is why "small payout" and "cheap payout" are different things.

```

fee = (10.5 + total input vB + total output vB) x rate in sat/vB

```

On dust specifically. Bitcoin Core refuses to relay outputs below a threshold derived from dustRelayFee of 3,000 sat/kvB: 546 satoshis for P2PKH, 294 for P2WPKH, 330 for P2TR and P2WSH, per policy.cpp in the Bitcoin Core repository. That is a relay policy, not consensus, so a block containing such outputs is perfectly valid. Pool payouts almost never fall that low, which means the miner's real problem is economic rather than formal: an output of 50,000 satoshis is not dust by policy, but at 100 sat/vB it costs 6,800 satoshis to spend, 13.6% of itself.

At what fee rate does consolidation actually pay for itself?

Almost any time the future rate is no lower than today's. By POOL BTC's calculation, merging 200 inputs into one costs 13,641.5 vB today and saves 199 redundant inputs later, which is 13,532 vB. The break-even point therefore sits at a future rate just 0.8% above the current one.

The same thing in money, for those 200 outputs of 0.0005 BTC:

That is 202,432 satoshis saved, or 0.00202 BTC on a 0.1 BTC stack. Two percent of the whole stack, decided by one click.

The reverse case is just as real. Consolidate at 60 sat/vB and spend later at 5, and you pay 818,490 satoshis today to save 67,660 later: a straight loss of 750,830 satoshis. Consolidation is a bet that fees will be higher later than they are now. In a quiet mempool the bet is nearly free. During a spike it is a losing one.

At 14:59 UTC on 13.09.2026, mempool.space recommended 1 sat/vB at every priority level, and the median fee rate in blocks over the previous 24 hours and the previous week was also 1 sat/vB (mempool.space, fee-rates). That is what a quiet mempool looks like: consolidating 200 inputs at that rate costs about 13,642 satoshis. Rates move within hours, so check the current number yourself before you press send.

How does the payout threshold you pick today set your spending cost a year from now?

The threshold decides how many pieces your annual output arrives in. The lower it is, the more inputs pile up and the more a later spend costs. By POOL BTC's calculation, at 100 TH/s with a 0.0001 BTC threshold a year arrives as 177 outputs, and spending it at 20 sat/vB costs 241,550 satoshis, 13.6% of the year's output.

The calculation runs from a daily yield of 0.00000048671 BTC per terahash at network parameters of 08.09.2026 with a 2% pool fee, so 0.000048671 BTC per day at 100 TH/s and 0.017765 BTC over a year. Rising difficulty pushes every row down in payout count.

The gap between the first and last row is 239,360 satoshis a year at identical hashrate and identical pool fee. For scale: the difference between a 2% pool and a 3% pool at the same 100 TH/s is roughly 0.00018 BTC a year, about 18,000 satoshis. The payout threshold costs you more than the fee percentage does, and it gets discussed an order of magnitude less often.

The 0.01 BTC row looks ideal until you notice its price: two payouts a year means nearly all of your income sits on the pool's balance sheet as a debt to you rather than as coins you hold. How to weigh that against your own hashrate is worked through in minimum payout thresholds, and where to point payouts so your wallet will even show you the individual inputs is covered in wallets for mining payouts. Recalculate your own daily output at current network parameters in the calculator; a figure from a month-old article will not do.

What does consolidation reveal about you?

It proves publicly that every merged address belongs to one owner. This is the common-input-ownership heuristic, and it holds by construction: only someone holding all hundred keys can sign a transaction with all hundred inputs. Before consolidation that link was an assumption. Afterwards it is a fact recorded in the chain.

For a miner the consequence is specific. Your pool pays to one address or a handful, and the connection between them is visible only to you. Merge a year of payouts into one transaction and you weld them into a single cluster forever. From then on, one address from that cluster reaching a verified exchange account is enough to attach your name, and your whole mining history, to it inside a chain analytics database.

What people do about it in practice:

1. Consolidate in groups by purpose rather than all at once: one group destined for an exchange, another that stays in cold storage.
2. Never mix pool payouts with coins bought on a verified exchange in the same transaction. That one transaction ties your mining to your ID.
3. Keep a separate wallet or account for payouts instead of reusing the one holding purchases.
4. Avoid merging into a single output if the money will leave in pieces anyway, since change from a large input creates links of its own.

You cannot remove the disclosure entirely: any transaction spending several inputs leaks the same signal. Consolidation just does it all at once and at maximum scale. In exchange it saves fees. The choice is between privacy and money, not between a right and a wrong answer.

Why do exchanges and custodial wallets not have this problem?

They do have it. You just do not pay for it directly. An exchange balance is a row in a database, not an output in the chain. The exchange decides when to merge its own outputs, batches the work during quiet periods, and spreads the cost across all customers through a flat withdrawal fee.

Industrial practice looks like this: the custodian BitGo, as described in Spark's UTXO management guide, runs an hourly job that consolidates outputs under 100,000 satoshis once more than 200 of them accumulate, targeting roughly 1 sat/vB. That is a secondary source summarising BitGo's practice; we could not confirm it against BitGo's own documentation, so treat it as an illustration of the approach rather than an exact policy.

A home miner can reproduce the same logic by hand. A rule of "merge when I hold more than 200 outputs and the rate is below X" needs no infrastructure and nobody's permission. The only difference is that nobody will run it for you.

How do you calculate your own break-even point?

You need four numbers: how many inputs, what format they are, today's rate, and the rate you expect to spend at. Then you compare two sums, the cost of merging everything now against the cost of the redundant inputs later. One formula covers it and no calculator is required.

```

cost to consolidate today = (10.5 + N x input weight + 31) x rate today

saving at future spend = (N - 1) x input weight x future rate

consolidate if the saving exceeds the cost

```

The steps:

1. Open a wallet with coin control and look at the input list. Sparrow on desktop and BlueWallet on mobile show it directly; an ordinary wallet will only show you a total balance.
2. Count the inputs you actually intend to merge. Not the whole balance, only the ones smaller than a typical single spend.
3. Take the input weight from the address format: 68 vB for bc1q, 57.5 for bc1p, 148 for a 1-address.
4. Read the current rate from the mempool rather than the wallet's suggestion. The "fast, normal, slow" picker hides precisely the number you need.
5. Put your estimate of the future rate into the formula. If you would rather not guess, use today's rate: at equal rates, merging 200 inputs already clears break-even by 0.8%.
6. If the difference comes out to a few percent either way, do nothing. The mempool will empty again.

A worked example with 50 P2WPKH inputs, 4 sat/vB today and an expected 25 sat/vB later:

```

today: (10.5 + 50 x 68 + 31) x 4 = 3,441.5 x 4 = 13,766 sat

saving: (50 - 1) x 68 x 25 = 3,332 x 25 = 83,300 sat

net: 69,534 satoshis ahead

```

Run the same numbers with the rates reversed, 25 today and 4 later, and you are 72,710 satoshis behind. Same operation, same 50 inputs, opposite sign.

What are the common mistakes when consolidating?

There are four, and each costs money rather than just patience: consolidating during a fee spike, building a transaction above the standard size limit, underestimating what an RBF bump on that transaction costs, and sending straight to an exchange deposit address. Each one with a number you can check:

1. Consolidating during a spike. The mempool clears regularly, and the gap between a quiet night and a peak easily exceeds an order of magnitude. Scheduling consolidation by calendar makes no sense; the only sensible trigger is a low rate.

1. Building too large a transaction. Bitcoin Core will not relay transactions heavier than 100,000 vB, that is 400,000 weight units, the MAX_STANDARD_TX_WEIGHT constant in policy.h. By POOL BTC's calculation, one standard transaction fits at most 1,469 P2WPKH inputs: 10.5 + 1,469 x 68 + 31 = 99,933.5 vB, whereas 1,470 inputs come to 100,001.5 vB and will not propagate. For legacy inputs at 148 vB the ceiling drops to about 675. Split into several transactions if you hold more.

1. Underestimating RBF. Since Bitcoin Core 28.0 full RBF has been on by default, which means any unconfirmed transaction can be replaced. But a replacement must pay a higher absolute fee and additionally cover its own size at the incrementalrelayfee of 1 sat/vB. For a 13,641.5 vB consolidation that means at least 13,642 satoshis extra per bump attempt, on top of what you already paid. The practical rule: set the rate on a large consolidation low with room to wait, rather than planning to raise it twice.

1. Sending straight to an exchange deposit address. It looks like a way to hand the problem to the exchange, but it welds your whole cluster to a verified account in one move and takes away your choice of timing. If the coins are going to an exchange anyway, consolidate to your own address first and send a single finished input from there.

A note on change. If consolidation leaves a change output below the dust threshold of 294 satoshis for P2WPKH, the transaction will not relay. Wallets with coin control usually warn you; wallets without it quietly roll the remainder into the fee.

Common questions about consolidating small pool payouts

How do I know I have accumulated too many small UTXOs?

Open a wallet with coin control and count the inputs smaller than a typical single spend. If there are more than a few dozen and each would cost over 5% of its value to spend at 50 sat/vB, the pile is already costing you money. For a 68 vB input that 5% line is crossed at around 68,000 satoshis.

Should I consolidate if I have no plans to spend?

Yes, but there is no hurry. You will pay the fee the day you decide to spend, and nobody can predict the rate on that day. Consolidating in a quiet mempool locks the cost in at today's price. If the coins genuinely will not move for years you can wait, though there is no reason to postpone indefinitely either.

Can I ask the pool to pay me less often instead?

Most pools expose the payout threshold in account settings, and raising it is the cheapest way to fix the problem at the root. A higher threshold creates fewer outputs and makes future consolidation unnecessary. The trade-off is that your money sits on the operator's balance sheet for longer. Specific thresholds by pool are covered in minimum payout thresholds.

Does Lightning avoid the problem?

Yes, because Lightning payouts create no on-chain outputs at all. Instead of a hundred UTXOs you hold a channel balance, and an on-chain transaction is only needed to open and close it. The price is the usual Lightning one: channel liquidity, being online, and limits on amounts. Not every pool supports it.

Does consolidation affect my tax position?

Moving coins between your own addresses is not a disposal in most jurisdictions, but the rules differ, and consolidation fees are deductible in some countries and not in others. Check the specific treatment against your local regulation or a tax adviser rather than against a blog post.

Still unconfirmed as of 12.09.2026

1. The future fee rate. The 13.09.2026 snapshot (1 sat/vB on mempool.space) describes only the moment of publication; every other calculation runs from explicitly named hypothetical rates.
2. BitGo's consolidation policy (100,000 sat threshold, 200-output trigger, 1 sat/vB target) comes from Spark's summary; no primary BitGo source was found.
3. The daily yield of 0.00000048671 BTC per terahash reflects network parameters of 08.09.2026 and was not recalculated for 12.09.2026.
4. How individual wallets behave when asked to build a transaction above 100,000 vB, whether they warn in advance or surface the node's error, was not tested.
5. Thresholds at named pools are deliberately absent here. Several of them are not confirmed by official documentation; the detail is in the thresholds article.

The short version

Fees are charged by weight, not by amount, so small payouts get expensive when you spend them rather than when you receive them. By POOL BTC's calculation, spending 0.1 BTC that arrived as 200 payouts of 0.0005 BTC costs 272,830 satoshis at 20 sat/vB against 2,190 satoshis if it were a single input.

Consolidation pays off as soon as the future rate is no lower than today's; for 200 inputs a 0.8% rise is enough. Do it in a quiet mempool, in batches of no more than 1,469 inputs, and only after deciding you are willing to publicly link those addresses into one cluster.

The cheapest fix happens before the problem exists, in the threshold setting. By POOL BTC's calculation, at 100 TH/s a 0.001 BTC threshold instead of 0.0001 BTC saves roughly 217,600 satoshis a year in future spending fees alone. That is more than the gap between a 2% pool and a 3% pool at the same hashrate. Compare conditions in the pool table, work out your own output in the calculator, and pick a wallet that will actually show you the input list in the payout wallet guide.