From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 13 Nov 2026 08:28:35 -0800 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xRu8f-000RJc-Ua for bitcoindev@gnusha.org; Fri, 13 Nov 2026 08:28:35 -0800 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-45a07949855sf1504428fac.2 for ; Fri, 13 Nov 2026 08:28:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20260707; t=1794587308; x=1795192108; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=vMTh9PgCHDLl+9Hj11dTwqAPFx++f8gRgLKcFD92vRU=; b=r5cNmp7HovNoayibvrcIE1pFUiYWn3mJrlEDhpnyQJF7AGwT/QhnKuHHLuO5Jyd82h YZx7BDHjMMCyxZqvkHxlPvpTFAU30USOgiemkG6xI/cPz8nasPD4ifpqfVJL+s4eCftd Vykr4nR1uISu/Dohpqu7f+kIaCJTs5tOs01Z8t+pXi+O+QPzM+KbqPd5c24sp8WQecqc S8vd8DfAv+/+k1txbbSx6ce8cM5XA9F1ciUpZ0QcZeaI2QDtK+ax9AmLeI17PfSGRPDw 2tCDQHokHTGJ+y7HB5djRAcx5lWQw9HD66VkGHxbp7BYXIVtKbVYFkA8r98vNGLBRvFm VJnA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1794587308; x=1795192108; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=vMTh9PgCHDLl+9Hj11dTwqAPFx++f8gRgLKcFD92vRU=; b=F9WWdDoqBfOCoOqO4vCaTiFykKWSqBnLdPfUth7xd+zma/le3bc3SFhU0hdSWsSs+z JDymwJ6c2A5H7jn25Okclq7J91exRsqrK7YLmL9eJs1WC+91c4Z79Msb4qsUc1OuCpXK LDLkVZviKhAwAKB5oLTvT+eBVFueVhS8KTHliWOXB7qrgerh9mOiyBj/a8+A4v8V+Fzb 9JB5z4eOCf2b3b/nbRHNw5urtB0B0AcE6daa3qklaUCmyxFu24mTJDWukddEbPQqQ2jX +bs3yqbzamrjdKn9rMzykovLKa3fXAwCNNfB70pq0JhuEwutZLb7Qjun47zox7yf11uC es3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794587308; x=1795192108; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :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:content-type; bh=vMTh9PgCHDLl+9Hj11dTwqAPFx++f8gRgLKcFD92vRU=; b=bydd5wb44X75eUeD3P+pfS1Cd4U7yjdA1exaZl98f9eBc9W1wZziJGqLO6fDRqNjop SgNmoJJa8N2cjW6n+zNUdeB8aO7AWizIl1lw1nfYou2WcT/x7NXXLaf1oMK5IZdMI6vR ZBahdaPoMBiw9dK17v4ax1rAPWHfp7VpCbUrqeJGP0W63JDrB3i/7KN60VtLePzkUViL 37mkFKw+Pf4+YOPZQy9MKhXO91c1dayIH3z3XWOmwU0FrWskCggeBnGVYY4alpjZ3V9h zKvtUReDVKzEAm+8bfiGnsgxtlsrXeWlBIZxxCHs7L73q45uuahbJYfouTh19wnKlM5b EXlQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AL+hErHcoJVQV51/D4cwgYHeT0T/DiOyB+pTamCzfjFITq4zEJe5vEeOowouUyhGQtoNQbtusf8swL+jKRak@gnusha.org X-Gm-Message-State: APuU4Z+1ijNP4ytYUhH3j4wtC9hHc7oK1EaFF+IBd/e+5t3N1C27Reqx 84xloJPmH7SkXk1R6ifQbOXkVpZAYtCv7ZAxvKkEOOhXCmMXvswXpSfU X-Received: by 2002:a05:6871:7b0a:b0:49d:ff8c:205e with SMTP id 586e51a60fabf-4afdf2da638mr2881584fac.29.1794587306241; Fri, 13 Nov 2026 08:28:26 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLde0oEvW6gw9QyGMxJ7j9ROQLfWclN3BmbxdUEE81AHR4Q==" Received: by 2002:a05:687c:2f09:b0:49d:fffa:fcd0 with SMTP id 586e51a60fabf-4afdf02fc20ls1353818fac.2.-pod-prod-05-us; Fri, 13 Nov 2026 08:28:18 -0800 (PST) X-Received: by 2002:a05:6808:c123:b0:4b9:a829:f00e with SMTP id 5614622812f47-56e638a5fafmr2332236b6e.26.1794587297975; Fri, 13 Nov 2026 08:28:17 -0800 (PST) Received: by 2002:a05:690c:13:b0:8ae:b617:7167 with SMTP id 00721157ae682-8b4b0d296e4ms7b3; Fri, 13 Nov 2026 08:23:01 -0800 (PST) X-Received: by 2002:a05:690c:f85:b0:8ae:a0c0:4643 with SMTP id 00721157ae682-8b4aa2e1a6fmr21668797b3.26.1794586980788; Fri, 13 Nov 2026 08:23:00 -0800 (PST) Date: Fri, 13 Nov 2026 08:23:00 -0800 (PST) From: Liam Gilligan To: Bitcoin Development Mailing List Message-Id: <1b45f614-6251-4c79-8297-f880edc07c8bn@googlegroups.com> In-Reply-To: <29174459-1523-4cf8-a20f-5ce1abc302c3n@googlegroups.com> References: <29174459-1523-4cf8-a20f-5ce1abc302c3n@googlegroups.com> Subject: [bitcoindev] Re: [BIP Proposal] Transport Feature Negotiation MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8623_1524814995.1794586980440" X-Original-Sender: liamdgilligan@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_8623_1524814995.1794586980440 Content-Type: multipart/alternative; boundary="----=_Part_8624_169171298.1794586980440" ------=_Part_8624_169171298.1794586980440 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, I've written up this proposal into a draft BIP and made a PR=20 against my fork of the BIPs= =20 repo. I made some decisions about the open questions I left in my previous= =20 post, so I'd love to get some eyes and feedback on this. Looking forward to hear from you, Liam On Thursday, September 17, 2026 at 11:39:28=E2=80=AFPM UTC Liam Gilligan wr= ote: > Hi everyone, > > TL;DR (using Terms and Defs below): In order to support encryption=20 > upgrades and the addition of authentication to P2P, I propose we specify = a=20 > Transport Feature Negotiation protocol, which gives a framework for=20 > modifying the Transport Layer. This makes use of the version packet BIP-3= 24=20 > left unspecified for exactly this purpose, redefining it as a **negotiati= on=20 > packet** which carries the features a node supports. > > ## Terms and Defs > > There are some unfortunately similar names, so I'll lay out some=20 > terminology/definitions in addition to those I made in roasbeef's thread[= 1]. > - **Transport Layer**: The details of how Protocol messages are encoded o= n=20 > wire and what security services[2] are provided during transmission. > - The objects the Transport Layer concerns itself with are **packets**,= =20 > which can contain the Protocol Layer's **messages**. > - A **Transport** is a particular version of the Transport Layer; V1 and= =20 > V2 are the two that exist today. > - **Protocol Layer**: The layer that defines which Bitcoin P2P messages= =20 > and commands are used. > - The objects the Protocol Layer concerns itself with are **messages**,= =20 > which are contained in Transport Layer's **packets**. > - A **Protocol** is a particular version of the Protocol Layer; these are= =20 > the protocol versions carried in the version message, currently up to 700= 17. > - **P2P Handshake**: The exchange between two nodes to ensure they are=20 > using compatible Transports and Protocols. This can simply be called "the= =20 > handshake". It consists of two phases: > - **Transport Phase**: The process in which the Transport is established. > - V1 Transport exchanges no bytes during its Transport Phase. > - V2 Transport's Transport Phase is defined by BIP-324[3]. > - The V2 Transport Phase is terminated by a **version packet**, which is = a=20 > Transport Layer packet which contains no Protocol Layer message. The=20 > version packet will never contain the version message defined below.=20 > BIP-324 leaves its contents unspecified and sends it empty, making it=20 > exactly 20 bytes on the wire. > - A **negotiation packet** is that same packet with its contents=20 > specified. This proposal defines those contents as a list of features; a= =20 > negotiation packet advertising no features is empty, and is therefore a= =20 > version packet. > - **Protocol Phase**: The process in which the Protocol is established. > - This is done through an exchange of messages contained between a=20 > **version message** and a **verack message** (or simply verack). The vera= ck=20 > terminates both the Protocol Phase and the handshake itself. > - As the name suggests, a version message is a Protocol message contained= =20 > within a Transport Layer packet. It will never be contained in the V2=20 > Transport's version packet. > - Note that nodes not complying with BIP-434[4] may attempt modifying the= =20 > Protocol Layer after the verack. > - **Feature**: a modification to the Transport Layer which can be=20 > negotiated -- an encryption upgrade or authentication, for example. A=20 > feature is negotiated when both peers agree to use it, by rules given=20 > below. A feature exists only within the negotiation packet, whose content= s=20 > are a list of features and nothing else, and is identified by a one-byte= =20 > header. BIP-434 uses "feature" for the Protocol Layer equivalent; the two= =20 > never appear in the same packet. > > ## Motivation and Rationale > > As discussed earlier in roasbeef's thread[1], a PQ upgrade to the=20 > Transport is needed. The general consensus from that thread was that a CT= U=20 > solution would be best for this, which means we need a mechanism for=20 > performing such an upgrade. BIP-324 was designed with a future PQ upgrade= =20 > in mind, and left an unspecified version packet specifically to perform i= t,=20 > alongside authentication and other Transport upgrades. > > The version packet seems like a good fit, but is it the only option? Ther= e=20 > are two main alternatives that come to mind: BIP-434 and defining a V3=20 > Transport. > > BIP-434 is a complete P2P negotiation protocol, but is only used for=20 > negotiating which messages are sent and how they encode data. In other=20 > words, BIP-434 is sort of "Protocol Feature Negotiation". But encryption= =20 > and authentication are Transport features, not Protocol features. The=20 > timing is also an issue -- the Protocol Phase of the handshake will take= =20 > place over two separate Transports. > > Defining a V3 Transport by fully replacing the ElligatorSwift ECDH is als= o=20 > an option, but there are some issues with this. First, it wouldn't be a C= TU=20 > path that was (loosely) agreed upon in roasbeef's thread, and instead it= =20 > would be an OSH solution. More concretely, it would require committing to= =20 > one specific PQ KEM right off the bat. In the event that this KEM was=20 > broken or otherwise rejected, it would require a V4 Transport to replace= =20 > it. Negotiating the PQ KEM to use in band allows for modularity and=20 > backwards-compatibility, which is not offered by a V3. > > That leaves in-band negotiation inside V2. Given that a negotiation packe= t=20 > is needed in any case, defining an entirely new one instead of redefining= =20 > the version packet adds overhead and potentially round trips. The version= =20 > packet is existent, unused, and positioned ideally and intentionally for= =20 > this purpose. > > ## Proposed Design > > Transport Feature Negotiation specifies what the negotiation packet=20 > contains: > > ``` > Negotiation Packet Contents: > ------------------------------------- > | Feature | Feature | ... | Feature | > ------------------------------------- > > Feature structure: > ------------------------------------------ > | CompactSize | Header | Feature Payload | > ------------------------------------------ > ``` > > The contents of the negotiation packet are a list of features and they ar= e=20 > not packaged like a message[5], so no message type is prefixed. The=20 > negotiation packet can carry as many features as can fit in the maximum= =20 > packet size[6]. A node should disconnect if it can't parse a negotiation= =20 > packet. > > The CompactSize indicates the size of the Header + Payload in bytes. > > The Header is one byte that indicates what feature is being negotiated,= =20 > and nodes should ignore unsupported features. Header values should be=20 > recorded in a table maintained alongside this specification, as BIP-324= =20 > does for its one-byte message type IDs[7]. The value zero is reserved so= =20 > that a later revision can introduce a different structure. Because the=20 > CompactSize covers the Header as well as the Payload, a new Header can ta= ke=20 > on any shape. Until an alternative header format is specified, a zero=20 > header should be ignored. A node must not send more than one feature with= =20 > the same header, and a node receiving a negotiation packet in which a=20 > header repeats should act on the first occurrence and ignore[8] the rest. > > The Feature Payload contains information relevant to a feature being=20 > negotiated, and can be empty. How the payload is structured and interpret= ed=20 > is defined by that specific feature. A feature may specify that **feature= =20 > packets** can be sent -- additional packets whose contents can be used fo= r=20 > upgrade. These packets may only be sent if that feature was negotiated, a= nd=20 > they extend the Transport Phase past the negotiation packet. Their conten= ts=20 > must begin with the header of their respective feature, and feature packe= ts=20 > sent with headers that haven't been negotiated should be ignored. > > A node supporting no features sends an empty negotiation packet -- which= =20 > is identical to a version packet -- and therefore current V2 nodes are=20 > already compliant[9], advertising and selecting features correctly and=20 > ignoring unsupported ones. > > One negotiation packet from each side completes negotiation, but each act= s=20 > slightly differently. The first negotiation packet acts as advertisement:= =20 > it should contain every feature a node supports, including those that are= =20 > mutually incompatible. The second negotiation packet acts as selection: i= t=20 > responds with a subset of the first packet's features, thus deciding whic= h=20 > upgrades are performed. A feature is considered to be negotiated if and= =20 > only if it appears in the selecting packet. The two peers are therefore t= he=20 > advertiser and the selector. > > Features that require payloads should allow the advertiser to omit=20 > payloads from their advertised feature (for example, to advertise ML-KEM= =20 > support but not send the pubkey). This lets the advertiser avoid computin= g=20 > potentially costly setup for a feature which their peer may not support, = at=20 > the cost of a half round-trip. Similarly, these features should require t= he=20 > selector to always send payloads, and allow the advertiser to send their= =20 > payload after the fact in a feature packet. > > If no negotiated features require feature packets, the Transport Phase=20 > ends with the second negotiation packet in the same way BIP-324 terminate= s=20 > it. Otherwise, it terminates when the last feature packet is sent. > > Nodes should accept inbound connections regardless of what features their= =20 > peer supports[10], though a node may disconnect peers based on theirs. > > A MitM *can* strip features from the negotiation packet, and a node can't= =20 > tell if its peer doesn't support a feature or had its=20 > advertisement/selection stripped. An authentication feature can make this= =20 > detectable[11]. > > ## Scope and Open Questions > > I can't imagine that there will be any Transport features implemented in= =20 > practice aside from encryption and authentication upgrades. Should we=20 > restrict the features to just those? This would make ordering feature=20 > packets and coordinating the encryption upgrades easier. Is there some=20 > other subset of possible features we want to restrict to? Let me know you= r=20 > thoughts. > > Should we allow for "staggered negotiation"? Staggered negotiation is wha= t=20 > I'm calling the process of splitting feature advertisements across separa= te=20 > negotiation packets. This could allow nodes to withhold from advertising= =20 > authentication features until after an encryption upgrade is negotiated a= nd=20 > performed, for example. I haven't described a mechanism for it (because i= t=20 > is sort of a headache), but if you all think there is a need, a mechanism= =20 > could be readily designed, and it must be included from the start. There = is=20 > no way to future-proof the protocol to include staggering. > > Must the responder be the advertiser? As specified by BIP-324, the=20 > responder (the node accepting the inbound connection) sends the version= =20 > packet first and thus will always be the advertising peer, meaning the=20 > initiator gets to choose between mutually incompatible features. Should w= e=20 > allow the initiator this privilege? We could choose not to by allowing th= e=20 > responder to pass off the obligation of advertisement to the initiator.= =20 > What are your thoughts? > > Best, > Liam > > --- > > [1] https://groups.google.com/g/bitcoindev/c/n_5WuKVYqwI/ > [2] https://csrc.nist.gov/glossary/term/security_service > [3] https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki > [4] https://github.com/bitcoin/bips/blob/master/bip-0434.md > [5]=20 > https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#v2-bitcoin= -p2p-message-structure > [6] A BIP-324 packet carries a three-byte contents length, so any packet'= s=20 > contents are bounded at 2^24 - 1 bytes:=20 > https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#packet-enc= ryption > [7]=20 > https://github.com/bitcoin/bips/blob/master/bip-0324/message_type_ids.md > [8] Note that this is only relevant in the event that the two features=20 > carry distinct payloads. > [9] BIP-324 specifies this receive behaviour: "Receives a packet, ignores= =20 > its contents. The idea is that features added by future versions get=20 > negotiated based on what is supported by both parties... we defer=20 > specifying the encoding for such version content until there is a need fo= r=20 > it." Core implements it literally -- see VERSION_CONTENTS in src/net.h --= =20 > and any BIP-324 compliant implementation should do the same. > [10] This is to avoid partitioning. If a peer doesn't support the level o= f=20 > desired encryption or authentication, then the connection can be treated= =20 > like a V1. That is, sensitive data can be withheld from unsecure or=20 > unauthenticated connections. > [11] If every node challenges every peer, there is no signal telling a=20 > MitM which connections are safe to tamper with, and a node expecting an= =20 > authenticated connection can treat a missing authentication advertisement= =20 > as evidence of interference. The connection need not end and should=20 > continue unauthenticated, as with any peer lacking some feature -- but th= e=20 > interference becomes visible. If CRQCs become a serious threat, an=20 > authentication feature might go further and treat a connection as authent= ic=20 > only where a PQ KEM was also performed: authentication binds to the=20 > session, and a session established by classical key exchange alone gives = a=20 > quantum attacker everything that binding rests on. --=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/= 1b45f614-6251-4c79-8297-f880edc07c8bn%40googlegroups.com. ------=_Part_8624_169171298.1794586980440 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

