Add bip-txrelayv2
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
@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.
Updated at 143c993 with improvements on the BIP.
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`).
Shared an email on the mailing list this day to give an update on this BIP.
Mainly recalling the 3 problems that it wish to improve on:
- transaction-relay as DoS vector
- transaction-propagation deanonymization vector
- transaction-relay throughput overflow attacks on contracting protocols
Hello @ariard, this PR has had unaddressed review comments for over nine months. Are you still working on this?
Hello @ariard, this PR has had unaddressed review comments for over nine months. Are you still working on this?
Yes re-implementing my own node in rust(https://bitcoinbackbone.org/). While not there yet on the transaction-relay stuff, I do intend to implement tx-relay v2 in it. So I’ll address the review comments at some point.
Closing this for now, as it has had unaddressed feedback for over 11 months and is not expected to make any progress until an undetermined time in the future. Please feel free to request for this pull request to be reopened or open a new PR when this proposal is closer to ready for publication and more actively developed.
and is not expected to make any progress until an undetermined time in the future.
This is a presumptuous and gratuitous statement, which actually does not level-up the technical discussion.