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
EncryptedP2PState
to store the keys, functions for performing the initial v2 handshake and encryption/decryption. -
this class is used by
P2PConnection
in 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_state
is the object of classEncryptedP2PState
inP2PConnection
used 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_p2p
inP2PConnection
to denote if it supports v2 P2P. - introduce a boolean variable
advertises_v2_p2p
to denote whetherP2PConnection
which 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,
P2PConnection
is the initiator [TestNode
<———P2PConnection
]- Case 1:
- if the
TestNode
advertises/signals v2 P2P support (meansself.nodes[i]
set up with"-v2transport=1"
), different behaviour will be exhibited based on whether:P2PConnection
supports v2 P2PP2PConnection
does 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
P2PConnection
should support v2 P2P or not. Sosupports_v2_p2p
boolean variable is used as an option to enable support for v2 P2P inP2PConnection
. - Since the
TestNode
advertises v2 P2P support (using “-v2transport=1”), our initiatorP2PConnection
would send:- (if the
P2PConnection
supports v2 P2P) ellswift + garbage bytes to initiate the connection - (if the
P2PConnection
does not support v2 P2P) version message to initiate the connection
- (if the
- if the
- Case 2:
- if the
TestNode
doesn’t signal v2 P2P support;P2PConnection
being the initiator would send version message to initiate a connection.
- if the
- Case 1:
- During Outbound Connections [TestNode ——–> P2PConnection]
- initiator
TestNode
would send:- (if the
P2PConnection
advertises v2 P2P) ellswift + garbage bytes to initiate the connection - (if the
P2PConnection
advertises v2 P2P) version message to initiate the connection
- (if the
- Suppose
P2PConnection
advertises v2 P2P support when it actually doesn’t support v2 P2P (false advertisement scenario)TestNode
sends ellswift + garbage bytesP2PConnection
receives but can’t process it and disconnects.TestNode
then tries using v1 P2P and sends version messageP2PConnection
receives/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.py
test/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