I've written up this proposal = into a draft BIP and made a PR against my fork of the BIPs repo. I made some decisions abo= ut the open questions I left in my previous post, so I'd love to get some e= yes and feedback on this.

Looking forward to hea= r from you,
Liam

On Thursday, September 17, 2026 at 11:39:28= =E2=80=AFPM UTC Liam Gilligan wrote:
Hi everyone,

TL;DR (using Terms and Defs bel= ow): In order to support encryption upgrades and the addition of authentica= tion to P2P, I propose we specify a Transport Feature Negotiation protocol,= which gives a framework for modifying the Transport Layer. This makes use = of the version packet BIP-324 left unspecified for exactly this purpose, re= defining it as a **negotiation packet** which carries the features a node s= upports.

## Terms and Defs

There are some unfortunately simil= ar names, so I'll lay out some terminology/definitions in addition to t= hose I made in roasbeef's thread[1].
- **Transport Layer**: The deta= ils of how Protocol messages are encoded on wire and what security services= [2] are provided during transmission.
<= /span>- The objects the Transport Layer concerns itself with are **packets*= *, which can contain the Protocol Layer's **messages**.
- A **Transport** is a particular version of t= he Transport Layer; V1 and V2 are the two that exist today.
- **Protocol= Layer**: The layer that defines which Bitcoin P2P messages and commands ar= e used.
- The objects the Protoc= ol Layer concerns itself with are **messages**, which are contained in Tran= sport Layer's **packets**.
-= A **Protocol** is a particular version of the Protocol Layer; these are th= e protocol versions carried in the version message, currently up to 70017.<= br>- **P2P Handshake**: The exchange between two nodes to ensure they are u= sing compatible Transports and Protocols. This can simply be called "t= he handshake". It consists of two phases:
- **Transport Phase**: The process in which the Transport is= established.
- V1 Transport ex= changes no bytes during its Transport Phase.
- V2 Transport's Transport Phase is defined by BIP-324[3]= .
- The V2 Transport Phase is = terminated by a **version packet**, which is a Transport Layer packet which= contains no Protocol Layer message. The version packet will never contain = the version message defined below. BIP-324 leaves its contents unspecified = and sends it empty, making it exactly 20 bytes on the wire.
- A **negotiation packet** is that same pack= et with its contents specified. This proposal defines those contents as a l= ist of features; a negotiation packet advertising no features is empty, and= is therefore a version packet.
= - **Protocol Phase**: The process in which the Protocol is established.
= - This is done through an exchange= of messages contained between a **version message** and a **verack message= ** (or simply verack). The verack terminates both the Protocol Phase and th= e handshake itself.
- As the n= ame suggests, a version message is a Protocol message contained within a Tr= ansport Layer packet. It will never be contained in the V2 Transport's = version packet.
- Note that no= des not complying with BIP-434[4] may attempt modifying the Protocol Layer = after the verack.
- **Feature**: a modification to the Transport Layer w= hich can be negotiated -- an encryption upgrade or authentication, for exam= ple. A feature is negotiated when both peers agree to use it, by rules give= n below. A feature exists only within the negotiation packet, whose content= s are a list of features and nothing else, and is identified by a one-byte = header. BIP-434 uses "feature" for the Protocol Layer equivalent;= the two never appear in the same packet.

