Nostr notes by

Anyone interested in a serious review of v3 of my book The ...

2026-04-26T09:28:35Z

Anyone interested in a serious review of v3 of my book The Praxeology of Privacy before it goes to print?

It would indirectly kyc your main chain coin.

2026-04-26T08:08:06Z

In reply to nevent1q…rcmt
_________________________

It would indirectly kyc your main chain coin.

lol, when I initially wrote steamroller I started to get confused ...

2026-04-25T18:56:21Z

In reply to nevent1q…g0sm
_________________________

lol, when I initially wrote steamroller I started to get confused with wtf that even is

Yes, at least similar, cross fork decoy selection doesnt seem ...

2026-04-25T18:55:35Z

In reply to nevent1q…kce7
_________________________

Yes, at least similar, cross fork decoy selection doesnt seem trivial at all.

Thanks! Oh and individual audio tracks for each participant is ...

2026-04-25T18:36:43Z

In reply to nevent1q…hd75
_________________________

Thanks!
Oh and individual audio tracks for each participant is important.

So good, thanks for doing this!

2026-04-25T17:00:56Z

In reply to nevent1q…h3qu
_________________________

So good, thanks for doing this!

Massive improvement, try it out! The best way to anonymously ship ...

2026-04-25T17:00:36Z

Massive improvement, try it out!
The best way to anonymously ship your vibed apps.

quoting
nevent1q…3jwd
https://gitworkshop.dev rewrite shipped. Is there a better time to try git nostr? protocols > platforms

Yes, same issue with consolidation.

2026-04-25T16:39:21Z

In reply to nevent1q…jpht
_________________________

Yes, same issue with consolidation.

Send them one by one with multiple days in between for reduced ...

2026-04-25T15:39:27Z

In reply to nevent1q…8xck
_________________________

Send them one by one with multiple days in between for reduced timing attacks.

Let's say you use @nprofile…gldk and have 10 private utxos ...

2026-04-25T15:39:01Z

In reply to nevent1q…dz22
_________________________

Let's say you use WasabiWallet (nprofile…gldk) and have 10 private utxos nobody knows they are yours.

Now you go to the forked chain and send all 10 coins to the exchange in a single transaction, now everyone knows that the 10 unspent coins on bitcoin belong to the same person. Wasabi can't even know this and still assumes these coins are private when they actually are not.

Remember, when you move utxos on a forked chain you link common ...

2026-04-25T15:18:49Z

Remember, when you move utxos on a forked chain you link common coin ownership on the parent chain.
Don't fuck up your privacy for picking up pennies in front of the train.

It does. Not historically, but for the last update.

2026-04-25T12:09:00Z

In reply to nevent1q…6a6u
_________________________

It does. Not historically, but for the last update.

Big mute button, raise hand, seeing who is in the call, no google ...

2026-04-25T07:27:18Z

In reply to nevent1q…h87x
_________________________

Big mute button, raise hand, seeing who is in the call, no google play services, great recording quality.
Stability is more important than other features.
Fat zap if you make it work!

I'm a simple man. I see a fridge full of meat, I follow the ...

2026-04-24T16:20:12Z

In reply to nevent1q…60d2
_________________________

I'm a simple man.
I see a fridge full of meat, I follow the npub.

Can someone please make riverside obsolete? Nostr login, MOQ ...

2026-04-24T16:18:34Z

Can someone please make riverside obsolete?

Nostr login, MOQ audio/video calls, local recording and streamed to a blossom server for each participant.

Sending text mainly.

2026-04-24T16:16:07Z

In reply to nevent1q…sp45
_________________________

Sending text mainly.

To quote @nprofile…6htm: "though technically true, this ...

2026-04-24T16:14:27Z

In reply to nevent1q…remr
_________________________

To quote Arjen (nprofile…6htm):
"though technically true, this only applies to the ipv6 shim, which forces a 1280 minimum MTU + FIPS overhead.
When using the FIPS native API, that number will be much lower."

Tell that to @nprofile…2lxp, lol

2026-04-24T16:13:09Z

In reply to nevent1q…r32f
_________________________

Tell that to VitorPamplona (nprofile…2lxp), lol

Two projects aim at the same goal of unstoppable networks for ...

2026-04-24T09:24:34Z

Two projects aim at the same goal of unstoppable networks for human beings, and they arrive at radically different solutions. Reticulum strips addressing and ports from the protocol entirely and optimizes for radio links so slow that five bits per second counts as usable bandwidth, then builds its own parallel universe of applications on top. fips (npub1y0g…00ly) takes the opposite bet, keeping IPv6 semantics alive through a TUN adapter so that unmodified SSH and curl can cross a mesh of Nostr identities. This post walks both stacks from the wire up, then shows where their design choices force different tradeoffs.

quoting
naddr1qq…gwgh

Both projects begin from the same observation: the network that carries civilization's communication runs on a substrate of centralized coordination. ISPs allocate addresses, registrars gate domain names, certificate authorities vouch for identity, and DNS servers arbitrate reachability. Each of these functions imposes a dependency, and every dependency is a chokepoint that can be taxed, surveilled, or switched off.

Reticulum and FIPS respond by building mesh networks that require none of the above. A new node joins by connecting to any existing peer. Once connected, it generates its own address from a cryptographic keypair and starts routing over whatever physical medium is available to it. No one grants permission for any of it.

That shared premise is where the similarity ends. The two stacks make almost opposite engineering bets beneath the shared framing. Reticulum treats IP as something to route around entirely and optimizes for radio links so slow that five bits per second counts as usable bandwidth. FIPS treats IP as the interface legacy applications still expect and builds a mesh underneath that looks like IPv6 from the outside. Understanding why each choice follows from the other accounts for most of what separates these protocols in practice.

The Physical Layer: Agnostic by Design

Both protocols refuse to specify a transport. Whatever can move a datagram between two points is usable. Reticulum ships drivers for LoRa radios, serial links, packet radio over VHF, TCP and UDP tunnels, Ethernet, and I2P, with a minimum viable throughput of five bits per second and a physical MTU of 500 bytes. FIPS runs over WiFi, Ethernet, Bluetooth, UDP overlays, Tor circuits, serial lines, and satellite uplinks, and its IPv6 compatibility path needs at least 1357 bytes of transport MTU to carry an IPv6 minimum packet.

A word on MTU before moving up the stack. Every physical medium caps how many bytes can ride in a single packet, and that cap is the Maximum Transmission Unit. Ethernet and WiFi carry about 1500 bytes, a standard UDP-over-IP path lands near 1472, a Tor circuit sits a bit lower, and a LoRa radio running conservative parameters might permit only 256. Anything larger either gets fragmented by the link layer or dropped outright. Reticulum and FIPS both refuse to fragment at their own layers, so every packet they emit must fit inside whatever MTU the current hop provides, and that single packet has to carry protocol overhead, encryption envelopes, routing metadata, and application payload all together. Overhead eats directly into the payload budget, and the smaller the MTU, the more painful each byte of protocol framing becomes.

