[Part 2/2] Functional tests for v2 P2P encryption #24748

[stratospher]

Session details

• Date: 07-12-2023
• Time: IST 20:00 (UTC 14:30)
• PR: test/BIP324: functional tests for v2 P2P encryption bitcoin/bitcoin#24748
• Context: p2p test
• Difficulty: intermediate
• Language: python

Learning

This is the 2nd part for a 2-part review club. The review club will focus on how PR #24748 modifies the functional test framework in order to make v2 transport protocol work for the python implementation of a node's peer.

• Functional test framework
• P2P network

  Note: Drop your PR and review related suggestions/thoughts/questions below

Summary

• Developers often want to be able to send their own custom response, introduce malicious behaviour and check if error messages were reported, pause and examine bitcoind process etc. The P2PInterface class serves this purpose and mocks the behaviour of a peer. It's written in python and can be easily customised.
• bitcoind instance has support for encrypted transport protocol since #28331. In order for the P2PInterface class to communicate with bitcoind instance using encrypted transport protocol, we need to add support for encrypted transport protocol in P2PInterface class. This means introducing:
  1. Initial v2 handshake
     • Currently nodes establish connection with the other node by sending a version message and waiting for a version message and a verack message back from the other node. It then sends a verack back to the peer to establish the connection. This is called a version handshake.
     • With encrypted transport protocol, we even want the version message to be encrypted. So before the version handshake, an advanced form of Diffie-Hellman handshake (called initial v2 handshake) happens so that both nodes have same keystream to encrypt/decrypt P2P messages.
  2. New P2P message format for encrypting/decrypting P2P messages
     • v1 P2P message format
     • v2 P2P message format

Questions

1. Describe how the initial v2 handshake works.
   • see how v2_handshake() calls initiate_v2_handshake(), respond_v2_handshake(), complete_v2_handshake(), authenticate_v2_handshake()
   • Why are there 4 different functions?
2. How are inbound connections modified to support v2?
   • see where version msg get sent.
   • we need to call the v2 handshake functions before that.
3. How are outbound connections modified to support v2?
   • see where version msg get sent.
   • we need to call the v2 handshake functions before that.
4. Has the P2P message size reduced/increased in v2? Does order of sending P2P messages matter in v1/v2 P2P?
5. Why does false advertisement of services which a node can support happen? What happens if we start doing initial v2 handshake with a node which doesn't support encrypted transport protocol? How is backward compatibility maintained?

[rajarshimaitra]

The summary for Part 1 of this club is documented here: https://github.com/Bitshala/BitcoinCore-PR-Review-Club/discussions/47