## Motivation and Rational= e

As discussed earlier in roasbeef's thread[1], a PQ upgrade to = the Transport is needed. The general consensus from that thread was that a = CTU solution would be best for this, which means we need a mechanism for pe= rforming such an upgrade. BIP-324 was designed with a future PQ upgrade in = mind, and left an unspecified version packet specifically to perform it, al= ongside authentication and other Transport upgrades.

The version pac= ket seems like a good fit, but is it the only option? There are two main al= ternatives that come to mind: BIP-434 and defining a V3 Transport.

B= IP-434 is a complete P2P negotiation protocol, but is only used for negotia= ting which messages are sent and how they encode data. In other words, BIP-= 434 is sort of "Protocol Feature Negotiation". But encryption and= authentication are Transport features, not Protocol features. The timing i= s also an issue -- the Protocol Phase of the handshake will take place over= two separate Transports.

Defining a V3 Transport by fully replacing= the ElligatorSwift ECDH is also an option, but there are some issues with = this. First, it wouldn't be a CTU path that was (loosely) agreed upon i= n roasbeef's thread, and instead it would be an OSH solution. More conc= retely, it would require committing to one specific PQ KEM right off the ba= t. In the event that this KEM was broken or otherwise rejected, it would re= quire a V4 Transport to replace it. Negotiating the PQ KEM to use in band a= llows for modularity and backwards-compatibility, which is not offered by a= V3.

