From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 04 Dec 2025 15:16:59 -0800 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vRIZG-0001PX-Tv for bitcoindev@gnusha.org; Thu, 04 Dec 2025 15:16:59 -0800 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-3e890878e46sf405150fac.1 for ; Thu, 04 Dec 2025 15:16:58 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1764890213; cv=pass; d=google.com; s=arc-20240605; b=FFfCqLM1c/aKI4DW9voa+rxzfJ4rsue6CVbjMqddutkF4xyn4U9oYK++KSEDLuYrB4 usl5rePafYyupCpKGiQrcXE0VnUgz/leZ6cTkd3esbIw6584Uq8qhDdQMNCyXiKtF8J1 iFt7VRSrqfSnrP/nLIvVd+sDJEjuW7ACVxET8pMqTvXtbZrjpO88NvqCXbnZ3vGrMUl8 08eChhM6K+BgUY9qevwxqWZkX+ooJigQH1MbVhy6lDLvXc74+L6nY4R7Uxruvr4Kwydj 0qTCot+n7etTpeVJm727cAjw99BJQreImuTB/aaop6ld9nj/7GJW5spI00paokw9NSGi NPfw== ARC-Message-Signature: i=2; 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:to:subject:message-id:date:from :mime-version:sender:dkim-signature:dkim-signature; bh=NtxgvCPgKMjfBARuqwAUpt8vz3CGnvr9lbfwE9FSG/I=; fh=1TZcFTqZPA6Dy2KTB6k7YLgGoR/Su+Vp/9kcjmhe0zs=; b=LSTvNvpxjcz1D/Xtasqw5ADllHa9rDSkDZysye26RZwtOpz1jgvYqn4mTEm4yYjcje stOLre45hEz+1L3EEL6KNtvCZnjgGjYI/IRT63OJRem6LSP14RJplqRz2CbEJXX8AoIN EKp6YDbCtKfM5J5HEYvKApFqzY4otA9gTiv5drwngFjtmzRFy3l0BnVG3babnV/OKGI6 KTSMKuoHbDMgw97WkWoklD9rArbKeOwxxAeN3YOgPJ1XDm1yUXYDtITaV6YeTNUGGyKt 4jqSILNoJO1VMSra32Uq7KccT1fH99vLsTYC7ozza27qsoQ+UH7yCofD4GyG6tHbuuBF 6o+w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Jt2eKieZ; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::431 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=20230601; t=1764890213; x=1765495013; 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:to:subject:message-id:date:from:mime-version :sender:from:to:cc:subject:date:message-id:reply-to; bh=NtxgvCPgKMjfBARuqwAUpt8vz3CGnvr9lbfwE9FSG/I=; b=XF2IOmDueOzSKsW9HDqUjnEt5Gc/KklidIPjdFEhN2tfBLOgXZ0JY/p3et+iwJdg0w Y6G7SaUj/5aU22fmUmB17ZXFL8TiWWCukIByOdVzJwI/Rmbd+NvPKcGUrHVHwVb62L45 PX+AVoKaZnNOjQ3dlpDmI0HGlYLzraEGMpP/C3p4KpgC2KccW2S7peuYGOOnRYj5HDQE XMIYDS7E3pOLfVDRON+bv4Qg0FWLB+JRm1l4PD01YKYTS2k6yL4kmw/xjqOUM/VZarHC SOIxP3uxa9ZexglfPPvavMniy2FtwYdUDHIC+VcwrmfWE8sjXo7DnFXt3txLiffW0YpH K1/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764890213; x=1765495013; 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:to:subject:message-id:date:from:mime-version:from :to:cc:subject:date:message-id:reply-to; bh=NtxgvCPgKMjfBARuqwAUpt8vz3CGnvr9lbfwE9FSG/I=; b=C2nWjFmHM6Ikiv+O+LdnN4VcefNO/4kr/nmouae1R/acqQJ/AVtuTBxQMP596w5/BD AgLWgkPeDsM51pEr3VJmocf0c1bzcEgMMl1KzneK8BufPZG638urY4D+K1FgGD57ln6E ZC6mgQhxwmlfMRpRoM1dtkRyxNQuG/ct3n4K+XWtflyLPLoKLIR2MOtuos+vC5Tg2lNN I9OotMotGQamGPMrQ7JiQofZgIk+4k0ZyK1pWgszA8hLPiDPxmIqK4AuFHebdTzhvvaU xUVXgQ8bExP5lZEM7q8pEPKgmpSRm+TolzCXIt7Yn4YY1jEjiCdsi5LEQ94PYNmWN63F osTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764890213; x=1765495013; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:subject:message-id:date:from:mime-version :x-gm-gg:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=NtxgvCPgKMjfBARuqwAUpt8vz3CGnvr9lbfwE9FSG/I=; b=EigoZ72g778Imxjsr5mdHVRU0ZhM8ad8BeftTi+jxsDjWBrL1b07iInP4Go5qFZedl 011x7hRqOWjtXi5rnjfYL0Z+OIKtuZ5pTqN1f1VhXaMaEC4YLc4bVeFMUotQxM4GxTuG 2gbo6PJfGGr5c6pNVrZSGVBOZnN30nb9N8m/hnqR8EBqyQ0E87UT8qIUiABgpaQer4xw I4oVXjo/3pxr4e92kqyjbSaJzIuGErvk69eGoJZlde9MnCTAobrfbASMsutMAckri1tT 9WMcLGCOk3YEtK/wKLrlAQ+V0W2PEpnBG3qOy3ja4kxPfGSlRneJnOjx/Vk+crIzFLbl +EzQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVmRZ5zL72+uXaNL2vyrQoi6cqmbS4QyhZjJKfBopwIDaMxr2vDQPcaVrEk4/vUtCxgxRgn2ZmJER03@gnusha.org X-Gm-Message-State: AOJu0Yw/rKroEnAkTpzwGdsYAf3uJPdHus3TdkjujKQWNMD3B46+YCJN 1vBpLovbPuVJ9ZiTJw6gF2YS96l32bprwgdZ4xx8kSFA81wr4Mus0DxB X-Google-Smtp-Source: AGHT+IHbVkvwEwS+VCL0maUrBg3vPsQnPI++ATA8PugjYi98xeVSqGtO5+wSx0dWBB5fGfEpuZl2UA== X-Received: by 2002:a05:6870:d6a1:b0:3ec:4246:e6fc with SMTP id 586e51a60fabf-3f29758d0bdmr2763594fac.3.1764890212358; Thu, 04 Dec 2025 15:16:52 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+ak4lKJ1pUIi9mnNA/N73hGjB5pX4c7OGC9/5Qqhbrw0w==" Received: by 2002:a05:6871:2504:b0:3ec:4eb6:abba with SMTP id 586e51a60fabf-3f50904864fls608404fac.1.-pod-prod-05-us; Thu, 04 Dec 2025 15:16:47 -0800 (PST) X-Received: by 2002:a05:6808:1782:b0:453:315b:4f5c with SMTP id 5614622812f47-4536e55cbebmr4813913b6e.56.1764890207761; Thu, 04 Dec 2025 15:16:47 -0800 (PST) Received: by 2002:a05:620a:3f8d:b0:80d:5a8b:a44e with SMTP id af79cd13be357-8b64aab6565ms85a; Thu, 4 Dec 2025 14:33:56 -0800 (PST) X-Received: by 2002:a05:6214:d09:b0:87c:2bb6:741 with SMTP id 6a1803df08f44-888194cd3dfmr115053166d6.29.1764887635667; Thu, 04 Dec 2025 14:33:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1764887635; cv=none; d=google.com; s=arc-20240605; b=QbFLn/KpLoYmkurwr1/Cazh2RTMQNB/sHGE/j6r2+ksQ8VvPhC54sNz6N4VXimwA1k OG+XEAT9DXvqdrgl5dalJWK5NIprL7UvFzhcSdPfajJy0CufHyBb83VClK3f01Ad1ykv 9AKJFfyR5jLCzoPMN4eQHW5OHmdTzMgYF7o4TsPNcsWkhzkT3qC1B8Z+CptJuiRB8wkS 8V7O9GMkYbvF9FWs4rmBJdqJ7H1+W54nASU8Qjf/Bq9M9hFWKnQiOOuh3QXdyKa6TEHZ S7spZABBlX3Iojkgu9cYfmwtPfok2aZ5pzcfoD8ot7gJlY0n+35lfD2Pclo0oH2RShvT K2/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=DM82GYqmF6n37HrhXDeCVG91qDM0HdEdg5kfYpMmXEU=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=dXR5c8aubavkGSWP3qrlAE0D8IrR8xalYdLOX/c0prXymtJFKnE2mBZ5Qkmjq+t5y8 IVgEhwzcem3cny/sjVFWYWDzTyHAhJqQTkbT8z+5+aFkzvX+gU8G6driT82HZsOcW+Oe ISgd2vLrEveb9b9eNblU4eZrkAaUxncvPc68RTHXhzWSXhB1usPczqPuZuRvI7AD86tQ G5H3e2TOTqluwBrEAK7tIDyxQ+pUK+kwRtLFCaeIWC1OIPwboBjjILtPBUpj+RPHd42j E4++L6IlFLTkq5vdTNnAWHCRpvjZAckUGmlyXcd97ard2Lz3ygPBSWlqVbBvh9gJHzwE P7dw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Jt2eKieZ; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::431 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-pf1-x431.google.com (mail-pf1-x431.google.com. [2607:f8b0:4864:20::431]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-888282890f5si1088906d6.8.2025.12.04.14.33.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Dec 2025 14:33:55 -0800 (PST) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::431 as permitted sender) client-ip=2607:f8b0:4864:20::431; Received: by mail-pf1-x431.google.com with SMTP id d2e1a72fcca58-7b22ffa2a88so1488286b3a.1 for ; Thu, 04 Dec 2025 14:33:55 -0800 (PST) X-Gm-Gg: ASbGnct/FW3QZpghuSLdY0A6UQKjG0QFS3kFOo7mBhRGsJJiOfKFi0LDNxvvej53xPY n4eXI2g4lKKPrCQA2nGgwGuEGPiwbrogvEm+P3UIx21M7qxmBCSKiRbGIeUFIQ/JiHt66+m+rGn SY0xA7b1ZYcEBCn2rbKBfSPOEEjMQBBYVjRCLAbIQAqjv+ELS8/XFdMe/P9jnQiIb7uv2ceYc4Y 8ppb2X7w2dqShi7gEasM4YFPEY4fT8sZkLFw5Tm5KBZEmTQ87sq3F1mBN3XsSrcrRU+QV7U X-Received: by 2002:a05:7022:989:b0:11b:9386:a3c1 with SMTP id a92af1059eb24-11df0c5106emr5978393c88.44.1764887634148; Thu, 04 Dec 2025 14:33:54 -0800 (PST) MIME-Version: 1.0 From: Antoine Riard Date: Thu, 4 Dec 2025 22:33:43 +0000 X-Gm-Features: AWmQ_bk9CC0PXGlMXfYCtYr_K5TNL_3j5vjmX7SawDl8LPCyfPOhphFnQQc_BsA Message-ID: Subject: [bitcoindev] Splitting more block, addr and tx classes of network traffic To: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000808571064527ec7d" X-Original-Sender: antoine.riard@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Jt2eKieZ; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::431 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 (/) --000000000000808571064527ec7d Content-Type: text/plain; charset="UTF-8" Hi list, Surfacing an old idea concerning the network-level and the current meddling of block, tx and addr messages traffic generally all over one network link. Historically, for example, if you consider bitcoin core by default connections are going to be FULL_RELAY. Over the last years, there has been few improvements to separate network links by types e.g with the introduction of dedicated outbound BLOCK-RELAY connections [1], without the segregation at the network-level between the class of traffic really being pursued, or at least more flexibility in network mechanisms to signal to a node's peers what categories of messages will be processed on a given link. Previously it has been shown that leveraging tx-relay's orphan mechanism can allow to map a peer's network-topology [2] (sadly, one trick among others). Being able to infer 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 valuable to minimize the risks of escalation attacks based on network-topology (e.g for lightning nodes [3]). Segregating more network traffic by 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 link 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 disable tx-relay (i.e `fRelay`), however there is no signaling to disable block-relay 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 bitcoin backbone, started to natively isolate each class of traffic in its own process, and only strictly signaling what is needed in the VERSION message. 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 traffic, and 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" from "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 field and experimental bit services. One drawback, it's just one "logical" node might start to occupy multiple "physical" sockets of its peers (one for tx-relay, one for block-relay), but network-wide this might not be the most ressource-preserving approach, so I'm wondering if better mechanisms are worthy to muse about. Cheers, Antoine OTS hash: 22f8cfbd2b1fd093f6bb8737f3ddcdb956f8dadb1b9436dab3c8491e4b5583fd [0] 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 -- 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/CALZpt%2BHx9vFwNQd6qGSFMWXU%3DA6j82m6ZjJg3JaHK26WW0UQZw%40mail.gmail.com. --000000000000808571064527ec7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi list,

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

