# Hiding the source of a segmented payload > **Early draft, 2026-10-13.** Shared for comments before publication; the text and the measurements may still change. *Privacy is hard. Networking with privacy is harder. Networking at its most efficient, with privacy, is impossible.* *TL;DR: Every copy of a payload starts at its source, and the source's neighbours can tell: in segmented diffusion, and already in today's whole-message gossip. No change we tried in how the source sends hides it from them, and we expect none can. Letting the payload enter the network at another node does, at a delay of about a tenth of a second or less over warm connections; the simplest form has one node that knows, and for the most private form, getting copies in place in time is still open. Nothing here protects against an observer of the source's own link. Not every node needs this: each source can make that choice per payload, the network's default stays fast, and it pays off only once nothing else its validators publish names the node.* When a validator proposes, its node publishes the block, and a self-builder publishes the payload as well. Whoever can tell which node published them learns where that validator sits on the network: an address to attack the next time it proposes, and a link from the validator to its operator. For a home staker, that address is its home connection. Our earlier posts, [*What segmented payload diffusion is made of*](https://ethresear.ch/t/eip-8411-what-segmented-payload-diffusion-is-made-of/26025) (2026) and [*Informed Diffusion*](https://ethresear.ch/t/informed-diffusion-making-home-builders-publish-fast/26151) (2026), made payloads fast by cutting them into coded *chunks* that every node forwards as they arrive, long before it holds the whole payload.[^eip] That raises a fair question: does it make the node that publishes, the payload's *source*, easier to find? And if a source wants to hide, what can it do? This post answers both. The source's neighbours find it either way, for a reason we expect no change in its behaviour to remove. What hides it is letting the payload enter the network somewhere else. We show what that costs, what is still open, and why it matters only together with everything else a validator publishes. We focus on a home staker that builds its own payloads. It proposes rarely, so we ask what a single payload reveals. That is the floor of its exposure: the protocol links a validator's proposals, and its attestations go out every epoch. [^eip]: [EIP-8411](https://github.com/ethereum/EIPs/blob/41ba25ccbf3f5dc441d7d049d0bc6ec9ad8e8215/EIPS/eip-8411.md) at revision `41ba25cc` itself specifies chunked gossip; the code, the HAVE announcements and the publishing policies we measure here are the design developed in those posts, and the results are for that design. ## Who is watching? Ethereum's consensus clients spread messages with gossipsub: each node pushes every message to its *mesh*, about eight of its peers, and tells a sample of its other connections what it holds. We sort the observers by where they stand, and label them L1 to L8, roughly by how much access each has: - **Next to the source.** One of its mesh peers (L2); a few of them colluding (L3); and an adversary that targets a suspect by peering with it, probing it or delaying it (L5), which sees passively what L2 and L3 see once it lands in the suspect's mesh.[^l5] - **Across the network.** Any node, guessing that the neighbour it heard from first is the source (L1); spies spread over a share of all nodes, pooling everything they see (L4); and an adversary that knows the gossip graph and intersects the neighbourhoods of the nodes that published a builder's successive payloads (L7). - **On the way.** A node that handles the payload for the source before it is published (L8), and an observer of the network links themselves, such as the source's provider (L6). A neighbour does not know that it sits next to the source. For each payload it must point at one of its neighbours or say "none of mine", and we score how often it points at the right one. [^l5]: Its active forms, probing and delaying, we did not evaluate. ## Today's gossip already gives the source away In today's gossip every node receives the whole payload before it forwards it, so holding the payload is nothing special. Two things still single out the source. **It speaks first.** A gossipsub node tells its mesh peers when it has a large message, so that they do not send it again: an IDONTWANT. In the gossip library we simulate, every node sends one just before its own copy, the source included, but only the source's is the first word of the message on every one of its mesh links; a forwarding node's rarely is.[^idw] One neighbour that notices names the source with certainty, accusing no one else.[^setting] **Its bytes arrive first.** A node can forward a whole message only once it holds all of it, so the source's first bytes reach its neighbours a whole transfer ahead of anyone else's. Alone, that is a weak tell: far from the source, a node's first sender often leads by as much. Weighed together with what each neighbour is offered, it is mostly right even with no IDONTWANT at all. That second tell depends on where the observer looks. A gossip library reports a message to its application when the last byte has arrived, and traces of those reports are the usual way to study gossip. An attacker's node need not wait for the report: it sees the packets on its own connections as they arrive, and for a whole 1 MiB payload the first byte comes most of a second earlier. Spies spread across the network that watch packets name the source nearly twice as often as spies that see only what their library reports; without IDONTWANT, one neighbour goes from right about one time in five to mostly right. **A study of library traces would understate what spies and timing give away in today's gossip.** The segmented results do not have this problem: a chunk is a few kilobytes, its first byte and its arrival are milliseconds apart, and the attacks read nearly the same from either. [^idw]: go-libp2p-pubsub, since [v0.14](https://github.com/libp2p/go-libp2p-pubsub/releases/tag/v0.14.0). Before it, the source was the one mesh peer that pushed without sending IDONTWANT, which singles it out as well. We have not checked other clients' timing. [^setting]: We measure in a simulation that runs the real client and gossip-library code: 500 nodes in the *all-home network*, where every node, the source included, has 50 Mbps up and 100 down, and a 1 MiB payload. Each attack is an estimator run over what the simulated nodes saw; the results describe those attacks, not guarantees against every attacker. "Certain" means no false accusation at a useful rate of detection, in the typical network; for today's gossip it held in all but one of our networks. Results marked *computed* come from a model, and *argued* ones have no run behind them. Where single nodes and small groups (L1–L3) fall short of certain, they would be right less often in a network twenty times larger, because the share of observers next to the source falls with network size. ## What does segmentation change? Segmented diffusion is fast because nodes forward chunks as they arrive, long before they hold enough to decode the payload, which any large enough set of its coded chunks rebuilds. Every node starts with nothing and fills up, except one. **The source is the only node that is complete before it forwards**, and its neighbours can see it: - **in what it announces:** nodes describe the chunks they hold in a *HAVE bitmap*, and the source's could name every chunk before any has arrived anywhere, or tell different neighbours different things; - **in how much it sends:** it pushes each neighbour more chunks than a forwarding node that reached that neighbour first would, and a few colluding neighbours together receive more distinct chunks from it than any forwarding node we observed pushes into its whole mesh; - **in when it sends:** every node has some neighbour that talks to it first, so being first means little; but *by how much* the source is first does tell. A forwarding node's neighbours often get the same chunks early from someone else; the source's neighbours have no other early upstream. We call this lead the **root pattern**. One neighbour that weighs all of this names the source with certainty, as in the gossip we simulate, and a few colluding neighbours do it from a single count (Figure 1). **For its neighbours, segmentation changes why they find the source, not whether.** Across the network, one choice decides. A source can *stripe*: push its chunks over all its seventy or so connections at once, not only its mesh, which no forwarding node does. Striping makes spies spread across the network more successful than against today's gossip, almost always right, and leaves a node anywhere about where today's gossip has it. Without striping, a node anywhere is right about a quarter as often as against today's gossip, and spies much less often.  *Figure 1. Local observers, one attack per panel; (a) and (b) are scored over every observer, not only the source's neighbours. (a) One mesh peer combining every tell it can measure (L2): how often its accusation is right, against how often the source's mesh peers accuse it. (b) Colluding mesh peers (L3) using timing alone: how often their accusation is right, at a detection of one in two, against their number. (c) Colluding mesh peers of the source (L3) pooling the chunks it pushed them: how often they are certain of it, against their number, scored over the source's own coalitions; shown where the runs recorded which chunks were pushed. The whole message is timed at the first byte of each transfer, as an observer of the packets sees it. (b) and (c) each use one tell; the whole message's mesh peers are certain through IDONTWANT, which only (a) sees.* ## Why can't the source hide by itself? The obvious fix is to make the source behave like a forwarding node. It does not work, and the reason fits in a single scene. Picture the moment of release. The source holds every chunk; no other node holds one. Whatever it does next, its neighbours are watching. - If it announces what it holds, its HAVE names every chunk at a moment when no other node could name a single one. Any neighbour that receives it knows. - So it announces only what it has already sent, as if it too were filling up. But it keeps pushing chunks, different ones to different neighbours, and a forwarding node can only push what it has received: a handful of neighbours that pool what it pushed them count more distinct chunks than any forwarding node we observed pushes into its whole mesh. Announcing less than it has sent would be worse: two neighbours comparing notes see the gap. - And whatever it announces, it is first, by a margin only a direct link gives. The root pattern is geometry: announcing or pacing differently does not touch it, and feeding only a few neighbours at first moves it onto those few. **Every chunk starts at the source.** It is the first node able to decode, and either it says so first, or it holds back what it has, and the holding back shows. We tested this directly. The *source-only private mode* changes the source alone, with every other node unchanged: no striping; a HAVE that grows only as chunks actually leave; one copy per chunk, capped per peer, so each neighbour gets about what a forwarding node would send; and offering and answering nobody (what the stack post calls announcing to nobody), so its neighbours never pull from it. Each change removed one tell and exposed another. A source that pushes but is never asked stands out, because a forwarding node that pushes to a peer has also offered it chunks and been asked for some. So, in a separate experiment not in Table 1, we gave the source a forwarding node's whole profile. It offered and answered at a forwarding node's pace, admitted its own chunks into its router on a forwarding node's schedule, and fed only two neighbours at first. That staggering hides the root pattern from timing alone. But one neighbour that combines timing, announcements and transfers still names the source, and the delay reaches several hundred milliseconds. Throttling the source further starves the network, and its lead grows instead of shrinking. We read this as a limit, though we have not proved it for every possible policy. BitTorrent met the same wall: its initial seeders hid their completeness by announcing partial copies, and were found anyway, by observers joining early and linking one uploader's torrents (Le Blond et al.), much as a builder's payloads are linked by its bids. ## The way out: move where the payload enters If the source cannot look like a forwarding node, it can become one. Let another node publish the payload, and the source's own router never learns it early: when the chunks come back, it forwards them like everyone else, and its neighbours see an ordinary node because that is what it is. What remains is who that other node is, and what it learns. There are three answers, from the simplest to the most private. **1. An address of your own.** No protocol change is needed: publish through a second node, an address you can afford to expose. For a home staker that can be a cheap node rented in the cloud that only forwards: it holds no keys, it receives the payload from home and publishes it. Its neighbours find it, as they find any source, but it is not your home. It costs one transfer of the payload from home, and from the cloud's usually faster uplink it then publishes more like a datacenter builder. Its host sees your validators' identity and the payload early, it can be attacked, and it helps only if every duty and every fallback leaves through it too. We did not simulate it; it is the same move, made by hand. **2. A stem: one node that knows.** The source hands the payload to one peer, the *stem*, which publishes it as if it were the origin: Dandelion's stem, cut to one hop (Bojja Venkatakrishnan et al.; Fanti et al.). The source's neighbours see a forwarding node, and spies across the network fall to their own share. The price is one node that always knows the source and can withhold the payload. Over a connection kept warm, the hand-off adds about a hundred milliseconds; over a cold one, the first message pays most of a second. A stem should be kept. Each new stem adds exposure, and for a node that proposes a few times a year, a stem drawn per epoch is drawn per proposal; keep it across proposals, for months, as Tor keeps its guards (Dingledine et al., 2014). An adversary that knows the graph can intersect the neighbourhoods of successive stems: by our analysis on random and geographically clustered graphs, a one-hop stem falls after a few changes. A two-hop stem resists if both its first hop, the *guard*, and its second hop are kept, for a bit over a hundred milliseconds more. Denial of service on the stem can force a change, and retries can weaken anonymity (Borisov et al.). **3. Routes: nobody who knows for sure.** Routes follow Crowds (Reiter and Rubin). For each payload the source draws two short random routes, over connections outside the gossip graph; at each hop a node passes the payload on with probability one half, or ends the route. Every node on a route already holds the payload encrypted, carried to it along the same route before the release, so it learns no more from the copy than from the key. At release only a short key travels each route, and each route's last node decrypts and publishes. What we measured, with the copies already placed and the route links modelled: - the source's neighbours stay at the base rate of guessing, and the timing lead is gone; - intersecting the publishers' neighbourhoods found nothing over a handful of messages;[^isect] - one withholding route delays delivery but does not stop it; - the release costs a few tens of milliseconds. What we computed: - a node on a route sees its predecessor but cannot tell whether it originated the payload or forwarded it: by Crowds' arithmetic, with every node as likely as any other to be the origin, it is right about one time in two;[^clock] - spies are a given route's first hop about as often as their share of the network, provided route nodes come from a pool they cannot flood and a node opens its forwarding connections the same way whether it originates or forwards; over the two routes that is about twice their share, at that one-in-two confidence; - two withholders, one on each route, do stop delivery: about one payload in a hundred at a few per cent of spies.[^disjoint] Fanned out, routes can even be faster than publishing directly. Each route's last node passes the key to a set of slice publishers among which the chunks were dealt in advance, so the payload enters the network at dozens of points at once while the source still has only its two routes: a relative of information slicing (Katti et al.), with the anonymity coming from the routes. In our runs it beat the source publishing with or without striping, because the wide first hop happened before the release. Losing one branch leaves exactly the chunks needed to decode, with no slack. **The catch is placement.** The encrypted copies must be in place before the reveal, and a payload can only be built on the previous slot's, which is due halfway through that slot. A self-builder prepares the block and the payload together, so its copies can start out as soon as it has built them; how early it builds is its own trade, time to place the copies against a fresher payload. In practice that leaves a few seconds at most, along routes of a few hops. A form that streams coded slices at release, without placed copies, is therefore the normal case for a self-builder, not a corner; it is designed but not measured.[^builder] Table 1 puts the options side by side, and Figure 2 shows what each costs against what it buys. | who is looking | whole message | segmented, striped | segmented, source-only private mode | one-hop stem | routes | |---|---|---|---|---|---| | ***next to the source*** | | | | | | | L2, one mesh peer | certain† | certain | certain, combining its tells | sees a forwarding node | sees a forwarding node | | L3, a few colluding peers | certain† | certain | certain from a handful | sees a forwarding node | sees a forwarding node | | ***across the network*** | | | | | | | L1, a node anywhere | rarely right | about as often | about a quarter as often | about never | about never | | L4, spies across the network | high | high | below whole message | the spies' own share | about twice the spies' share, at one-in-two confidence‡ | | L7, a graph-aware adversary | – | – | – | falls after a few stem changes; resists as a two-hop stem kept across proposals‡ | found nothing over a handful of messages | | ***on the way*** | | | | | | | L8, a node on the path | – | – | – | the stem knows the source | cannot tell origin from forwarder, about one in two‡ | | L6, an observer of the source's link | likely§ | likely§ | likely§ | likely§ | likely§ | | **added delay at 1 MiB** | – | – | tens of ms | about a hundred ms, warm | a few tens of ms, copies placed | *Table 1. Who finds the source, by publishing mode, in the all-home network at 1 MiB.[^setting] The entries summarize the attacks we ran, not guarantees. "Certain": no false accusation observed at a useful rate of detection, in the typical network. The whole message is timed at the first byte of each transfer, as an observer of the packets sees it; for a chunk, first byte and arrival are milliseconds apart. † Through IDONTWANT, in the gossip library we simulate; without it, one mesh peer is still mostly right. ‡ Computed, not measured. § Argued. L5 sees passively what L2 and L3 see and has no row. Delays are against the source publishing without striping; striping, which a source as fast as its peers does not use, is about as fast at this size.*  *Figure 2. What each mode costs and what it buys, at 1 MiB in the all-home network. Horizontal: the added release-to-delivery delay (the 99th percentile over nodes, messages after the first) against the source publishing without striping. Vertical, one attack per panel: (a) how often one mesh peer's accusation is right (L2), (b) how often spies on 5 % of the nodes name the source (L4), (c) how often a node anywhere does (L1); (b) counts spies in the gossip network only, spies on the routes are computed above. Hollow: routes, whose encrypted copies were placed before the release.* [^isect]: With route nodes drawn from all nodes alike. Drawing them away from the source's own connections had made the source the one node never next to a publisher. [^clock]: In [ePBS](https://eips.ethereum.org/EIPS/eip-7732), enshrined proposer-builder separation, the block arrives before the payload and gives every node a clock; what a route node reads from the key's arrival against the block, or from when its copy was placed, we have not measured. [^disjoint]: Our routes were disjoint by construction, which a real source cannot ensure. [^builder]: A builder other than the proposer learns that its bid won only from the block, and would hardly hand its payload to anyone before; with routes it could, since the copies are encrypted, and a lost bid then costs the placement's bandwidth, its own and its route nodes'. ## What about the source's own link? None of these designs protects against an observer of the source's network link (L6), such as its provider. The tell there is the one this post keeps meeting: the source uploads the payload before anything of it has come in. Hiding that is the problem of traffic flow confidentiality: padding, dummy packets and timing applied to an encrypted link (Kiraly et al.; standardised for IPsec tunnels as IP-TFS, RFC 9347). Its full form, a constant rate, hides everything at a constant cost. Behind a tunnel to an address it can afford to expose, a source could use a fixed schedule: from a fixed time in every slot, a burst of fixed length and rate in each direction, long enough to carry any payload that comes in while it runs, real bytes replacing padding as they arrive in whichever direction the payload travels, and padding in the other. Its own copy then arrives at the burst's pace, and the link carries one such burst each way per slot, one of them padding. We have not measured it. A hand-off, a placement or a key release could still be correlated with the slot schedule by an observer of the forwarding traffic. Low-latency anonymity networks, including one built at the network layer from IPsec tunnels (Kiraly and Lo Cigno), leave that observer out of their threat model and point to traffic flow confidentiality against it. The anonymity literature prices that protection in cover traffic and delay (Das et al.'s trilemma): mix networks such as Loopix add delay by design, and basic DC-nets have every participant send a payload-sized contribution, whether or not it is the sender (Chaum). We have not evaluated a design that meets the payload's deadline with that protection. ## A payload is one of many things a validator publishes Hiding the payload's source helps only if nothing else the validator publishes leads back to the same node, and much can. **Attestations already do, every epoch.** They travel on 64 subnets, and a node forwards attestations only on the few it has joined, so a node that keeps publishing on subnets whose traffic it does not forward associates its validators with itself. Observers joined to all subnets located more than a seventh of all validators in three days this way (Heimbach et al.). It is a heuristic over repeated observations, and a target joined to all subnets defeats it, at the bandwidth of every subnet, leaving the weaker timing tells any gossip has. And since the [proposer schedule](https://eips.ethereum.org/EIPS/eip-7917) is public an epoch ahead, once a validator is tied to a node, that node is known before it proposes. **A proposal is three publications.** The block is small, goes whole and comes first; it must leave by the payload's private path, or from an address that is not the node's. The payload is the subject of this post. The blob columns could be the weakest channel or the cheapest to hide: a builder that publishes all 128 columns itself pushes into subnets it does not belong to, the same kind of tell as striping, of a strength we have not measured, while blobs only the builder knows must take the payload's private path.[^columns] **Other duties ride the same address:** aggregates, sync-committee messages every slot while serving, payload-timeliness votes, and the proposer preferences a validator may send an epoch ahead in Gloas, the fork that brings enshrined proposer-builder separation (ePBS); sending none says it takes no trustless bids, which points to self-building. A registered builder also exposes its bids, losing ones included. Each needs a publication policy, though not necessarily the same route: a separate address that does not lead back to the node is enough. A home operator proposes rarely but attests every epoch, so routes drawn afresh, which suit its payloads, would not suit its attestations. **Secret leader election** complements all of this. It hides the next proposer until the block (Boneh et al.), removing the warning an attacker has today even when validator addresses are known. It does not hide the node that publishes, and in ePBS the block names the proposer before the payload, whose timeliness deadline is halfway through the slot. We did not simulate any of these channels; this section is argued from the protocol and, for attestations, from published measurements. [^columns]: Nodes that already hold the blob data can rebuild the columns from the block's commitments, as clients already do, but the block alone is not enough, and we know of no measurement of how often the blobs are already in place. In Gloas, the fork that brings ePBS, publishing the columns is the builder's duty: a builder that publishes only its own custody columns, no earlier than a node that has just received the block, trades privacy for an availability risk, and its fallback cannot be publishing the rest itself. ## Not every node needs this What we hide is where the source sits in the network, not who it is. A self-built block says so itself (its bid carries the self-build marker), so a source that visibly takes a private path tells an observer nothing new about who it is, only that it chose privacy. That is what lets privacy be a choice of the few sources that need it, made per payload, while every other node keeps the fast default. - **A home self-builder**, the case we care about, loses little: without striping it is also at its fastest. Today it can publish through a cheap node of its own in the cloud that only forwards (the first answer above), and check that every duty and every fallback leaves there. Stems and routes are experimental alternatives, with the open questions below. - **A validator using an external builder** publishes the block and its other duties. It can separate the addresses that attest and propose, or use one exposed sentry for both, covering aggregation, sync-committee and payload-timeliness duties. - **A professional builder** publishes many times a day, from addresses it can expose without revealing its core infrastructure. Striping is a speed choice that makes those addresses easier to find; repetition rules out the source-only modes we tried, and its bids link its payloads anyway. - **A large staking operator** separates public publishing addresses from its core infrastructure, and attesting from proposing where useful, and audits duplicate and fallback publication. - **Every other node** runs segmented diffusion as it is. Only routes would ask something of it: forwarding keys and holding placed copies for others. ## What's next? Moving the entry point works in our runs. Making it work in Ethereum leaves these questions open: - **Placement in time.** Can the copies reach their route nodes in the few seconds a self-builder has, or is streaming coded slices at release the form to build? - **Who pays for routes.** Every node would forward keys and hold copies for others, a cost on all for the benefit of a few. How large is it, and how should it weigh against making routes a default? - **A stem that fails safe.** If the payload does not appear, the source must not publish it itself, which names it at once, and an attacker must not be able to force re-routes cheaply. This is not built. - **Repeated publication.** Fresh routes suit a node that publishes a few times a year. One that publishes many times a day would be found by the predecessor attack (Wright et al.), and needs routes kept across messages, as a guard is. - **The link within the deadline.** Can traffic flow confidentiality hide a source from its own link at a cost the slot allows? - **The other duties.** Columns, attestations and the rest each need a publication policy; none was simulated here. - **Other clients.** We checked the IDONTWANT timing of one gossip library only. For a home self-builder the step that matters most is the oldest one: let every duty its validators perform leave through an address it can afford to expose. Payload privacy is one part of that, and routes are the design that could make it the default rather than an operator's chore. ## References - Reiter, Rubin. *Crowds: anonymity for web transactions.* ACM TISSEC 1(1), 1998. - Bojja Venkatakrishnan, Fanti, Viswanath. *Dandelion: redesigning the Bitcoin network for anonymity.* ACM SIGMETRICS 2017; Fanti et al. *Dandelion++: lightweight cryptocurrency networking with formal anonymity guarantees.* POMACS 2018. - Heimbach, Vonlanthen, Villacis, Kiffer, Wattenhofer. *Deanonymizing Ethereum validators: the P2P network has a privacy issue.* USENIX Security 2025. - Le Blond, Legout, Lefessant, Dabbous, Kaafar. *Spying the world from your laptop: identifying and profiling content providers and big downloaders in BitTorrent.* USENIX LEET 2010. - Das, Meiser, Mohammadi, Kate. *Anonymity trilemma: strong anonymity, low bandwidth overhead, low latency — choose two.* IEEE S&P 2018. - Wright, Adler, Levine, Shields. *The predecessor attack: an analysis of a threat to anonymous communications systems.* ACM TISSEC 2004. - Piotrowska et al. *The Loopix anonymity system.* USENIX Security 2017. - Chaum. *The dining cryptographers problem: unconditional sender and recipient untraceability.* J. Cryptology 1(1), 1988. - Boneh, Eskandarian, Hanzlik, Greco. *Single secret leader election.* ACM AFT 2020. - Borisov, Danezis, Mittal, Tabriz. *Denial of service or denial of security? How attacks on reliability can compromise anonymity.* ACM CCS 2007. - Dingledine, Hopper, Kadianakis, Mathewson. *One fast guard for life (or 9 months).* HotPETs 2014. - Katti, Cohen, Katabi. *Information slicing: anonymity using unreliable overlays.* NSDI 2007. - Kiraly, Teofili, Bianchi, Lo Cigno, Nardelli, Delzeri. *Traffic flow confidentiality in IPsec: protocol and implementation.* In *The Future of Identity in the Information Society*, IFIP vol. 262, pp. 311–324, Springer 2008. - Kiraly, Lo Cigno. *IPsec-based anonymous networking: a working implementation.* IEEE ICC 2009. - Hopps. *Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS).* RFC 9347, 2023.