From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 10 Dec 2025 10:12:40 -0800 Received: from mail-qv1-f64.google.com ([209.85.219.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vTOg3-0002av-5W for bitcoindev@gnusha.org; Wed, 10 Dec 2025 10:12:40 -0800 Received: by mail-qv1-f64.google.com with SMTP id 6a1803df08f44-8885a6666b1sf2906246d6.2 for ; Wed, 10 Dec 2025 10:12:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765390353; x=1765995153; 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=DznNS0g3qEkzkQ5ZTxkRgTG7MCJpN2/zAcDhIC6CGV0=; b=TUTuYZThQxT/sUsHSkLinsHaSyAy9dgxHmQUNp209qUMmjvK2mvHQNiB88OQLqB5zJ +bNULsjycxT13bjgb8IzZIG7IbAJXII4HAfdC5bpFUye8IOax2xeqP3L75DaHrnFPBPI a66ktynTOSlEyn4f/EFx53SVC5QdL6dsVucBOxcIlDNa0g4i/vb4EFW/FStMjBJK3VuA dQBDwGatHEebGeHKjp5cYPqkHJevr3xgo3unwjYBqT7JheQZtEySvR5wI9IidUD1vv0M ja4A84KKDmY/9w/R8WdHQMWZTLPRLjVDaLELqzq695+QgQjac/Bpr9FgCjRM/HrPY7I3 cacA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765390353; x=1765995153; 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=DznNS0g3qEkzkQ5ZTxkRgTG7MCJpN2/zAcDhIC6CGV0=; b=AYA3LdF4CS9H+RDIkaHFDwkrBe29fUP18IRUqhpe4xeFi5shyvTclJ8JE8WSAxqqTC nbdOpzPZ1a+U+Bdim2n4IO2vFmlVNT7WEsYjYyc/QKvXdn88wVLeTS82SHdRBp7q48/K 73JU0bqmLndPj6XEzcfS7xWHiru1r6FiUZu8siJI2dCwjydCd4nSeBySzsXGG4vqZ5QI bs4Ywad4Ua3hzslduYl087CoIXB+60QLiKEV+YT2oKasf090jq+AQpwnvuc8Zjyicdt5 hJUB6bXHrEr8kL1Htq3Cq7MdA2LhByEgU2+nVD783b8R+GnfMLLcee0kbn6Ajgxkhcfu EABQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765390353; x=1765995153; 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=DznNS0g3qEkzkQ5ZTxkRgTG7MCJpN2/zAcDhIC6CGV0=; b=Fbq3nZ+JIKyKambQYSa3cG/h3d9gjT51+1LIB9yYu8qyQAkwRWiMlNDIycWUnfamwk K0sWyIaPftj8RtB1pWuXub7swBo+HKDyfQ1zHjHErDxZrxa7nEZechqzTgT4wpg6fDg4 0oE1bvCBUvocK6W4X0WYc8dpfoqZaSDVobJI7FAev/0dViFItSgmv5cE74wiRgImZJlE YqaKAWq8+rI5M9um1aGF0YROQ4QJOpl6ISs8TRsFrosbKJGEJ+eg9wCmML66aszeMybm ++KVA4CMMFsTdfhiGQ2cH1cMUBbc/P8UAxlyJBNys3Z10tOeKxwziuAdHkO7BcAefCYv 3KDw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXoqOZswv4zlbtF1FzoKSjJzcCPJqDkgtGLEqY9xGzAf//aQxt4+QdslN166EUx1pCr13GfKGV+HBaV@gnusha.org X-Gm-Message-State: AOJu0YzaWHE1066PgquE2tcmckghtgnqyg33nSpTd3Sw7IMNMJI8IKeA OYK9VQdZTE6L9JE5R6DIUQ1EVgAybx/YKB6UzvVJzjxb3+/6JLaHVccl X-Google-Smtp-Source: AGHT+IGJ2Cyiw1xtN5ExOXHcLksL+Ln2vBbQJzx0PoW2JxkQtYSWuVAFrcAdmHgG9HwgVmC6nhP3dQ== X-Received: by 2002:a05:6214:4106:b0:880:42a7:772c with SMTP id 6a1803df08f44-88863ac15f1mr48510976d6.54.1765390352716; Wed, 10 Dec 2025 10:12:32 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWbao0pv38yaQ1hDmpO8AAj/dPn9dCLmhoqFYrLY0gnMkQ==" Received: by 2002:a05:6214:808b:b0:87b:d44b:314a with SMTP id 6a1803df08f44-88825e65f8fls116160706d6.2.-pod-prod-01-us; Wed, 10 Dec 2025 10:12:25 -0800 (PST) X-Received: by 2002:a05:620a:4016:b0:8b2:db27:4262 with SMTP id af79cd13be357-8ba39f585dbmr505448685a.74.1765390345099; Wed, 10 Dec 2025 10:12:25 -0800 (PST) Received: by 2002:a05:690c:9314:b0:78a:986f:9439 with SMTP id 00721157ae682-78c5aaeb8d7ms7b3; Tue, 9 Dec 2025 15:13:07 -0800 (PST) X-Received: by 2002:a05:690e:14c7:b0:644:472d:daf8 with SMTP id 956f58d0204a3-6446e84f6f7mr509967d50.0.1765321986043; Tue, 09 Dec 2025 15:13:06 -0800 (PST) Date: Tue, 9 Dec 2025 15:13:05 -0800 (PST) From: defenwycke To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: [bitcoindev] Re: Splitting more block, addr and tx classes of network traffic MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_726282_946233558.1765321985691" X-Original-Sender: cal.defenwycke@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_726282_946233558.1765321985691 Content-Type: multipart/alternative; boundary="----=_Part_726283_2046511103.1765321985691" ------=_Part_726283_2046511103.1765321985691 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Antoine, This is an interesting problem, and introducing finer-grained traffic=20 classes certainly makes sense. The three areas that stand out to me are=20 peer declaration, topology inference and system bottlenecks. Peer declaration:=20 Explicit signalling of specialised roles (Example - I only relay=20 hot-blocks) to peers increases the fingerprint/profile. We already see=20 topology inference attacks via relay behaviour; adding public role=20 declarations may expand that surface. Nodes can already drop or=20 deprioritise whatever they wish locally, so explicit signalling may not be= =20 necessary. Topology inference: Since topology inference can be drawn from tx-relay timing and relay=20 behaviour, an internal class-based model also allows the node to randomise= =20 acceptance, forwarding, and scheduling behaviour per class. Even small=20 amounts of deliberate jitter or probabilistic message handling make it far= =20 harder for an observer to infer which peers are responsible for block-relay= =20 versus tx-relay traffic. This further reduces the value of explicit=20 capability signalling, since role exposure can be disguised at the=20 behavioural level instead. System bottlenecks:=20 Introducing multiple traffic classes as separate processes and sockets=20 increases resource consumption, as you=E2=80=99ve noted. A single connectio= n can=20 already multiplex all P2P message types. A cleaner approach might be to integrate the class separation internally,= =20 without advertising anything to peers. Incoming messages can be classified= =20 (Examples - hot blocks, cold blocks, tx, address gossip, etc.) and=20 per-class policies applied locally. Since a node doesn=E2=80=99t need to re= ceive or=20 forward traffic it doesn=E2=80=99t want to handle, it seems unnecessary to = declare=20 toggle roles at handshake time. An additional benefit of integrating classes internally is that it gives a= =20 natural place for per-class bandwidth accounting and load shedding. Under= =20 congestion, hot-block traffic could be prioritised while less critical=20 classes (Example - cold block serving) are throttled, without multiplying= =20 sockets or increasing signalling surfaces. Externally the peer sees a normal connection; internally the node routes=20 each message into class-specific queues and rate-limit buckets. This=20 preserves flexibility (isolated CPU paths, independent scheduling) while=20 avoiding multiple processes, multiple VERSION messages, and multiple=20 physical sockets. Conceptually: ``` enum TrafficClass { HOT_BLOCK, COLD_BLOCK, TX_RELAY, ADDR_GOSSIP,=20 META_HEAVY } function classify(msg): if msg.type =3D=3D BLOCK and is_recent(msg): return HOT_BLOCK if msg.type =3D=3D BLOCK and is_old(msg): return COLD_BLOCK if msg.type in {TX, INV_TX}: return TX_RELAY if msg.type in {ADDR, ADDRV2}: return ADDR_GOSSIP return META_HEAVY function allow(class): if class =3D=3D TX_RELAY and !config.tx_relay: return false if class =3D=3D COLD_BLOCK and !config.archive: return false return true ``` Obviously the exact implementation details would differ, but the idea is to= =20 show that a single-process, single-socket design can still support multiple= =20 internal relay lanes. Do you see any drawbacks with internalising the traffic classes rather than= =20 exposing multiple processes, sockets or service bits? Curious if I=E2=80=99= m=20 missing a constraint. Kind regards, Defenwycke On Thursday, December 4, 2025 at 11:16:52=E2=80=AFPM UTC Antoine Riard wrot= e: > Hi list, > > Surfacing an old idea concerning the network-level and the current=20 > meddling of block, > tx and addr messages traffic generally all over one network link.=20 > Historically, for > example, if you consider bitcoin core by default connections are going to= =20 > be FULL_RELAY. > Over the last years, there has been few improvements to separate network= =20 > links by types > e.g with the introduction of dedicated outbound BLOCK-RELAY connections= =20 > [1], without the > segregation at the network-level between the class of traffic really bein= g=20 > pursued, or at > least more flexibility in network mechanisms to signal to a node's peers= =20 > what categories > of messages will be processed on a given link. > > Previously it has been shown that leveraging tx-relay's orphan mechanism= =20 > can allow to map > a peer's network-topology [2] (sadly, one trick among others). Being able= =20 > to infer a peer's > "likely" network topology from tx traffic, one can guess the peers used t= o=20 > carry block-relay > traffic. From the PoV of an economical node, dissimulating the block-rela= y=20 > traffic is a very > valuable to minimize the risks of escalation attacks based on=20 > network-topology (e.g for > lightning nodes [3]). > > Segregating more network traffic by class of messages sounds to suppose 1= )=20 > being able to signal > among the {ADDR, ADDRV2} service bits if block, addr or tx relay is=20 > supported on a link to be > opened for a pair of a (net_addr, port) or alternatively 2) if network=20 > link are open blindly > with peers, being to signal in the VERSION message or with a dedicated=20 > message what class of > message is supported. There is already a signaling mechanism in the=20 > VERSION message to > disable tx-relay (i.e `fRelay`), however there is no signaling to disable= =20 > block-relay over a link. > Alternatively, it has been proposed in the past to add a new early messag= e=20 > among all the other > handshake messages between the VERSION / VERACK flow, but it has never=20 > been implemented [4]. > > For bitcoin backbone, started to natively isolate each class of traffic i= n=20 > its own process, and > only strictly signaling what is needed in the VERSION message. Though, I'= m=20 > starting to reach > the limit of the current network mechanisms, e.g I've an `archive_relayd`= =20 > process to service "cold" > blocks, dissociate from the process doing full block-relay traffic, and= =20 > this process is emitting versions > messages, with the NODE_NETWORK bit set and the others process would have > NODE_NETWORK_LIMITED. If you're asking the why of dissociating "cold" fro= m=20 > "hot" block relay > servicing, that avoids wasting CPU cycles on a busy code path. > > Anyway, for now I think I can come up with good hacks with the service=20 > field and experimental bit > services. One drawback, it's just one "logical" node might start to occup= y=20 > multiple "physical" sockets > of its peers (one for tx-relay, one for block-relay), but network-wide=20 > this might not be the most > ressource-preserving approach, so I'm wondering if better mechanisms are= =20 > worthy to muse about. > > Cheers, > Antoine > OTS hash: 22f8cfbd2b1fd093f6bb8737f3ddcdb956f8dadb1b9436dab3c8491e4b5583f= d > > [0]=20 > https://github.com/bitcoin/bitcoin/blob/master/src/node/connection_types.= h > [1] https://github.com/bitcoin/bitcoin/pull/15759 > [2] https://discovery.ucl.ac.uk/id/eprint/10063352/1/txprobe_final.pdf > [3] https://arxiv.org/pdf/2006.01418 > [4] https://github.com/bitcoin/bips/blob/master/bip-0338.mediawiki > --=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/= de958fe0-5897-4fb0-9b4c-b41f5c63296bn%40googlegroups.com. ------=_Part_726283_2046511103.1765321985691 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Antoine,

This is an interesting problem, and introducing f= iner-grained traffic classes certainly makes sense. The three areas that st= and out to me are peer declaration, topology inference and system bottlenec= ks.

Peer declaration:

Explicit signalling of special= ised roles (Example - I only relay hot-blocks) to peers increases the finge= rprint/profile. We already see topology inference attacks via relay behavio= ur; adding public role declarations may expand that surface. Nodes can alre= ady drop or deprioritise whatever they wish locally, so explicit signalling= may not be necessary.

Topology inference:

=
Since topology inference can be drawn from tx-relay timing and r= elay behaviour, an internal class-based model also allows the node to rando= mise acceptance, forwarding, and scheduling behaviour per class. Even small= amounts of deliberate jitter or probabilistic message handling make it far= harder for an observer to infer which peers are responsible for block-rela= y versus tx-relay traffic. This further reduces the value of explicit capab= ility signalling, since role exposure can be disguised at the behavioural l= evel instead.

System bottlenecks:

Introducing m= ultiple traffic classes as separate processes and sockets increases resourc= e consumption, as you=E2=80=99ve noted. A single connection can already mul= tiplex all P2P message types.

A cleaner approach might be to int= egrate the class separation internally, without advertising anything to pee= rs. Incoming messages can be classified (Examples - hot blocks, cold blocks= , tx, address gossip, etc.) and per-class policies applied locally. Since a= node doesn=E2=80=99t need to receive or forward traffic it doesn=E2=80=99t= want to handle, it seems unnecessary to declare toggle roles at handshake = time.

An additional benefit of integrating classes internally is= that it gives a natural place for per-class bandwidth accounting and load = shedding. Under congestion, hot-block traffic could be prioritised while le= ss critical classes (Example - cold block serving) are throttled, without m= ultiplying sockets or increasing signalling surfaces.

Externally= the peer sees a normal connection; internally the node routes each message= into class-specific queues and rate-limit buckets. This preserves flexibil= ity (isolated CPU paths, independent scheduling) while avoiding multiple pr= ocesses, multiple VERSION messages, and multiple physical sockets.
Conceptually:

```
enum TrafficClass { HOT_BLOCK, CO= LD_BLOCK, TX_RELAY, ADDR_GOSSIP, META_HEAVY }

function classify(= msg):
=C2=A0 =C2=A0 if msg.type =3D=3D BLOCK and is_recent(msg): retur= n HOT_BLOCK
=C2=A0 =C2=A0 if msg.type =3D=3D BLOCK and is_old(msg): = =C2=A0 =C2=A0return COLD_BLOCK
=C2=A0 =C2=A0 if msg.type in {TX, INV_T= X}: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return TX_RELAY
=C2=A0 = =C2=A0 if msg.type in {ADDR, ADDRV2}: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 re= turn ADDR_GOSSIP
=C2=A0 =C2=A0 return META_HEAVY

function a= llow(class):
=C2=A0 =C2=A0 if class =3D=3D TX_RELAY =C2=A0and !config.= tx_relay: =C2=A0 =C2=A0return false
=C2=A0 =C2=A0 if class =3D=3D COLD= _BLOCK and !config.archive: =C2=A0 =C2=A0return false
=C2=A0 =C2=A0 re= turn true
```
Obviously the exact implementation details wou= ld differ, but the idea is to show that a single-process, single-socket des= ign can still support multiple internal relay lanes.

Do you see = any drawbacks with internalising the traffic classes rather than exposing m= ultiple processes, sockets or service bits? Curious if I=E2=80=99m missing = a constraint.

Kind regards,

Defenwycke

= On Thursday, December 4, 2025 at 11:16:52=E2=80=AFPM UTC Antoine Riard wrot= e:
Hi list,

Surfacing an old idea concerning the network-level= and the current meddling of block,
tx and addr messages traffic general= ly all over one network link. Historically, for
example, if you consider= bitcoin core by default connections are going to be FULL_RELAY.
Over th= e last years, there has been few improvements to separate network links by = types
e.g with the introduction of dedicated outbound BLOCK-RELAY connec= tions [1], without the
segregation at the network-level between the clas= s of traffic really being pursued, or at
least more flexibility in netwo= rk mechanisms to signal to a node's peers what categories
of message= s will be processed on a given link.

Previously it has been shown th= at leveraging tx-relay's orphan mechanism can allow to map
a peer= 9;s network-topology [2] (sadly, one trick among others). Being able to inf= er a peer's
"likely" network topology from tx traffic, one= can guess the peers used to carry block-relay
traffic. From the PoV of = an economical node, dissimulating the block-relay traffic is a very
valu= able to minimize the risks of escalation attacks based on network-topology = (e.g for
lightning nodes [3]).

Segregating more network traffic b= y class of messages sounds to suppose 1) being able to signal
among the = {ADDR, ADDRV2} service bits if block, addr or tx relay is supported on a li= nk to be
opened for a pair of a (net_addr, port) or alternatively 2) if = network link are open blindly
with peers, being to signal in the VERSION= message or with a dedicated message what class of
message is supported.= There is already a signaling mechanism in the VERSION message to
disabl= e tx-relay (i.e `fRelay`), however there is no signaling to disable block-r= elay over a link.
Alternatively, it has been proposed in the past to add= a new early message among all the other
handshake messages between the = VERSION / VERACK flow, but it has never been implemented [4].