This 857-byte gap in minimum MTU is the first visible consequence of the different design targets. Reticulum expects its deployments to include hobbyist LoRa modules speaking across dozens of kilometers at bitrates too low to stream an email attachment in an afternoon. FIPS expects its deployments to include IPv6-capable transports that can carry a reasonable TCP segment without fragmentation. Both are valid environments, and they demand different overhead budgets and different fallback strategies when the medium misbehaves.

Below the drivers, neither protocol assumes trust at the physical layer. A WiFi access point is treated with the same suspicion as a radio broadcasting over open spectrum. Every link carries authenticated, encrypted frames, and every mesh-level operation survives transport-level tampering. The transport is a pipe for ciphertext, nothing more.

Identity as Address

In the classical Internet, your address is assigned and your identity is asserted, and the two are held together by a certificate issued by a third party. Both protocols collapse this into a single cryptographic operation.

Reticulum calls its identity primitive an Identity: an Ed25519 signing keypair combined with an X25519 encryption keypair. From an Identity you construct destinations, each of which appears on the wire as a 16-byte truncation of a SHA-256 hash over a dotted naming hierarchy. A destination name looks like lxmf.delivery or environmentlogger.remotesensor.temperature, and the hash of that name, combined with the destination's public key for private types, becomes a 128-bit address. One Identity can publish any number of destinations for different purposes.

FIPS uses secp256k1. Bitcoin and Nostr use the same curve, which means a FIPS node can derive its identity from an existing Nostr nsec without generating anything new. A node's public key, encoded in bech32 as an npub, is its application identity. From the raw x-only pubkey, FIPS derives a 16-byte node_addr by truncating SHA-256, and from that derives an fd00::/8 IPv6 address by prepending 0xfd. The three identifiers serve different layers: npub for users, node_addr for routing, IPv6 for legacy applications.

Two consequences follow from these choices. First, Reticulum's destinations are application-scoped while FIPS identities are node-scoped. A Reticulum Identity publishes a distinct destination hash for each application, giving every app its own routable endpoint, though every destination's announce still carries the Identity's public key and an observer correlating announces can recover the shared Identity. A FIPS node exposes every application through a single npub and dispatches to them using port numbers above FSP. Reticulum is more fine-grained in addressing; FIPS is simpler to reason about.

Second, the choice of elliptic curve has practical downstream effects. secp256k1 lets FIPS inherit Nostr identities directly, so any user with an nsec already holds a usable FIPS identity. Ed25519 and X25519 give Reticulum access to faster, batch-verifiable signatures and a well-audited lineage of NaCl-style constructions, at the cost of sitting outside the cryptographic world that Bitcoin and Nostr occupy.

How the Mesh Finds Itself

Addressing is cheap; finding the holder of an address is where mesh protocols get expensive. Reticulum and FIPS answer that question in opposite ways.

Reticulum uses an announce mechanism. When a destination wants to become reachable, it broadcasts a signed packet containing its destination hash, its public key, and optional application metadata. Transport nodes receive this announce and forward it, recording which direction it came from and how many hops it took. Announces propagate with randomized delay, bandwidth limits configurable per interface, and priority weighted inversely by hop count, so that slow segments stay responsive to local traffic while still gradually learning about distant destinations. Every transport node ends up holding a lookup table that says "to reach destination X, forward to peer Y," where each entry encodes only the next hop toward the destination and no node has the full path in memory.

FIPS builds a spanning tree. Every node picks the peer that offers the best measured path to a deterministic root, chosen as the node with the lexicographically smallest node_addr, and the resulting parent-child relationships form a tree over the mesh. Each node's position in the tree becomes its coordinate: the sequence of node_addr values from itself back to the root. To route a packet, a node finds the peer whose coordinate is closest to the destination's coordinate by tree distance. For destinations not known through the tree, nodes exchange bloom filters advertising reachability, and consult those filters when tree routing alone would drop a packet.

The tradeoffs here are subtle but real. Reticulum's announce model is simple and resilient. It converges quickly on networks with reasonable bandwidth, handles topology changes through the same gossip channel that propagated the initial announces, and requires no coordination between nodes beyond the signed announce format. The cost is memory: every transport node holds a routing entry for every destination it has ever heard an announce for, and bandwidth spent on announce floods grows with the number of announced destinations.

FIPS's spanning tree is tighter. Coordinates are computed from local information, forwarding decisions iterate only the direct peer list to find the closest coordinate to the destination, and bloom filters compress reachability information at the cost of occasional false positives. When the network partitions, each segment independently re-elects a root and reconverges in O(diameter) rounds. The cost is complexity: spanning tree construction, MMP link measurement, bloom filter gossip with split-horizon rules, and a coordinate cache that must be consulted before every forwarding decision.

Both approaches handle partition healing automatically, and that property is load-bearing for a mesh designed to survive adversity. Neither needs human intervention when a link goes down. The difference is that Reticulum will route your packet through whatever path an announce has carved out recently, while FIPS will route your packet along the spanning tree's idea of the shortest path right now.

A subtler architectural choice shows up in the packets themselves. Reticulum omits source addresses entirely; a forwarded packet carries only the destination hash and the payload, and transit nodes track return paths through the link identifier they remembered when the link was established. FIPS includes both source and destination node_addr values in the FMP routing envelope, because the spanning tree forwarding logic needs to know where to send responses and because the two-layer encryption model treats the envelope as cleartext to transit routers by design. The trade is concrete: Reticulum gets a stronger anonymity story at the cost of a more constrained forwarding model, while FIPS gets simpler routing at the cost of revealing source and destination hashes to every hop.

The Cryptographic Core

Reticulum and FIPS both encrypt everything by default, and both refuse to carry unencrypted traffic on multi-hop paths. Beyond that shared commitment, their cryptographic layers look like they come from different decades.

Reticulum's primitive list reads as a conservative choice from the mid-2010s: Ed25519 for signatures, X25519 for ECDH, HKDF for key derivation, AES-256 in CBC mode for bulk encryption, HMAC-SHA256 for message authentication, and SHA-256 plus SHA-512 for hashing. Every packet to a single destination gets a freshly generated ephemeral X25519 keypair, which performs ECDH against the destination's public key to derive a per-packet symmetric key. No handshake is needed because the sender already knows the destination's public key from a previous announce. Encrypt-then-MAC via AES-CBC and HMAC-SHA256 provides authenticated encryption in the older composition style that predates AEAD constructions like ChaCha20-Poly1305. A destination can optionally enable a ratchet, so that per-packet ECDH uses successive ratchet keys instead of the long-term public key, giving forward secrecy to link-less traffic.

