Repository navigation
transport strawman ladder outline #27
Description
this is an initial proposal for us to move forward
each rung builds broadcast from the primitives of the previous one and ends with the problem that motivates the next
preliminaries (not rungs)
- this document absorbs the transport parts of the existing strawman ladder (Strawman ladder #17), while the sneakernet case stays in the overview (proposed overview structure #21)
- datagram vs stream transports (IP, UDP, TCP, TLS, QUIC) and why our channel is message oriented
- adversary taxonomy and where each network sits
- webrtc/iroh (honest, e2e encryption only), tor/i2p (local passive), nym (global passive), ohttp (relay/gateway non-collusion)
- honest, semi-honest and byzantine threat models, and which rungs suffice for each
- bitcoin's p2p layer as a running case study
- p2p channels
- a channel trait for opaque datagrams with explicit delivery semantics and no ordering or dedup
- framing with a length prefix on stream transports and fixed-size cells where message size leaks information
- flavors by substrate (as subsections here or as their own chapter?)
- tor via socks5h or arti
- ohttp for constrained clients
- i2p and nym later
- flavors by anonymity, sender-anonymous vs authenticated opening, kept apart by type-state
- connection initiation covering factories, addressing, bootstrap, discovery and circuit lifecycle
- capnp subprocess plugins for conflicting dependency trees
- bip 324 and addrv2 as the bitcoin case study
- the remaining problem is that a channel connects exactly two peers
- broadcast over a fully connected clique
- broadcast by sending on every channel, with static membership and a shared-secret handshake
- the remaining problems are n² circuits, partial connectivity, dynamic membership and mobile peers
1b. server broadcast, the transport analog of the upper ladder's trusted coordinator
- a per-topic grow-only message set on the gateway, with multi-homing across operators
- this solves n² and mobile but reintroduces a coordinator trusted with liveness
- naive gossip
- re-sending on all channels, which requires a logical message identity across transports
- peer network topology with and without the ohttp service
- an extensible encoding for the message set (tlv)
- bridging the tor and ohttp worlds into three-way interop
- inv/getdata, transaction relay and addr gossip as the bitcoin case study
- the remaining problems are redundant bandwidth and selective omission, enough for semi-honest but not for bft
- set reconciliation
- exchanging sketches instead of messages, both for bandwidth efficiency (erlay/minisketch) and for recovery after partitions (rateless iblt, multi-server)
- the remaining problem is that reconciliation under equivocation requires a hash-linked causal structure
cross-cutting
- denial of service through kvac credentials with presentation-bound proof of work, issued against bip 322/coindays, payment or pow (cross-cutting or its own rung after 0?)
- layered trust on the ohttp side, from non-collusion through multi-path key consistency and tee attestation to onion routing, with details living in hartig
- how each rung is verified (conformance suite, nixos vms, convergence e2e, restart recovery)
future rungs, parallel to the upper ladder
- the blocklace (https://arxiv.org/abs/2402.08068) as a causal gossip structure
- bft crdts (kleppmann 22 (https://martin.kleppmann.com/papers/bft-crdt-papoc22.pdf))
- agreement primitives over the disseminated set
@Mshehu5 @0xZaddyy @zealsham please share your thoughts, if there's anything missing or that could be improved
Activity
nothingmuch commentedon Aug 25, 2026
this should be for expositional purposes, no need to go into details, and just tor and ohttp are representative enough - one is stream based and the other datagram based and with framing both can provide async typed message bidirectional channel is enough to establish what a p2p channel is.
also ignore wire level considerations like TLV encoding, framing, message types, ... if you want to discuss we can revisit those details later and add them as an addendum to this document, but it's better if this stays abstract in regards to those details so that this document doesn't go stale
no need to review IP, UDP, TCP here - that was just context i felt you should have
no need to address at all, just the privacy taxonomy.
this layer takes care of message delivery, not view consistency, or even the communication model (synchronous, partial synchrony or async, if synchronous then any timeouts at the protocol level are more or less independent of timeouts on the transport level).
1b - can be a designated leader (participating node) or 3rd party server.
compatibility limitations of web clients (including PWAs) and how OHTTP can bridge them to other privacy overlays should be discussed as 0b i guess, and then 1b can be related to that (there's some details relating to that in the existing strawman ladder)
kvac credentials only make sense for the 3rd party server, participating peers don't need (coalition formation will have built in rate limiting and txn construction has other DoS protection).
tor and nym likewise have non-collusion assumptions, they are just more robust due to longer paths and in nym's case some symmetry properties of the network structure and the loopix traffic patterns.
details of key consistency, tee attestation etc are not really relevant for this outline, at least not yet IMO.
Focus on the communication patterns required. Given p2p channels, we want all participants, even with asymmetric capabilities (e.g. some clients may be bandwidth constrained) to arrive at the same set of messages, order insensitive, in multiple epochs as efficiently as possible.
There are many tradeoffs, for example epidemic broadcast will likely win on latency but set reconcilation will win on communication complexity. There is a whole spectrum of network coding possibilities. Multiparty set reconcilation has not yet been studied as far as I'm aware (recent set reconcilation papers have focused on 2 party cases).
The same building blocks may not be applicable to both public/open broadcast (coalition formation) and private/closed group broadcast (transaction construction), or, independently of the message type, the type of peer 3rd party server vs. participating peer. even for 3rd party servers, if we assume multiple servers vs. a single server there may be large variations.
then there is the parameter range for the messages themselves. for example, segwit inputs are (mostly) safe to sign with just the prevout data, whereas legacy inputs require the full previous transaction. full nodes will be able to find prevouts in their utxo set, but other clients may expend different amounts of bandwidth resources depending on their capabilities and trust model, and for this reason it may be desirable to use on set reconcilation for this auxilirary data as well (this can be constrained a co-spend proposal txn parameter allowing exclusion or requirement of these data in broadcast). all this is mainly to say that the message count and size may also vary substantially, even for the same set of parameters.
and underlying goal of this is to help you organize your understanding of the task dependency graph relating to this:
there are many results in the literature on gossip, set reconciliation and network coding. we could spend a lifetime studying these... we should map out the most relevant ones and sequence them in order of decreasing simplicity.
so this document is to help you, and readers, understand the logic of these communication patterns, why they are appropriate for the protocols (coalition formation and txn construction, in particular no strong ordering requirement for messages, just set consensus) and how roughly how they work in practice
bc1cindy commentedon Aug 25, 2026
thank you @nothingmuch
preliminaries (not rungs)
0b. web clients
1b. coordinator broadcast, transport analog of the trusted coordinator
cross-cutting
future rungs, parallel to the upper ladder
nothingmuch commentedon Aug 25, 2026
hmm sneakernet can be helpful to think about here
in the preliminaries, IMO no need to say what it is not about, that's claudish
no need to discuss bitcoin p2p, i just think that would be useful for you all to review (lightning stuff too, i think bolts 1, 8, maybe 7 too though the gossip layer will be quite different it's a good basis for comparison
btw more typical name for fully connected clique that eluded me yesterday is "multicast"
0b - it is in principle possible for webrtc to also be used peer to peer, using a server only to exchange ICE messages, there is no way to have transport metadata privacy from other peers with this. if it is ok for all peers to learn the IPs of other peers, something like DC nets could also be used, which wuold still provide message anonymity within this set of peers.
since we want to support honest, semi-honest and BFT settings, this would potentially allow a limited peer to use another trusted peer to broadcast on its behalf if we add a mechanism for it. for example your node at home may support webrtc and tor, and you want to execute a coinjoin using your hardware wallet, which you do have on you, i think it would make more sense to treat the node at home as the actual user agent and provide remote RPCs for it in this particular example, but in some situations, for example imagine a group of friends that all have mobile devices but only one of them has a server at home, even if that server is not publicly reachable on the internet it could proxy from webrtc to tor for its trusted peers (the friends' mobile phones).
1b:
to be a bit more precise, some peers may have publicly reachable IPs and support HTTP or even OHTTP, but that would mean light clients would be trusting a participant in the transaction for their transport level privacy, or a pair of them to not collude, with no authorization mechanism, so in the BFT setting it seems like this would have to be 3rd party services.
btw could also be in exchange for payment (lightning, cashu like https://athenut.com/) or proof of work, the main thing is to limit the data rate from both a 3rd party service's point of view and the peers' pov
initially up to hundreds of peers in transaction construction setting, many messages per peer, small messages on the happy path, larger messages for validity proofs
but potentially many more for open gossip setting for order book/coalition formation, with few messages per peer, but potentially large-ish messages (co-spend proposals in particular)
nothingmuch commentedon Aug 25, 2026
also note that KVACs are just what i'm most familiar with, but rate limiting credentials are not just based on KVACs, see for example Bitcoin-PIR's implementation
bc1cindy commentedon Aug 26, 2026
preliminaries (not rungs)
cross-cutting
future rungs, parallel to the upper ladder
0xZaddyy commentedon Aug 28, 2026
The 1 → 1b → 2 relationship isn't strictly sequential, right? 1b solves n²/mobile but not partial connectivity, and gossip re-solves rung 1's problems independently of 1b. 1b is just a branch, not a required step toward 2.
bc1cindy commentedon Aug 28, 2026
thanks @0xZaddyy good point!
right, 1b is a branch, not a step toward 2, gossip supersedes multicast directly. i've reindented the outline so 0b and 1b now nest under their parent rungs, keeping the spine 0 → 1 → 2 → 3 explicit. seems better?
0xZaddyy commentedon Aug 29, 2026
Okay, that makes sense. I don't really think there is any need to make it explicit like that; we just need to make it clear.
Rung 1 lists several problems, but 1b only solves the n² connections and mobile-peer problems. Could we separate the list into what 1b solves and what remains for Rung 2 to solve with gossip? Also, could the "gossip supersedes multicast directly" reasoning be folded into the outline itself, but we just need soft wording like "gossip builds on multicast directly, bypassing 1b"?
bc1cindy commentedon Sep 2, 2026
added a line to each
"a parallel branch, not a step toward 2. solves rung 1's problems by centralizing, and stays necessary for constrained clients"
1b solves all four. everyone talks to the coordinator instead of each other (kills n² circuits and partial connectivity), late joiners just fetch the log (dynamic membership), and constrained clients don't relay (mobile peers)
"supersedes multicast directly, not 1b, and only gossip bridges overlays, where peers on different networks can only reach each other through a peer that speaks both"
1b isn't bypassed, it's the ohttp side of the bridge