That leaves in-band negotiation inside V2. Given that a negotia= tion packet is needed in any case, defining an entirely new one instead of = redefining the version packet adds overhead and potentially round trips. Th= e version packet is existent, unused, and positioned ideally and intentiona= lly for this purpose.

## Proposed Design

Transport Feature Ne= gotiation specifies what the negotiation packet contains:

```
Neg= otiation Packet Contents:
-------------------------------------
| Fea= ture | Feature | ... | Feature |
-------------------------------------
Feature structure:
------------------------------------------
|= CompactSize | Header | Feature Payload |
------------------------------= ------------
```

The contents of the negotiation packet are a lis= t of features and they are not packaged like a message[5], so no message ty= pe is prefixed. The negotiation packet can carry as many features as can fi= t in the maximum packet size[6]. A node should disconnect if it can't p= arse a negotiation packet.

The CompactSize indicates the size of the= Header + Payload in bytes.

The Header is one byte that indicates wh= at feature is being negotiated, and nodes should ignore unsupported feature= s. Header values should be recorded in a table maintained alongside this sp= ecification, as BIP-324 does for its one-byte message type IDs[7]. The valu= e zero is reserved so that a later revision can introduce a different struc= ture. Because the CompactSize covers the Header as well as the Payload, a n= ew Header can take on any shape. Until an alternative header format is spec= ified, a zero header should be ignored. A node must not send more than one = feature with the same header, and a node receiving a negotiation packet in = which a header repeats should act on the first occurrence and ignore[8] the= rest.

