Revert "Don't send 'sendaddrv2' to pre-70016 software" #20800

Now that other software projects can handle sendaddrv2 messages, either by explicitly allowing them or by ignoring unknown messages, the temporary workaround can be removed. See also the mailing list post explaining that addrv2 is not dependent on a p2p protocol version: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-December/018301.html

Some references:

• https://github.com/bitcoin-s/bitcoin-s/pull/2315 (ignores unknown messages)
• https://github.com/bcoin-org/bcoin/blob/master/test/net-test.js#L821(ignores unknown messages)
• https://github.com/btcsuite/btcd/pull/1670 (explicit support for sendaddrv2)

Please don't merge until the above mentioned software projects issues a release.

This saves one line of code and at best does nothing, but more likely introduces spurious incompatibilities with existing deployed software.

Keeping it will create spurious incompatibilities with to-be-deployed software that implements according to the BIP. If the goal is to keep this workaround permanently, it might be good to propose an update to the BIP first. I don't want to decide what the BIP should say, but I think that Bitcoin Core should generally follow the BIP specification.

I don't think there's any rush to do this. We can live with this exception to the BIP for a couple of years and then revert.

Please don't merge until the above mentioned software projects issues a release.

We should wait some time after they issue a release. There may be unupgraded nodes from those projects for some time. Probably not many, but we should avoid breaking compatibility with those unnecessarily.

I agree with greater conservatism (e.g. a couple of years) on when to revert.

If the goal is to keep this workaround permanently

The goal isn't for a permanent workaround, it is for a temporary workaround. But I agree this could be communicated temporarily on the BIP to avoid the problems with future implementations of the BIP you talk about @MarcoFalke.

But I agree this could be communicated temporarily on the BIP to avoid the problems with future implementations of the BIP you talk about @MarcoFalke.

If you think this is the right way to go I'm happy to open a PR on the BIP.

@MarcoFalke My thinking here was that it could also wait a few years, depending on network developments. As far as I can see, this doesn't make Bitcoin Core incompatible with the BIP - it's just choosing in some cases to not opt into an optional feature (based on a heuristic to guess that the other side doesn't understand it anyway). If clients on the network appear that want BIP155 but somehow don't want to increment the protocol version, that would be a good reason to revert this.

Ok, let's revisit in 2022 or so