Mainnet connectivity problems

Technical Support
1

Let’s use this thread to document & discuss the network connectivity problems being observed on mainnet right now:

Problem #1 - Bootstrapping:
mainnet.z.cash resolves to 1 IPv4 address no matter where you resolve it, and it’s refusing all new TCP connections (AFAICT). As a result new nodes cannot join the network.
Evidence:
2016-10-28 19:59:31 socket recv error Connection reset by peer (104) in debug.log
or use tcpdump, wireshark, etc to examine at the network traffic
Expected Solutions:

  • The zcash ops team should repair that node, and (ideally) provide a few dozen more IPv4 addresses of geographically-distributed nodes for people to use. Given the popularity of this coin (and the 13117 h4x0r bullshit that attracts), it was not wise launch w/ just one addnode :-\
  • Users with a working, well-connected node could post some nodes from their getpeerinfo rpc here, to allow new users to try joining the network through them. Note though that any/all of these may be bogus/malicious.
  • The zcash devs could restore the IRC boostrapping code from satoshi’s initial bitcoin releae (j/k, sorta)

Problem #2:
The client attempts to connect to IPv6 addresses on nodes without IPv6 connectivity.
Evidence:
‘connect() to [2a01:4f8:201:7489::2]:8233 failed: Network is unreachable (101)’ in debug.log
Solution(s):
This is a SW bug in the client that should ideally be fixed there, but you can work around it by adding ‘onlynet=ipv4’ to zcash.conf

2

Problem #1 may be resolved or partially resolved now. I was just able to bring up a new node.

3

Problem #3:
Errors reported in getinfo & getmininginfo rpcs
Evidence:
A line like “errors” : “WARNING: abnormally high number of blocks generated, 284 blocks received in the last 4 hours (96 expected)” in these rpc responses
Solution(s):
AFAICT these are harmless & OK to ignore. They are just a result of the diff adj algo taking a while to catch up to the network hash rate.

4

Possible Problem #4:
The node is not connecting to other peers. After running for a while it has only 1 con to mainnet.z.cash.
Evidence:
single entry in getpeerinfo rpc matching the bootstrap node’s IP address
Solution(s)
None known. This may be an intentional design decision but obviously it means there is no P2P decentralization at the network level.

5

Your #4 looks like a known issue

6

Thanks. Possible Workaround for #4: Open and/or Forward TCP port 8233.

daira said that’s needed due to an upstream issue from bitcoind, but if so, it must be version-specific. I have a firewalled bitcoind 0.13.0 node on the same host which reliably maintains 8 cons.

7

Does zcash have an upper limit on the amount of nodes that a given node can have concurrently connected (akin to -maxconnections=)?

Relying on all nodes to responsibly forward on p2p messages/block events to other nodes is not a wise practise.

8

I’m not sure on the upper limit, but I sure as hell would love to see maxconnections implemented in zcashd. My node is currently sitting at 63 public connections and I might need to take it down if it burns through my bandwidth.