Title: Is the handshake version-verack? Post by: wunchofbankers on March 06, 2023, 07:44:02 PM I have read conflicting specs online: when a node initiates a connection to another node, does the protocol level handshake go:
version --> version <-- verack <-- verack --> OR version --> verack <-- version <-- verack --> (arrow from left to right represents a message from the connecting node to the listening node, and vice versa) In other words, does the listening node respond first with verack and then with a version message, or vice versa? Thanks all Title: Re: Is the handshake version-verack? Post by: ymgve2 on March 06, 2023, 08:31:08 PM Since it's not properly specified: your code should handle both cases.
Title: Re: Is the handshake version-verack? Post by: wunchofbankers on March 06, 2023, 08:48:41 PM Why doesn't the protocol just specify this? Oh I guess there is a remote chance 2 peers both try and initiate a connection with each other at the same time. Specifying one or the other would cause a handshake failure if the listener sent a version message (coincidentally) whilst the client's own version message was in flight.
Title: Re: Is the handshake version-verack? Post by: ymgve2 on March 06, 2023, 09:14:53 PM Why doesn't the protocol just specify this? Oh I guess there is a remote chance 2 peers both try and initiate a connection with each other at the same time. Specifying one or the other would cause a handshake failure if the listener sent a version message (coincidentally) whilst the client's own version message was in flight. If both peers try to connect to each other at the same time, it will result in two different TCP connections, it doesn't automatically become a single connection. Title: Re: Is the handshake version-verack? Post by: wunchofbankers on March 06, 2023, 11:19:25 PM Ok. Then what is the reason the protocol doesn't specify whether the listener should respond with version or verack first?
Title: Re: Is the handshake version-verack? Post by: pooya87 on March 07, 2023, 03:57:47 AM Connections are two way (bidirectional) not one way and what you refer to as "listener" is just listening for incoming connections so after that it receives a connect request it opens up a new "socket" where it can both send and receive messages over TCP at the same time.
The reason why you see version first then verack second or vice versa is that the clients put both messages into a single "package" and then send it over the opened socket. This only make implementation slightly more complicated (to handle both cases). Otherwise to make sure other node receives verack first it would have to first initiate a "I/O send" operation for verack then finish it and initiate another for version and both messages are tiny and have to be sent so it makes sense to send them together. Title: Re: Is the handshake version-verack? Post by: NotATether on March 07, 2023, 06:33:02 AM Ok. Then what is the reason the protocol doesn't specify whether the listener should respond with version or verack first? Here is what I found inside Bitcoin Core unit tests that seems to imply that nodes can send anything before receiving the "verack" message: Quote from: https://github.com/bitcoin/bitcoin/blob/e9262ea32a6e1d364fb7974844fadc36f931f8c6/test/functional/p2p_leak.py Code: """Test message sending before handshake completion. And this is from another unit test that appears to support the theory that the version message should be received before verack is sent: Code: p2p_conn.peer_connect(**kwargs, net=self.chain, timeout_factor=self.timeout_factor)() Pay special attention to this section: Code: # At this point we have sent our version message and received the version and verack, however the full node I'm sure you can get a more precise answer by inspecting the P2P code written in C++, but then it's not guaranteed that other full nodes will do the same thing. Just do what ymgve2 said and handle both cases. Title: Re: Is the handshake version-verack? Post by: wunchofbankers on March 07, 2023, 04:01:53 PM Connections are two way (bidirectional) not one way and what you refer to as "listener" is just listening for incoming connections so after that it receives a connect request it opens up a new "socket" where it can both send and receive messages over TCP at the same time. I know now that both message orders are supported but I'm still a bit unclear on this explanation though. By packet do you mean a single TCP packet? I still don't get why, even if the verack and the version are sent together somehow, we don't just specify that one comes first. The reason why you see version first then verack second or vice versa is that the clients put both messages into a single "package" and then send it over the opened socket. This only make implementation slightly more complicated (to handle both cases). Otherwise to make sure other node receives verack first it would have to first initiate a "I/O send" operation for verack then finish it and initiate another for version and both messages are tiny and have to be sent so it makes sense to send them together. Say verack comes first. Then the node which initiates the connection sends version, then receiving node responds with varack-version in this order and then the initiating node responds with its own verack. What's the problem? Title: Re: Is the handshake version-verack? Post by: digaran on March 07, 2023, 06:17:01 PM Say verack comes first. Then the node which initiates the connection sends version, then receiving node responds with varack-version in this order and then the initiating node responds with its own verack. What's the problem? Do you have any example to show us? Where did you see any interruption between sender and receiver? Edit, according to my source, both clients need to exchange their versions first, then the header ( verack ). Read from here, https://en.bitcoin.it/wiki/Protocol_documentation |