Hello. I see a lot of talk about “server requirements” but all seem more focused on cores and the like. I own plenty of hardware but am curious if there is a static IP requirement for leader nodes?
Don’t need to be static IPs but we don’t support NAT punch-through right now so it cannot be behind a NAT
1 Like
hey Casimir. Do you mean we can’t use routers to link miners to Nockchain please? If so, what’s the solutions for this? thanks. 
1 Like
You can if you can do that without using a NAT for the machine that you want to be publicly accessible.
To be clear I have to use port forwarding for UDP port 3005 etc. on my router to the machine that runs the Nockchain miner?
1 Like
Yes that should work
2 Likes
is UPnP sufficient?
Port forwarded 3005+3006 on one computer, 3007+3008 on another 
I think I’m stuck on this networking piece as well. I’ve got a few machines on my local network but none can find peers presently (running make run-nockchain-leader on one, and make run-nockchain-follower on the others), and I haven’t set up any of the port forwarding stuff and am a bit confused on how to do that. I expect if I am forwarding/opening up those ports that I do that on the router, but I also have a tailscale network set up for all these devices; is there a better way to do this using tailscale?
What makes you think leader/followers are not finding peers? Are you seeing errors to that effect?
I’m getting this on all followers. What would be the best resources for learning about this kind of home networking solution? This portion of things is new to me and frankly what I’ve used Urbit to avoid, lol.
that behavior will happen sometimes even during successful running so I wouldn’t worry about it
1 Like
Even if it happened all night? what would tell me that the followers have properly found the leader and/or some peers?
tangentially, if I expose one local node to the web via port forwarding, can the others stay closed off and just interact through local peers?
local peering should work though I haven’t tried it. Once the github repo is updated, pull it down, build, follow steps, all should be fine
@sunnyg / @milset I’m guessing you guys haven’t really been able to confirm if port forwarding works yet?
Correct, have not been able to confirm - if its any consolation, Ive been getting the same logs despite running a leader on one machine and a follower on another.
@thelifeandtimes I was able to peer two Mac minis in my local LAN with assigned fixed IP addresses. I used the peer flags for that.
But I never tried to peer a Mini in my local LAN with another machine over the public internet where port forwarding of my home router comes into play.
2 Likes
What CLI options did you provide to do that peering test?
I had Google Gemini analyze crates/nockchain/src/lib.rs where the flags are located. Unfortunately, I didn’t save the commands that I used during the test but I had Gemini recreate them here from the inputs I gave it.
The idea is to launch the leader without default peers, copy the leader’s peer id from the output of the launched nockchain process and insert that peer id and the IP address of the leader in the command for the genesis-watcher.
nockchain \
--fakenet \
--genesis-leader \
--mine \
--mining-pubkey MACA_LEADER_PUBKEY \
--npc-socket ./nockchain.sock \
--bind /ip4/0.0.0.0/udp/3005/quic-v1 \
--new-peer-id \
--no-default-peers \
--genesis-message "MacA Local Test Genesis"
nockchain \
--fakenet \
--genesis-watcher \
--mine \
--mining-pubkey MACB_FOLLOWER_PUBKEY \
--npc-socket ./nockchain.sock \
--bind /ip4/0.0.0.0/udp/3006/quic-v1 \
--peer /ip4/192.168.1.100/udp/3005/quic-v1/p2p/12D3KooW...MACA_PEER_ID \
--new-peer-id \
--no-default-peers \
1 Like
I expect this NAT situation impacts home networks and maybe even something like Google Cloud? Panic