The Feature Payload contains information relevant to a featur= e being negotiated, and can be empty. How the payload is structured and int= erpreted is defined by that specific feature. A feature may specify that **= feature packets** can be sent -- additional packets whose contents can be u= sed for upgrade. These packets may only be sent if that feature was negotia= ted, and they extend the Transport Phase past the negotiation packet. Their= contents must begin with the header of their respective feature, and featu= re packets sent with headers that haven't been negotiated should be ign= ored.

A node supporting no features sends an empty negotiation packe= t -- which is identical to a version packet -- and therefore current V2 nod= es are already compliant[9], advertising and selecting features correctly a= nd ignoring unsupported ones.

One negotiation packet from each side = completes negotiation, but each acts slightly differently. The first negoti= ation packet acts as advertisement: it should contain every feature a node = supports, including those that are mutually incompatible. The second negoti= ation packet acts as selection: it responds with a subset of the first pack= et's features, thus deciding which upgrades are performed. A feature is= considered to be negotiated if and only if it appears in the selecting pac= ket. The two peers are therefore the advertiser and the selector.

Fe= atures that require payloads should allow the advertiser to omit payloads f= rom their advertised feature (for example, to advertise ML-KEM support but = not send the pubkey). This lets the advertiser avoid computing potentially = costly setup for a feature which their peer may not support, at the cost of= a half round-trip. Similarly, these features should require the selector t= o always send payloads, and allow the advertiser to send their payload afte= r the fact in a feature packet.

