Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add bip-txrelayv2 #1663

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

Add bip-txrelayv2 #1663

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
143c993
Add bip-txrelayv2
ariard Sep 5, 2024
2a0842b
Add SHOULD support BIP324
ariard Sep 13, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 51 additions & 0 deletions bip-txrelayv2.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
<pre>
BIP: XXX
Layer: Peer Services
Title: Transaction Relay V2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Author: Antoine Riard <[email protected]>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0XXX
Status: Draft
Type: Standards Track
Created: 2024-09-05
License: GPLv2
</pre>

==Abstract==

This BIP proposes a new Bitcoin transaction relay protocol by introducing new
signaling support, which can be further used by nodes to negotiate new transaction
relay mechanisms and policies.

==Motivation==

Historically, upgrades to the transaction relay protocols have been down by updating
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

the protocol version number, and upgraded peers expecting support for new p2p messages
processing or alteration in current processing of p2p messages from equivalently upgraded
peers.

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

Check warning on line 27 in bip-txrelayv2.mediawiki

View workflow job for this annotation

GitHub Actions / Typo Checks 

"sanctionned" should be "sanctioned".
Copy link
Member

@jonatack jonatack Sep 6, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

by an upgraded peer at the peering level by a disconnection of the violating non-upgraded peers.
Non-upgraded peers and clients can see their transaction broadcast silently failing for a subset
of theirs opened connections.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
of theirs opened connections.
of their open connections.


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

@jonatack jonatack Sep 6, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

node service bit to signal support for a new v2 transaction relay protocol. Within this protocol,
nodes can negotiate new transaction relay mechanisms and policies.

==Specification==

Peers supporting the v2 transaction relay protocol signal support by adverstising
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

the 13th bit service flag in the addr p2p messages (`ADDR` and `ADDRV2`).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


==Backward compatibility==

Older clients remain fully compatible and interoperable after this change.
Comment on lines +44 to +46
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


==Implementation==

https://github.com/bitcoin/bitcoin/pull/30572

==Copyright==

This BIP is licensed under the GPLv2.
Loading