From: <eric@voskuil.org>
To: "'Anthony Towns'" <aj@erisian.com.au>
Cc: 'Bitcoin Protocol Discussion' <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Packaged Transaction Relay
Date: Wed, 5 Oct 2022 21:32:29 -0700 [thread overview]
Message-ID: <040f01d8d93c$a58c2540$f0a46fc0$@voskuil.org> (raw)
In-Reply-To: <03ca01d8d8fb$1558ed50$400ac7f0$@voskuil.org>
>> ...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
next prev parent reply other threads:[~2022-10-06 4:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-05 20:43 [bitcoin-dev] Packaged Transaction Relay Eric Voskuil
2022-10-06 4:32 ` eric [this message]
2022-10-07 6:31 ` Anthony Towns
2022-10-08 19:58 ` eric
2022-10-09 5:52 ` Anthony Towns
2022-10-09 7:00 ` eric
2022-10-09 13:27 ` Anthony Towns
2022-10-10 22:05 ` eric
[not found] <A485FF21-3B14-49B4-BC53-99AFAA90E38D@voskuil.org>
2022-09-27 19:21 ` Eric Voskuil
-- strict thread matches above, loose matches on Subject: below --
2022-06-08 22:43 eric
2022-09-26 17:50 ` alicexbt
2022-09-26 21:19 ` eric
2022-09-27 9:29 ` alicexbt
2022-10-04 15:15 ` Suhas Daftuar
2022-10-05 0:01 ` eric
2022-10-05 6:55 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='040f01d8d93c$a58c2540$f0a46fc0$@voskuil.org' \
--to=eric@voskuil.org \
--cc=aj@erisian.com.au \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox