Batching Bitcoin Transactions: How Multi-Output Payments Cut Fees and Conserve Block Space

Batching Bitcoin transactions is the practice of combining multiple payments into a single on-chain transaction with many outputs. Instead of creating a separate transaction for every recipient, a single input funds many outputs, amortizing the fixed overhead of transaction headers, version fields, and input signatures across all payments. The result is a direct reduction in per-payment fees, often reaching 75% savings when batching just ten payments, with no degradation in confirmation speed.

This technique is not merely a convenience for exchanges. Any entity or individual that needs to send Bitcoin to multiple parties within a short time window can use batching to reduce their on-chain footprint and lower costs. The mechanics are straightforward, but the operational patterns have evolved significantly since the technique first gained attention during the 2017 fee spike.

Why Batching Saves Fees: The vByte Mathematics

Bitcoin fees are not calculated by the monetary value of a transaction but by its data size, measured in virtual bytes (vBytes). Every transaction carries fixed overhead: the version number, input count, output count, locktime, and the witness marker and flag for SegWit transactions. Each input adds a substantial cost because it must include the previous transaction ID, output index, sequence number, and a cryptographic signature proving ownership.

A typical single-payment SegWit transaction with one input and two outputs (payment plus change) consumes approximately 140-150 vBytes. If you were to send ten individual payments, you would repeat the fixed overhead ten times, producing roughly 1,400-1,500 vBytes total. By batching Bitcoin transactions into a single transaction with one input and eleven outputs (ten payments plus one change output), the total size drops to approximately 350-400 vBytes. The fixed overhead is paid once, and the only additional cost per recipient is the output itself, which is typically 30-35 vBytes for a native SegWit (bech32) address.

The savings become even more pronounced under SegWit because witness data (signatures) is discounted in the weight calculation. A batched transaction with a single input minimizes the input-side witness data, while the output-side data remains small. This is why modern batching recommendations emphasize UTXO consolidation first: maintaining a small number of large inputs allows a batched transaction to run on a single input, maximizing the efficiency ratio.

From Simple Batching to Additive RBF Batching

The simplest form of batching is static: you collect payment requests over a time window, construct one transaction with many outputs, and broadcast it. Exchanges and mining pools have used this method for years, often waiting for 100 or 200 outputs to accumulate before publishing a batch.

Static batching has a operational limitation. Once broadcast, the transaction occupies a slot in the mempool. If fee rates spike before confirmation, the batch may sit unconfirmed for hours or days. Worse, if the batch contains many outputs, any recipient who spends their unconfirmed output creates a child transaction. If enough recipients do this, the transaction group can hit Bitcoin Core's descendant limit (25 unconfirmed descendants per transaction group as of version 0.20 and later), preventing the sender from using Child-Pays-For-Parent (CPFP) or Replace-By-Fee (RBF) to bump the fee. This is known as transaction pinning.

Additive batching solves this by treating the batch as a living transaction in the mempool. Rather than waiting for a large queue to form before broadcasting, the operator publishes an initial batch with a low fee rate and then uses BIP-125 (RBF) to replace it with a new version that appends additional outputs and increases the fee. Each replacement reuses the same input UTXO, provided it is large enough to cover all outputs. In theory, an entire high-volume operation could run on a single UTXO, appending outputs until the transaction confirms, then using the change output to fund the next batch.

This approach carries significant engineering complexity. The operator must prevent double-sends if a non-latest version of the transaction confirms during a chain reorganization. They must also handle the case where the wallet software crashes after building but before broadcasting the replacement, since the transaction ID is deterministic from the transaction data itself. A robust implementation stores the built transaction in a local database before attempting broadcast, then monitors the mempool for which version ultimately confirms.

For non-enterprise users, the practical lesson is simpler: if you use RBF on a batched payment, be aware that any recipient spending their unconfirmed output can interfere with your ability to fee-bump the entire batch.

UTXO Management: The Hidden Constraint

Batching efficiency depends heavily on input selection. A batched transaction with multiple inputs loses much of its advantage because each input carries a heavy witness burden. The ideal batch uses a single, large, confirmed UTXO as its sole input.

High-volume operators face a UTXO stockpile problem. If you need to publish a new batch every few seconds to serve immediate withdrawal requests, and blocks are mined only every ten minutes, your unconfirmed change outputs are not safe to reuse until they confirm. Without additive batching, you would need to maintain a hot wallet with hundreds or thousands of pre-funded UTXOs of appropriate sizes, an operational burden that scales poorly and creates security risks. Additive batching mitigates this by reusing the same unconfirmed input UTXO across replacements, collapsing the stockpile requirement down to a single output.

For individual users, the takeaway is to consolidate UTXOs during low-fee periods. Sending all your dust outputs to yourself in one transaction creates a single large UTXO that can later fund efficient batched payments without bloating the input count.

Privacy Implications and the Common-Input-Ownership Heuristic

Batching introduces a privacy trade-off that basic explainers rarely address in depth. When you receive a batched payment from an exchange, you can inspect the transaction on any block explorer and see the amounts and addresses of every other recipient in the same batch. Your salary, your vendor payment, and your refund are all visible to each other within that single transaction.

From a chain-analysis perspective, batching also strengthens the common-input-ownership heuristic. This heuristic assumes that all inputs in a single transaction are controlled by the same entity. While this is already the default assumption for most transactions, batching often produces transactions with a single input and many outputs, making the heuristic nearly 100% accurate for that transaction. If any of those outputs are later spent together with other outputs in a multi-input transaction, analysts can link the entire cluster.

