Skip to main content

Bitcoin Fee Estimation for Developers: RBF, CPFP, and Batch Strategies Explained

· 3 min read
OverBlock Team
OverBlock Team
OverBlock Engineering

Bitcoin fee estimation is one of those problems that looks simple until you handle it in production. Simple sat/vB tiers break down quickly when you need to handle stuck transactions, vary by transaction type, or send hundreds of transactions efficiently.

The basics: sat/vB and virtual size​

Bitcoin fees are measured in satoshis per virtual byte (sat/vB). Higher fee rate = higher priority in the miner's mempool. The total fee is feeRate × vsize.

Virtual size depends on transaction type. Some concrete numbers:

Transaction typevsize (1 input, 2 outputs)
P2PKH (legacy)~226 vB
P2SH-P2WPKH (wrapped segwit)~165 vB
P2WPKH (native segwit)~141 vB
P2TR (taproot)~111 vB

A wallet showing "22 sat/vB" without knowing the transaction type is showing an incomplete picture. For a taproot transaction at 22 sat/vB: 22 × 111 = 2,442 sats. For P2PKH at the same rate: 22 × 226 = 4,972 sats. The difference matters.

RBF: replacing a stuck transaction​

Replace-By-Fee (BIP125) lets you replace an unconfirmed transaction with one that pays a higher fee. The rules:

  1. The replacement must signal RBF (most wallets do by default)
  2. The new fee rate must be at least 1 sat/vB higher than the original
  3. The absolute fee must increase by enough to cover the minimum relay fee for the replacement

The practical calculation: newFeeRate = MAX(currentFeeRate + 1, currentMempoolThreshold).

If your transaction is at 15 sat/vB and the next-block threshold is 42 sat/vB, bumping to 16 sat/vB won't help. You need to reach the threshold.

# Get the RBF bump recommendation for a stuck transaction
curl -X POST https://api.overblock.io/bitcoin-fees/fee-advisor/rbf-bump \
  -H "X-API-Key: your-token" \
  -H "Content-Type: application/json" \
  -d '{
    "currentFeeRateSatVb": 15,
    "currentFeeSat": 2115,
    "vsize": 141,
    "targetBlocks": 1
  }'

CPFP: accelerating via a child transaction​

Child-Pays-For-Parent (CPFP) is the alternative when you're the recipient - you create a new transaction spending the unconfirmed output, and pay enough fee to cover both transactions.

The combined fee rate needs to meet the next-block threshold:

childFeeRequired = (threshold × (parentVsize + childVsize)) - parentCurrentFee

For a wallet receiving funds, CPFP lets you accelerate confirmation without touching the original transaction.

Batch optimization: beyond "send everything at fast fee"​

If you need to send 500 transactions by a deadline, paying fast fee on all of them is often unnecessary and expensive.

The minimize_cost strategy sends transactions in waves:

  1. Send 30% now at medium fee
  2. Wait for the mempool to partially clear (typically 10-20 minutes)
  3. Send the next 40% at the (now lower) medium fee
  4. Send the rest at economy fee

Total fee reduction vs. sending all at fast: typically 30-60% depending on conditions.

curl -X POST https://api.overblock.io/bitcoin-fees/fee-advisor/batch \
  -H "X-API-Key: your-token" \
  -H "Content-Type: application/json" \
  -d '{
    "transactions": [{"vsize": 141}, {"txType": "p2wpkh"}],
    "deadlineSec": 7200,
    "targetProbability": 0.9,
    "strategy": "minimize_cost"
  }'

When to use asap instead: when the deadline is under 10 minutes, or during mempool congestion where waiting doesn't help.

The data source matters​

Fee estimation accuracy depends on mempool data freshness and source diversity. A single provider can have stale data or a different estimation algorithm than what miners use.

bitcoin-fees-advisor aggregates multiple sources, refreshes every 10-30 seconds, and provides the full toolkit described above as a REST API - including RBF, CPFP, deadline targeting, and batch planning.