Electrs Pruned + SHA256 Knots Companion – Sparrow cannot load old Trezor transaction history

Dennis66 · September 21, 2026, 11:21am

Hi Paul, and others,

I’m trying to use a Trezor Safe 5 with Sparrow, while keeping the entire Bitcoin backend on my own StartOS server.

My setup is:

Bitcoin Knots (SHA256) Companion → Electrs Pruned → Sparrow → Trezor Safe 5

Configuration/status:

Bitcoin Knots (SHA256) Companion is fully synced
Knots is running pruned at 5000 MiB
RPC Proxy reports ready
Electrs Pruned 0.11.1:39 is fully synced
Electrs is connected to the SHA256 Knots Companion
Sparrow 2.5.5 connects successfully to Electrs over SSL
Sparrow detects and imports the Trezor Safe 5 correctly

The problem

Sparrow can open the Trezor wallet, but it cannot load its historical transaction history. It eventually reports:

Error loading transactions: Failed to subscribe to paths

and:

Error retrieving wallet history

At the same time, Electrs Pruned logs errors like:

failed to fetch pruned block ... over RPC

an RPC provider that serves pruned blocks (e.g. btc-rpc-proxy) is required

followed by:

Couldn't connect to host: Resource temporarily unavailable (os error 11)

My assumption is that Sparrow/Electrs finds historical transactions belonging to the wallet, but the corresponding blocks are older than the data currently retained by the 5000 MiB pruned Knots node.

As I understand it, Electrs Pruned is specifically designed for this situation: when an old block has already been pruned, it should retrieve that block on demand through the RPC proxy and verify it against the known block hash.

In my case, that on-demand retrieval appears to be the part that is failing.

Question:

Is this expected to work with Bitcoin Knots (SHA256) Companion + Electrs Pruned, and if so, what should I check to get the RPC proxy to successfully retrieve these old pruned blocks?

My goal is simply to have Sparrow display the complete history of my Trezor wallet using only my own StartOS backend, without switching Sparrow to a public/external Electrum server.

I’d prefer to keep the node pruned if possible rather than downloading the full blockchain again.

paul · September 21, 2026, 12:48pm

I think this is probably a timeout in Sparrow itself (which I fixed in Sparrow BLAKE2b but that doesn’t help folks on a pruned SHA256 node). Let me see what I can do in this setup.

Dennis66 · September 21, 2026, 2:22pm

Thank You Paul,
yes that make sense and we can use the trezor without history.
not that important.

paul · September 21, 2026, 9:21pm

Check the latest version of Electrs Pruned. I add a couple of optimizations to reduce the time on these calls. I have a couple more I can do, so if it isn’t working yet I’ll do some more work on it.

Dennis66 · September 22, 2026, 6:50am

We do run the latest version and it seems working without the history.

paul · September 22, 2026, 11:29am

I assume this means it is not working (since it should show historical transactions). I’ll keep digging. Anything new in the logs that seems interesting?

Dennis66 · September 22, 2026, 12:04pm

These logs goes above my head
2026-09-22T13:04:30+02:00 [2026-09-22T11:04:30.124Z WARN electrs::electrum] RPC blockchain.transaction.get failed: failed to get transaction info: JSON-RPC error: RPC error response: RpcError { code: -5, message: “No such mempool transaction. Use -txindex or provide a block hash to enable blockchain transaction queries. Use gettransaction for wallet transactions.”, data: None }
2026-09-22T13:08:26+02:00 [2026-09-22T11:08:26.329Z INFO electrs::index] indexing 1 blocks: [968136..968136]
2026-09-22T13:08:26+02:00 [2026-09-22T11:08:26.382Z INFO electrs::chain] chain updated: tip=0000000000000000000148c293f2c4cfd9aebbe881e25b7159f5eea095ee27b1, height=968136
2026-09-22T13:26:03+02:00 [2026-09-22T11:26:03.591Z INFO electrs::index] indexing 1 blocks: [968137..968137]
2026-09-22T13:26:03+02:00 [2026-09-22T11:26:03.645Z INFO electrs::chain] chain updated: tip=0000000000000000000028042756cb14dd572dd63dd83bc58431d73bf1179ac6, height=968137
2026-09-22T13:39:45+02:00 [2026-09-22T11:39:45.122Z INFO electrs::index] indexing 1 blocks: [968138..968138]
2026-09-22T13:39:45+02:00 [2026-09-22T11:39:45.160Z INFO electrs::chain] chain updated: tip=0000000000000000000020c231d1f3c41171a8e9bb22551c81a38f0777a2f91e, height=968138
2026-09-22T13:45:41+02:00 [2026-09-22T11:45:41.705Z INFO electrs::index] indexing 1 blocks: [968139..968139]
2026-09-22T13:45:41+02:00 [2026-09-22T11:45:41.749Z INFO electrs::chain] chain updated: tip=00000000000000000000af04627edbf71ab1a4d30ca87af7ac8fc60502645643, height=968139
2026-09-22T13:58:00+02:00 [2026-09-22T11:58:00.817Z INFO electrs::index] indexing 1 blocks: [968140..968140]
2026-09-22T13:58:00+02:00 [2026-09-22T11:58:00.860Z INFO electrs::chain] chain updated: tip=0000000000000000000037a8683413c8dde7a65ebc4b0e839241f8fae72d240e, height=968140

paul · September 22, 2026, 9:51pm

Couple of questions:

Is all history missing, or only transactions after August 8 (or is all the history before that date)?
Is Electrs Pruned pointed at Bitcoin Knots or at Bitcoin Konts (SHA256) Companion? (Actions & Config > Select Node)

One test for pruning being a cause: In Sparrow, with your server connected, press Ctrl+I (Cmd+I on macOS), or use File → Open Transaction → From ID…, and paste this transaction ID:

a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d

That is a well known transaction from 2010. It is not yours and reveals nothing about your wallet. It is old enough that your node has certainly pruned it, so fetching it exercises the same path your history uses.

Tell me which happens:

A transaction window opens showing 10,000 BTC sent in May 2010. Then the server is healthy and the problem is narrower than it looks.
“A transaction with that ID could not be found”, or an error. Then the server’s index is the problem.

Either way, please also stop Electrs Pruned, then start it back up and download the logs (Logs > Download). Send it to me in a DM (don’t post it here on this thread in case there is any privacy information)