This PR introduces support for v2 P2P encryption(BIP 324) in the existing functional test framework and adds functional tests for the same.
commits overview
- 
introduces a new class EncryptedP2PStateto store the keys, functions for performing the initial v2 handshake and encryption/decryption.
- 
this class is used by P2PConnectionin inbound/outbound connections to perform the initial v2 handshake before the v1 version handshake. Only after the initial v2 handshake is performed do application layer P2P messages(version, verack etc..) get exchanged. (in a v2 connection)- v2_stateis the object of class- EncryptedP2PStatein- P2PConnectionused to store its keys, session-id etc.
- a node advertising support for  v2 P2P is different from a node actually supporting v2 P2P (differ when false advertisement of services occur)
- introduce a boolean variable supports_v2_p2pinP2PConnectionto denote if it supports v2 P2P.
- introduce a boolean variable advertises_v2_p2pto denote whetherP2PConnectionwhich mimics peer behaviour advertises V2 P2P support. Default option isFalse.
 
- introduce a boolean variable 
- In the test framework, you can create Inbound and Outbound connections to TestNode- During Inbound Connections, P2PConnectionis the initiator [TestNode<———P2PConnection]- Case 1:
- if the TestNodeadvertises/signals v2 P2P support (meansself.nodes[i]set up with"-v2transport=1"), different behaviour will be exhibited based on whether:- P2PConnectionsupports v2 P2P
- P2PConnectiondoes not support v2 P2P
 
- In a real world scenario, the initiator node would intrinsically know if they support v2 P2P based on whatever code they choose to run. However, in the test scenario where we mimic peer behaviour, we have no way of knowing if P2PConnectionshould support v2 P2P or not. Sosupports_v2_p2pboolean variable is used as an option to enable support for v2 P2P inP2PConnection.
- Since the TestNodeadvertises v2 P2P support (using “-v2transport=1”), our initiatorP2PConnectionwould send:- (if the P2PConnectionsupports v2 P2P) ellswift + garbage bytes to initiate the connection
- (if the P2PConnectiondoes not support v2 P2P) version message to initiate the connection
 
- (if the 
 
- if the 
- Case 2:
- if the TestNodedoesn’t signal v2 P2P support;P2PConnectionbeing the initiator would send version message to initiate a connection.
 
- if the 
 
- Case 1:
- During Outbound Connections [TestNode ——–> P2PConnection]
- initiator TestNodewould send:- (if the P2PConnectionadvertises v2 P2P) ellswift + garbage bytes to initiate the connection
- (if the P2PConnectionadvertises v2 P2P) version message to initiate the connection
 
- (if the 
- Suppose P2PConnectionadvertises v2 P2P support when it actually doesn’t support v2 P2P (false advertisement scenario)- TestNodesends ellswift + garbage bytes
- P2PConnectionreceives but can’t process it and disconnects.
- TestNodethen tries using v1 P2P and sends version message
- P2PConnectionreceives/processes this successfully and they communicate on v1 P2P
 
 
- initiator 
 
- During Inbound Connections, 
 
- 
the encrypted P2P messages follow a different format - 3 byte length + 1-13 byte message_type + payload + 16 byte MAC 
- 
includes support for testing decoy messages and v2 connection downgrade(using false advertisement - when a v2 node makes an outbound connection to a node which doesn’t support v2 but is advertised as v2 by some malicious intermediary) 
run the tests
- functional test - test/functional/p2p_v2_encrypted.pytest/functional/p2p_v2_earlykeyresponse.py
I’m also super grateful to @ dhruv for his really valuable feedback on this branch. Also written a more elaborate explanation here - https://github.com/stratospher/blogosphere/blob/main/integration_test_bip324.md