From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 19 Sep 2026 19:27:19 -0700 Received: from mail-oo1-f62.google.com ([209.85.161.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x87Gw-00005a-DN for bitcoindev@gnusha.org; Sat, 19 Sep 2026 19:27:18 -0700 Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-6c1a8f2c565sf2557499eaf.2 for ; Sat, 19 Sep 2026 19:27:17 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1789871232; cv=pass; d=google.com; s=arc-20260327; b=qVb3bKYaLyNDlZ9WgV25j/x+hKK8Nz51b9qfOSELTTI6q1LCf3AstVWFBOGf8LeW+5 6p9r1qhZn9No+X2pP4ayDZnqRsZiBgpXmz3MBWbrIcJphT9JVtfB6+S7yQM8GW2N4WMQ Fee1w6LjoRfWebGr2GRQPA1AeTu6e7drFtE3H/6yZBoNd3yaNJlFFDCZTbKccoewjh7E zXhvtPwBfn6PEgVQqKaZqOis/FNmxJfm6P4OD7qiOtr/aRzd9W+ir846n6dEgkAdIx9n DS4crF2g+XWAhkMsVmPT0MxRgfANPT0/xwI4MtE9Z6Ez1sAr9IA2vv3fe4mmzikj5vLy OXLg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-disposition:mime-version :message-id:subject:to:from:date:sender:dkim-signature; bh=EQJiurE9Yn5oe9afP7tfq9QzVqSCPxHp76VArjN9pRQ=; fh=qdsYdQpftgBPqjj3ovfWngXHQkt4Ga00C17YeG7Nggo=; b=LUlmk8geATGNAqTDuEiiBHXgj991caCz5Ta3r8AHTTsXUsjzHApGporukxSTCFk37N /E8G+rT/cwDbWFdM8hN22JY+sYBvm/Dyn4ZGeCReUnTDg/e23GEfawDNQ5AaB/KKedl7 QyI2379cMvg4bH/6e19jaSyVv7XXJ2O8h6X7MwZNnLrCGrM+alFF9CUfG6nYSArCtBNk a3WvvFjfOM7v9ILeT34NGRfis3c85PnWTYE5OeQwGsFU/XPTP71gTWDX9OVZyYbPU0VQ CE+z4Kg45d/M3DsQGGjYWBvADGdA6CpgJDo2pDddlEVfY+/1uydwjo3SoPBrEHUiUp2d qpTg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1789871232; x=1790476032; 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:content-disposition:content-type:mime-version :message-id:subject:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=EQJiurE9Yn5oe9afP7tfq9QzVqSCPxHp76VArjN9pRQ=; b=fna8+/jzB/57V/pMNJZzfucT08iklrxz3dxxBdeVF5PjqWwO2yUIU8tfFguPMVbi0+ /+R3o80KPF1WTN2NaK+eLVI+n3BNhYCR5uJBgBv6ydp+9CHTb2QL3XpAzxCr0dEfrfY3 rE9puShwgiokOiq1AXpaqfy+JSQLDfYG6y5pfRKF7pf9lZeniHWSy4a89znD72VYRD/S kE5dubxHPRZKNaIP3MiW8r1vm1ujh7aodwG6El2EUVkQ2Pbm0tvrd5KUl2ppntZXEA/k q2wviB97daKzmx0CZKqBGcDSTgJEVnRC7cC2oBFj0V/+dVoCTwBSDnuGZNaC7fIc89/V zDow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789871232; x=1790476032; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-disposition:content-type:mime-version :message-id:subject:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=EQJiurE9Yn5oe9afP7tfq9QzVqSCPxHp76VArjN9pRQ=; b=YzdRQdhP0XZ/vlsstMG+0VNgvI2Lnxrwovqa66538NdTr9w1OxsR5rF3qYcCJW5H59 8UTFzh/6t7GYgJVADrOSg9kFYIrFsRf6TeR6/knxRsRK7pZMQmILTIimXnpq6RbburVX bVGVYHqzCl9iOUsFK8Q/W470L0cTOs2sfYT5Vy3FH3r6uVNSjN4mzc1duSq0i7fXC22c ZUOgs2QhHWA2rMell2SBqqOjcjwlPrVghAmNaPDNk2CSGMCUcEvfmGS+fbL/DtRAfLBL fHi5n6n48J1dYBdAWtmW+7Bz8Ux1s8zXbd09hS5eiLAMqN7j4LQu1MVOhunL7uiPU1pf oriQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AKwUvBxrjx4PaTPIeonUUbCaTEKPvdzEo/1Kp8CfeqS9d2jwEGJKanZ2uoP5q31/OOvO4F10vaeeRtMKTy+l@gnusha.org X-Gm-Message-State: AFuF++mjNlXzq9FLRom/tHXbscGhjRL1mKVkvO/vfy6W3oTxxhZJ0wyy 25WD06Yf698eJsaIG7W3AXvDhtmgIxe2bYcdMcuJAEbPmP5QVCmZNMSy X-Received: by 2002:a05:6820:60c:b0:6bd:a88f:c8cb with SMTP id 006d021491bc7-6ca99d2cdafmr6834489eaf.6.1789871231590; Sat, 19 Sep 2026 19:27:11 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdeeoB9A4YD5aXtbfvLsDxaPsiDNczDM662gxde9R/xGXA==" Received: by 2002:a05:6871:14e:b0:479:bbe:a714 with SMTP id 586e51a60fabf-485709141b5ls5646059fac.0.-pod-prod-08-us; Sat, 19 Sep 2026 19:27:03 -0700 (PDT) X-Received: by 2002:a05:6808:1926:b0:4bb:3b7f:217b with SMTP id 5614622812f47-4ccf5e014c4mr7351725b6e.7.1789871223683; Sat, 19 Sep 2026 19:27:03 -0700 (PDT) Received: by 2002:a05:620a:915b:b0:93b:ffe9:3f99 with SMTP id af79cd13be357-93bffe94045ms85a; Sat, 19 Sep 2026 19:08:23 -0700 (PDT) X-Received: by 2002:a05:620a:1a02:b0:93a:1fa7:1afb with SMTP id af79cd13be357-93bf5722923mr392360185a.42.1789870102939; Sat, 19 Sep 2026 19:08:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1789870102; cv=none; d=google.com; s=arc-20260327; b=b/AluFMrwJyCWK09DhjamKu9pEv/V9H0tT1NQYYvJblwhbmT1FNVy1w+FhQZmHRwZ4 6TBxlMOHbAZPtT7ZY0qSll19d5lU5ClycHMBXvZDo+RflIN369G8fgi/WYnpJaYpQof5 8TySmccuiLV7Htl0+eDDPnt7nujIXYgz/fW49Jk2CaUPRnLbVDGIbcJU1ZoYd+buFrdk l4dkzsSV3ZDZ+RuUCxU7jZslFqeqZ5mY6bgNYm5svhOC+MqPi+nenKqHsZYTV10R9cOK zKFIHRlzhwyK3wL0mrZwa8m0Y5svNOJQTQvQggmDCXbrskwL3ilAmcJS36Nhx+xA93Zr yH6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-disposition:mime-version:message-id:subject:to:from:date; bh=MzcpaY44wv97MffyLVo7NMzIRTyYtmoEzSPpSLr1XJg=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=Ept8smsdwfFC2PJm4LbrIhkectcZOu3k5GwYXIa7Xnnvt4c/vwqyirr3j7qCGi6lnC y1Mipm7P/jwDBoNdVSzF9S0vtaHzwNnrzr4gg7vn3MCpz+wi3WOR+jlW4Hr3+od/Xx/o cumfFfu/ERtoxtFLb3IbagA3Ed2lcroku1b25dCPPwY6oQNEtDvjlwe4XYXbCoCHxTZN DUdFNl8CnQ1IIttk4z9HGsWQT2frm+a1jD+TDPkhEdFgSmQGSF33Lvd9RLz6h3r6Hp9T xnKkkjCxqLtivwqjVWWbNcpu+tA57sNemANhBmWqKBPoLWPAaIVn8wn3TOln2KuLPrjh /Wuw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au Received: from cerulean.erisian.com.au (azure.erisian.com.au. [172.104.61.193]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-9126095e7b1si1055956d6.1.2026.09.19.19.08.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Sep 2026 19:08:22 -0700 (PDT) Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193; Received: from aj@azure.erisian.com.au by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x86yP-0000Fb-0L for bitcoindev@googlegroups.com; Sun, 20 Sep 2026 12:08:20 +1000 Received: by email (sSMTP sendmail emulation); Sun, 20 Sep 2026 12:08:14 +1000 Date: Sun, 20 Sep 2026 12:08:14 +1000 From: Anthony Towns To: bitcoindev@googlegroups.com Subject: [bitcoindev] [BIP Proposal] BIP324 One-Byte Message Type ID Alias Assignment Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline X-Spam_score: -0.0 X-Spam_bar: / X-Original-Sender: aj@erisian.com.au X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au 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.8 (/) Hello world, I'd like to propose adding a `set324alias` p2p message for dynamic assignment of BIP324 one-byte message type IDs for P2P messages. You can see the current (non-dynamic) assignments at: - https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#user-content-v2_Bitcoin_P2P_message_structure - https://github.com/bitcoin/bips/blob/master/bip-0324/message_type_ids.md The TLDR summary is that nodes that implement this proposal would send a `set324alias [98:messagea, 99:messageb]` message, then afterwards can save 12 bytes every time they send `messagea` or `messageb` by using the corresponding one-byte message type id (98 or 99) instead. Which messages get aliases and what those number those aliases have are chosen by whoever sends the messages (probably by the node developer at compile-time), so nodes on the same connection may give different aliases to the same messages. Draft BIP text follows, including a link to a bitcoin core patchset implementing it. I've previously mentioned this concept at: - https://github.com/bitcoin/bips/pull/2241#discussion_r3754167576 - https://github.com/bitcoin/bips/pull/1937#discussion_r2323645154 - https://gnusha.org/pi/bitcoindev/aUUXLgEUCgGb122o@erisian.com.au/ - https://github.com/bitcoin/bips/pull/1378#discussion_r990569523 Related: - https://github.com/bitcoin/bips/pull/2092 - https://github.com/bitcoin/bips/pull/2086 Cheers, aj ``` BIP: TBD Layer: Peer Services Title: BIP324 One-Byte Message Type ID Alias Assignment Authors: Anthony Towns Status: Draft Type: Standards Track Created: TBD License: BSD-2-Clause Requires: 324, 434 ``` ## Abstract Provides a new `set324alias` message that permits peers using [BIP-324][BIP324] encrypted transport to assign one-byte message type ID aliases to improve bandwidth usage for their outbound messages. ## Motivation [BIP-324][BIP324] assigns one-byte message type IDs via a fixed table, and adding additional entries to the table requires global coordination with the potential for conflicts. Allowing peers to choose their own one-byte message type IDs for their own outgoing messages avoids the need for centralized coordination, and increases flexibility for experimentation at the peer-to-peer layer. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. ### Feature advertisement Support for this feature is indicated via the [BIP-434][BIP434] `feature` message, with `featureid` **TBD** and an empty `featuredata`. Support for this feature SHOULD NOT be advertised on connections that do not support one-byte message type IDs. ### `set324alias` message The `set324alias` allows extending or modifying the set of aliases defined by [BIP-324][BIP324]. The payload of the `set324alias` message contains a vector of aliases, represented as a CompactSize encoded number of aliases being defined, followed by that number of aliases. | Type | Name | Description | | ------------ | ------------- | ----------- | | alias-vector | `aliases` | The new aliases | Each alias is represented by a single byte identifying the alias (with value 1 to 255), followed by a CompactSize-prefixed string of up to 12 bytes giving the message type the alias corresponds to. | Type | Name | Description | | ------------ | ------------- | ----------- | | `uint8_t` | `id` | The alias (1-255) | | `var_string` | `msg_type` | A 1-12 byte message type | Nodes MUST NOT send `set324alias` before sending `verack`. Nodes MUST NOT send `set324alias` to a peer that has not advertised support for the feature. Nodes MUST NOT send more than 255 elements in `aliases`, MUST NOT define an alias with `id=0`, and MUST NOT send a `msg_type` longer than 12 bytes. Nodes SHOULD NOT send `set324alias` on a connection that does not support one-byte message types. Nodes SHOULD NOT send `set324alias` with an empty `aliases` vector. Nodes SHOULD define an alias for all messages that they expect to send multiple times over a connection. Nodes SHOULD NOT define an alias for any message that will only be sent at most once over the connection. Nodes SHOULD NOT define aliases for messages that already have an alias defined in [BIP-324][BIP324]. Nodes SHOULD send `set324alias` only once per connection, and SHOULD send it as soon as possible (eg, immediately after receiving the `feature` message indicating support). Nodes MAY hardcode a bundle of aliases they prefer and send that bundle to all peers that support this feature. Nodes receiving a `set324alias` message MUST maintain a per-peer alias id to message mapping, so that future messages using the one-byte alias are correctly interpreted as if the 1-12 byte `msg_type` had been used instead. A node receiving a `set324alias` message MUST apply the new aliases immediately, as the very next message may make use of aliases declared in that message. Nodes receiving a `set324alias` message MUST update the aliases in order (eg if `[1:foo, 2:bar, 1:baz]` is received, the one-byte message type `1` will be interpreted as `baz` thereafter). If a peer specifies an unknown `msg_type` in an alias, the node receiving the alias SHOULD record the alias as being a generic unknown message type rather than tracking each unknown `msg_type` distinctly. Nodes MUST NOT treat a `set324alias` message defining an alias for unknown messages as an error. Nodes MAY treat a later message using that alias as an error if they would also have treated a message using `msg_type` it aliases as an error. A node receiving a `set324alias` message MUST continue to accept messages that use the 1-12 byte `msg_type` rather than the alias. ## Reference implementation **TODO** See https://github.com/ajtowns/bitcoin/commits/202605-bip324-id/ in the meantime. ## Backward compatibility Non-implementing peers never receive a `set324alias` (gated on their advertisement), so they keep the default mapping and are unaffected. The long form message type stays valid for every message, so messages whose one byte type ID alias has been reassigned to a different message type can still be sent. ## Copyright This BIP is licensed under the 2-clause BSD license. [BIP324]: https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki [BIP434]: https://github.com/bitcoin/bips/blob/master/bip-0434.md -- 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 email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aq9ADn7GscMHWc19%40erisian.com.au.