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

Re-opening there is tx-relay work-in-progress available here: https://bitcoinbackbone.org/.

Open comments on #1663 have been fixed.

[ariard]

By the way I have a question about the BIPs, and not sure where to ask.

I’m on re-implementing BIP324 in backbone and in my humble opinion there are some sections that could be more well-defined or clarified not only in pseudo-code (e.g around FSChaCha20Poly1305 and FSChaCha20), i.e adding precise typing, use more strict cryptographic vocabulary sometimes, etc.

When I have a list of erratas and suggestions ready to submit, what should be the process, like I’m opening a pull request for review ? There are not technical changes per se, more clarifying the vocabulary for re-implementators and ease the work there. cc @jonatack @murchandamus

[jonatack]

When I have a list of erratas and suggestions ready to submit, what should be the process, like I’m opening a pull request for review ?

Hi @ariard, yes, open a pull request to this repository.

[ariard]

Hi @ariard, yes, open a pull request to this repository.

Okay not forgetting that. Shared more code on my BIP324 implementation in Backbone yesterday (https://bitcoinbackbone.org/ — commit 378dcb7590) Next development cycle is more focus on the transaction-relay stack in Backbone. So I’ll update that BIP proposal in consequence when it’s ready, soon.

[ariard]

Shared an update on txrelayv2 here: https://groups.google.com/g/bitcoindev/c/zD0hNBVrsk0

To be frank, the technical support for txrelayv2 is easy in itself. I’m still thinking if there are other things to indicate in the BIP e.g how it interacts with Erlay (same than classic tx-sync, reject it but I want to see how it works with tx-announcement management, i.e the flows deal by TxRequestTracker in core). I think I’ll propose a ready for review version of the BIP when I have also code for Erlay support in backbone.

I have notes for BIP324 too. I’m still finishing some bits of my BIP324 implementation, I’ll share them when it’s done.

[jonatack]

Thanks for the update. Converted to draft -- please ping here when ready for review.

[murchandamus]

Closed for lack of activity. Please open a new PR or request to reopen this PR when a proposal is under active development.

[ariard]

Closed for lack of activity. Please open a new PR or request to reopen this PR when a proposal is under active development.

@murchandamus Seeing that only now, while I was searching for other stuff. Let’s take e.g #1489 an old one still open. Latest comment on this pull request is dated 22 November 2024. Latest comment on the current pull request was dated November 19 2025.

The proposal on this pull request is dated 19 November 2025.

There is tx-relay code that has been tested partially against bitcoin core tx-relay, with code available at bitcoinbackbone.org.

                                        NetworkMessage::Tx(tx) => {
                                                if tx_stack_settings.enable_txrelay_v2 {
                                                        let txid = tx.compute_txid();
                                                        if let Ok(mut txn_known_lock) = txn_known.lock() {
                                                                let is_asked = txn_known_lock.txid_known.get(&txid).is_some();
                                                                if is_asked { /* TODO: disconnect peer */ };
                                                        }
                                                }
                                                tx_sender.send(tx.clone());
                                        }
                                        _ => {

This is unclear under which objective criterias the call to close this pull request has been made…?