pleb priority

Locally apply out-of-band fee deltas to your Bitcoin Core node, using public acceleration data from the mempool.space API.

Inband vs Out-of-band Bids

Inband block bids are well accommodated by Bitcoin Core, provided your policy rules ensure incentive compatibility. Out-of-band bids are outside the remit of Bitcoin Core for good reason.

What are Out-of-band bids?

Out-of-band bids are incentives made to miners/pools to prioritise transactions, beyond the inband fee. They can be made:

• to individual miners/pools who offer acceleration services
• via acceleration market places (e.g. Mempool Accelerator, which places acceleration requests to 80% of the network hashrate)

Current Problems

• Mining Centralisation: Mempool Accelerator doesn't currently have a way for smaller pleb miners to access the additional out-of-band revenue.
• Inaccurate Fee Projection: Nodes which are unaware of out-of-band accelerations may underestimate projected fees.

Benefits to node runners

• Non Mining Nodes: Have a local mempool that is mempool accelerator aware.
• Mining Nodes: Theoretically in the future mempool.space could opt to pay pleb miners for accelerated transactions (e.g. to the block's coinbase address).

How it works

A single Rust binary reconciles your node against the public acceleration list:

1. Fetch the pending accelerations from https://mempool.space/api/v1/services/accelerator/accelerations (no API key required).
2. Diff them against what has already been applied — recorded in a local state file and cross-checked against the node's own getprioritisedtransactions.
3. Apply only the difference with bitcoin-cli prioritisetransaction.
4. If an accelerated transaction is missing from the local mempool, fetch its raw hex from mempool.space and submit it with sendrawtransaction. The fee delta is applied first and Core counts prioritisation deltas during mempool acceptance, so a transaction whose inband feerate is below your node's mempool min fee still gets in.
5. When an acceleration ends: if the delta is still on the node (bid canceled or expired), it is removed with a negative prioritisetransaction; if the node already cleared it, the transaction was mined and there is nothing to undo.

Because each cycle applies diffs rather than replaying an event log, the tool is idempotent: re-runs, retries, duplicate API entries, bid increases, cancellations and bitcoind restarts all converge to the correct delta instead of accumulating. A network failure aborts the cycle without touching anything — an unreachable API is never mistaken for "no accelerations".

Usage

cargo build --release
./target/release/plebpriority               # reconcile every 60s (daemon mode)
./target/release/plebpriority --once        # single cycle, e.g. from cron

Requirements

• Bitcoin Core reachable via bitcoin-cli (cookie or configured auth — whatever your bitcoin-cli already uses).
• Core 26+ recommended: getprioritisedtransactions is what lets the tool detect bitcoind restarts (deltas don't survive them) and distinguish mined from canceled when undoing. Older nodes work in a degraded mode with a warning.

Notes & limitations

• prioritisetransaction deltas are cumulative on the node, which is why the tool only ever applies diffs of its own recorded contribution. Deltas you set manually on other txids are never touched; a manual delta on the same txid as an active acceleration coexists fine, except in the narrow case where bitcoind restarts mid-acceleration (the tool can't tell whose delta survived — it reapplies its own).
• Injection failures (e.g. an unconfirmed parent missing from your mempool) are logged and retried each cycle.
• The state file is written atomically after every applied change. If it's ever corrupt, the tool refuses to run rather than guessing.
• Deltas do not survive a bitcoind restart; run the tool as a daemon (or frequent cron) so they are reapplied promptly.

Command to get the position of a txid in your local block template:

txid="YOUR_TRANSACTION_ID_HERE"
bitcoin-cli getblocktemplate '{"rules": ["segwit"]}' | jq --arg txid "$txid" '.transactions | map(.txid == $txid) | index(true)'