Electrs (or Fulcrum) and Sparrow are not compatible with the new chain. I have forks which are compatible. For the indexer, you can use “Electrs Pruned” (also works with full nodes) from my app stores, along with my BLAKE2b fork of Sparrow
2 Likes
I found this today: https://youtu.be/3Eky1BKYDZ4?si=tqO3MwVNizPnVANp&t=400 But it is a bit complicated. Yes, we have updated your apps on Start9 v 0.4.0.1, today.
What happens with our normal Core Chain pre-rdts Sparrow on Start9. Will we still be able to run at the same time as your Electrs Pruned with your BLAKE2b fork?
Could you describe what you mean by pre-rdts Sparrow on Start9? How do you have things hooked up, and what version of Start9 are you running?
1 Like
I have just sent you a message, as suggested by Discourse!
1 Like
Paul: I had missed your Mempool Pruned, which I have just started installing.
Will all these work together with the KNOTS Pre-RDTS on our Start9 v. 0.4.0.1?
Many thanks,
The best thing would be a whole video from you about all this and also the two chains Replay attack problems.
Best regards.
Rui
Paul: Do I have to turn off my Start9 0.4.0.1 Electrs which is running normally with Pre-RDTS Knots, for the Electrs Pruned to work with the other apps from your registry?
My quibble is that I still want to use my Desktop CoreChain Sparrow with my Start9 Electrs without screwing up the Original wallets that I have on Sparrow (the original Desktop Sparrow)?
Thanks.
yes
Electrs Pruned can run alongside Electrs. The original intent was to run two nodes on the same server. Electrs is only compatible with Pre-RDTS. Electrs Pruned is compatible with both chains.
Yes, that is the configuration it is designed around, where you have two stacks on one Start9 server. Main stack for legacy chain:
- Bitcoin Knots pre-RDTS (full node)
- Datum Gateway
- Mempool
- Electrs <<< Sparrow connects to this one
And pruned stack for the new chain:
- Bitcoin Knots (BLAKE2b) Companion (pruned node)
- Datum Gateway (BLAKE2b) Companion
- Mempool Pruned
- Electrs Pruned <<< Sparrow BLAKE2b connects to this one
3 Likes
Paul: I am taking an address from the Blake2b Companion to put in the Datum Blake2b Companion, which I still haven’t installed until moments ago. It is a btc1qq… address; God knows which wallet it belongs to (me, I suppose?) Waiting:
| Status | |
|---|---|
| Stratum | Waiting on |
| Compatibility capture | Waiting on Stratum… |
| Dashboard | Waiting on Stratum… |
| Miners connected | Waiting on Stratum… |
| Estimated hashrate | Waiting on Stratum… |
| Electrs Pruned: |
| Electrs is building its address index: 68.3%, block 659,400 of 965,215. This can take several hours on first run. | |
|---|---|
| Electrum Server | Electrum server is ready and accepting connections |
| So, I suppose it’s waiting time. | Good to know the normal Electrs will work with my old Sparrow. But your Balke2b Sparrow clone won’t connect, even trying it with the Bitcoin Knots node (can’t find “server=1” or the bitcoin.conf file, altough I put it there! |
|---|
Now for the Bitcoin Knots Pre-RDTS companion: it says…
| Status | |
|---|---|
| RPC | The Bitcoin RPC Interface is ready |
| Blockchain Sync | Syncing blocks…21.53% |
| Index Sync | All enabled indexes are up to date |
| I2P | Inbound and outbound connections |
| Tor | Inbound and outbound connections |
| Clearnet | Outbound only. Publish an IP address to enable inbound. |
Uptime
0Days
7Hours
10Minutes
45Seconds
Tasks
| All tasks complete |
|---|
Clearnet: I don’t get this??? Publish an IP address, where?
Many thanks. I will keep checking tomorrow. Burning the candle at both ends!
Best reagrds
Rui
Don’t do this on mainnet (that was mainly for regtest since there was no wallet to use to generate one). You want to use a Bitcoin address that you control the keys to. You can generate one in Sparrow, for example.
1 Like
Ok, it is not clear what setup you are trying to do here. Questions for you:
- What version of Bitcoin Knots is installed on this server (your main one, not the Companion)? Options:
- Bitcoin Knots (Retropex’s fork)
- Bitcoin Knots pre-RDTS
- Bitcoin Knots RDTS
- Which Bitcoin Service is Electrs Pruned pointed to (Actions & Config > Select Bitcoin Service)? Options:
- Bitcoin Knots
- Bitcoin Knots (pre-RDTS) Companion
- Bitcoin Knots (BLAKE2b) Companion
- What is your end goal? Options:
- Bitcoin Knots pre-RDTS as main full node, with Bitcoin Knots (BLAKE2b) Companion as second pruned node
- Bitcoin Knots (Retropex’s fork) as the main full node, with Bitcoin Knots (Pre-RDTS) Companion as the second pruned node
1 Like
OK, I generated a new address from the Shriek wallet (Sparrow Greg Tonosvki) and put it in Datum (Blake2b) Gateway Companion, and it is still waiting, waiting on all the Health checks.
I have got installed:
Bitcoin Knots (pre-rdts) running, since I switched back from the RDTS after watching your post-BIP110 stalling video;
The Retropex Knots fork asks if I want to switch, which I don’t yet, as I don’t know if it spoils anything to do with the legacy chain, so that I can use it with my old Sparrow on the desktop;
Electrs Pruned is pointed at Bitcoin Knots. Should I change it to Blake2b Companion or to the pre-RDTS Companion?
- I don’t know, really, but Bitcoin Knots pre-RDTS as the main full node with Bitcoin Knots (Blake2b) Companion as a second pruned node might be ok to run the Blake2b node and maybe mine later with hash renting. 3 b) Maybe Retropex (switch) will be fine with Pre-RDTS Knots Companion as a 2nd pruned node will be fine as long as I can still link my Electrs (old one from Start9) to my old Sparrow so that I can keep track of my legacy coins. I trust you will clarify everything but until these all sync I can’t see the forest for the trees! Good night from me.
Ok, I’ll suggest this setup then (what you have is mixed up)
What should be installed on your server:
Your Main, Full Node:
Bitcoin Knots pre-RDTS
Datum Gateway (optional, if you want to mine on the SHA256 chain)
Mempool
Electrs
Tor
Your Pruned Companion Node:
Bitcoin Knots (BLAKE2b) Companion
Datum Gateway (BLAKE2b) Companion (optional, if you want to mine on the BLAKE2b chain)
Mempool Pruned
Electrs Pruned
For configurations, you want:
Bitcoin Knots (BLAKE2b) Companion
- Actions & Config > Select Chain > mainnet
Datum Gateway (BLAKE2b) Companion
- Actions & Config > Set Payout Address > (a bitcoin address generated from Sparrow)
Mempool Pruned
- Actions & Config > Select Node > Bitcoin Knots (BLAKE2b) Companion
Electrs Pruned
- Actions & Config > Select Bitcoin Service > Bitcoin Knots (BLAKE2b) Companion
- Interfaces > Electrum (SSL) > Tor > Add Onion Service (if there isn’t one already)
What should NOT be installed on your server:
Bitcoin Knots (pre-RDTS) Companion
2 Likes
OK: so I have just stopped Bitcoin Knots (pre-RDTS) Companion; is it better to uninstall it completely?
For the Main, Full Node, yes, I have them all, and I’d better stop Datum Gateway as I am not mining on the SHA256 chain. So HashGG is not needed either, nor Pickhash for that purpose?
Electrs Pruned is updating with your new update now, so Bitcoin Knots (Blake2b) Companion;
I will look into the configs tomorrow, as I am about to pass out with so many late B2B nights.
Health Checks
| Name | Status |
|---|---|
| Sync Progress | Electrs is building its address index: 70.4%, block 679,870 of 965,227. This can take several hours on first run. |
| Electrum Server | Electrum server is ready and accepting connections |
Many, many Thanks.
Yes, uninstall it completely.
Correct, you won’t need Datum Gateway or HashGG if you aren’t mining on the SHA256 chain. If you want to mine on the BLAKE2b chain, you can install HashGG Companion (that one connects to your companion stack, which is BLAKE2b in your case).
Pickhash is for renting hash. It works on either chain, so if you want to rent BLAKE2b hashrate, then you can keep it, otherwise remove it.
The rest (if configured as I mentioned – Mempool Pruned and Electrs Pruned pointing to the correct node) should just be a matter of letting it finish IBD and sync.
1 Like
Hello, Paul: I will keep Pickhash.
I may mine on both chains if it comes to that, by renting hash rate.
Dtaum Gateway (Blake2b) Companion seems not to be going anywhere, as it is “Waiting” on the Node and on Stratum… unless it is waiting on the sync?!
I will configure it once it is all synced, so as not to disrupt the sequence.
Keeping you posted. Regards. Rui
All downstream applications block while upstream is syncing. I usually just leave them stopped until their upstream component is finished. The order of the long syc processes goes like:
- Knots completed the IBD (then start Datum Gateway and electrs)
- electrs completes its indexing (then start Mempool, and connect Sparrow)
- Mempool completes its cache (now you can comfortably explore the blockchain)
Knots needs to finish before Datum Gateway can function
Knots also needs to finish before electrs will start its indexing.
And electrs needs to finish before Mempool will start its caching.
Additionally, electrs needs to finish before Sparrow will connect properly.
1 Like
OK; still on it! Waiting on sync Knots Blake2b Companion:
Syncing 718045/966598
Curois about the log report for Knots 29.4.1:6
2026-09-03T09:51:32-06:00 15:51:32@921/warn - Streaming: Resend #4, another remote lease has been selected for stream with rSID=1138643393, sSID=2902907843
2026-09-03T09:51:38-06:00 15:51:38@921/warn - Streaming: Resend #5, another outbound tunnel has been selected for stream with sSID=2807858607
2026-09-03T09:51:41-06:00 15:51:41@921/warn - Streaming: Resend #5, another outbound tunnel has been selected for stream with sSID=2902907843
2026-09-03T09:51:42-06:00 15:51:42@921/warn - Streaming: Resend #2, another remote lease has been selected for stream with rSID=447402623, sSID=34544949222026-09-03T09:51:42-06:00 15:51:42@630/warn - Tunnels: Test of tunnel 269380818 failed
2026-09-03T09:51:43-06:00 15:51:43@921/error - SAM: Read error: End of file2026-09-03T09:51:43-06:00 15:51:43@786/warn - Transports: Session to peer CCWPn4WlPlssLDOEOBv3he976jQfUJD8QMN4~R7kH60= has not been created in 15 seconds
The messages themselves look like normal I2P churn, but they are fairly close together in time. Do you see these continuously spamming the log in rapid succession over an extended period of time, or is it bursty where you get a few all at once, and then none for a while?