There are mitigations. If privacy is paramount, batching should be combined with other techniques. A batched transaction can be structured as a non-equal-value CoinJoin, where the multiple outputs obscure which input funded which payment. Alternatively, users can withdraw batched funds to an intermediate wallet they control, then use separate transactions with fresh UTXOs for onward payments, breaking the direct link. For payroll or other sensitive use cases, the visibility of all recipient amounts within a single transaction may be unacceptable regardless of other mitigations.

How to Batch: Wallet and RPC Support

Batching Bitcoin transactions is not limited to exchange backends. Several tools support it directly.

Bitcoin Core: The sendmany RPC creates and broadcasts a transaction that pays multiple addresses in a single transaction. The syntax is straightforward:

bitcoin-cli sendmany "" '{
  "bc1q...": 0.1,
  "bc1q...": 0.2,
  "bc1q...": 0.3
}'

Bitcoin Core will select inputs automatically, though for optimal efficiency you should consolidate UTXOs beforehand so the transaction uses as few inputs as possible. Note that Bitcoin Core nodes will not relay transactions exceeding 100,000 vBytes, so extremely large batches should be split.

Sparrow Wallet: Sparrow added native payment batching support in 2020, allowing users to construct multi-output transactions through its graphical interface. Sparrow also provides full coin control, so you can manually select a single large UTXO as the input and specify multiple payees before broadcasting. This makes Sparrow one of the most accessible tools for non-technical users who want to batch payments without writing RPC commands.

Electrum: While Electrum does not feature a dedicated "batching" mode in its standard send tab, advanced users can construct multi-output transactions through the command line or by using plugins. However, Sparrow and Bitcoin Core currently offer the most direct paths for intermediate users.

Bull Bitcoin Batcher: For enterprise or high-volume operators, Bull Bitcoin released an open-source, non-custodial batching plugin for Bitcoin Core in 2024. It automates queue management, aggregation of payments to the same address, and pro-rata fee distribution across outputs.

Platforms like BYDFi handle withdrawal batching on the backend for users who trade on the exchange, but self-custodial users who manage their own wallets can implement the same efficiency principles using the tools above.

Practical Recommendations

If you plan to use batching in your own workflow, follow these guidelines.

First, do not depend on fee-bumping a batched transaction. Use a conservative fee estimate from Bitcoin Core's estimatesmartfee RPC in CONSERVATIVE mode, or set a fee rate that has a high probability of confirmation within your desired window. If you must use RBF, instruct recipients not to spend their outputs until confirmation to avoid transaction pinning.

Second, batch within a defined time window rather than waiting for an arbitrary number of payments. An hourly cron job that sends all pending payments in one transaction strikes a reasonable balance between speed and efficiency. The longer the window, the more payments you can include, but the longer each recipient waits.

Third, maintain a small set of large, consolidated UTXOs for batching inputs. Periodically consolidate dust outputs when mempool congestion is low. This ensures that your batched transactions remain small even as the number of recipients grows.

Fourth, if you operate a service that pays multiple users, consider the privacy implications. Recipients will see each other's addresses and amounts. For sensitive payments, either avoid batching or add a privacy layer such as separate intermediate wallets.

Key Takeaways

Batching Bitcoin transactions remains one of the most effective base-layer scaling techniques available today. By combining multiple payments into a single transaction, users and services can cut per-payment fees by up to 75% while reducing overall network congestion. The technique has evolved from simple static batching into dynamic additive batching using RBF, enabling high-volume operators to scale with minimal UTXO stockpiles. For individual users, tools like Bitcoin Core's sendmany RPC and Sparrow Wallet make batching accessible without requiring custom infrastructure.

If you are accumulating Bitcoin and plan to make regular on-chain payments, consolidating your UTXOs and using batching when appropriate will minimize your long-term fee exposure. Traders who acquire BTC through BYDFi and withdraw to self-custody can apply these same principles to manage their on-chain spending efficiently.

FAQ

Can I batch transactions if I only have one recipient?

No. Batching requires at least two separate payment outputs to a different recipient, plus typically one change output back to yourself. A single-recipient send cannot share fixed transaction overhead with other payments, so there is no efficiency gain.

Does batching slow down confirmation times?

No, provided the batched transaction pays an appropriate fee rate. A batched transaction competes for block space on the same terms as any other transaction of the same vByte size. In fact, because the total vByte count is lower than the sum of individual transactions, a batched payment may confirm faster than the same payments sent individually at the same per-payment fee budget.

What happens if I need to cancel one payment in a batched transaction?

You cannot remove a single output from a broadcast batched transaction without creating an entirely new transaction that excludes that output. If the original transaction was not yet confirmed and you enabled RBF, you can replace the entire batch with a new version that omits the unwanted payment, but you must re-sign and re-broadcast the whole transaction. This is a key operational difference from sending individual transactions.

Is additive batching safe from double-spending?

Additive batching is safe only if implemented with rigorous transaction tracking. Because each RBF replacement contains a different set of outputs, the operator must monitor which version confirms, including handling chain reorganizations. If an older version confirms unexpectedly, any outputs added in later versions must be rolled over to a new batch. Without this tracking, double-paying is a real risk.

Do all wallets support receiving batched payments?

Yes. From the recipient's perspective, a batched payment is indistinguishable from any other on-chain transaction output. Any wallet that can receive Bitcoin can receive a batched payment. The batching logic exists entirely on the sender's side.

This article is for educational purposes only and does not constitute financial advice. Bitcoin transaction fees, network conditions, and protocol behavior are subject to change. Always verify current mempool conditions and test with small amounts when implementing new transaction workflows.