FIPS uses the Noise Protocol Framework with ChaCha20-Poly1305 as the AEAD. Every link between adjacent peers runs a Noise IK handshake, which completes mutual authentication in one round-trip because the initiator already knows the responder's static public key. Every end-to-end session runs a Noise XK handshake, which hides the initiator's static key until the third handshake message, so transit routers cannot learn the initiator's npub from observing the handshake. Both Noise instances produce AEAD keys used with ChaCha20-Poly1305 for the rest of the session.

The architectural difference runs deeper than primitive choice. Reticulum applies encryption per-destination-type: single destinations get ECDH-derived per-packet encryption, group destinations use a preshared AES-256 key, plain destinations are cleartext, and link destinations establish an ephemeral X25519 tunnel with forward secrecy. Which encryption you get depends on how you addressed the packet.

FIPS applies encryption in two independent layers, always. The lower layer, called FMP, encrypts every hop under its own Noise IK session, so a node forwarding a packet decrypts under the incoming link key and re-encrypts under the outgoing link key. The upper layer, called FSP, encrypts the end-to-end payload under a Noise XK session and remains opaque to every intermediate hop. The construction resembles Tor's onion model at a smaller scale, without the anonymity guarantees that Tor's three-hop circuits and large shared user base provide.

The two-layer construction gives FIPS a cleaner story about what each observer can see. A transit router sees FMP-decrypted packets containing opaque FSP payloads and routing envelope data: source and destination node_addrs, TTL, path MTU. It can tell that a particular pair of node_addrs is exchanging traffic and watch the volume and timing of that exchange, but the FSP payload stays sealed and the npubs behind those hashes stay out of reach. Reticulum approaches the same threat model through its claim of initiator anonymity: the sender's identity is never revealed on the wire for packet-style communication, and for link-style communication the initiator can choose to authenticate only after the link has come up and been verified.

Sessions and the Shape of a Conversation

For single-shot datagrams, both protocols offer simple encrypted delivery. For extended conversations, the abstractions diverge again.

Reticulum's Link is a first-class construct. Establishing a link costs three packets totaling 297 bytes, during which both sides contribute fresh X25519 keypairs to an ECDH exchange that derives an ephemeral symmetric key. The link carries its own identifier, a hash of the link request packet, and every transport node along the path remembers this identifier so that subsequent traffic can address the link directly instead of re-resolving the destination. The link provides forward secrecy, receipt proofs via Ed25519 signatures, and bidirectional addressing. Keeping a link open costs roughly 0.45 bits per second, which means a 1200 bps packet radio channel can host a hundred concurrent links with ninety-six percent of its capacity still available for actual data.

FIPS's FSP session is less explicit. Every end-to-end exchange runs a Noise XK session, which provides forward secrecy and bidirectional AEAD encryption from the first message. There is no separate link-establishment phase visible to the application; the session is the delivery mechanism. Reliability is handled above FSP, either by the native API contract or by TCP running inside the IPv6 adapter, because FSP delivers datagrams only and leaves stream semantics to the layer above.

The practical consequence is that Reticulum applications tend to be written against the Link API for anything larger than a notification, and the Resource abstraction on top of Link handles chunking, compression, and reassembly of arbitrarily large transfers. FIPS applications tend to be written against the native datagram API when they can be, or against the IPv6 adapter when they need to speak to unmodified software, and they inherit whatever reliability layer lives in the application protocol.

The Rest of the World

At some point both protocols have to answer the question of what happens when an application written for the normal Internet wants to talk to a peer on the mesh. The two answers point in opposite directions.

Reticulum's answer is to write new applications. The project ships Nomad Network, LXMF for messaging, Sideband for mobile use, and a handful of other tools that speak Reticulum natively. No compatibility shim for SSH or curl exists. If you want to run a service on a Reticulum network, you link against RNS and implement your protocol against destinations and links. The design bet is that applications meant to survive adversarial environments should be built for those environments from the start, and that dragging along the assumptions of a TCP/IP application stack into a five-bit-per-second LoRa link is a category error.

FIPS's answer is a TUN adapter. The daemon creates a virtual interface, assigns itself an fd00::/8 address derived from its node_addr, and asks the kernel to route the entire fd00::/8 block through the interface. When an application opens an IPv6 socket to a fips0 peer, the adapter receives the packet, looks up the destination's pubkey in a DNS-primed identity cache, and hands the packet to FSP. TCP MSS clamping keeps segments within the effective 1395-byte MTU. ICMPv6 Packet Too Big messages fall back to path MTU discovery for applications that bypass the MSS clamp. A separate fips-gateway sidecar extends this trick to LAN clients that do not run FIPS themselves, allocating virtual IPs from fd01::/112 and installing nftables rules that NAT traffic between the LAN and the mesh.

Reticulum is a parallel network stack that competes with IP at the application layer, while FIPS is a mesh substrate that preserves IP at the application layer. Applications running over Reticulum stay inside the universe Reticulum defines, with no substrate for DNS, TLS, or HTTP conventions to attach to below them. Applications running over FIPS keep their existing codebase but inherit every IPv6 behavior the operating system already implements, including the ones that can surprise you inside a mesh.

Each approach fits a different problem. An off-grid community deploying LoRa radios gains the most from Reticulum's willingness to throw away the old assumptions; a self-hosted user routing SSH and Syncthing across a censored border gains the most from FIPS's willingness to preserve them.

What Each Threat Model Promises

Reticulum claims initiator anonymity. Packets sent to single destinations carry no identifying information about the sender, and links can be established and used without the initiator ever authenticating to the destination. The destination learns that a link was established; the initiator's identity stays hidden until the initiator chooses to authenticate inside the encrypted channel. Once authenticated, the identity is visible only to the verified destination. This property is load-bearing for applications like anonymous messaging or whistleblowing tools.

FIPS declines to claim anonymity. Direct peers learn each other's npub through the Noise IK handshake, and there is no mixing layer, cover traffic, or tunnel rotation. A direct peer always knows who you are. What FIPS does claim is that transit routers, meaning peers who are not direct neighbors but are forwarding your session, see only opaque routing hashes and cannot correlate traffic to npubs. The claim is weaker than Reticulum's by design: FIPS assumes you know your direct peers, and the protocol optimizes for privacy against adversaries further away.

Both projects are explicit that a global passive observer with vantage points across multiple transports can perform traffic analysis against them. Neither pads packets, batches traffic, or rotates through decoy paths the way a mix network would. Payloads stay confidential; the occurrence of a conversation remains visible to anyone with enough observation points. Mix networks solve a different problem and impose padding and cover-traffic overheads that these stacks are built to avoid.

On eclipse resistance, both rely on topological diversity. Cryptographic signatures on tree announces or on routing packets cannot save a node whose every direct peer is hostile, because the hostile peers hold valid identities too. The defense in both protocols is the same: peer across independent operators and independent transports, so that any single compromise leaves the target with other views of the network.

Where Each One Wins