If no negotiated features require fe= ature packets, the Transport Phase ends with the second negotiation packet = in the same way BIP-324 terminates it. Otherwise, it terminates when the la= st feature packet is sent.

Nodes should accept inbound connections r= egardless of what features their peer supports[10], though a node may disco= nnect peers based on theirs.

A MitM *can* strip features from the ne= gotiation packet, and a node can't tell if its peer doesn't support= a feature or had its advertisement/selection stripped. An authentication f= eature can make this detectable[11].

## Scope and Open Questions
=
I can't imagine that there will be any Transport features implement= ed in practice aside from encryption and authentication upgrades. Should we= restrict the features to just those? This would make ordering feature pack= ets and coordinating the encryption upgrades easier. Is there some other su= bset of possible features we want to restrict to? Let me know your thoughts= .

Should we allow for "staggered negotiation"? Staggered n= egotiation is what I'm calling the process of splitting feature adverti= sements across separate negotiation packets. This could allow nodes to with= hold from advertising authentication features until after an encryption upg= rade is negotiated and performed, for example. I haven't described a me= chanism for it (because it is sort of a headache), but if you all think the= re is a need, a mechanism could be readily designed, and it must be include= d from the start. There is no way to future-proof the protocol to include s= taggering.

Must the responder be the advertiser? As specified by BIP= -324, the responder (the node accepting the inbound connection) sends the v= ersion packet first and thus will always be the advertising peer, meaning t= he initiator gets to choose between mutually incompatible features. Should = we allow the initiator this privilege? We could choose not to by allowing t= he responder to pass off the obligation of advertisement to the initiator. = What are your thoughts?

