From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id A9F50C002B for ; Fri, 17 Feb 2023 22:13:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 7FC6940195 for ; Fri, 17 Feb 2023 22:13:22 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 7FC6940195 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=wuille.net header.i=@wuille.net header.a=rsa-sha256 header.s=protonmail3 header.b=Ld2R8PdO X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1gQoWEMvuXg for ; Fri, 17 Feb 2023 22:13:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4306E400F8 Received: from mail-4321.protonmail.ch (mail-4321.protonmail.ch [185.70.43.21]) by smtp2.osuosl.org (Postfix) with ESMTPS id 4306E400F8 for ; Fri, 17 Feb 2023 22:13:20 +0000 (UTC) Date: Fri, 17 Feb 2023 22:13:05 +0000 Authentication-Results: mail-4321.protonmail.ch; dkim=pass (2048-bit key) header.d=wuille.net header.i=@wuille.net header.b="Ld2R8PdO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail3; t=1676671988; x=1676931188; bh=FwIKYudgfOP8+lKMPPF6RCO11HpFSu/pUfFB8mBc1x8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Ld2R8PdO7opTGilK3cBUdqOCBVwN3b3dY3vVYUOj82XfmITYjFv/JMDjhTdsBRImc zkDJcEH6xa/iu26XIzUKvWkyQaMHM+6yiyDKxFSWRMfZ7z+3WmdsgEyqztsPmqjigm dJVzmZkbQGdrhti5wQ6EOixNtD2XSZ6NMpfrKeB7uxqLI6KWbyheMIQrVT0I4DAf/W JjH1vMitOavodSfgEIrrmsK9Lbj7dL0piwKwJhNsDOdRkzDT2npp1JzyJstbzedZEh oTohUOCqzK7OyvL7g2GeuQLkzncROyG71f452lBgCd+ETamGXmo+pXiZkMflSPdFTr R4FV+FZMp+VUw== To: Anthony Towns , Bitcoin Protocol Discussion From: Pieter Wuille Message-ID: In-Reply-To: References: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com> <6b83c32e-59ca-65ef-2553-d66f8d117e56@bip324.com> Feedback-ID: 19463299:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 17 Feb 2023 22:28:50 +0000 Cc: Dhruv M Subject: Re: [bitcoin-dev] Refreshed BIP324 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2023 22:13:22 -0000 On Friday, February 17th, 2023 at 10:51 AM, Anthony Towns via bitcoin-dev <= bitcoin-dev@lists.linuxfoundation.org> wrote: > I think it's probably less complex to close some of the doors? =20 > 2) are short ids available/meaningful to send prior to VERACK being > completed? Ah, I hadn't considered this nuance. If we don't care about them being avai= lable before VERACK negotiation, then it may be possible to introduce a way= to negotiate a different short id mapping table without needing a mechanis= m for *re*-negotiating. > Here's another approach: >=20 > idea: we use short ids to minimise bandwidth, and don't care about > bandwidth for long ids >=20 > implementation: > short id 0 is reserved for long commands. when received, we > decode the first 12 bytes of the payload and treat them > exactly the same as a v1 p2p message (trailing 0-bytes, etc) > (if there's not 12 bytes of payload, it's just treated as an > invalid command and dropped) >=20 > short ids 1-255 are available for use as aliases of particular > long commands >=20 > (That's exactly compatible with p2p v1, and also avoids the temptation > to try to choose short command names rather than descriptive ones -- the > 0-padding to 12 bytes prevents you from saving any bandwidth that way; > but that's what we have short ids for anyway) I like this idea. It avoids the variable-length encoding question and relat= ed complexity entirely for things where we admittedly don't care about the = bandwidth impact anyway. It may also have another (rather weak) advantage, in that it may reduce how= much information a passive observe may learn about application level featu= res (sendheaders, sendaddrv2, ...) from the packet size sent (which would o= therwise depend on command lengths), even when decoys are not in use, if no= short commands are included for these messages. > > - We remove 1 byte allocations for messages that are sent at most once = per connection per direction >=20 > I think this leaves 32 commands that get short ids initially: >=20 > misc: ADDR, ADDRV2, BLOCK, FEEFILTER, GETBLOCKS, GETDATA, GETHEADERS, > HEADERS, INV, NOTFOUND, PING, PONG, TX > bip 35/37: FILTERADD, FILTERCLEAR, FILTERLOAD, MEMPOOL, MERKLEBLOCK > bip 152: BLOCKTXN, CMPCTBLOCK, GETBLOCKTXN > bip 157: CFCHECKPT, CFHEADERS, CFILTER, GETCFCHCKPT, GETCFHEADERS, > GETCFILTERS > bip 330: RECONCILDIFF, REQRECON, REQSKETCHEXT, SENDCMPCT, SKETCH Sounds right. > which drops: >=20 > VERSION, VERACK, GETADDR, SENDADDRV2, SENDHEADERS, SENDTXRCNCL, > WTXIDRELAY Indeed. > compared to bip 324 currently. >=20 > I think the things missing from the current list (and not currently in > use by bitcoin core) are: >=20 > bip 61: REJECT > bip 331: GETPKGTXNS, PKGTXNS, ANCPKGINFO Do you feel REJECT should be included? > > - Optionally, in the implementation we can attempt to move the type id = mapping to the p2p layer away from the transport layer. I suspect this coul= d also be done after the implementation is merged but might be cleaner as t= he mapping is a p2p concern. > > I agree that's fine, though I expect that we'll probably want to do it > not long after bip 331 is ready for merge (or some other p2p improvement > comes along)... I do prefer that as well; it feels like the transport layer shouldn't be aw= are of the different command names that exist, but this is very much just a= n implementation issue. Perhaps a possibility is having the transport layer translate short-command= -number-N to the 12-byte command "\x00\x00..." + byte(N), and hand that to = the application layer, which could then do the mapping? Cheers, --=20 Pieter