For a LoRa mesh across a valley, where the medium is a 300 bps radio channel and the nodes are Raspberry Pis with RNodes, Reticulum is the protocol. FIPS's IPv6 compatibility path requires transport MTUs that LoRa cannot sustain, its spanning tree would reconverge constantly in a mesh where links come and go with weather, and its application story assumes you have applications that can be recompiled to run over it. Reticulum was designed for exactly this environment, and its Link API, Resource abstraction, and announce-based path discovery all pay off in the low-bandwidth regime.

For a Nostr-native mesh where users want to SSH into their home servers over a Tor-transported overlay without standing up Cloudflare tunnels or tailnets, FIPS is the protocol. Its npub-as-identity model inherits the social graph users already have on Nostr, and its IPv6 adapter lets most existing tools work without modification. Noise-based two-layer encryption matches the trust structure of deployments where direct peers know you and distant peers should not, and the spanning tree performs well on the transport MTUs a Tor circuit or WiFi LAN provides.

Coexistence between the two is possible in principle. A FIPS gateway running on a node that also participates in a Reticulum mesh could bridge traffic between them, and both projects are sufficiently medium-agnostic that nothing in their design prevents nesting one inside the other. In practice the communities and tooling sit apart, and the cryptographic curves never meet.

A Note on Age and Maturity

Reticulum was dedicated to the public domain in 2016 and has a shipping 1.x reference implementation in Python, a thorough manual, the RNode open-source LoRa hardware platform, and a growing catalog of applications including Nomad Network, Sideband, LXMF, and MeshChat. It has not been externally audited, which the project is explicit about, but its primitives are conservative and its design has had close to a decade to settle.

FIPS was built during SEC-07 at Sovereign Engineering and is, at the time of writing, young software. Specs are public, the reference implementation lives on GitHub, and a learning site walks through every layer with interactive simulations. It inherits cryptographic primitives from the Noise Framework and from Nostr tooling, which mitigates some of the risk that comes with new protocol work, but the network-level behavior has not seen years of deployment stress yet. Anyone planning a production deployment should weigh that accordingly.

The Convergent Insight

Despite their different answers, Reticulum and FIPS share the same deep claim: a network can function without central coordinators, identity and addressing follow from cryptographic keypairs held by the participants themselves, and every link in such a network should be encrypted by default because there is no reliable way to know which links are hostile.

Two implementations of the same claim, making different bets about which tradeoffs to prioritize. Both worth running. Both worth understanding on their own terms before picking one.

Thats a good idea actually @nprofile…ympz

2026-04-23T12:29:46Z

In reply to nevent1q…hy0t
_________________________

Thats a good idea actually franzap (nprofile…ympz)

Yeah, but who's gonna trust GitHub for app distribution...

2026-04-23T11:02:19Z

In reply to nevent1q…mn35
_________________________

Yeah, but who's gonna trust GitHub for app distribution...

Awesome!

2026-04-23T11:00:54Z

In reply to nevent1q…xkjc
_________________________

Awesome!

Woah, why?

2026-04-23T10:14:25Z

In reply to nevent1q…60av
_________________________

Woah, why?

The reminder worked...

2026-04-23T10:13:13Z

In reply to nevent1q…cqjg
_________________________

The reminder worked...

I'm curious, how did you find @nprofile…gsu4? Were you a ...

2026-04-23T06:28:58Z

In reply to nevent1q…p7zs
_________________________

I'm curious, how did you find Zapstore (nprofile…gsu4)?
Were you a nostrich before already, or are you new to the space?

Honestly, it's the only app store that just works, especially ...

2026-04-23T06:26:19Z

In reply to nevent1q…vpkl
_________________________

Honestly, it's the only app store that just works, especially for devs.

I see more and more non-nostr apps publishing on ...

2026-04-23T05:55:33Z

I see more and more non-nostr apps publishing on Zapstore (nprofile…gsu4)!
Like nprofile1qqswwksctsqe6zgyn40ukr3f5txfhlgpdmq0dkyjljv0dllqrqdysrgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9nhwden5te0wfjkccte9ejxjar5duh8qatz9uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7s88teg (nprofile…8teg), a climbing app, which recommends zapstore as best place to get the app, and use nostr DMs for feedback.
https://zapstore.dev/apps/naddr1qq2kxmmd9e3hyatcvdhkzcmg9eskuerjda5kgqgcwaehxw309aex2mrp0yh85ctswd6x7un99ejx2aszyrn45xzuqxwsjpyatl9su2dzejdl6qtwcrmd3yhunrm0lcqcrfyq6qcyqqq8uzch789f5

Basically, a group of people create a public key, such that only ...

2026-04-23T05:45:00Z

In reply to nevent1q…k80h
_________________________

Basically, a group of people create a public key, such that only if a complex program returns valid does someone get the private key.
It's really a powerful building block.

It's edible... Once...

2026-04-22T18:31:38Z

In reply to nevent1q…2ue3
_________________________

It's edible... Once...

I see that makes sense, thanks for working on this!

2026-04-22T16:15:34Z

In reply to nevent1q…05jk
_________________________

I see that makes sense, thanks for working on this!

Honestly, LLMs are shockingly good at rewriting in a different ...

2026-04-22T14:13:44Z

In reply to nevent1q…8vr9
_________________________

Honestly, LLMs are shockingly good at rewriting in a different language, especially when there is good test coverage.

Oh, and does Jam work ontop of the new implementation?

Theft.

2026-04-22T10:39:44Z

In reply to nevent1q…cva2
_________________________

Theft.

btw, zaps to you are failing.

2026-04-22T10:14:55Z

In reply to nevent1q…lx4z
_________________________

btw, zaps to you are failing.

Thank you for your service sir! Joinmarket was pioneering in so ...

2026-04-22T10:11:28Z

In reply to nevent1q…lx4z
_________________________

Thank you for your service sir!
Joinmarket was pioneering in so many ways, you are an inspiration, and I learned so much from you!
I hope the project continues to be maintained and used.
Curious tho, why is it written in Python again?

We might add it. But aren't you promoting your investment ...

2026-04-22T09:58:29Z

In reply to nevent1q…8egn
_________________________

We might add it.
But aren't you promoting your investment right now? 🙃

Your relay list is messed up btw.

2026-04-22T08:26:12Z

In reply to nevent1q…zyhp
_________________________

Your relay list is messed up btw.

That's a cool idea.

2026-04-22T08:22:54Z

In reply to nevent1q…zyhp
_________________________

That's a cool idea.

Lightning sender privacy is great, and just use Wasabi for ...

2026-04-22T08:17:34Z

In reply to nevent1q…c2gz
_________________________

Lightning sender privacy is great, and just use Wasabi for onchain payments.

By the way, Appendix A in this edition is my favorite history of ...

2026-04-21T12:50:56Z

In reply to nevent1q…2rwy
_________________________

By the way, Appendix A in this edition is my favorite history of religion, very interesting framing.

The usual covenant debate on Bitcoin starts with Script and soft ...

