WIP [don't merge] Add BIP324 - Version 2 Peer-to-Peer Message Transport Protocol #1024

jonasschnelli · 2020-10-21T08:49:42Z

Discussions happend here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/thread.html#16806
https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#comments

Implementations is partially merged in Bitcoin Core (AEAD, KDF).

jonatack · 2020-10-21T09:00:05Z

Concept ACK

dr-orlovsky · 2020-10-22T10:14:37Z

Question: why not to stick to the same messaging structure used by the current LN and increase the number of encoding standards/protocol/library code?

jonasschnelli · 2020-10-22T12:13:47Z

@dr-orlovsky
I think BOLT8 is very similar to the proposed AEAD scheme we use in BIP324. I guess BOLT8 was inspired by BIP151 which is the predecessor of BIP324.
The main differences are the handshake as well as the MACing of the encrypted length.

The reason why I don't think using BOLT8 directly are the following:

LN nodes have static node keys (nodeid), Bitcoin doesn't. Bitcoin Nodes try to be non fingerprintable.
One goal of designing BIP324 was to not increase the bandwidth (traffic) requirement of peers. My observations shows that roughly 50% of all sent and receives bitcoin messages of a node are <= 64 bytes (even higher for pruned peers). Adding another 16byte MAC for each package would increase the traffic requirement significant (IMO without reasonable security benefits).

ysangkok · 2020-10-31T21:56:20Z

bip-0324.mediawiki

+
+== Motivation ==
+
+The current peer-to-peer protocol is partially inefficient and in plaintext.


I don't like "current" for the same reason I don't like it on Wikipedia, it will be weird reading this document in 5 years. Better just write "the P2P protocol supported in Bitcoin 0.20.1".

"partially inefficient" in which way? Because of the double-SHA256? Surely the lack of encryption isn't inefficient, which is what most of the section talks about. I would at least just remove "partially", inefficiency isn't black/white in any case, so the word "partially" doesn't add anything.

ysangkok · 2020-10-31T21:56:37Z

bip-0324.mediawiki

+
+== Abstract ==
+
+This BIP describes a new Bitcoin peer to peer transport protocol with opportunistic encryption.


Inconsistent hyphenation in peer-to-peer

ysangkok · 2020-10-31T21:59:02Z

bip-0324.mediawiki

+
+Adding opportunistic encryption introduces a high risk for attackers of being detected. Peer operators can compare encryption session IDs or use other form of authentication schemes <ref name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki BIP150]</ref> to identify an attack.
+
+Each current version 1 Bitcoin peer-to-peer message uses a double-SHA256 checksum truncated to 4 bytes. Roughly the same amount of computation power would be required for encrypting and authenticating a peer-to-peer message with ChaCha20 & Poly1305.


It would be nice if there were some rough figures referenced here, maybe in seconds per byte?

ysangkok · 2020-10-31T22:02:18Z

bip-0324.mediawiki

+
+Additionally, this BIP describes a way to identify data which has been manipulated by peers (intercepting, then blocking or tampering with messages).
+
+Encrypting traffic between peers is already possible with VPN, tor, stunnel, curveCP or any other encryption mechanism on a deeper OSI level, however, most of those solutions require significant technical experience in setting up a secure channel and are therefore not widely deployed.


Why invoke OSI? It is not clear what is deep in OSI. Apparently it is anything that can wrap the Bitcoin P2P protocol. But such a protocol could also leverage the application layer. I think it would be better to just say it can wrap Bitcoin.

ysangkok · 2020-10-31T22:07:30Z

bip-0324.mediawiki

+
+A peer signaling <code>NODE_P2P_V2</code> MUST accept encrypted communication specified in this proposal.
+
+Peers MAY only make outbound connections to peers supporting <code>NODE_P2P_V2</code>.


Before you connect, you can't know whether the node supports V2. Why not say "maintain" instead of "make"?

Why is "peers" plural here, when it is singular above? An implementer of this BIP will write node software for a single peer, so I think singular works better. Better use plural for the other nodes.

ysangkok · 2020-10-31T22:37:05Z

bip-0324.mediawiki

+
+Optimized implementations of ChaCha20-Poly1305@bitcoin are relatively fast, therefore it is very likely that encrypted messages will not require additional CPU cycles per byte when compared to the current unencrypted p2p message format (ChaCha20/Poly1305 versus double SHA256).
+
+The initial packet sequence numbers are 0.


Since there is only one initial element of anything, I suggest using singular.

ysangkok · 2020-10-31T22:37:55Z

bip-0324.mediawiki

+
+Encrypted messages do not have the 4byte network magic.
+
+The maximum message size is 2^23 (8,388,608) bytes. Future communication MAY exceed this limit and thus MUST be split into different messages.


To make it clear that this is not xor, one could spell out "to the power of".

ysangkok · 2020-10-31T22:38:48Z

bip-0324.mediawiki

+
+Peers calculate the counterparty limits and MUST disconnect immediately if a violation of the limits has been detected.
+
+=== Test Vectors ===


why not put this in a CSV file so that it can easily be tested?

ysangkok · 2020-10-31T22:39:34Z

bip-0324.mediawiki

