Mempool Pruned 3.3.1.6: pruning bugs with mining index and old block pages

Bitcoin
1

Hi,

I ran into two reproducible issues with Mempool Pruned on Umbrel and was able to isolate both fairly well.

Environment:

  • Umbrel Home
  • Mempool Pruned app: 3.3.1.6
  • Backend image: Package mempool-pruned-backend · GitHub
  • Electrs Pruned: electrs 0.11.1
  • Bitcoin Knots node is pruned
  • BTC pruneheight during testing: approximately 962982
  • BTC tip during testing: approximately 967157–967161
  • Mempool CORE_RPC_HOST correctly points to the Electrs Pruned RPC proxy, not directly to Bitcoin Knots.

ISSUE 1 — Mining indexer repeatedly tries to index below pruneheight

With the default:
MEMPOOL_INDEXING_BLOCKS_AMOUNT=52560

the Mempool API repeatedly logged:
Core index ‘basic block filter index’ is synced. Best block height is 967157
[Mining] Indexing 9958 blocks from #967157 to #957158
[Mining] Block indexing failed. Trying again in 10 seconds. Reason: Block not available (pruned data)
Indexer failed, trying again in 10 seconds. Reason: Block not available (pruned data)

This repeated approximately every 10 seconds. The Bitcoin node’s pruneheight was about 962982, so the requested range extended several thousand blocks below the locally retained blocks.

WORKAROUND:
I changed:
MEMPOOL_INDEXING_BLOCKS_AMOUNT: ‘52560’
to:
MEMPOOL_INDEXING_BLOCKS_AMOUNT: ‘4000’

After restarting Mempool Pruned, it worked normally:
[Mining] Indexing 3954 blocks from #967161 to #963162
[Mining] Block indexing completed: indexed 3954 blocks
[Mining] Indexing blocks prices completed. Indexed 3984
[Mining] Indexed 2 difficulty adjustments
[Mining] Daily network hashrate indexing completed: indexed 27 days
[Mining] Weekly mining pools hashrates indexing completed: indexed 4 weeks

So limiting the mining-index range to blocks still above pruneheight eliminates the retry loop.

ISSUE 2 — Old transaction loads, but surrounding old block pages fail

I opened an old transaction from July 2025 in Mempool Pruned. The transaction itself loads correctly through Electrs, including the transaction details and confirmations. However, the historical block tiles around that transaction remain blank.

Brave Developer Tools showed requests such as:
/api/v1/blocks/906180
returning:
HTTP 500
Response:
{“error”:“Failed to get blocks”}

I verified that this is not a browser/WebSocket problem. The Mempool WebSocket connection succeeds:
ws://umbrel.local:3032/api/v1/ws
HTTP 101 Switching Protocols

I also confirmed that Mempool is correctly configured to send Core RPC requests to the Electrs Pruned proxy. Mempool CORE_RPC_HOST points to the Electrs Pruned proxy, not directly to Bitcoin Knots.

DIRECT TEST OF OLD BLOCK THROUGH THE RPC PROXY

Block height: 906180
Block hash:
00000000000000000000ba9244544120c07b0605b55e5cf51a8cd2f9c109e2d3

I tested this block directly through the same RPC proxy used by Mempool.

getblock verbosity 0:
HTTP 200
block received: YES
serialized block bytes: 1276808

getblock verbosity 1:
HTTP 200
error: null
result returned: true

getblock verbosity 2:
HTTP 500
error: { code: -1, message: ‘Block not available (pruned data)’ }
result returned: false

So the proxy can successfully retrieve this pruned historical block when getblock uses verbosity 0 or 1. Verbosity 2 fails with:
Block not available (pruned data)

This appears consistent with the historical Mempool block-page path requiring data equivalent to getblock verbosity 2. I have not traced the exact backend call itself, so that last part is an inference rather than something I directly verified.

Observed behavior:

  • Old transaction details: WORK
  • Confirmations: WORK
  • Electrum lookup: WORK
  • WebSocket: WORK
  • Current/recent Mempool data: WORK
  • Recent mining index after limiting to 4000 blocks: WORK
  • Historical block tiles around old transaction: FAIL
  • /api/v1/blocks/906180: HTTP 500
  • Old miner information: unavailable

There are also occasional messages such as:
Cannot get fetch orphaned blocks. Reason: Block not available (pruned data)

and once:
Cannot get fetch orphaned blocks. Reason: ETIMEDOUT

These did not prevent Mempool itself from otherwise syncing.

SUMMARY

There appear to be two separate pruned-node edge cases:

  1. The mining indexer does not stop at the locally retained prune boundary and repeatedly retries when MEMPOOL_INDEXING_BLOCKS_AMOUNT extends below pruneheight.
  2. Historical block-page requests fail even though Electrs Pruned’s RPC proxy can successfully retrieve the same old block using getblock verbosity 0 or 1.

For now I have left MEMPOOL_INDEXING_BLOCKS_AMOUNT=4000 as a workaround.

1 Like