2026-04-21T12:31:47Z

The usual covenant debate on Bitcoin starts with Script and soft forks. PIPEs v2 starts somewhere stranger: it asks whether a spend condition can be enforced by making the signing key itself unavailable until a proof exists. That move shifts the burden away from on-chain verification and into witness encryption, committee setup, a huge off-chain artifact, and the engineering needed to bind them together.
The result is one of the most interesting proposals in current Bitcoin research because it enlarges the design space without asking Bitcoin consensus to change.

quoting
naddr1qq…ce4x

Bitcoin can already enforce whatever its existing Script system can express, and the covenant debate persists because many of the conditions people want to impose concern future spending behavior or off-chain facts that Bitcoin does not natively know how to check. If you want an output that can move only after a proof verifies or a recovery condition is satisfied, today's options usually fall into one of two camps. You can push for new opcodes that let Script say more, or you can wrap the existing chain in an optimistic protocol that relies on challengers and time windows spread across multiple transactions. PIPEs v2 proposes a third route, and its central move is easy to state even if the machinery behind it is not: do not teach Bitcoin to verify the condition, make it impossible to produce the required signature until the condition holds.

In an ordinary Bitcoin output, the private key already exists and the whole security question is who controls it. In PIPEs v2, the usable signing secret is hidden behind a witness-encrypting ciphertext bound to some statement. The chain still sees an ordinary public key. Spending still looks like an ordinary Schnorr signature. The novelty lies in the claim that the private key cannot be recovered by anyone unless they know a witness for the chosen condition. A successful spend therefore signals that the condition was satisfied, even though the chain never checked the condition itself.

The paper frames this idea through what it calls a witness signature. The phrase sounds exotic, yet the intuition is direct. Take a statement that has the form, "there exists some witness w such that verification accepts." That witness might be a zero-knowledge proof for a published instance or a recovery secret satisfying a hash relation. More generally, it can be any object whose validity can be checked quickly once presented. Witness encryption lets you publish a ciphertext that any observer can see but only someone holding a valid witness can decrypt. PIPEs v2 uses that primitive in the most literal possible way: the plaintext inside the ciphertext is the signing material for the Bitcoin output, or an equivalent secret that reveals it.

Schnorr stays simple in this design. Bitcoin is not learning a new rule. Bitcoin is doing what it already does under BIP 340: it checks that a Schnorr signature verifies under a public key. PIPEs v2 leaves that part untouched. The burden of enforcement shifts off-chain, where the cryptography governing key recovery decides whether a valid signature can ever come into existence. The proposal therefore buys expressive authorization conditions while paying with a very different kind of complexity.

The Cryptographic Machinery

Witness encryption is the decisive primitive because it turns a hard relation into a decryption gate. In the current PIPEs v2 discussion, the construction comes from the recent AADP line of witness encryption. The internal details involve structured matrices and determinant computations produced by nontrivial reductions that are far removed from ordinary Bitcoin engineering. For the architectural argument, only one property matters: if you know a valid witness, decryption is possible; without one, the ciphertext should reveal nothing useful, so the witness never persuades Bitcoin directly and only reveals the secret that can.

If one operator generated the signing key in the usual way, that operator could spend immediately and the whole scheme would collapse. PIPEs v2 therefore leans on distributed setup. A committee jointly generates the Schnorr keypair so that the public key can be published on-chain while the secret key stays unavailable to any single participant during setup. The witness-encrypted ciphertext is then created and bound to the exact public key and statement instance. These schemes rely on committee honesty properties and correct setup behavior. The trust surface sits at setup.

Hashes and commitments do quieter but equally necessary work. They bind the ciphertext to the exact statement and public key so the encrypted secret authorizes only this spend. Without those bindings, an attacker could try to transplant ciphertext material between contexts or exploit ambiguity in what the encrypted secret actually authorizes. Much of the protocol engineering lives in these bindings, because the high-level idea is elegant and the low-level implementation is where thefts happen.

How the Flow Works

The protocol begins off-chain. A committee runs distributed key generation and obtains a Bitcoin Schnorr public key together with secret signing material that no one party should know outright. The application designer also fixes the relation to be enforced and the concrete instance for this output. If the use case is proof-gated release, the instance might be a verification key, public inputs, and a commitment to the proof system being checked. If the use case is a recovery path, the instance might be a recovery relation encoded as a circuit.

Next comes the expensive step. The protocol produces a witness-encrypting ciphertext tied to that instance and containing the signing material. The corresponding public key is placed in a normal Bitcoin output. On-chain, nothing reveals that the output is special. It looks like a standard key spend waiting for a standard Schnorr signature.

Unlocking happens entirely off-chain until the last moment. Whoever learns a valid witness for the chosen relation runs the witness-decryption procedure on the ciphertext. If the witness is valid, the ciphertext yields the hidden signing secret. That party can then construct an ordinary Bitcoin spending transaction and sign it under the public key already committed on-chain. Once the transaction reaches Bitcoin, validation is immediate because Bitcoin only checks the Schnorr signature. There is no extra opcode and no proof verification inside Script. The challenge game never reaches the spend itself.

Many Bitcoin constructions achieve expressive behavior by spreading the logic across multiple transactions with delays and monitoring requirements. PIPEs v2 compresses the authorization boundary into one binary fact: either the signing secret becomes available and the spend can happen, or it never does.

What Security Depends On

"No soft fork required" hides the cost. The trust and security burden moves off-chain. The first assumption is witness encryption itself. If the AADP construction or its concrete encoding leaks the secret without a real witness, the scheme fails at once. Witness encryption is the sharpest edge in the design because it remains far more exotic than signatures and hashes, and stranger to most Bitcoin engineers than the proof systems they already discuss today.

The second assumption is setup integrity. Distributed key generation has to ensure that no participant can walk away with the signing secret before the witness condition is met. Descriptions of PIPEs v2 often phrase this as a one-of-n committee honesty assumption, meaning at least one participant must follow the setup correctly. Committee honesty remains a meaningful trust assumption, and anyone comparing PIPEs v2 with native covenant opcodes should keep it in view.

The third assumption is ordinary signature security, which is the least controversial part of the picture. If Schnorr itself becomes forgeable, every Taproot key spend has bigger problems than PIPEs. More interesting are the binding assumptions around commitments and statement encoding. A ciphertext must authorize this exact output under this exact condition. A loose binding can turn a clever construction into an expensive theft vector.

Then there is the liveness assumption hidden inside performance. A condition that is theoretically decryptable but economically or operationally impossible to recover in time may still be useless. The current published estimates are best read with caution. Primary sources around PIPEs v2 discuss ciphertext sizes around 330 terabytes, determinant computations spread across roughly fifty large machines, and cloud costs around one to two hundred dollars for a single execution, all coming from author estimates without independent benchmarks. Discussions of future reductions toward roughly 100 gigabytes exist, but those numbers are aspirational in the material currently available. The basic on-chain cost is tiny. The off-chain bill is enormous.

