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: https://github.com/bitcoin/bitcoin/pull/30572
0@@ -0,0 +1,49 @@
1+<pre>
2+ BIP: XXX
3+ Layer: Peer Services
4+ Title: Transaction Relay V2
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).
0@@ -0,0 +1,49 @@
1+<pre>
2+ BIP: XXX
3+ Layer: Peer Services
4+ Title: Transaction Relay V2
5+ Author: Antoine Riard <btc@ariard.me>
6+ Comments-Summary: No comments yet.
7+ Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0339
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.
32+transaction relay mechanisms and policies.
33+
34+==Specification==
35+
36+Peers supporting the v2 transaction relay protocol signal support by adverstising
37+the 13th bit service flag in the addr p2p messages (`ADDR` and `ADDRV2`).
36+Peers supporting the v2 transaction relay protocol signal support by adverstising
37+the 13th bit service flag in the addr p2p messages (`ADDR` and `ADDRV2`).
38+
39+==Backward compatibility==
40+
41+Older clients remain fully compatible and interoperable after this change.
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.
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.
22+Historically, upgrades to the transaction relay protocols have been down by updating
23+the protocol version number, and upgraded peers expecting support for new p2p messages
24+processing or alteration in current processing of p2p messages from equivalently upgraded
25+peers.
26+
27+This upgrade mechanism raise issues if new processing of current p2p messages is sanctionned
Nice to see the new typos CI working (edit: though it doesn’t seem to catch everything, hm)
0This 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)
17+signaling support, which can be further used by nodes to negotiate new transaction
18+relay mechanisms and policies.
19+
20+==Motivation==
21+
22+Historically, upgrades to the transaction relay protocols have been down by updating
0Historically, upgrades to the transaction relay protocols have been done by updating
25+peers.
26+
27+This upgrade mechanism raise issues if new processing of current p2p messages is sanctionned
28+by an upgraded peer at the peering level by a disconnection of the violating non-upgraded peers.
29+Non-upgraded peers and clients can see their transaction broadcast silently failing for a subset
30+of theirs opened connections.
0of their open connections.
27+This upgrade mechanism raise issues if new processing of current p2p messages is sanctionned
28+by an upgraded peer at the peering level by a disconnection of the violating non-upgraded peers.
29+Non-upgraded peers and clients can see their transaction broadcast silently failing for a subset
30+of theirs opened connections.
31+
32+We can improve current upgrade mechanism of the transaction relay protocol by introducing a new
0We can improve the current upgrade mechanism of the transaction relay protocol by introducing a
missing “the”, and “introducing” implies new
33+node service bit to signal support for a new v2 transaction relay protocol. Within this protocol,
34+nodes can negotiate new transaction relay mechanisms and policies.
35+
36+==Specification==
37+
38+Peers supporting the v2 transaction relay protocol signal support by adverstising
0Peers supporting the v2 transaction relay protocol signal support by advertising
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.
0 ==Specification==
1
2+Peers supporting the v2 transaction relay protocol SHOULD support the Version 2 P2P Encrypted
3+Transport Protocol as specified by BIP324.
4+
5 Peers supporting the v2 transaction relay protocol signal support by adverstising
6 the 13th bit service flag in the addr p2p messages (`ADDR` and `ADDRV2`).
