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
Re-opening there is tx-relay work-in-progress available here: https://bitcoinbackbone.org/.
Open comments on #1663 have been fixed.
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
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.
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.