Previously it has been = shown that leveraging tx-relay's orphan mechanism can allow to map
a= peer's network-topology [2] (sadly, one trick among others). Being abl= e to infer a peer's
"likely" network topology from tx traf= fic, 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=
valuable to minimize the risks of escalation attacks based on network-t= opology (e.g for
lightning nodes [3]).

Segregating more network t= raffic by class of messages sounds to suppose 1) being able to signal
am= ong the {ADDR, ADDRV2} service bits if block, addr or tx relay is supported= on a link to be
opened for a pair of a (net_addr, port) or alternativel= y 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 su= pported. There is already a signaling mechanism in the VERSION message todisable tx-relay (i.e `fRelay`), however there is no signaling to disable= block-relay over a link.
Alternatively, it has been proposed in the pas= t to add a new early message among all the other
handshake messages betw= een the VERSION / VERACK flow, but it has never been implemented [4].
For bitcoin backbone, started to natively isolate each class of traffic i= n its own process, and
only strictly signaling what is needed in the VER= SION message. Though, I'm starting to reach
the limit of the current= network mechanisms, e.g I've an `archive_relayd` process to service &q= uot;cold"
blocks, dissociate from the process doing full block-rela= y traffic, and 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" from "h= ot" 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 wi= th the service field and experimental bit
services. One drawback, it'= ;s just one "logical" node might start to occupy multiple "p= hysical" sockets
of its peers (one for tx-relay, one for block-rela= y), but network-wide this might not be the most
ressource-preserving app= roach, so I'm wondering if better mechanisms are worthy to muse about.<= br>
Cheers,
Antoine
OTS hash: 22f8cfbd2b1fd093f6bb8737f3ddcdb956f8= dadb1b9436dab3c8491e4b5583fd

[0] https://github.com/bitc= oin/bitcoin/blob/master/src/node/connection_types.h
[1] https://github.com/bitcoin/bi= tcoin/pull/15759
[2] https://discovery.ucl.ac.uk/id/eprint/10063= 352/1/txprobe_final.pdf
[3] https://arxiv.org/pdf/2006.01418
[4] https://github.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/bitcoindev/CALZpt%2BHx9vFwNQd6qGSFMWXU%3DA6j82m6ZjJg3JaHK26WW0UQZw%= 40mail.gmail.com.
--000000000000808571064527ec7d--