From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 11 May 2026 17:50:27 -0700 Received: from mail-oi1-f184.google.com ([209.85.167.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wMbKM-00087c-GS for bitcoindev@gnusha.org; Mon, 11 May 2026 17:50:27 -0700 Received: by mail-oi1-f184.google.com with SMTP id 5614622812f47-4828a2091d9sf1709685b6e.3 for ; Mon, 11 May 2026 17:50:26 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1778547020; cv=pass; d=google.com; s=arc-20240605; b=QHE+pB8QUvYCOMEeJXXrKYM3iyCovhtmHBeDZFxJqcbeGBidRaIzuzDveTmb+KmVxz oavN0FbJMixjkJBw/pbbjHAi2dGVWjsdTgxcEPQGk6MxLQgxRwCS8+O6IKmesnQQEDqh sWPk2mfEaOCG0GCqdOmzZXSzFYa6MZkWG48F2/X+OQZzsLcCrlqLNpXIAJ3+hTcK3Poa OSmi4TgxFiCqH+Cn8Fgviyd7Ci4dWNs90NaqZb/OBWF9736iRy0rOe2+1muwC6do+P1F 1vcffoQXDCWcbgvvEvLxkfuZoOrQSpfZk3I8lU/0PgBoASiaWL3uJEiVvU6YG1tY9kLK nMsQ== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=fC/+ZCiNsrXXSzMb+jI6A8izbvU7skSYwRiKKZtebsQ=; fh=enGewEnYouKRxHt/rTA/W9P53mj7UL+iMXzcsdNu+M0=; b=ORrhD3YtCcvyQd79dItLYMvIppNtQvf5T4r+li7OJv7MnJLUFCP4B6t9xZgJZ+/52O kcttvLt443g18k68zT0HeKjI7HZdFdJWPkdrUDZYti1XqVgxaU4SFQTeDdrYZeDZleh9 j2bvHGCCJbynhfhYvabc9I7fNq7ln/R+OkcmzgLWMjLo0Obh6wfmuktMgmWhvJnTqwBq Tl0BJ174BZH3kx7Fl/h4oEOm3qCzoyxYhbSugF023T9u7wk+Oqth3RXid3KVwOM+ft3j Ehf0xuj9BH96zTTBoiNlDVOf6x9lbwMdzglMIlKbxN62hhGV+WhykoYNOQ3nQQKimIY9 8ztQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b="QVMhK/gx"; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::122c as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1778547020; x=1779151820; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=fC/+ZCiNsrXXSzMb+jI6A8izbvU7skSYwRiKKZtebsQ=; b=HNDucNZ5qFkB+6IYD22Dw1XSi1LINGTBe2dUkH1BQco/FGaoyYS9KQR6QOAWD4c6wi t1cMc1Zw7IDho8JGXzmgkHDC83g8FrfDD0mkfnlsrf7fRn8gjI0t5tTqgCwUUevh/2Ty d/KVHoEpLEE0pPK6TO3rQCTZOOev7QOeLNLRCKqSBwgGVC4/9KmgSkzf3e+FfqzMa7ax volgVg97M/qgHb8egbIO23kTgR9+VtnlDH8rEhUNTq18zvrv/qOE553yPdKhyafoSAIW sAtTXZc8EwgptegaYesIlhioTx1uFHV9BJZd20NoB+M/zJShRinQOxSgWVDQn2ki5P/B jivg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778547020; x=1779151820; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fC/+ZCiNsrXXSzMb+jI6A8izbvU7skSYwRiKKZtebsQ=; b=qJaRgsnuuN+byCsF3HmcExgFOHsvchFnSdIzvbuW2LpdT3COrCx5Aq1udvOcTGmrNN vXcn2Brz2yED3VkmbvewbmNsJpYIGP+Jgfs4FdIzzxMOHx1B9etVOThvbOHw/yC+yLZL 0huM4nKWCzoREcAw23HmB/ls1AQ8dqaIIkdGrcEPQUGLc93Rr8sGTb042GE1hsZVn3e+ ohIHGiWBiOOhdPfiQCWbHSMyJPwlqMqyQ4TukKgy5PF977OHqET9NJOTsvTgMxIIizLg CKM6VLvovP5gYWpfcEQHla+qlsgrAslnJS1+Os23F7L4pFV+dhFRc+yzXc/tRx9Q+dds Grsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778547020; x=1779151820; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=fC/+ZCiNsrXXSzMb+jI6A8izbvU7skSYwRiKKZtebsQ=; b=QV1hBOBMPKcjNn4ZWgjhZEgjPSfFTegGkdDAGuXc7dboAAH3Af/wWlYTHfdqC+hxtb Hkr1d3TJVblzTO5TLLiGSgeZ7b++v5AqCXqbTCjeDoSTdQQs9apah5TOrccON8iXlxo9 OOLO221ShbX4BKU7OLxUJJNd7UglEK7bIX1zaMTMgqGIOx4rkHD1xUz2ahaneLK7AwRO zHLhR6S7+W4yv74MHc6NLU7f9ZgJzMHth7sSPd1/jpkDVGihSLsyWOG7vr27ugohgXMc qxoEUF0h5dIi+oZVExLe8v6lfdqt73ublw4EoGe0eYE10PkAS+YWXCjf3bQ9Dypbgqgi k8Nw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ/4nqOkvb5SSkJGoN4lEvHjJE6a8cE7KhKWiGxwImP1HdZ+LKelJaH0QWmI+2WdSQ15ENlkNgFcleSI@gnusha.org X-Gm-Message-State: AOJu0YwmSmisAuuFV0Krwvx+n4+oMXkJnR+NSuZmBqiNoOBGG5DsYplj BwrVyZRHY10QRgtBnQC2ESuJyRzHD8KYfg3Yra8a3nsDKodUiMvbnSJw X-Received: by 2002:a05:6808:4f1f:b0:479:fa21:adfe with SMTP id 5614622812f47-4807fbf776emr9559729b6e.6.1778547019938; Mon, 11 May 2026 17:50:19 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMNf0fnZkUcvQkG98XQEgpfmiIBkEXvmWTQ+VkpYebdPcg==" Received: by 2002:a05:6871:54b:b0:423:2c4e:f14b with SMTP id 586e51a60fabf-435907cead9ls1553353fac.1.-pod-prod-01-us; Mon, 11 May 2026 17:50:14 -0700 (PDT) X-Received: by 2002:a05:6809:10c:20b0:482:4fe0:215c with SMTP id 5614622812f47-4824fe0b944mr4525559b6e.32.1778547014264; Mon, 11 May 2026 17:50:14 -0700 (PDT) Received: by 2002:a05:6808:912:b0:479:9f23:6621 with SMTP id 5614622812f47-4807b051099msb6e; Mon, 11 May 2026 17:49:45 -0700 (PDT) X-Received: by 2002:a05:6a00:aa82:b0:837:6bb9:acb7 with SMTP id d2e1a72fcca58-83cf1e48de4mr15950739b3a.0.1778546984237; Mon, 11 May 2026 17:49:44 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1778546984; cv=pass; d=google.com; s=arc-20240605; b=MXR7wmz0OF9d5wzVlKuiquARdQiy0px42njGLmdX3DSJi3cGLgmr8dYIwZ4Cde0bx6 Fuf+smbMNh29C20dpM8JZfuyC9ryidSMCUNxda8/a6PWNzoGV7U74VzlNfUaEDip8EZv m7SKkFSNQwxJC70QO9ndiuvM/RzNbHAqD5cyVzrh82ct6XXaqtafnBTRfR7C/RBgFQ4N lJZSm7yfcyCWpm5pMZG+7zzspqd2Nj+aKeGIAqymMube2K2W5HooTgJGrBb127jdqgEe gdSqUbk+58gEayBpt7HcQGaW4pBo6mRdCbYQtKaUt1O2iIRbCew3p4ahA7J8J0R43x0R VK2Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=jkR+6/N8kjROYrrICd0HXvgzOcMT8HsduqtjOm1cQy8=; fh=eQwyrPB7DiKLZfk3HA1+IBNTG62m+FxzJ3AFq+zftRc=; b=AUPLg9hdQP3D4mDZ9WsYExH5xPY6STuHyUidsRUWWSu9zHys4Lru0e7STKbMo64vMl vl75euCSQjY212+oTbz62zphJdYIAbn1ad8+SVhoYgkt6LbKwgnuM+TvyN2hK+KIHFd7 17pg1GgI7H70+ubWFMR8pHTeSOpC/S2g70SZwB+vxPmALiJwRkRn7f5ENToqLWn7Dtza dCsbld86n+PSoZyPxHtjdvVM0n/gTvXn1YQMuMdEXp7dX68HWZ2F/97Y7KeYVKJsTzeU H408uH/UILDP0EWyzy95+aqhGVbOCJ4xpJcnegzAHmlSaLNKqPTWyQUBnFQJYaL+yYCm UXew==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b="QVMhK/gx"; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::122c as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-dl1-x122c.google.com (mail-dl1-x122c.google.com. [2607:f8b0:4864:20::122c]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-8396534630esi674407b3a.2.2026.05.11.17.49.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2026 17:49:44 -0700 (PDT) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::122c as permitted sender) client-ip=2607:f8b0:4864:20::122c; Received: by mail-dl1-x122c.google.com with SMTP id a92af1059eb24-132830d8281so2495326c88.1 for ; Mon, 11 May 2026 17:49:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778546984; cv=none; d=google.com; s=arc-20240605; b=FKqI/0PV8uXQYqqSQvNtQqLKL45lUG5RBG+pMX4mEDK29mQfGid9pK60M3t5PJR5T1 QxkJso7dnjp8XhanhoBiGeldU0xP+ZVmcsquAPXCA89eJ4pWFBJULvLuJoQAyct3nSok ob/zOyq1WyTI3k6UmRLkXGpDg5aFA+qQkFQzuvqVIpXKRR4yZBThNrmGPL8wedip6kyh nZMc/VwWOronS6hplXmByBhPJ3K3zilEc1Gt2s0kchtfwf5+TDi4tMm1l+WEBHwc8t6A 3PqksZr1oqfesjVFzB3adkstqy/ATn++NFjJcH8oNlSLEVkLqWa5S9BWWAEpJMwfP2rk nfsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=jkR+6/N8kjROYrrICd0HXvgzOcMT8HsduqtjOm1cQy8=; fh=eQwyrPB7DiKLZfk3HA1+IBNTG62m+FxzJ3AFq+zftRc=; b=SPWIrR3TmJcT7lVsN+t1bUywxfK1ddKTs17zKDAJMurBmLXwd+leIA1W2VPbdFkQHC NbwA7Vu6xI2bKaUOfbdwMgIz/Yi687F/pfA9NmoZ5bU3wt03Gh4zGaGIx1QXULtOuFP9 0e2iGIYv15fT7IdfesNtL7e46qDkIrvO8k4JmxJ2Jpg44wX4M7B20iYYgKIi7wiaFY92 wssf6YvVO5e2eTdPAOT1iEXvi2pVKph7JbnXCbb3EZ9oDXyo3rKGBslaGpbXDCHLMSIe gKpn9uT42pBnRqw9uIqkB5P3nAQUlnz7drTyz9fK7T9uFGBf/cnI7Ef2+W/9ltJN8Vru 7YMg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: Acq92OEYi4lohmuG79ZLiJKw+vtsyTsOFGa/4qUkRkbnGi34I/ELkkMO25UbDB3RY+C rFxDcyVDqcJQotgTRaI9a5CrZDuRghdA3tbd1MxwLpIqbdJUWFuHhks0BgZfiRc0wF0PH3ZbXEA IyVPnvpps2Tt5lYIrTK0wFteDsC1tHaDh8R1n2i9CS29FjQ/cNclAf62BzV72gZ4rRtwhgSE/Ga /hEISAh8s7DUULtwcudSu8AZStYWYaE9roat3oMfv/+Mqitsp+BkJfdoTn+S3x5+vhzs3xTHRtG yiRLUhqJ X-Received: by 2002:a05:7022:660d:b0:12b:f881:d8fb with SMTP id a92af1059eb24-1327124fafemr10246966c88.3.1778546983345; Mon, 11 May 2026 17:49:43 -0700 (PDT) MIME-Version: 1.0 References: <6783db94-fbbd-4df8-b05f-639fa3ace6f1n@googlegroups.com> In-Reply-To: From: Antoine Riard Date: Tue, 12 May 2026 01:49:31 +0100 X-Gm-Features: AVHnY4K6z8GaRMQb3KsAlhG4zxExBA-aJ1dJvtNV41-iQX6UfUhTuke6xhkyrS4 Message-ID: Subject: Re: [bitcoindev] Re: [BIP Proposal] Peer Feature Negotiation To: Anthony Towns Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000028a20b0651943dfe" X-Original-Sender: antoine.riard@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b="QVMhK/gx"; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::122c as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --00000000000028a20b0651943dfe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi AJ, Sorry for the late answer here. > Sending a bunch of FEATURE messages that are immediately ignored is no > different from receiving a bunch of INV messages for txs you've already > seen, or sending any other payload that you expect the peer to ignore. It's true that for INV messages we have already the MAX_INV_SZ limit. Witht he current BIP text, there is limit laid out that `featuredata`'s byte-vector must not be superior to 512 bytes. However, there is no indication that declared `featureid` must be consistent with `featuredata`, so I don't see why a peer couldn't iterate _multiple times_ over the 80^2 `feature_id` space to repeatedly attach 512 byte payload. One if a peer can escalate one of your inbound slot (i.e win over `ConsiderEviction`), and from then cloak your CPU processing with dumb FEATURE message. Recommending some time-bounded processing window for a fairly generous number of FEATURE would make sense. I'm taking the caveat that it might be a bit early to add such p2p limit, that it will add too much rigidity for a not even experimentally deployed proposal (and "early optimization is the rule of all evil"). > A VERACK timeout is a pretty normal thing to have -- eg `-peertimeout` > already exists and defaults to 60 seconds. It's not clever to waste a > connection slot on a peer that's delaying ever getting into the part > where you relay bitcoin information to each other. Right, may I note that your `-peertimeout` should make a distinction between in-handshake (before VERACK) versus post-handshake. If you look at bitcoind core, I'm not sure if `InactivityCheck` / `ReceivedMsgBytes` make that distinction. > In my opinion, interactive feature negotiation (of the form "I'll only > tell you I support X if you first tell me you do/don't support Y") > is massively overcomplicating things, and essentially an anti-pattern. Here I was thinking more about cryptographic schemes upgrade. Let's say you have a p2p v3 encryption (or we wish to upgrade some cryptographic primitive e.g the hash func in BIP330 for the short ids). Here, you can see first if your peer supports the simple version, and then propose the upgrade. This would allow to make smoother upgrade over the network. > There's no way to "freeze" development -- if BIP x says "you can't do > Y", then doing Y just means you aren't implementing BIP x; you're not > in any way inhibited from doing Y. I believe we do have consensus fields reserved for future usage e.g not using the taproot annex which is checked by its own policy rule. Of course, it's policy only, there is difference between inhibition and encouragement of good practice. > Messages received before `version` will generally already result in a > disconnect, as that's how nodes recognise they're talking to another > bitcoin node. Yeah, this proposal is still tightening the `version` message protocol field bump with signaling support for BIP434. One way to disentangle would be to version-feature the FEATURE message with a 1-byte field (which for a 1-byte connection only doesn't seem a high bw cost). Not sure if there is really a hard constraint to bump the protocol version here and it wouldn't be more elegant to add an optional byte in `version` message. Best, Antoine OTS hash: 408e1c06080fa6b53c1ab076f9e881b5b1d9f971b984d12f9eaaf06bf5fb8d3c Le dim. 8 mars 2026 =C3=A0 12:14, Anthony Towns a =C3= =A9crit : > On Sun, Mar 01, 2026 at 10:06:20AM -0800, Antoine Riard wrote: > > I'm > > thinking that one drawback with the multiple feature / signaling messag= es > > approach compared to the fixed-size length verack payload comes with th= e > > novel feature messages becoming a novel if not a least a vector of > > denial-of-service, at least some vector of annoyance. One peer can alwa= ys > > throw a number of `feature` message only bounded by the 80^2 informatio= n > > space of the `featureid` string length. > > There's nothing stopping a peer from sending the same FEATURE message > multiple times prior to sending a VERACK, or sending the a FEATURE > message with the same featureid but different featuredata. > > However these aren't a DoS concern, because such messages are either > expected to be ignored (if the featureid isn't recognised by the peer) > or can be rejected as invalid (if the featureid is recognised but isn't > in compliance with the feature's specification). > > Sending a bunch of FEATURE messages that are immediately ignored is no > different from receiving a bunch of INV messages for txs you've already > seen, or sending any other payload that you expect the peer to ignore. > > > I don't think there is an easy or obvious answer > > to this issue, other than introducing a verack negotiation timeout (wit= h > > all the frictions of the lack of an easy to use coordinated clock among > > peers...). > > A VERACK timeout is a pretty normal thing to have -- eg `-peertimeout` > already exists and defaults to 60 seconds. It's not clever to waste a > connection slot on a peer that's delaying ever getting into the part > where you relay bitcoin information to each other. > > > I do see the idea with that it's indeed allowing some form of > > interactive feature negotiation, > > In my opinion, interactive feature negotiation (of the form "I'll only > tell you I support X if you first tell me you do/don't support Y") > is massively overcomplicating things, and essentially an anti-pattern. > > > One last high level remark, I'm wondering if the protocol > > versioning shouldn't be "frozen" in itself, > > There's no way to "freeze" development -- if BIP x says "you can't do > Y", then doing Y just means you aren't implementing BIP x; you're not > in any way inhibited from doing Y. > > > - the BIP is silent on unknown messages received before `version` > > reception > > Messages received before `version` will generally already result in a > disconnect, as that's how nodes recognise they're talking to another > bitcoin node. > > Cheers, > aj > --=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/= CALZpt%2BFOrh4OEM7z3Fk5D3cNFONcUB_6ZYtiyXRMkPMUZq1VNQ%40mail.gmail.com. --00000000000028a20b0651943dfe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi AJ,

Sorry for the late answer here.

> = Sending a bunch of FEATURE messages that are immediately ignored is no
&= gt; different from receiving a bunch of INV messages for txs you've alr= eady
> seen, or sending any other payload that you expect the peer to= ignore.

It's true that for INV messages we have already the MAX= _INV_SZ limit.
Witht he current BIP text, there is limit laid out that `= featuredata`'s
byte-vector must not be superior to 512 bytes. Howeve= r, there is no
indication that declared `featureid` must be consistent w= ith `featuredata`,
so I don't see why a peer couldn't iterate _m= ultiple times_ over the
80^2 `feature_id` space to repeatedly attach 512= byte payload.

One if a peer can escalate one of your inbound slot (= i.e win over
`ConsiderEviction`), and from then cloak your CPU processi= ng with
dumb FEATURE message. Recommending some time-bounded processing<= br>window for a fairly generous number of FEATURE would make sense.

= I'm taking the caveat that it might be a bit early to add such
p2p l= imit, that it will add too much rigidity for a not even
experimentally d= eployed proposal (and "early optimization is
the rule of all evil&q= uot;).

> A VERACK timeout is a pretty normal thing to have -- eg = `-peertimeout`
> already exists and defaults to 60 seconds. It's = not clever to waste a
> connection slot on a peer that's delaying= ever getting into the part
> where you relay bitcoin information to = each other.

Right, may I note that your `-peertimeout` should make a= distinction
between in-handshake (before VERACK) versus post-handshake.= If you look
at bitcoind core, I'm not sure if `InactivityCheck` / `= ReceivedMsgBytes`
make that distinction.

> In my opinion, inte= ractive feature negotiation (of the form "I'll only
> tell y= ou I support X if you first tell me you do/don't support Y")
&g= t; is massively overcomplicating things, and essentially an anti-pattern.
Here I was thinking more about cryptographic schemes upgrade. Let'= ;s say
you have a p2p v3 encryption (or we wish to upgrade some cryptogr= aphic
primitive e.g the hash func in BIP330 for the short ids). Here, yo= u
can see first if your peer supports the simple version, and then propo= se
the upgrade. This would allow to make smoother upgrade over the netwo= rk.

> There's no way to "freeze" development -- if = BIP x says "you can't do
> Y", then doing Y just means = you aren't implementing BIP x; you're not
> in any way inhibi= ted from doing Y.

I believe we do have consensus fields reserved for= future usage e.g not
using the taproot annex which is checked by its ow= n policy rule. Of course,
it's policy only, there is difference betw= een inhibition and encouragement
of good practice.

> Messages = received before `version` will generally already result in a
> discon= nect, as that's how nodes recognise they're talking to another
&= gt; bitcoin node.

Yeah, this proposal is still tightening the `versi= on` message protocol
field bump with signaling support for BIP434. One w= ay to disentangle would
be to version-feature the FEATURE message with a= 1-byte field (which
for a 1-byte connection only doesn't seem a hig= h bw cost).

Not sure if there is really a hard constraint to bump th= e protocol
version here and it wouldn't be more elegant to add an op= tional byte
in `version` message.

Best,
Antoine
OTS hash: 4= 08e1c06080fa6b53c1ab076f9e881b5b1d9f971b984d12f9eaaf06bf5fb8d3c

Le=C2=A0dim. 8 mars 2026 =C3=A0=C2=A012:14, Anthony Towns <aj@erisian.com.au> a =C3=A9crit=C2= =A0:
On Sun, Mar= 01, 2026 at 10:06:20AM -0800, Antoine Riard wrote:
> I'm
> thinking that one drawback with the multiple feature / signaling messa= ges
> approach compared to the fixed-size length verack payload comes with t= he
> novel feature messages becoming a novel if not a least a vector of
> denial-of-service, at least some vector of annoyance. One peer can alw= ays
> throw a number of `feature` message only bounded by the 80^2 informati= on
> space of the `featureid` string length.

There's nothing stopping a peer from sending the same FEATURE message multiple times prior to sending a VERACK, or sending the a FEATURE
message with the same featureid but different featuredata.

However these aren't a DoS concern, because such messages are either expected to be ignored (if the featureid isn't recognised by the peer)<= br> or can be rejected as invalid (if the featureid is recognised but isn't=
in compliance with the feature's specification).

Sending a bunch of FEATURE messages that are immediately ignored is no
different from receiving a bunch of INV messages for txs you've already=
seen, or sending any other payload that you expect the peer to ignore.

> I don't think there is an easy or obvious answer
> to this issue, other than introducing a verack negotiation timeout (wi= th
> all the frictions of the lack of an easy to use coordinated clock amon= g
> peers...).

A VERACK timeout is a pretty normal thing to have -- eg `-peertimeout`
already exists and defaults to 60 seconds. It's not clever to waste a connection slot on a peer that's delaying ever getting into the part where you relay bitcoin information to each other.

> I do see the idea with that it's indeed allowing some form of
> interactive feature negotiation,

In my opinion, interactive feature negotiation (of the form "I'll = only
tell you I support X if you first tell me you do/don't support Y")=
is massively overcomplicating things, and essentially an anti-pattern.

> One last high level remark, I'm wondering if the protocol
> versioning shouldn't be "frozen" in itself,

There's no way to "freeze" development -- if BIP x says "= ;you can't do
Y", then doing Y just means you aren't implementing BIP x; you'= ;re not
in any way inhibited from doing Y.

> - the BIP is silent on unknown messages received before `version`
> reception

Messages received before `version` will generally already result in a
disconnect, as that's how nodes recognise they're talking to anothe= r
bitcoin node.

Cheers,
aj

--
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/bitcoindev/CALZpt%2BFOrh4OEM7z3Fk5D3cNFONcUB_6ZYtiyXRMkPMUZq1VNQ%40ma= il.gmail.com.
--00000000000028a20b0651943dfe--