Just to be clear, I’ll have both Fulcrum and electrs Pruned running for blake2b at the same time as Fulcrum will be running for SHA256. Correct?
I thought they were mutually exclusive, and I didn’t realized you’ve deconflicted them.
Also, my intention is to mine on both chains, at least for now. Other than me using Shrike instead of your downstream Sparrow wallet, mining on both chains from a single Start9 seems the easiest method.
I spun up a Knots node native to MacOS, during the early days of the split. Do you think there would be any advantages to connecting the Shrike wallet to that, and mining from that? I would run DATUM from a Docker container.
Yes, my “pruned companion” stack is fully deconflicted, for the purpose of running two nodes on the same server. A “full stack” in this context is Knots, Datum Gateway, HashGG, Electrs, and Mempool.
The only component which is a bit different is Pickhash. It is designed to be one instance supporting both chains. I haven’t yet written in support for multiple simultaneous sessions/campaigns, though, so currently you can only run it for one algo at a time.
For the SHA256 chain, Knots, Fulcrum, HashGG, and Datum Gateway are running. For Blake2b, I have the same four companion apps. The only issue I have is in the Knots companion, I have an error message regarding ZeroMQ Block and ZeroMQ Transaction:
This address will not work from your local network due to a router hairpinning limitation
A couple questions to help narrow down the problem:
- Is the warning under a public/clearnet address for those interfaces, rather than LAN or Tor?
- What external port does StartOS show for those ZMQ addresses — 28332/28333, or something else?
- On the official Knots package, is ZMQ exposed or forwarded?
- Did you deliberately expose ZMQ publicly, or did this appear with the default config?
The error is associated with my StartTunnel Public. It should be protected, but I can turn it off, if recommended. Neither uses 28332/28333.
On the Knots pre-RDTS app, the error isn’t posted, and 28332/28333 are the ports in use.
I turned on the StartTunnel public, but StartOS picked the ports.
If I’m interpreting that message correctly, I think it is about one address only, and isn’t really an error in the app. I think what’s happening is StartOS tested the ZeroMQ ports from outside your home IP and got an answer, so they are reachable from the internet. It then tried to reach that same public address from inside your own network and could not. Most home routers will not let you loop back to your own public IP from inside, which I think is the “hairpinning limitation” it mentions. So that public address works from outside but not from your home network. Your apps should all be unaffected, because they talk to the node over the internal network and never use that address.
I think the reason it shows up on one node and not the other is just which interfaces ended up on the tunnel. Both packages set ZeroMQ up identically, so it is not a difference between the apps.
I would turn off ZeroMQ specifically. ZeroMQ in Bitcoin has no password and no encryption. Anyone who can reach the port gets the feed. What it carries is blocks and transactions, which are public anyway, so nothing secret is leaking. But there is no upside either. Fulcrum, HashGG and Datum all reach it over the internal network, so exposing it publicly gains you nothing and puts an open port on the internet for no reason.
To change it:
- Open the Knots (BLAKE2b) Companion.
- Go to Interfaces, then ZeroMQ Block.
- Find the StartTunnel address. It will be marked Public with a globe icon.
- Click that and switch it to Local, or use Delete on the address if there is no Local option.
- Do the same for ZeroMQ Transaction.
The warning should go away with it and nothing else changes. Keep StartTunnel on anything you genuinely reach from outside. If you want remote access to the node itself, RPC is the one to use, since that at least has a password on it. If you are not reaching it remotely, there is no need to expose that either.
Thanks, Paul. The warnings are gone. I didn’t need to enable those public addresses. I use the tunnel for the node and most of the services, when I’m away from home.
1 Like
Newest Shrike versions connect properly now with Electrs Pruned.
That was my experience, too.
Hi Paul, Is there any point in tracking Sparrow flavors for Blake2B; Do you diff against Shrike changes? I assume Shrike didn’t have what you needed at the time you were creating the Blake2B companion versions.
Thanks a lot
TBH, I didn’t want to trust Shrike until it builds a reputation. I’ll probably continue to maintain Sparrow BLAKE2B for the foreseeable future, because it allows me to remain up to date on whats happening with the new chain, and it lets me verify what Sparrow itself is pushing out rather than trusting that they are trustworthy actors. I don’t expect Sparrow BLAKE2b to be widely used, though. Shrike has clearly taken that slot.
4 Likes