The Bitcoin Network Protocol. What is the point in so much socket sharing?...

[MatthewLM]

Hello.

The version message has two network addresses (socket information with services information). One for the receiving address and another for source addresses. The receiving address is apparently to help nodes detect their own IP. Why is this needed? Why would you need to know your own IP? Apparently it is to advertise your own IP to other nodes... well isn't that what happens when you make a TCP/IP connection? When you connect to another node, that node should be able to detect the source socket of the connection, so why would you need to advertise your socket information outside TCP/IP?

It was said that it's because you can give alternative IP addresses to nodes. What does that mean? So that you can run several IPs and once you found them all you can advertise the different IPs through the different connections? If that is the case then I guess that might be a use but how does bitcoin currently use it's own IP address and why?

The second network address in the version message is for the source IP. What is this for? I have no idea. Why would you want to give an alternative source socket other than from the TCP/IP connection socket? Apparently this is not used, so why is it there?

And why does bitcoin periodically send addr messages? Why not a ping? Apparently the TCP/IP source IPs are not OK since they can be changed midway through transmission. Well the bitcoin messages can be modified too, right? So what is the benefit of using the bitcoin protocol to obtain socket information as opposed to the normal TCP/IP protocol?

I'm sure there are all good reasons but I'm quite confused so can anyone explain?

Thank you.

[1715195932]

1715195932

[Pieter Wuille]

In a perfect world, where everyone has a nice and well-defined and reachable single IP address, without NATs and bridges and IPv4/IPv6 split, or the necessity for onion routing, ..., yes, TCP/IP would suffice, and you could determine the source IP directly from the IP socket layer.

Reality is more complex. Some nodes are firewalled and only can or only want to make outgoing connections. Some may have an address they can be reached on that differs from the one they connect with. From the other direction, nodes may be behind a NAT and not know their own public IP, even though they are reachable.

As to why Satoshi did things the way he did - we don't know, and we can't ask. Until quite recently, the values in addrMe and addrYou in version messages were entirely unused. That changed, as they can be useful for discovering which of your (perhaps several) detected addresses people connect on, and as a way to advertize your own address. Whether this was what Satoshi intended to be done with them? No idea...

[MatthewLM]

I understand you may want to share an alternative IP address for incoming connections but you still don't need to know what the IP address is for your outgoing connections.

The way I would have done it is perhaps modify the behaviour of the addr message so that you can send an unspecified address (All zero).  This would tell nodes to share the IP from the connection used in receiving the addr message. If you want to use an alternative address, you send that through instead. If you want no incoming connections, then send no addr message for yourself. This way you don't need to obtain your own IP address. Obtaining your own address is a redundant operation.

[Pieter Wuille]

There are hundreds of possible micro-improvements possible to the protocol, of course. Very few are worth breaking backward compatibility for.