From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 01 Mar 2026 10:13:51 -0800 Received: from mail-ot1-f55.google.com ([209.85.210.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vwlIb-0000IB-PB for bitcoindev@gnusha.org; Sun, 01 Mar 2026 10:13:50 -0800 Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-7d1936b8a7csf42773910a34.3 for ; Sun, 01 Mar 2026 10:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1772388823; x=1772993623; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=PzuhMwWoKnWbmfAkXm87C6LLcbnbePQEqOPnkLRG+v4=; b=GKfG0mDOuQjdGFMK9F8BesqzOGhiYvxq6nklG4H/lm4HIsOtaP8sazxbV+zjDxTrdu EoKfNxPAHFDjQvFyReCwiwn5sPEobq9FbreDJtmhN5CfPr5VVWQpK9iZclzyAq7mRglU b9rDJjTe9jwlTVzyFGXvWcwcA4YT9jVImhXZ1LehLhrh09Taz/dpWNttyQwMALbQWZI5 zx/JoaFTt8o5D7Gb+C9Hu9rPP8WSX8SMxTIeU3i2fHGARSFpBayroT5zb6oBUf3MFooE oREyhoApefAY0/Y0svTwDSwnp1RESICdyjFFH2bspTghsYB3IsCRmP0FgI/a2WkUhY3v k/Yw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772388823; x=1772993623; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=PzuhMwWoKnWbmfAkXm87C6LLcbnbePQEqOPnkLRG+v4=; b=dtFO5I2H4eLzuufrdjmNZEWcYH7vml1zfPD7CnR3vhs1h4BD9B9Yyew/CcIciu+ecL U8DBxdg9dyLeZ/Q6fj5wkQPIS0aYfMrE/33Ax0fIEvVcw1hZXMMbtrXweQ+6liJv6c95 d1mT1YXZF+bFFV7XU1x7WeaHgig/O4AXwXppIxyufzXlxhOpCicdyJxm3dZIn+b/ad3q PPO4X7KBdKpzuL8uN45PSOL/simit9NnafQMKdkEjpAWR8RSZeklEO+aVNbt/4UNOJzW ASxAPB4GDexoQJIVxoH1BbTagH0oKLmxq3vEs0N7U+CfLnF7gMEbZSezhliG0yMFU6uw F6mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772388823; x=1772993623; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=PzuhMwWoKnWbmfAkXm87C6LLcbnbePQEqOPnkLRG+v4=; b=B65uIXmyv/dfXUK617Ln80AYt/97apgn5fbf6AYnIgV4bP0hvGHIXj9YysyPMHEHLL 8TJ8w48bQT+XSqMGF9hF70S8CV4qotNxQW5ZVE65okvsMsrXOfMKgfnh2PUxTn126UOR D58VGP7j1YW0y4mdc31jwwS0f7m4A31kzt9K5cAReFUQ31xgHzI9GXcE7L9oh+CN7S69 LHi+X5hKJEF1b+nUUThMuVCkiP5+4hLOfUeNEFFEzfw3VJas+JiWx/cBD6GUNfpRFXbG HHsNFu1AVNnW5qafcd0FUp4v8mCbnscIKigKyzEjs4E+xTW+of7idLVJdWb4zq8Jte6e 9mAQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXcHO4AidWMEnOc50YS0xXljOjQA4JGqbw2emoVXUK1jDQkJ+nO+Z1St3uJ1jvwoMsxgVRbovbCpVNK@gnusha.org X-Gm-Message-State: AOJu0YyDuvqUxYpQ1u03w6KTXdtF9ZGjm06YIPJ321g2MVxfWF9UpSYY suEtOqV6IrS+EFZXRPoUaOJGjCJqkjEW+zGU6z1M5MWI16Ek4wj45Kl8 X-Received: by 2002:a05:6870:ad08:b0:40e:e78d:b238 with SMTP id 586e51a60fabf-41626e168c4mr5001255fac.18.1772388823548; Sun, 01 Mar 2026 10:13:43 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HRy38ignUzzb/4OWzCWCl/Ph9Mm8H/OzwSvTNEsV0kOg==" Received: by 2002:a05:6871:28a5:b0:416:1b5c:16df with SMTP id 586e51a60fabf-4161b5c1ce5ls1937227fac.2.-pod-prod-08-us; Sun, 01 Mar 2026 10:13:37 -0800 (PST) X-Received: by 2002:a05:6808:c226:b0:45e:b6a4:fec1 with SMTP id 5614622812f47-464beb5dc96mr4915548b6e.37.1772388816884; Sun, 01 Mar 2026 10:13:36 -0800 (PST) Received: by 2002:a05:690c:e30f:b0:796:d04e:652b with SMTP id 00721157ae682-7988644115bms7b3; Sun, 1 Mar 2026 10:06:21 -0800 (PST) X-Received: by 2002:a05:690c:1a:b0:796:6df5:4840 with SMTP id 00721157ae682-7988563810dmr83201597b3.59.1772388381052; Sun, 01 Mar 2026 10:06:21 -0800 (PST) Date: Sun, 1 Mar 2026 10:06:20 -0800 (PST) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <6783db94-fbbd-4df8-b05f-639fa3ace6f1n@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: [BIP Proposal] Peer Feature Negotiation MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_410800_1757015449.1772388380642" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_410800_1757015449.1772388380642 Content-Type: multipart/alternative; boundary="----=_Part_410801_1447241904.1772388380642" ------=_Part_410801_1447241904.1772388380642 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 Hello AJ, I had finally a read on your BIP434 proposal, and here few=20 thoughts on the design and the novel processing rules proposed. I'm=20 thinking that one drawback with the multiple feature / signaling messages= =20 approach compared to the fixed-size length verack payload comes with the=20 novel feature messages becoming a novel if not a least a vector of=20 denial-of-service, at least some vector of annoyance. One peer can always= =20 throw a number of `feature` message only bounded by the 80^2 information=20 space of the `featureid` string length. If if I'm understanding correctly= =20 your proposal, this would be an acceptable valid behavior and this raises= =20 the question, if incidentally peers do not have to agree on dos-limit even= =20 for feature negotiation, that is moving us away from the "permissionlessly= =20 goal" you're laying out. I don't think there is an easy or obvious answer= =20 to this issue, other than introducing a verack negotiation timeout (with=20 all the frictions of the lack of an easy to use coordinated clock among=20 peers...). I do see the idea with that it's indeed allowing some form of=20 interactive feature negotiation, where one peer can always make the=20 announcement of feature_XYZ conditional on the previous announcement of=20 feature_ABC, which is also possible with verack payload by reconnecting /= =20 disconnecting. I don't think we should consider connect / reconnect as=20 free, as even if you're a peer doing legit interactive feature negotiation= =20 there might be friction with the underlying socket eviction logic (i.e for= =20 bitcoin core `SelectNodeToEvict()`). This is unclear from the=20 "Considerations" of your proposal if it's taking the position that=20 interactive feature negotation is either a valuable or not mechanism to=20 have at the p2p protocol-level. Personally, I'm thinking it's interesting= =20 to have as it would enable deployment of complex feature tier by tier where= =20 you're using the messages of feature_ABC as direct messages in the flow of= =20 feature_XYZ, and it does bring some flexibility in the network deployment= =20 of said features. One last high level remark, I'm wondering if the protocol= =20 versioning shouldn't be "frozen" in itself, and reserved solely for=20 signaling changes in the "peer feature negotiation" mechanism (or the usage= =20 of the service bits ?). More low level remarks on some BIP proposed=20 processing rules in itself: - the BIP is silent on unknown messages=20 received before `version` reception - same if a recipient MAY disconnect a= =20 peer if unsupported messages received post-verack - imho would be better to= =20 canonically define namespace section "...be a globally unique id..." - the= =20 re-interpretation of BIP324 messages as `feature` sounds gross, already the= =20 service bit While the proposal might appear as over-engineered, I don't=20 think otherwise, though it would won to laid out better the design=20 trade-off compared to verack in the "Considerations" section, and=20 potentially to define more if the service bit can be indifferently use to= =20 signal feature, without going through the explicit feature negotiation=20 mechanism. If I have misunderstood some aspect of your BIP proposal, please= =20 let me know. Best, Antoine OTS hash:=20 2a9215d42ee79a30ccc31b3410f74ab486d99f99408ad705b244d0dd8822ce53 Le Friday, December 19, 2025 =C3=A0 11:35:52=E2=80=AFAM UTC, Anthony Towns = a =C3=A9crit : > Hello world, > > I've been thinking recently about a few ideas that would benefit > from new p2p messages, namely template sharing [0], updating the > bip324-one-byte-message-types [1], and sharing recent stale blocks [2]. > That's made me want to make sure that we've got a good way of negotiating > new features, and revisiting the ideas from the 2020 thread [3] has me > still liking the "FEATURE" message idea [4]. > > As such, and with Ava's recent exhortation that everyone should be > writing BIPs [5] in mind, I've written a BIP: > > > https://github.com/ajtowns/bips/blob/202512-p2p-feature/bip-peer-feature-= negotiation.md > > Sample code, though that part isn't really very interesting: > > > https://github.com/ajtowns/bitcoin/commit/80301f0040fe6048a85b89d0fdf0ffc= ca836a1d0 > > The BIP is perhaps a bit over-engineered at this point for what it does, > but I figure better to be over-engineered than under-. And in any event, > there was some degree of breakage with the SENDADDRV2's deployment [6,7] > which would be good to avoid repeating. In any event, the BIP text has > a bunch more background, etc. > > Comments welcome. > > Cheers, > aj > > [0] https://github.com/bitcoin/bitcoin/issues/33691 > > [1] https://github.com/bitcoin/bips/pull/1378#discussion_r2585766526 > > [2] https://github.com/bitcoin-data/stale-blocks > The idea behind sharing stale blocks (or headers) more proactively, > is it better insight into the orphan rate, and whether hashrate > is extending the chain vs potentially creating a reorg; and also > potentially makes syncing to the new tip after a reorgs more > efficient, as you'll have already downloaded the parent of the new tip > > [3]=20 > https://gnusha.org/pi/bitcoindev/CAFp6fsE=3DHPFUMFhyuZkroBO_QJ-dUWNJqCPg9= =3DfMJ3Jq...@mail.gmail.com/=20 > > > [4] https://gnusha.org/pi/bitcoindev/20200821023647....@erisian.com.au/= =20 > > > [5] https://x.com/btcplusplus/status/2000489894515253529 > > [6] https://github.com/btcsuite/btcd/issues/1661 > > [7] https://github.com/bitcoin/bitcoin/pull/20564 > > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 6783db94-fbbd-4df8-b05f-639fa3ace6f1n%40googlegroups.com. ------=_Part_410801_1447241904.1772388380642 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello AJ, I had finally a read on your BIP434 proposal, and here few thoughts on the design and the novel processing rules proposed. I'm thinking that one drawback with the multiple feature / signaling messag= es approach compared to the fixed-size length verack payload comes with the no= vel feature messages becoming a novel if not a least a vector of denial-of-serv= ice, at least some vector of annoyance. One peer can always throw a number of `f= eature` message only bounded by the 80^2 information space of the `featureid` strin= g length. If if I'm understanding correctly your proposal, this would be an acceptabl= e valid=20 behavior and this raises the question, if incidentally peers do not have to= agree on dos-limit even for feature negotiation, that is moving us away from the "permissionlessly goal" you're laying out. I don't think there is an easy o= r obvious answer to this issue, other than introducing a verack negotiation timeout (= with all the frictions of the lack of an easy to use coordinated clock among peers..= .). I do see the idea with that it's indeed allowing some form of interactive f= eature negotiation, where one peer can always make the announcement of feature_XYZ= conditional on the previous announcement of feature_ABC, which is also possible with ve= rack payload by reconnecting / disconnecting. I don't think we should consider c= onnect / reconnect as free, as even if you're a peer doing legit interactive feature= negotiation there might be friction with the underlying socket eviction logic (i.e for = bitcoin core `SelectNodeToEvict()`). This is unclear from the "Considerations" of your proposal if it's taking t= he position that interactive feature negotation is either a valuable or not mechanism t= o have at the p2p protocol-level. Personally, I'm thinking it's interesting to have a= s it would enable deployment of complex feature tier by tier where you're using the me= ssages of feature_ABC as direct messages in the flow of feature_XYZ, and it does brin= g some flexibility in the network deployment of said features. One last high level remark, I'm wondering if the protocol versioning should= n't be "frozen" in itself, and reserved solely for signaling changes in the "peer = feature negotiation" mechanism (or the usage of the service bits ?). More low level remarks on some BIP proposed processing rules in itself: - the BIP is silent on unknown messages received before `version` reception - same if a recipient MAY disconnect a peer if unsupported messages receive= d post-verack - imho would be better to canonically define namespace section "...be a glo= bally unique id..." - the re-interpretation of BIP324 messages as `feature` sounds gross, alrea= dy the service bit While the proposal might appear as over-engineered, I don't think otherwise= , though it would won to laid out better the design trade-off compared to verack in = the "Considerations" section, and potentially to define more if the service bit can be indiffere= ntly use to signal feature, without going through the explicit feature negotiation mechanism. If I have misunderstood some aspect of your BIP proposal, please let me kno= w. Best, Antoine OTS hash: 2a9215d42ee79a30ccc31b3410f74ab486d99f99408ad705b244d0dd8822ce53<= /span>

Le Friday, December 19, 2025 =C3=A0 11:35:52=E2=80=AFAM UTC, Anthony Towns= a =C3=A9crit=C2=A0:
Hello world,

I've been thinking recently about a few ideas that would benefit
from new p2p messages, namely template sharing [0], updating the
bip324-one-byte-message-types [1], and sharing recent stale blocks [2].
That's made me want to make sure that we've got a good way of n= egotiating
new features, and revisiting the ideas from the 2020 thread [3] has me
still liking the "FEATURE" message idea [4].

As such, and with Ava's recent exhortation that everyone should be
writing BIPs [5] in mind, I've written a BIP:

https://github.com/ajtowns/bips/blob/202512-p2p-feature/bip-peer-fe= ature-negotiation.md

Sample code, though that part isn't really very interesting:

ht= tps://github.com/ajtowns/bitcoin/commit/80301f0040fe6048a85b89d0fdf0ffcca83= 6a1d0

The BIP is perhaps a bit over-engineered at this point for what it does= ,
but I figure better to be over-engineered than under-. And in any event= ,
there was some degree of breakage with the SENDADDRV2's deployment = [6,7]
which would be good to avoid repeating. In any event, the BIP text has
a bunch more background, etc.

Comments welcome.

Cheers,
aj

[0] https://github.com/bitcoin/bitcoin/issues/33691

[1] https://github.com/bitcoin/bips/= pull/1378#discussion_r2585766526

[2] https://github.com/bitcoin-data/stale-blocks
The idea behind sharing stale blocks (or headers) more proactively,
is it better insight into the orphan rate, and whether hashrate
is extending the chain vs potentially creating a reorg; and also
potentially makes syncing to the new tip after a reorgs more
efficient, as you'll have already downloaded the parent of the = new tip

[3] https://gnusha.org/pi/bitcoin= dev/CAFp6fsE=3DHPFUMFhyuZkroBO_QJ-dUWNJqCPg9=3DfMJ3Jq...@mail.gmail.com/

[4] ht= tps://gnusha.org/pi/bitcoindev/20200821023647....@erisian.com.au/

[5] https://x.com/btcplusplus/status/2000489894515253529

[6] https://github.com/btcsuite/btcd/issues/1661

[7] https://github.com/bitcoin/bitcoin/pull/20564

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/6783db94-fbbd-4df8-b05f-639fa3ace6f1n%40googlegroups.com.
------=_Part_410801_1447241904.1772388380642-- ------=_Part_410800_1757015449.1772388380642--