Best,
Liam

---

[1] https://groups.google.com/g/bitcoindev/c/n_5WuKVYqwI/
[2] https://csrc.nist.gov/glossary/term/security_service
[3] https://github.com/bitcoin/bips/blob/master/bip-0324.mediaw= iki
[4] https://github.com/bitcoin/bips/blob/master/bip-= 0434.md
[5] https://github.com/bitcoin/bips/blo= b/master/bip-0324.mediawiki#v2-bitcoin-p2p-message-structure
[6] A B= IP-324 packet carries a three-byte contents length, so any packet's con= tents are bounded at 2^24 - 1 bytes: https://github.com/bitcoin/bips/blob/master/bip-0= 324.mediawiki#packet-encryption
[7] https://github.com/bitcoin/bips/blob/master/bip-0324/message= _type_ids.md
[8] Note that this is only relevant in the event that t= he two features carry distinct payloads.
[9] BIP-324 specifies this rece= ive behaviour: "Receives a packet, ignores its contents. The idea is t= hat features added by future versions get negotiated based on what is suppo= rted by both parties... we defer specifying the encoding for such version c= ontent until there is a need for it." Core implements it literally -- = see VERSION_CONTENTS in src/net.h -- and any BIP-324 compliant implementati= on should do the same.
[10] This is to avoid partitioning. If a peer doe= sn't support the level of desired encryption or authentication, then th= e connection can be treated like a V1. That is, sensitive data can be withh= eld from unsecure or unauthenticated connections.
[11] If every node cha= llenges every peer, there is no signal telling a MitM which connections are= safe to tamper with, and a node expecting an authenticated connection can = treat a missing authentication advertisement as evidence of interference. T= he connection need not end and should continue unauthenticated, as with any= peer lacking some feature -- but the interference becomes visible. If CRQC= s become a serious threat, an authentication feature might go further and t= reat a connection as authentic only where a PQ KEM was also performed: auth= entication binds to the session, and a session established by classical key= exchange alone gives a quantum attacker everything that binding rests on.<= /blockquote>

--
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/1b45f614-6251-4c79-8297-f880edc07c8bn%40googlegroups.com.
------=_Part_8624_169171298.1794586980440-- ------=_Part_8623_1524814995.1794586980440--