+
+== Motivation ==
+
+The current peer-to-peer protocol is partially inefficient and in plaintext.


Maybe link to the section "Length comparisons between v1 and v2 messages" as a reference for the inefficiency.

ysangkok · 2020-10-31T22:39:55Z

bip-0324.mediawiki

+ ------------------------------------------------------------------------------------------
+</pre>
+
+==== AEAD Test Vectors ====


These could be in a CSV file.

luke-jr · 2022-05-05T14:51:09Z

@jonasschnelli Are you still working on this?

michaelfolkson · 2022-05-05T15:28:34Z

@luke-jr: I think @dhruv has taken over work on BIP 324. In fact (assuming @dhruv agrees) this PR could probably be closed in favor of a future PR from @dhruv.

dhruv · 2022-05-05T15:38:52Z

@michaelfolkson @luke-jr I agree we can close this PR. The new new draft is very different and reviewing the diff will not make sense. I will link this closed PR in the new one.

jonasschnelli added the New BIP label Oct 21, 2020

Add BIP324 - Version 2 Peer-to-Peer Message Transport Protocol

2d331e8

jonasschnelli force-pushed the master branch from dbae6de to 2d331e8 Compare October 30, 2020 08:05

ysangkok suggested changes Oct 31, 2020

View reviewed changes

jonasschnelli changed the title ~~Add BIP324 - Version 2 Peer-to-Peer Message Transport Protocol~~ WIP [don't merge] Add BIP324 - Version 2 Peer-to-Peer Message Transport Protocol Nov 3, 2020

narich approved these changes Feb 18, 2022

View reviewed changes

luke-jr closed this May 5, 2022

dhruv mentioned this pull request Oct 7, 2022

Add BIP324: v2 P2P Transport Protocol #1378

Merged

bitcoin deleted a comment from protechq88 Oct 21, 2022

bitcoin locked and limited conversation to collaborators Oct 21, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP [don't merge] Add BIP324 - Version 2 Peer-to-Peer Message Transport Protocol #1024

WIP [don't merge] Add BIP324 - Version 2 Peer-to-Peer Message Transport Protocol #1024

jonasschnelli commented Oct 21, 2020

jonatack commented Oct 21, 2020

dr-orlovsky commented Oct 22, 2020

jonasschnelli commented Oct 22, 2020

ysangkok Oct 31, 2020

ysangkok Oct 31, 2020

ysangkok Oct 31, 2020

ysangkok Oct 31, 2020

ysangkok Oct 31, 2020

ysangkok Oct 31, 2020

ysangkok Oct 31, 2020

ysangkok Oct 31, 2020

ysangkok Oct 31, 2020

ysangkok Oct 31, 2020

luke-jr commented May 5, 2022

michaelfolkson commented May 5, 2022 •

edited

Loading

dhruv commented May 5, 2022


		== Motivation ==

		The current peer-to-peer protocol is partially inefficient and in plaintext.


		== Abstract ==

		This BIP describes a new Bitcoin peer to peer transport protocol with opportunistic encryption.


		Adding opportunistic encryption introduces a high risk for attackers of being detected. Peer operators can compare encryption session IDs or use other form of authentication schemes <ref name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki BIP150]</ref> to identify an attack.

		Each current version 1 Bitcoin peer-to-peer message uses a double-SHA256 checksum truncated to 4 bytes. Roughly the same amount of computation power would be required for encrypting and authenticating a peer-to-peer message with ChaCha20 & Poly1305.


		Additionally, this BIP describes a way to identify data which has been manipulated by peers (intercepting, then blocking or tampering with messages).

		Encrypting traffic between peers is already possible with VPN, tor, stunnel, curveCP or any other encryption mechanism on a deeper OSI level, however, most of those solutions require significant technical experience in setting up a secure channel and are therefore not widely deployed.


		A peer signaling <code>NODE_P2P_V2</code> MUST accept encrypted communication specified in this proposal.

		Peers MAY only make outbound connections to peers supporting <code>NODE_P2P_V2</code>.


		Optimized implementations of ChaCha20-Poly1305@bitcoin are relatively fast, therefore it is very likely that encrypted messages will not require additional CPU cycles per byte when compared to the current unencrypted p2p message format (ChaCha20/Poly1305 versus double SHA256).

		The initial packet sequence numbers are 0.


		Encrypted messages do not have the 4byte network magic.

		The maximum message size is 2^23 (8,388,608) bytes. Future communication MAY exceed this limit and thus MUST be split into different messages.


		Peers calculate the counterparty limits and MUST disconnect immediately if a violation of the limits has been detected.

		=== Test Vectors ===

WIP [don't merge] Add BIP324 - Version 2 Peer-to-Peer Message Transport Protocol #1024

WIP [don't merge] Add BIP324 - Version 2 Peer-to-Peer Message Transport Protocol #1024

Conversation

jonasschnelli commented Oct 21, 2020

jonatack commented Oct 21, 2020

dr-orlovsky commented Oct 22, 2020

jonasschnelli commented Oct 22, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

luke-jr commented May 5, 2022

michaelfolkson commented May 5, 2022 • edited Loading

dhruv commented May 5, 2022

michaelfolkson commented May 5, 2022 •

edited

Loading