From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Splitting more block, addr and tx classes of network traffic
Date: Thu, 4 Dec 2025 22:33:43 +0000 [thread overview]
Message-ID: <CALZpt+Hx9vFwNQd6qGSFMWXU=A6j82m6ZjJg3JaHK26WW0UQZw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3714 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4608 bytes --]
reply other threads:[~2025-12-04 23:16 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALZpt+Hx9vFwNQd6qGSFMWXU=A6j82m6ZjJg3JaHK26WW0UQZw@mail.gmail.com' \
--to=antoine.riard@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox