Add bip-txrelayv2

[ariard]

If we find a better way to implement reject unrequested transactions in a backward compatible fashion, I’ll withdraw it.

ML post: https://groups.google.com/g/bitcoindev/c/nWUcXBQbLGU
Bitcoin Core conceptual discussion: bitcoin/bitcoin#30572

[murchandamus]

Hi @ariard, I was not able to find messages pertaining to this BIP draft on the mailing list. Has this draft been posted to the mailing list?

After a quick read, this document seems to be an early draft. We recommend that BIP authors open an initial pull request against their personal BIPs repository while they are collecting their thoughts and iterating quickly by themselves, and only open a pull request against the main repository after they have shared their proposal with the mailing list and are seeking public review.

[murchandamus]

Could you perhaps reconsider the title? This sounds somewhat similar to the v2 P2P protocol that was recently deployed. Maybe something along the lines of "Behavior regarding unsolicited Transactions", if I’m getting the gist of what you are thinking about?

[ariard]

This is intentional to be similar to BIP24 and the upgrade of the V2 P2P protocol. Before the BIP design and implementation, the peer-to-peer protocol was not versioned, neither really encrypted. Similarly, we’re introducing a versioning of the transaction-relay protocol, which a node can use to selectively support policies and mechanisms.

[jonatack]

I agree that this naming can be easily confused with v2 p2p and v3 transaction relay; differentiated naming would be beneficial.

[ariard]

I agree that this naming can be easily confused with v2 p2p and v3 transaction relay; differentiated naming would be beneficial.

I’ll let you come with a better name, v2 p2p is the 2nd version of the p2p protocol, of which technically this transaction relay v2 protocol should lay on top. v3 transaction relay if you mean the TRUC thing it’s about the transaction versioning (the nVersion transaction field).

[murchandamus]

Suggested change

Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0339

[ariard]

Corrected with BIP-0XXX, in my memory bip339 is the oldest bip related to p2p tx-relay upgrade (as bip338 was never implemented and deployed). So I copy past bip layout from it.

[murchandamus]

The Specification seems to define how to advertise a new network service, but it should perhaps elaborate what this service entails.

[ariard]

No, it’s intentional. The mechanisms and policies supported should be described in a distinct BIP, e.g if some class of messages are disabled like it was proposed by BIP338, which is a distinct mechanism than behavior regarding unsolicited transactions.

[murchandamus]

Please be sure to include sufficient detail in the spec or compatibility section to explain why this is the case.

[ariard]

This is the case - Earliest version behavior can be applied on the linked implementation code is bitcoin core 29.0.

[ariard]

@murchandamus

Hi @ariard, I was not able to find messages pertaining to this BIP draft on the mailing list. Has this draft been posted to the mailing list?

An email should have been sent linking this BIP draft to the bitcoin dev mail list.

After a quick read, this document seems to be an early draft. We recommend that BIP authors open an initial pull request
against their personal BIPs repository while they are collecting their thoughts and iterating quickly by themselves, and only > open a pull request against the main repository after they have shared their proposal with the mailing list and are seeking
public review.

My “offensive” self and my “defensive” self after carefully weighing the technical trade-offs have dialogued for long enough and they have come to consensus that this BIP was ready for more review :) I’m seeking public review.

[ariard]

Updated at 143c993 with improvements on the BIP.

[jonatack]

Nice to see the new typos CI working (edit: though it doesn't seem to catch everything, hm)

Suggested change

	This upgrade mechanism raise issues if new processing of current p2p messages is sanctionned
	This upgrade mechanism raise issues if new processing of current p2p messages is sanctioned

(you can run it locally by installing https://github.com/crate-ci/typos and then running typos in repo root)

[jonatack]

Suggested change

	Historically, upgrades to the transaction relay protocols have been down by updating
	Historically, upgrades to the transaction relay protocols have been done by updating

[jonatack]

Suggested change

	of theirs opened connections.
	of their open connections.

[jonatack]

Suggested change

	We can improve current upgrade mechanism of the transaction relay protocol by introducing a new
	We can improve the current upgrade mechanism of the transaction relay protocol by introducing a

missing "the", and "introducing" implies new

[jonatack]

Suggested change

	Peers supporting the v2 transaction relay protocol signal support by adverstising
	Peers supporting the v2 transaction relay protocol signal support by advertising

[ariard]

Updated at 2a0842b.

From reading Jon’s comment on the naming issue, and after brainstorming with myself alone, as this BIP can be used to introducing more compartmentalization in the p2p messages (transactions, blocks, addr, etc), it is good to make explicit which version of the p2p protocol, this compartmentalization is building on.

With BIP324 we have a versioning of the protocol, so it can be requested that NODE_TXRELAY_V2 implies support for NODE_P2P_V2.

 ==Specification==
 
+Peers supporting the v2 transaction relay protocol SHOULD support the Version 2 P2P Encrypted
+Transport Protocol as specified by BIP324.
+
 Peers supporting the v2 transaction relay protocol signal support by adverstising
 the 13th bit service flag in the addr p2p messages (`ADDR` and `ADDRV2`).