What PIPEs v2 Can Actually Enforce

The term covenant carries more baggage than the construction can bear. PIPEs v2 enforces a binary authorization condition. Funds become spendable if the witness exists and remain unspendable if it does not. Proof-gated release fits that model well, yet the construction is narrower than the richer covenant proposals that directly constrain transaction structure.

Once the secret key is recovered, the spender holds ordinary signing power over the output. Bitcoin sees an ordinary key spend. The construction therefore does not, by itself, force the post-recovery transaction to send coins to a prescribed script, maintain a fee rule, preserve a template, or obey some recursively constrained tree of descendants. Anyone calling PIPEs v2 a full covenant system is stretching the phrase beyond its useful meaning. Binary covenant is the more accurate description.

The limitation follows directly from the design choice. PIPEs v2 relocates enforcement to key availability, and key availability answers one question only: may a valid signature exist?

Where It Fits

The narrow scope still leaves room for serious applications. A vault can use PIPEs v2 for an escape path that activates only when a recovery witness is available. A bridge or rollup design can use it to gate finalization on a proof verifying for a published instance. An optimistic protocol can compress part of its dispute logic into a condition on key release, so the final on-chain effect becomes one ordinary spend whose existence tells observers that the off-chain condition was met.

BitVM is the natural comparison. It keeps Bitcoin verification inside an optimistic game: a prover makes a claim and watchers challenge bad behavior as the protocol moves through its dispute path. PIPEs v2 aims at a different compression. The watcher logic moves off the spend path, and the decisive event becomes witness discovery plus key recovery. If that works, the chain sees only the ending.

PIPEs v2 also fits zero-knowledge gated releases. Bitcoin never has to verify the proof system used elsewhere. The off-chain world only needs a relation whose witness can be encoded into the witness-encryption instance. That opens the door to proof systems or application logic that Bitcoin Script could never hope to express directly.

Comparison to Other Paths

Compared with native covenant proposals such as CTV, TXHASH-style ideas, CSFS, or OP_VAULT, PIPEs v2 is economically inverted. Opcode-based covenants would put the complexity into consensus design and soft fork politics, then let every node enforce compact rules with cheap validation. PIPEs v2 avoids consensus change and pays for that avoidance with setup assumptions plus huge off-chain cryptographic state. If the goal is broad, cheap, expressive covenant functionality across everyday transactions, native opcodes still look like the cleaner engineering path.

Compared with BitVM fraud proofs and garbled-circuit systems, PIPEs v2 exchanges interactivity for cryptographic heaviness. BitVM asks participants to stay online and push disputes through challenge windows. PIPEs v2 offers a more final-looking spend path because the chain only sees the ordinary signature. The price is a witness-encryption artifact that currently lives at absurd scale. BitVM's burden is procedural. PIPEs v2's burden is computational.

Compared with pre-signed transaction trees, which already power practical vault ideas and channel constructions, PIPEs v2 is less rigid at the authorization boundary and weaker at output control. Pre-signing works with familiar assumptions and small artifacts, but every branch has to be prepared in advance and policy changes can become operationally awkward. PIPEs v2 can wait for a witness discovered later in time, which is a real gain. After key recovery, it stops constraining the transaction in the way a pre-signed tree can.

The simplest alternative is trusted humans holding a threshold key and deciding when to sign. In many deployments that option remains more practical today. PIPEs v2 replaces committee discretion with a cryptographic gate. That trade looks best in applications that need cryptographic gating badly enough to justify the cost and the remaining faith placed in witness encryption.

Why PIPEs v2 Matters

PIPEs v2 enlarges Bitcoin's design vocabulary because it shows that spending conditions need not live entirely inside Script. They can live upstream of Script, inside the question of whether a usable signing key can ever be obtained. The proposal's real achievement is conceptual. Native opcodes remain the direct answer for cheap, expressive covenants. Optimistic systems remain the answer for many constructions available under today's assumptions. PIPEs v2 occupies a narrower territory where single-transaction proof-gated authorization is valuable enough to justify a mountain of off-chain cryptography.

The future of witness encryption will decide whether that territory grows. If the primitive gets smaller and better understood, PIPEs v2 could become a practical tool for a narrow class of high-value contracts. If it does not, the proposal will still have done something useful. It showed that control over spendability can be pushed one layer deeper than most Bitcoin discussions assume, into the problem of key availability itself.

Wise words

2026-04-21T06:35:47Z

In reply to nevent1q…ckqn
_________________________

Wise words

Yes that one goes even further, wild.

2026-04-20T14:09:14Z

In reply to nevent1q…nnpk
_________________________

Yes that one goes even further, wild.

We're building a little something... #nevent1q…kfz3

2026-04-20T14:08:52Z

We're building a little something...

quoting
nevent1q…kfz3
Introducing internet privacy foundation.

We build the infrastructure that protects privacy online: open protocols and permissionless tools.

We're a 501(c)(3) nonprofit. Donations are tax-deductible for US donors.

https://ipf.dev

Excited to get this launched!

2026-04-20T14:08:29Z

In reply to nevent1q…7unc
_________________________

Excited to get this launched!

Yes, use TEEs for AI inference for now.

2026-04-20T13:01:16Z

In reply to nevent1q…qzwz
_________________________

Yes, use TEEs for AI inference for now.

Yes. Might be my #1 book recommendation for cypherpunks.

2026-04-20T13:00:45Z

In reply to nevent1q…qkcd
_________________________

Yes.
Might be my #1 book recommendation for cypherpunks.

Awesome, a rare find! That looks to be the very first print ...

2026-04-20T13:00:04Z

In reply to nevent1q…9sfc
_________________________

Awesome, a rare find!
That looks to be the very first print edition, check if its the same text as this initial online edition. https://anarplex.sirion.io/hosted/files/A_Lodging_of_Wayfaring_Men.pdf

Yeah, we're fat from running llms through homomorphic ...

2026-04-20T05:21:25Z

In reply to nevent1q…qzwz
_________________________

Yeah, we're fat from running llms through homomorphic encryption.
You can now do wallet queries which is already impressive. Eventually I'd love to use it for nostr event queries, but that's also still far away.

Three architectural families have broken an assumption that was ...

2026-04-19T14:25:53Z

Three architectural families have broken an assumption that was treated as a law of cloud architecture for two decades: that the machine running a computation must see the data the computation runs on. Homomorphic encryption operates on ciphertexts, secure multi-party computation distributes the work across non-colluding participants, and trusted execution environments isolate the work inside a hardware enclave opaque to the machine's owner. The privacy architecture of the next decade will be built on their compositions.

quoting
naddr1qq…wja5

Verification vs Execution

Zero-knowledge proofs operate on a result that already exists. Some machine has performed the computation on inputs that were visible to some party. A zero-knowledge proof certifies the correctness of what was computed and says nothing about who saw the inputs along the way. Zero-knowledge is the verification primitive.

