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 classEncryptedP2PStateinP2PConnectionused 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 P2PP2PConnectiondoes 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 bytesP2PConnectionreceives but can’t process it and disconnects.TestNodethen tries using v1 P2P and sends version messageP2PConnectionreceives/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