eric at voskuil.org [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-06 📝 Original message:>> ...sendaddrv2 messages ...
📅 Original date posted:2022-10-06
📝 Original message:>> ...sendaddrv2 messages are only sent to nodes advertising version 70016 or later (same as wtxidrelay)
> I don’t see this constraint in BIP155. Do you mean that addrv2 support was
> released in Core at the same time as wtxidrelay, or that it is an
> undocumented version constraint implemented in Core?
I see that it is the latter:
// BIP155 defines addrv2 and sendaddrv2 for all protocol versions, but some
// implementations reject messages they don't know. As a courtesy, don't send
// it to nodes with a version before 70016, as no software is known to support
// BIP155 that doesn't announce at least that protocol version number.
https://github.com/bitcoin/bitcoin/pull/20564/files#diff-6875de769e90cec84d2e8a9c1b962cdbcda44d870d42e4215827e599e11e90e3R2366-R2370
The version string in the log message I posted implies it may not be a Core release. Yet it is BIP155 compliant.
Protocol cannot be defined on an ad-hoc basis as a "courtesy" - and it's not exactly a courtesy to keep yourself from getting dropped by peers. It is not clear to me why such a comment would be accepted instead of specifying this properly. A new protocol cannot define a message for "all versions", it can only assume that older versions will disregard all unknown message traffic - or that implementers will patch it in this ad-hoc matter.
I would suggest that authors update BIP155 and BIP330 (both still in Draft status), as well any pending proposals that may have picked up this pattern from BIP155.
I doubt that anyone who's worked with it is terribly fond of Bitcoin's P2P protocol versioning. I've spent some time on a proposal to update it, though it hasn't been a priority. If anyone is interested in collaborating on it please contact me directly.
e
📝 Original message:>> ...sendaddrv2 messages are only sent to nodes advertising version 70016 or later (same as wtxidrelay)
> I don’t see this constraint in BIP155. Do you mean that addrv2 support was
> released in Core at the same time as wtxidrelay, or that it is an
> undocumented version constraint implemented in Core?
I see that it is the latter:
// BIP155 defines addrv2 and sendaddrv2 for all protocol versions, but some
// implementations reject messages they don't know. As a courtesy, don't send
// it to nodes with a version before 70016, as no software is known to support
// BIP155 that doesn't announce at least that protocol version number.
https://github.com/bitcoin/bitcoin/pull/20564/files#diff-6875de769e90cec84d2e8a9c1b962cdbcda44d870d42e4215827e599e11e90e3R2366-R2370
The version string in the log message I posted implies it may not be a Core release. Yet it is BIP155 compliant.
Protocol cannot be defined on an ad-hoc basis as a "courtesy" - and it's not exactly a courtesy to keep yourself from getting dropped by peers. It is not clear to me why such a comment would be accepted instead of specifying this properly. A new protocol cannot define a message for "all versions", it can only assume that older versions will disregard all unknown message traffic - or that implementers will patch it in this ad-hoc matter.
I would suggest that authors update BIP155 and BIP330 (both still in Draft status), as well any pending proposals that may have picked up this pattern from BIP155.
I doubt that anyone who's worked with it is terribly fond of Bitcoin's P2P protocol versioning. I've spent some time on a proposal to update it, though it hasn't been a priority. If anyone is interested in collaborating on it please contact me directly.
e