Computing on secrets is the execution primitive. It answers a different question: can a computation be performed when no single party is permitted to see the inputs? The answer is yes, and it has only become practical within the last decade. Fully homomorphic encryption performs arithmetic directly on ciphertexts. Secure multi-party computation splits a computation across participants so that no participant sees the whole input. Trusted execution environments run computation inside a hardware enclave opaque to the operating system and to the machine's owner.

The two primitives compose naturally. A pipeline that protects privacy end to end typically uses computing on secrets to operate on private data and zero-knowledge to prove the result was produced honestly. Verification and execution are complementary halves of the same problem.

Consider a voting system in which each voter's choice must remain private and the tallied result must be publicly verifiable. The inputs (individual ballots) must stay secret. The output (the tally) must be computable and verifiable. Plain encryption handles secrecy at rest and leaves secrecy in use untouched. If ballots are encrypted and sent to a counting service, the counting service must decrypt them to count them, which means at least one party has access to every individual ballot. The architecture has moved the problem from transport to a processing node, and left it there.

Zero-knowledge proofs handle verifiability of the output while leaving the privacy of the inputs to some other mechanism. A zk-proof can certify that a tally was computed correctly from some set of ballots. The proof ensures only that the tally corresponds to them, leaving open the question of who saw the ballots along the way. Privacy of inputs is a separate requirement. Computing on secrets handles it directly. Homomorphic addition lets the counting service sum ballots in ciphertext form without decrypting any individual ballot; the final tally ciphertext is decrypted once by a distributed threshold of key holders. Multi-party computation distributes the counting across nodes so that no single node sees any voter's choice. A trusted execution environment runs the count inside an enclave that refuses to disclose its memory to any external party, and provides an attestation that the canonical counting software ran on the expected inputs. Ballots stay private through computing on secrets; the tally is publicly verifiable through zero-knowledge. Neither family alone solves the problem. Their combination does.

Homomorphic Encryption: Arithmetic on Ciphertext

Homomorphic encryption permits operations on ciphertexts that correspond to operations on the underlying plaintexts. If Enc(a) is the encryption of plaintext a, and Enc(b) is the encryption of b, then a homomorphic addition produces a ciphertext whose decryption equals a + b, without any party learning either value in plaintext form. Stated plainly the construction sounds close to impossible, and it is achievable only under specific mathematical assumptions.

Early schemes supported one operation only. RSA supports homomorphic multiplication as a side effect its designers did not advertise. The Paillier cryptosystem supports homomorphic addition. Partially homomorphic schemes have been used for narrow applications for decades, including e-voting and private information retrieval.

Craig Gentry's 2009 dissertation gave the first construction of a scheme capable of both addition and multiplication on arbitrary circuits. The original construction was roughly a billion times slower than the equivalent plaintext computation, which ruled it out for any serious application. What mattered was the proof of existence itself. Fifteen years of engineering since have cut the overhead by roughly four orders of magnitude, moving narrow applications into feasibility while keeping general-purpose computation out of reach.

Present deployments fall into categories whose common property is that narrow usefulness beats broad slowness. Encrypted machine-learning inference lets a client send an encrypted input to a service and receive an encrypted output without the service seeing the input; the applications include encrypted medical diagnosis and financial-risk scoring. Private information retrieval lets a client query a database without revealing which record it wants. Encrypted databases let a service host encrypted customer data and answer queries over it without decrypting. Homomorphic encryption still falls short of fully general-purpose computation at acceptable speed. The overhead remains large enough that applications are chosen for their tolerance for latency and their limited complexity.

The structural claim underneath any specific application is simpler. Homomorphic encryption breaks the assumption that the service running a computation must see the data on which the computation runs. That assumption had been treated as a law of cloud architecture for two decades. Homomorphic encryption denies it. The service and the user become parties to an exchange in which the service performs a function and the user retains epistemic ownership of the inputs. The contract structure that was previously infeasible is now infeasible only at certain workload sizes, and the set of feasible workloads expands each year.

Secure Multi-Party Computation

Multi-party computation (MPC) addresses a different problem with a different architecture. Multiple parties each hold private inputs; they wish to jointly compute a function of those inputs and to learn only the output. No party learns any other party's input beyond what the output itself reveals.

The classical constructions rely on a small family of cryptographic primitives. Secret sharing, studied by Shamir in the 1970s, splits a secret into shares such that any threshold number of shares reconstructs it and any smaller subset reveals nothing. Garbled circuits, introduced by Yao, let two parties evaluate a Boolean circuit where one party encrypts the circuit and the other evaluates the encryption; each gate's behavior is correct while its intermediate values stay hidden. Oblivious transfer lets a party receive one of several values chosen by another party without the sender learning which value was chosen.

The single most successful MPC deployment is threshold signing, and it has reached institutional scale. A threshold signature scheme distributes the private key across multiple parties such that signing requires a threshold of them to cooperate; no subset below the threshold can produce a valid signature. No party ever holds the full private key, so a breach of any individual party does not compromise the system. Fireblocks, the largest institutional custody provider, operates threshold-signed wallets for roughly two thousand customers including major banks and payment processors. The architecture is the basis on which several regulated institutions extended credit into the crypto-asset space at all, because the alternative of a single-party custodian required levels of counterparty trust they were not prepared to extend.

Two Schnorr-based constructions have made threshold signing directly visible on Bitcoin. MuSig2, specified in BIP 327, aggregates an arbitrary number of signers into a single public key and a single signature indistinguishable from a normal single-party Schnorr signature. FROST extends the same approach to t-of-n threshold signing, so any t of the n key shareholders suffice to produce a signature and the protocol tolerates up to n minus t shares going offline or hostile without losing liveness. Both became usable on Bitcoin with Taproot activation in November 2021. Chain analysis cannot distinguish a ten-of-ten MuSig2 transaction from a single-key transaction, nor a three-of-five FROST spend from either. The architecture delivers the distributed-trust guarantee of MPC and the base-layer privacy of Bitcoin in one construction.

MPC distributes trust across parties who do not trust one another, and the distributed trust produces a cryptographic guarantee that no single party can violate. This is a different guarantee from what homomorphic encryption provides. Homomorphic encryption lets one party execute a computation on another party's private input. Multi-party computation lets several parties execute a computation on their own private inputs, with no party learning any other party's input. The two primitives solve complementary problems, and many real systems combine them. The cryptographic guarantee replaces a coordination cost that was previously priced into every cooperative computation: the cost of establishing enough trust to share the inputs. When that cost falls, cooperation expands to cases that were previously uneconomic.

Trusted Execution Environments

Trusted execution environments (TEEs) take a different architectural path. Where cryptographic means prevent the computing party from seeing the inputs, a TEE achieves the same outcome through hardware isolation. A region of memory inside the processor is marked as an enclave; code running inside the enclave decrypts inputs and produces outputs, while any code running outside the enclave (the operating system included, and every other process on the host alongside it) cannot observe enclave memory. An attestation mechanism lets a remote party verify that a specific piece of software is running inside an authentic enclave on an authentic processor.

