Disallow certain message types under BIP324 v2 transport

[dergoegge]

V2 transport presents a unique opportunity to disallow a couple p2p messages that we can't deprecate under v1 given their usage. Of the top of my head, it seems like the following things could be disallowed:

• Bloom filters should not be used and are superseded by client side filtering. filter{add,clear,load}, merkleblock and mempool could therefore be disallowed.
• V1 address relay was superseded by V2 address relay (not to be confused with BIP324 v2 transport). addr could therefore be disallowed.
• getblocks makes very little sense which is why Bitcoin Core no longer sends it. Syncing headers before downloading blocks should always be preferred. getblocks could therefore be disallowed.

This might be too late to squeeze in and would require BIP changes as well but long term it seems worthwhile considering. If we ever get rid of v1 transport we can delete the entire code for the things mentioned above (and maybe more?)!

[fjahr]

Thinking if this would become an issue if we expect other projects to adopt BIP324 via something like BIP324 Proxy. If that were to happen and stay that way mid/long term, I am not sure this is a good idea. Or, on the flipside, if it is a good idea I guess worst case something like BIP324 Proxy becomes infeasible as a quick fix for most projects.

CC @theStack

[sipa]

I think it's far too late to add something like this to do BIP324, and I don't see the benefit really - we need the logic to keep supporting these messages (to the extent they aren't optional like bloom filters) anyway.