For bi= tcoin backbone, started to natively isolate each class of traffic in its ow= n process, and
only strictly signaling what is needed in the VERSION mes= sage. Though, I'm starting to reach
the limit of the current network= mechanisms, e.g I've an `archive_relayd` process to service "cold= "
blocks, dissociate from the process doing full block-relay traffi= c, and this process is emitting versions
messages, with the NODE_NETWORK= bit set and the others process would have
NODE_NETWORK_LIMITED. If you&= #39;re asking the why of dissociating "cold" from "hot"= block relay
servicing, that avoids wasting CPU cycles on a busy code pa= th.

Anyway, for now I think I can come up with good hacks with the s= ervice field and experimental bit
services. One drawback, it's just = one "logical" node might start to occupy multiple "physical&= quot; sockets
of its peers (one for tx-relay, one for block-relay), but = network-wide this might not be the most
ressource-preserving approach, s= o I'm wondering if better mechanisms are worthy to muse about.

C= heers,
Antoine
OTS hash: 22f8cfbd2b1fd093f6bb8737f3ddcdb956f8dadb1b94= 36dab3c8491e4b5583fd

[0] https://github.com/bitcoin/bitcoin/blob/master/src/node/connection_t= ypes.h
[1] https://github.com/bitcoin/bitcoin/pull/15759
[2] https://discovery.ucl.ac.uk/id/eprint/10063352/1= /txprobe_final.pdf
[3] http= s://arxiv.org/pdf/2006.01418
[4] https://g= ithub.com/bitcoin/bips/blob/master/bip-0338.mediawiki

--
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/de958fe0-5897-4fb0-9b4c-b41f5c63296bn%40googlegroups.com.
------=_Part_726283_2046511103.1765321985691-- ------=_Part_726282_946233558.1765321985691--