TEE deployment at consumer scale breaks into two patterns. The first is the device-local enclave. ARM TrustZone on Android phones and Apple's Secure Enclave on iOS devices, together with the TPM 2.0 specification that ships on every modern PC, place a hardened execution environment inside hundreds of millions of consumer devices, where it holds biometric templates, payment-credential keys, disk-encryption keys, and attestation material. The device-local enclave is the oldest and most widely deployed consumer TEE pattern, and it is the least controversial because the user and the enclave live in the same physical device under the same owner.

The second pattern is the remote attested enclave. A consumer device sends a request to a cloud-operated server whose hardware and software can be cryptographically attested and whose code is published for inspection. Each server's software is cryptographically measured. The measurement is published, and the client device refuses to send a request to any server whose measurement does not match a published image. The servers are built to hold no persistent state beyond the request's lifetime, so that even a full compromise of a server at a later time yields no earlier request's inputs. Signal's Private Contact Discovery was an early instance of this pattern. Apple Private Cloud Compute, introduced in June 2024 to handle Apple Intelligence workloads exceeding on-device capacity, is the most consumer-visible deployment to date and has been published in the most architectural detail.

The promise of the architecture is that a cloud service can be operated in a way that the service itself cannot observe user inputs, which is the same structural claim as homomorphic encryption achieved through different means. The limit is that the guarantee depends on the provider's honest publication of server images and on the assumption that no side-channel attack breaks the enclave's hardware isolation. Trust is reduced to a narrower surface, and still required on that surface. The user has traded trust in a provider's operational practices for trust in its hardware-software supply chain and attestation discipline. Whether the new trust assumption is preferable depends on the user's model of the provider's incentives.

TEE-based privacy scales the most easily today. Homomorphic encryption remains expensive for general computation. Multi-party computation requires at least two non-colluding parties, and organizing them is a social problem as much as a technical one. TEEs run at plaintext speeds on general-purpose workloads, and the cryptographic overhead is limited to attestation and to the isolation boundary. The primitive fits the cloud-service business model almost exactly. Its history of side-channel attacks against SGX, however, shows that the hardware-integrity assumption remains actively contested. The Spectre and Meltdown families, along with the successor vulnerabilities published every year since, show that the contested boundary extends across the entire processor design. A TEE-based privacy claim must be evaluated against the specific hardware vendor's track record, the specific attestation architecture it uses, the specific software image published for verification, and the specific side-channel posture of the CPU on which the enclave runs. TEEs are useful when the alternative is no privacy guarantee at all, and they are inferior when the alternative is a cryptographic primitive that does not require trusting hardware.

The Edges: PIR and Differential Privacy

Two further primitives complete the picture at the edges of the design space.

Private Information Retrieval lets a client retrieve an item from a server's database without the server learning which item was retrieved. The query index is the private input; the item is the output. The server performs a computation over its entire database that depends cryptographically on the query but preserves no observable trace of which element the query selected. Information-theoretic PIR replicates the database across multiple non-colluding servers; computational PIR operates with a single server and relies on additively homomorphic or fully homomorphic encryption. The cost is that every query must touch every record in the database, which is why computational PIR took two decades of engineering to become practical. The applications that matter are the ones in which the query is itself the information. Bitcoin light clients are the clearest case: BIP 37 bloom filters leak which addresses a wallet cares about, and BIP 158 compact block filters leak less but still allow traffic analysis. A PIR-based light client would let a wallet fetch block filters and transaction data without telling the serving node which addresses or transactions it is watching.

Differential privacy is a statistical guarantee about aggregated data releases. It operates on the privacy of individuals whose records contribute to a released aggregate, a different concern from protecting individual records during a live computation. The mechanism is randomization: a differentially private release looks essentially the same whether any specific individual's record was included. An adversary who sees the output cannot tell whether any particular record was present, up to a multiplicative factor parametrized by epsilon. Small epsilon gives strong privacy at the cost of accuracy. The U.S. Census Bureau applied this to the 2020 redistricting release through the TopDown Algorithm. Apple uses local differential privacy for aggregate telemetry on iOS. Differential privacy composes across queries: two releases at epsilon₁ and epsilon₂ reveal information at combined level epsilon₁ plus epsilon₂, which means the privacy budget is a scarce resource that real deployments must allocate. The guarantee operates on the individual's contribution to an inference and leaves the inference itself visible; a DP-released statistic will still reveal that everyone in a group buys a product, and any individual known to be in that group will be implicated by the population-level pattern.

Resistance at the Compute Layer

A system's security is measured by the cost required to compromise it. Computing on secrets extends that measurement to the compute layer of the stack, which had previously been free to observe.

Homomorphic encryption's resistance surface is the set of cryptographic assumptions underlying the specific scheme in use. The assumption set is the same one underlying the post-quantum standards: learning-with-errors for lattice schemes, the hardness of decoding random linear codes for code-based schemes. A break in a specific scheme would affect the applications using that scheme; it would not break the family, because alternative schemes under different assumptions exist.

Multi-party computation's resistance surface is the threshold model. The guarantee holds if and only if fewer than the threshold number of participants collude. A threshold must be chosen large enough that collusion is infeasible, and the participants must be chosen to have diverse incentives. The construction binds together through the social structure of the participant set as much as through the cryptographic math.

Trusted execution environments have the largest resistance surface. Hardware vendor integrity, attestation mechanism correctness, side-channel resistance, and software-image verification are each separate assumptions, and the composed guarantee is the conjunction of all of them. A break in any single assumption compromises the whole. The empirical track record includes multiple documented side-channel attacks, and the architectural response has been to rebuild the hardware where software patching was insufficient. History shows both that the primitive is contestable and that the contesting process is active.

Compositions inherit this logic. An attacker must compromise each primitive in the composition, and the compromise cost compounds. The defender's architectural choice is the selection of primitives whose compositions raise the compromise cost above the adversary's willingness to pay. Computing on secrets promises something narrower than invulnerability and more useful than cryptographic folklore: the cost curve of observation now bends upward at the execution layer, which is the layer the adversary had previously assumed was free. That bending is the principal achievement of the last decade of cryptographic and hardware-security engineering, and it is the architectural basis on which the privacy-preserving applications of the next decade will be built.

In theory yes, but in practice the code is all mangled with nostr ...

2026-04-17T06:39:39Z

In reply to nevent1q…fk8k
_________________________

In theory yes, but in practice the code is all mangled with nostr deeply, specifically would be great to also support FIPS.

Here's some thoughts on the new architecture.
https://github.com/marmot-protocol/whitenoise-meta/blob/c387af9d1ad0d543112a9569ab04cac5fa188358/Engineering/marmot-architecture/target-architecture.md