zerocurrencycoin / Zero

Zero Currency Blockchain Project
https://zerocurrency.io
Other
19 stars 19 forks source link

NAT Address #11

Open tearodactyl opened 6 years ago

tearodactyl commented 6 years ago

Evaluate situations where nodes behind a NAT have different internal and external (routable) addresses, and may get confused when connecting to themselves via the external address.

Such a situation could be generating the following error messages:

2018-04-13 06:54:07 receive version message: /MagicBean:1.0.81/: version 170002, blocks=300522, us=107.135.67.9:37730, peer=1
2018-04-13 06:54:07 Added time data, samples 2, offset +0 (+0 minutes)
2018-04-13 06:54:07 connect() to 213.32.78.132:23801 failed after select(): Connection refused (111)
2018-04-13 06:54:08 receive version message: /MagicBean:1.0.81/: version 170002, blocks=300522, us=107.135.67.9:38324, peer=2
2018-04-13 06:54:08 Added time data, samples 3, offset +0 (+0 minutes)
2018-04-13 06:54:10 ERROR: ContextualCheckBlockHeader: incorrect proof of work
2018-04-13 06:54:10 Misbehaving: 213.239.212.246:23801 (0 -> 100) BAN THRESHOLD EXCEEDED
2018-04-13 06:54:10 ERROR: invalid header received
2018-04-13 06:54:10 ProcessMessages(headers, 544003 bytes) FAILED peer=1
2018-04-13 06:54:12 ERROR: ContextualCheckBlockHeader: incorrect proof of work
2018-04-13 06:54:12 Misbehaving: 64.237.50.236:23801 (0 -> 100) BAN THRESHOLD EXCEEDED
2018-04-13 06:54:12 ERROR: invalid header received
2018-04-13 06:54:12 ProcessMessages(headers, 544003 bytes) FAILED peer=2

Note that the "Misbehaving" error message does not start with ERROR:

tearodactyl commented 5 years ago

Is this a real issue or 'cannot replicate' or 'will not implement' or otherwise de-prioritize?

CryptoForge commented 5 years ago

I'm a little unclear on what the issue is.

CryptoForge commented 5 years ago

213.239.212.246:23801 appear to be the same node reference in https://github.com/zerocurrencycoin/Zero/issues/47

tearodactyl commented 5 years ago

A separate but perhaps related issue is that many nodes on the network edge, like at homes and institutions, are behind NATs and firewalls and can only reach out. Is (Bitcoin) P2P code attempting to use any NAT or firewall traversal methods? Continuing to attempt reaching such nodes and even more so sharing their info with P2P peers is a waste of network resources. There could also exhaust the inbound connection slots.

tearodactyl commented 5 years ago

Example of the problem https://www.reddit.com/r/Bitcoin/comments/b7i5rs/only_8_connections_no_incoming/ Firewall https://bitcoin.org/en/full-node#firewall-configuration Bitcoin connection status https://bitnodes.earn.com/#join-the-network NAT Traversal and (UDP) hole punching https://www.zerotier.com/blog/state-of-nat-traversal.shtml IETF standards http://www.eyeball.com/standards/stun-turn-ice/ https://www.twilio.com/docs/stun-turn/faq ICE https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment STUN TURN WebRTC https://www.avaya.com/blogs/archives/2014/08/understanding-webrtc-media-connections-ice-stun-and-turn.html [IGDP, NAT-PMP, PCP, ALG, uPnP]