Nostr notes by

Yeah

2026-07-15T19:03:21Z

In reply to nevent1q…53kz
_________________________

Yeah

It's less of an inefficiency for Americans themselves I ...

2026-07-15T18:27:17Z

In reply to nevent1q…hapg
_________________________

It's less of an inefficiency for Americans themselves I guess? Separate lines for citizens; there'd only be a tiny number of US citizens transiting through and not stopping.

It is a big wasted cost though, there's that.

Panama is a huge regional hub (I use it a lot), but less ...

2026-07-15T13:02:51Z

In reply to nevent1q…2acm
_________________________

Panama is a huge *regional* hub (I use it a lot), but less significant intercontinentally in my experience. Might just depend on my specific routes though.

Sometimes Canada works, from what I heard? Though I've never ...

2026-07-15T12:40:33Z

In reply to nevent1q…z4aw
_________________________

Sometimes Canada works, from what I heard? Though I've never used it, but I might soon.

Can't see it happening with Caribbean, too small I guess.

I wonder how many Americans are aware (because I don't think ...

2026-07-15T12:23:50Z

I wonder how many Americans are aware (because I don't think I've ever heard one mention it) just how uniquely obnoxious the transit system in their airports is. You might not immediately grok what I mean; you might think "foreigners aren't entitled to anything" but in which case you didn't get my point - my point is that *for a traveller who has no interest in entering the United States* the experience is uniquely obnoxious. Every other major international airport has what's called "transit". I'm going from country A to country B with a connecting flight in country C. if C != USA, I just stay in the pre-immigration area and move over to the other flight; sometimes they have baggage checks (and ticket checks ofc), but not full blown immigration, because you're not entering the country. The problem is that the USA is a *major* hub for flights, for the Western hemisphere; it's not trivial at all, to avoid it, for some routes. And couple this with the fact that US immigration is not exactly relaxed (which is fine, but is not fine when you have no intention of stepping foot in the country ...)

Why?

And as bad as it is for me, I could use the 'visa waiver program' (still shit - still have to go through immigration) but many countries don't have that entitlement, meaning a citizen wanting to travel *via* (again, not into, via) the US would have to do this just to get to their non-US destination. Which goes from obnoxious to .. I don't know, surreally obnoxious.

What really amused me about Borges' Library of Babel is how ...

2026-07-14T00:02:51Z

What really amused me about Borges' Library of Babel is how he goads the reader by giving them all the exact numbers required to count exactly how big the library will be if it contains every possible book, once, but then stops short of counting and starts musing about infinity :)

Even more amusing is the discussion of the fabled catálogo 😄 ... which can't exist. The *contents* of the library is ~perfectly compressible ("print every book length N" does it), but the *ordering* of the library, which is the purpose of a catalog, is perfectly incompressible: the only catalogue is the library itself!

It could maybe be done as a protocol between 2 participants. But, ...

2026-07-13T23:00:06Z

In reply to nevent1q…uzdj
_________________________

It could maybe be done as a protocol between 2 participants. But, in that model it's (maybe?) less interesting because you don't have the steganographic property. Would need some thinking ...

Hmm I'm not sure but it's possible you misunderstood my ...

2026-07-13T17:45:02Z

In reply to nevent1q…68ww
_________________________

Hmm I'm not sure but it's possible you misunderstood my point there. By skewed bet I mean that one side has a positive expectation and the other a negative one. Imagine like, the pot is 1M sats, but Alice puts up 400k sats and Bob puts up 600k sats. This is *not* a negative effect on privacy of the babilonia setup at all (I guess it has zero effect on the privacy benefit, maybe even it's slightly better, not sure); when I said "limits the activity" I meant, Bob cannot keep doing that ad infinitum because he'll eventually lose all his money from the negative expectation bets.

Def more people rather than more rounds; having a skewed bet ...

2026-07-13T15:54:12Z

In reply to nevent1q…fud9
_________________________

Def more people rather than more rounds; having a skewed bet means one side is paying the other, over time, which limits the activity.

Motivating participation, basically.

2026-07-13T02:07:57Z

In reply to nevent1q…zs35
_________________________

Motivating participation, basically.

True, it is kind of against the spirit of the idea. On the other ...

2026-07-12T21:03:30Z

In reply to nevent1q…ph7p
_________________________

True, it is kind of against the spirit of the idea. On the other hand I'm not convinced that some kind of hybrid is impossible .. maybe with 2 party coordination nested inside N party. Even if the properly p2p version feels much better...

So iow yeah i agree with you. The dusty change thing connects in ...

2026-07-12T19:32:17Z

In reply to nevent1q…udkx
_________________________

So iow yeah i agree with you.

The dusty change thing connects in with lightning probabilistic payments ideas, i guess. I.e. similar motivation.

Right. I briefly mention in Section 8 of the paper I just posted, ...

2026-07-12T19:15:17Z

In reply to nevent1q…jvkr
_________________________

Right. I briefly mention in Section 8 of the paper I just posted, rhat it's likely there are tricks to be played with n party coinjoin here, but indeed N>2 versions are way harder (collusion). Perhaps embed 2 party negot. inside.

Paper as promised: https://github.com/AdamISZ/babilonia-paper and ...

2026-07-12T19:12:34Z

Paper as promised:

https://github.com/AdamISZ/babilonia-paper

and delving post: https://delvingbitcoin.org/t/babilonia-probabilistic-coinjoin-and-covert-betting/2704

Pot sweeteners was a late addition and I think it's much more interesting because of that.

quoting
nevent1q…hzxt
https://mempool.space/signet/tx/2070fba2551a5702bcfbe964486692d8a5d4519bd58ae2ee2a7d6bf5aed847d4

https://mempool.space/signet/tx/c9e68df6f7384bc43a4379007265ff343e8c381e7ab232e7ea9b94037598803d#vin=0

Nothing about the two transactions shown is strange. The first is 2 in 2 out, the second is 1 in, 2 out; normal payments [1]. If you examine their witness you'll see they're like 90% of other taproot transactions, just keypath, no scripts involved.

But in fact, this is a bet. Two parties flipped a fair coin for the winnings (a small chunk of the input funds). Not literally; they used cryptography to get an exactly 50% chance of winning without having to trust the other. They were both running signet nodes (in fact I had one on my laptop at home and another on a VPS), and used decoy packets in BIP324 (bitcoin p2p encrypted transport) to communicate, so no one could even know the negotiation was happening (side note: this idea feels like it should be useful in many other contexts, and it's surprisingly easy to set up, with a very simple patch to your bitcoind).

So we have a fair bet inside a coinjoin; you could think of it as a randomized payjoin if you like, but, the transfer of funds is not for some goods and services but, just a wager, and it's perfectly fair because of a cryptographic trick that was discussed on delving [2] though it's changed from what was written there.

Payments inside coinjoins break subset sum analysis; this is just another kind of payment. Amongst other virtues of such a system is that it creates economic activity between peers without middlemen which is vital to Bitcoin's general pseudonymity.

The implementation is at https://github.com/AdamISZ/babilonia . The repo is currently 95% AI-written so not very readable (still not *unreadable*, but, y'know how it is) but I have a paper that I've nearly finished that is human written and human readable for those interested in the mechanics.

[1] In fact those familiar with details of payjoins *will* see something specific about the 1st transaction that makes it like a payjoin. But it isn't hard to remove that, and anyway, it's only a watermark for 'this is a payjoin', not for what it *actually* is...

[2] https://delvingbitcoin.org/t/emulating-op-rand/1409/7

Cheers!

2026-07-11T21:01:38Z

In reply to nevent1q…vv76
_________________________

Cheers!

Yes. Guess there's positive and negative here. Traffic ...

2026-07-11T15:10:56Z

In reply to nevent1q…fuy4
_________________________

Yes. Guess there's positive and negative here. Traffic shaping etc. vs spam traffic. Does Core have ddos defense against general encrypted noise... just dropping decoys is most of it I guess, but ..?

Nostr event nevent1qqsgyt0tnuh5ygs675c0s9a60sexy658geduj93kzwe9zwensc6ks8sp89mhxue69uhhyetvv9uju6r0v3kxymmpwfjzummjvuhkummnw3er5un9d3shjtngdajxccn0v9exgtn0wfnj76twvfhhsq3qvadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q8jws6p

2026-07-11T13:59:03Z

https://mempool.space/signet/tx/2070fba2551a5702bcfbe964486692d8a5d4519bd58ae2ee2a7d6bf5aed847d4

https://mempool.space/signet/tx/c9e68df6f7384bc43a4379007265ff343e8c381e7ab232e7ea9b94037598803d#vin=0

Nothing about the two transactions shown is strange. The first is 2 in 2 out, the second is 1 in, 2 out; normal payments [1]. If you examine their witness you'll see they're like 90% of other taproot transactions, just keypath, no scripts involved.

But in fact, this is a bet. Two parties flipped a fair coin for the winnings (a small chunk of the input funds). Not literally; they used cryptography to get an exactly 50% chance of winning without having to trust the other. They were both running signet nodes (in fact I had one on my laptop at home and another on a VPS), and used decoy packets in BIP324 (bitcoin p2p encrypted transport) to communicate, so no one could even know the negotiation was happening (side note: this idea feels like it should be useful in many other contexts, and it's surprisingly easy to set up, with a very simple patch to your bitcoind).

So we have a fair bet inside a coinjoin; you could think of it as a randomized payjoin if you like, but, the transfer of funds is not for some goods and services but, just a wager, and it's perfectly fair because of a cryptographic trick that was discussed on delving [2] though it's changed from what was written there.

Payments inside coinjoins break subset sum analysis; this is just another kind of payment. Amongst other virtues of such a system is that it creates economic activity between peers without middlemen which is vital to Bitcoin's general pseudonymity.

The implementation is at https://github.com/AdamISZ/babilonia . The repo is currently 95% AI-written so not very readable (still not *unreadable*, but, y'know how it is) but I have a paper that I've nearly finished that is human written and human readable for those interested in the mechanics.

[1] In fact those familiar with details of payjoins *will* see something specific about the 1st transaction that makes it like a payjoin. But it isn't hard to remove that, and anyway, it's only a watermark for 'this is a payjoin', not for what it *actually* is...

[2] https://delvingbitcoin.org/t/emulating-op-rand/1409/7

Read about the 30 maidens of Geneva. Quite remarkable. However ...

2026-07-10T11:28:13Z

Read about the 30 maidens of Geneva.

Quite remarkable. However stupid you think the bureaucrats running your life are, they'll struggle to compete with late18th century France.

It's actually a perfect model of why adversarial thinking matters. In the absence of an adversary, choosing the price of the annuity for the average buyer (age 50) is an efficient decision.

It's a very common thing. I'd mainly call it wishful ...

2026-07-10T11:19:09Z

In reply to nevent1q…4mer
_________________________

It's a very common thing. I'd mainly call it wishful thinking: they want bitcoin to be cool, they wan the interface of using it to be slick, they want to use the companies and tools of the famous people they admire, so they choose people like Jack Mallers, and then when the reality of these nonfree tools inevitably shows itself, they get hit with cognitive dissonance.

The ugly truth is you kind of have to learn how to deal with both the shitty older systems and the new genuinely empowering open systems, the latter are clunky, dangerous, difficult and not cool/slick at all but 100% worth learning. Occasionally you find little corners that are truly magical.

Gotcha.

2026-07-10T11:01:28Z

In reply to nevent1q…7mte
_________________________

Gotcha.

I have a couple test transactions at 1.58 sats/vb stuck for 4 ...

2026-07-09T21:46:17Z

In reply to nevent1q…ux3t
_________________________

I have a couple test transactions at 1.58 sats/vb stuck for 4 hours now, lol. Not that it matters, just, I'm confused what's happening.

Why are signet blocks only mining 1M weight not 4? ...

2026-07-09T19:00:00Z

Why are signet blocks only mining 1M weight not 4?

https://mempool.space/signet

Excellent summary. I think the final paragraph is the most ...

2026-07-09T17:07:13Z

Excellent summary. I think the final paragraph is the most important, but also: at least in theory, any particular round with a central coordinator and anonymous counterparty, cannot be guaranteed to not be Sybiled by the coordinator.

With any form of coordination, that's possible; indeed that was a common early critique of Joinmarket, and even imposing anti-Sybil style costs doesn't remove that risk, either.

The reason I always saw that risk as worse with a central coordinator was the standard CPOF arguments.

Let's not forget that a central coordinator offers big advantages, too.

quoting
nevent1q…vxxs
You are fully trusting the coordinator with your privacy when using Whirpool (Samourai). Here are some practical attacks with a PoC.

https://gist.github.com/m0wer/e701bf5934474935c459b5e84e5d4e1b

Thanks.

2026-07-08T20:59:32Z

In reply to nevent1q…e2kr
_________________________

Thanks.

Jesus. The cynicism of this is unreal. #nevent1q…w5wj

2026-07-08T12:39:36Z

Jesus. The cynicism of this is unreal.

quoting
nevent1q…w5wj
The EU Parliament rejected mass scanning of private messages in March.

Yesterday, it approved an urgent procedure to revive the measure, setting up a decisive vote on Thursday, the last sitting day before summer recess.

At second reading, the text passes automatically unless 361 MEPs vote against it, and some MEPs have already left for the Summer break...

https://reclaimthenet.org/eu-parliament-revives-chat-surveillance-for-thursday-vote

Isn't it worth mentioning that by default, makers randomize ...

2026-07-07T16:59:39Z

In reply to nevent1q…jvvt
_________________________

Isn't it worth mentioning that by default, makers randomize fees in reannouncements?

Or am I misremembering something. Not unlikely.

I agree this is not some straightforward privacy upgrade, as some ...

2026-07-07T16:56:32Z

In reply to nevent1q…rrn6
_________________________

I agree this is not some straightforward privacy upgrade, as some want to paint it. But disagree that it's a privacy downgrade; it's more nuanced than that.

Yeah needs a fork. I haven't read it yet 😄 Hmm how it ...

2026-07-07T16:54:45Z

In reply to nevent1q…avwf
_________________________

Yeah needs a fork. I haven't read it yet 😄

Hmm how it work; presumably different checksig opcode with the typical noop opcode for soft fork. You couldn't just use a sighash flag because it's not *only* changing the message signed; it's a different verification algo.

That's the answer I wanted to make to @nprofile…qm68 more ...

2026-07-07T13:59:53Z

In reply to nevent1q…s3uj
_________________________

That's the answer I wanted to make to VitorPamplona (nprofile…qm68) more than matt (nprofile…4e3p) tbh, but, either way 😄

Clearly that's the pure perspective, but I'll keep ...

2026-07-07T13:58:23Z

In reply to nevent1q…z5hl
_________________________

Clearly that's the pure perspective, but I'll keep harping on this point: a model like Phoenix where you don't have privacy from Phoenix is absolutely different from a model like onchain payments. It fits closer to, and is better than, what people are (unconsciously) used to: when they use a bank card they know the bank knows all their transactions, and they accept that tradeoff (mostly because they have no choice to be fair!). I'm not saying a CPOF isn't a problem; such things will always come back to bite you eventually, if they get big enough. But that tradeoff is not even close to being a bad tradeoff with the current status quo, and it is emphatically a better privacy model than the vast majority of others (and I suppose it can still get better). So: self custody, privacy w.r.t. merchant[1] but not service provider, strictly better than bank money: no self custody, privacy w.r.t merchant but not service provider.

[1] just means they don't see your financial history

Fabian Jahr put out a concrete proposal for DahLIAS! ...

2026-07-07T13:49:48Z

Fabian Jahr put out a concrete proposal for DahLIAS!

https://github.com/fjahr/bips/blob/4b34e86d0040edad6cba3f7518b33472a11ebeaf/bip-XXXX.mediawiki

This is a CISA proposal with a security proof. I was hoping there'd be more comments on DahLIAS by now, but having read it myself (the paper, not this BIP, yet) I think it's solid; the only part I didn't like, I was convinced by the authors is just aesthetics.

Drag yourself away from PQC panic or bip110 panic, if you dare 😄

Its sender side privacy is not bad at all, speaking generally.

2026-07-05T21:53:15Z

In reply to nevent1q…nahn
_________________________

Its sender side privacy is not bad at all, speaking generally.

It's definitely a more correct position to take by default ...

2026-07-05T19:42:23Z

In reply to nevent1q…e5jy
_________________________

It's definitely a more correct position to take *by default* but by saying it's absolutely true that everything is traceable you're failing at the other extreme.

And especially with Lightning. Even with onchain. The problem is not that everything's traceable, the problem is people thinking that some particular simple system fully defends you from that.

Certainly not always true.

2026-07-05T18:58:32Z

In reply to nevent1q…0szd
_________________________

Certainly not always true.

That last point is a good one. By copying content and then have ...

2026-07-04T12:32:17Z

In reply to nevent1q…hv39
_________________________

That last point is a good one. By copying content and then have the pipe constantly move around, you could make it near impossible to stop. I guess, that's exactly how bittorrent works 😄

Also according to claude, in Spanish they also have 'mas feo ...

2026-07-03T20:50:11Z

In reply to nevent1q…pgg5
_________________________

Also according to claude, in Spanish they also have 'mas feo que pegarle a un padre'.

That one's not so much absurd, more disturbing.

2026-07-03T20:48:06Z

In reply to nevent1q…u9wa
_________________________

That one's not so much absurd, more disturbing.

Every now and then i learn a new Spanish idiom that genuinely ...

2026-07-03T16:36:50Z

Every now and then i learn a new Spanish idiom that genuinely makes me lol. Today it was "Es tan feo que le da un susto al miedo." 😆

(Something like: "he's so ugly he gives fear a fright")

I can't think of an English idiom that has such a streak of abstract absurdism.

Hat tip "Erre que ELE" on youtube.

Valid thoughts; I guess you cannot make absolute statements about ...

2026-07-03T16:15:33Z

In reply to nevent1q…70ha
_________________________

Valid thoughts; I guess you cannot make absolute statements about the security of the system without making assumptions about the distribution of the covertext, i.e. how you 'normally' use the LLM model.

Not necessarily. Run the software offline and isolated. But from ...

2026-07-03T10:58:31Z

In reply to nevent1q…9g07
_________________________

Not necessarily. Run the software offline and isolated.

But from another angle your warning isn't strong enough: knowing the privkey generation is safe does not prevent key exfiltration via signatures, for example.

I set up haven and am happy with it. But my needs are very basic ...

2026-07-03T10:55:03Z

In reply to nevent1q…qg27
_________________________

I set up haven and am happy with it. But my needs are very basic and I don't know what NIP 50 is 😄

Ack! (i.e. it works 😁)

2026-07-02T18:40:56Z

In reply to nevent1q…gzyr
_________________________

Ack!

(i.e. it works 😁)

I was about to post this, but see this description; it's not ...

2026-07-02T17:34:06Z

In reply to nevent1q…4aa8
_________________________

I was about to post this, but see this description; it's not exact, and it's from an LLM, but it's very digestible and gets across the basic idea:

quoting
nevent1q…y2qp
It's different from what I was thinking. Here is a Chinese LLM generated example for irony.

## A Concrete, Step-by-Step Example

To make this tangible, let's use a **toy model with a small vocabulary of 11 words** so you can see every number. The real scheme works identically, just with vocabularies of ~50,000 tokens and floating-point probabilities.

### Setup

**The model:** A tiny "LLM" with a fixed vocabulary of 11 words:

`{apple, date, banana, cherry, pie, juice, tart, sauce, for, with, and}`

At each step, the model assigns a probability to **all 11 words** based on the context. The probabilities change as the context grows, and they always sum to 1.0. (A real LLM does the same thing, just with ~50,000 tokens instead of 11.)

**The shared context/prompt:** `"I like to eat"` — both Alice and Bob have this. It is not secret, just shared.

**The shared secret key:** Used to seed a pseudorandom number generator (PRNG). The key produces the random stream: `0.15, 0.62, 0.40, ...` (uniform random numbers between 0 and 1).

**The secret message Alice wants to send:** The bits `0 1 1` (3 bits — in reality this would be a longer message, but let's keep it tiny).

---

### Encoding (Alice's Side)

#### Step 1: Alice runs the model

Alice feeds the shared context `"I like to eat"` into the model. The model outputs a probability distribution over all 11 words. After "I like to eat", fruits are the most natural continuation, so they get the highest probabilities:

| Word | Probability | Interval |
|--------|-------------|---------------|
| apple | 0.20 | [0.00, 0.20) |
| date | 0.15 | [0.20, 0.35) |
| banana | 0.10 | [0.35, 0.45) |
| cherry | 0.05 | [0.45, 0.50) |
| pie | 0.20 | [0.50, 0.70) |
| juice | 0.12 | [0.70, 0.82) |
| tart | 0.08 | [0.82, 0.90) |
| sauce | 0.05 | [0.90, 0.95) |
| for | 0.03 | [0.95, 0.98) |
| with | 0.015 | [0.98, 0.995) |
| and | 0.005 | [0.995, 1.00) |

This is just normal LLM behavior — the model is predicting what word comes next. Notice the probabilities sum to 1.0, and the intervals partition [0, 1).

#### Step 2: Alice encodes her first secret bit

Alice's first secret bit is `0`. She interprets this as: "look in the **first half** of the range [0, 1), i.e., [0.00, 0.50)."

The words whose intervals fall within [0.00, 0.50) are:
- apple: [0.00, 0.20)
- date: [0.20, 0.35)
- banana: [0.35, 0.45)
- cherry: [0.45, 0.50)

Alice uses her next random number from the shared key, `0.15`, to pick within [0.00, 0.50). The value `0.15` falls in [0.00, 0.20), which is **apple**.

**Alice outputs: "apple"**

Text so far: `"I like to eat apple"`

#### Step 3: Alice runs the model again

Now the context is `"I like to eat apple"`. The model outputs a new distribution over all 11 words. After "apple", food preparations like pie and tart become more likely, while the other fruits become less likely:

| Word | Probability | Interval |
|--------|-------------|---------------|
| apple | 0.15 | [0.00, 0.15) |
| date | 0.10 | [0.15, 0.25) |
| banana | 0.08 | [0.25, 0.33) |
| cherry | 0.07 | [0.33, 0.40) |
| for | 0.06 | [0.40, 0.46) |
| with | 0.04 | [0.46, 0.50) |
| pie | 0.20 | [0.50, 0.70) |
| tart | 0.16 | [0.70, 0.86) |
| juice | 0.08 | [0.86, 0.94) |
| sauce | 0.04 | [0.94, 0.98) |
| and | 0.02 | [0.98, 1.00) |

Alice's next secret bit is `1`. This means "look in the **second half** [0.50, 1.00)."

The words whose intervals fall within [0.50, 1.00) are:
- pie: [0.50, 0.70)
- tart: [0.70, 0.86)
- juice: [0.86, 0.94)
- sauce: [0.94, 0.98)
- and: [0.98, 1.00)

Alice uses her next random number, `0.62`, to pick within [0.50, 1.00). She scales it into that range: `0.50 + 0.62 × 0.50 = 0.81`. The value `0.81` falls in [0.70, 0.86), which is **tart**.

**Alice outputs: "tart"**

Text so far: `"I like to eat apple tart"`

#### Step 4: Alice runs the model again

Context: `"I like to eat apple tart"`. Model output — after "apple tart", connectors and prepositions like "with" and "and" become the most likely continuations, while the fruits and preparations drop in probability:

| Word | Probability | Interval |
|--------|-------------|---------------|
| apple | 0.10 | [0.00, 0.10) |
| date | 0.08 | [0.10, 0.18) |
| banana | 0.07 | [0.18, 0.25) |
| cherry | 0.06 | [0.25, 0.31) |
| pie | 0.08 | [0.31, 0.39) |
| juice | 0.06 | [0.39, 0.45) |
| for | 0.05 | [0.45, 0.50) |
| tart | 0.06 | [0.50, 0.56) |
| sauce | 0.04 | [0.56, 0.60) |
| with | 0.18 | [0.60, 0.78) |
| and | 0.22 | [0.78, 1.00) |

Alice's next secret bit is `1`. Look in the second half [0.50, 1.00):

The words whose intervals fall within [0.50, 1.00) are:
- tart: [0.50, 0.56)
- sauce: [0.56, 0.60)
- with: [0.60, 0.78)
- and: [0.78, 1.00)

Random number `0.40` → scaled: `0.50 + 0.40 × 0.50 = 0.70`. Falls in [0.60, 0.78), which is **with**.

**Alice outputs: "with"**

Text so far: `"I like to eat apple tart with"`

#### Alice is done

Alice sends Bob the text: **"I like to eat apple tart with"**

(Plus whatever padding/continuation she wants to make it look like a complete sentence.)

To any observer, this looks like someone generated a sentence about food. Nothing suspicious.

---

### Decoding (Bob's Side)

Bob has:
- The received text: `"I like to eat apple tart with"`
- The same model
- The same shared context: `"I like to eat"`
- The same shared key (so the same random stream: `0.15, 0.62, 0.40, ...`)

#### Step D1: Bob runs the model

Bob feeds `"I like to eat"` into the model. He gets the **same** distribution Alice got:

| Word | Probability | Interval |
|--------|-------------|---------------|
| apple | 0.20 | [0.00, 0.20) |
| date | 0.15 | [0.20, 0.35) |
| banana | 0.10 | [0.35, 0.45) |
| cherry | 0.05 | [0.45, 0.50) |
| pie | 0.20 | [0.50, 0.70) |
| juice | 0.12 | [0.70, 0.82) |
| tart | 0.08 | [0.82, 0.90) |
| sauce | 0.05 | [0.90, 0.95) |
| for | 0.03 | [0.95, 0.98) |
| with | 0.015 | [0.98, 0.995) |
| and | 0.005 | [0.995, 1.00) |

Bob sees that Alice chose **apple**, which is in the interval [0.00, 0.20).

Now Bob asks: "Which half was apple in?" Apple is in [0.00, 0.20), which is in the **first half** [0.00, 0.50).

**First half → bit `0`**

**Bob recovers bit: `0`** ✓

#### Step D2: Bob runs the model again

Bob appends "apple" to context: `"I like to eat apple"`. Model output:

| Word | Probability | Interval |
|--------|-------------|---------------|
| apple | 0.15 | [0.00, 0.15) |
| date | 0.10 | [0.15, 0.25) |
| banana | 0.08 | [0.25, 0.33) |
| cherry | 0.07 | [0.33, 0.40) |
| for | 0.06 | [0.40, 0.46) |
| with | 0.04 | [0.46, 0.50) |
| pie | 0.20 | [0.50, 0.70) |
| tart | 0.16 | [0.70, 0.86) |
| juice | 0.08 | [0.86, 0.94) |
| sauce | 0.04 | [0.94, 0.98) |
| and | 0.02 | [0.98, 1.00) |

Bob sees Alice chose **tart**, interval [0.70, 0.86).

"Which half was tart in?" [0.70, 0.86) is in the **second half** [0.50, 1.00).

**Second half → bit `1`**

**Bob recovers bit: `1`** ✓

#### Step D3: Bob runs the model again

Context: `"I like to eat apple tart"`. Model output:

| Word | Probability | Interval |
|--------|-------------|---------------|
| apple | 0.10 | [0.00, 0.10) |
| date | 0.08 | [0.10, 0.18) |
| banana | 0.07 | [0.18, 0.25) |
| cherry | 0.06 | [0.25, 0.31) |
| pie | 0.08 | [0.31, 0.39) |
| juice | 0.06 | [0.39, 0.45) |
| for | 0.05 | [0.45, 0.50) |
| tart | 0.06 | [0.50, 0.56) |
| sauce | 0.04 | [0.56, 0.60) |
| with | 0.18 | [0.60, 0.78) |
| and | 0.22 | [0.78, 1.00) |

Bob sees Alice chose **with**, interval [0.60, 0.78).

"Which half?" [0.60, 0.78) is in the **second half** [0.50, 1.00).

**Second half → bit `1`**

**Bob recovers bit: `1`** ✓

---

### Result

Bob has recovered: `0 1 1` — exactly the message Alice sent.

---

## Diagram

```
┌──────────────────────────────────────────────────────────────────┐
│ ALICE (ENCODER) │
│ │
│ Secret bits: 0, 1, 1 │
│ Shared context: "I like to eat" │
│ Shared key → random stream: 0.15, 0.62, 0.40 │
│ │
│ For each bit: │
│ 1. Run model with current context → distribution │
│ 2. Use bit to pick which HALF of [0,1) to look in │
│ 3. Use random# to pick a word within that half │
│ 4. Append word to context, repeat │
│ │
│ Output: "I like to eat apple tart with" │
└──────────────────────────────────────────────────────────────────┘
│
│ (sent over channel — looks innocent)
▼
┌──────────────────────────────────────────────────────────────────┐
│ BOB (DECODER) │
│ │
│ Received text: "I like to eat apple tart with" │
│ Shared context: "I like to eat" (SAME as Alice) │
│ Shared key → random stream: 0.15, 0.62, 0.40 (SAME as Alice) │
│ │
│ For each word: │
│ 1. Run model with current context → SAME distribution │
│ 2. Find which interval the word falls in │
│ 3. Determine which HALF that interval is in │
│ 4. That half = the recovered bit │
│ 5. Append word to context, repeat │
│ │
│ Recovered bits: 0, 1, 1 ✓ │
└──────────────────────────────────────────────────────────────────┘
```

---

## Key Points

1. **The LLM never saw the secret message.** The secret bits controlled *which word was picked* from the distribution. The LLM just produced distributions.

2. **The output looks natural.** "I like to eat apple tart with" is a perfectly normal sentence. A censor seeing this has no reason to be suspicious.

3. **Both sides run the same model with the same context.** This is why they get the same distributions. If Bob had a different model or different context, the distributions would differ and decoding would fail.

4. **The shared key provides the random stream.** This is needed for the encoding to be secure — without it, the censor could run the same model and try to decode. With the key, the censor can't reproduce the random choices.

5. **Each token encodes roughly 1 bit** in this toy example (because we split into 2 halves). In reality, with arithmetic coding over a 50,000-word vocabulary, you can encode **multiple bits per token** — roughly 2–4 bits per token for a real LLM, depending on how uncertain the model is at each step.

6. **The "half" splitting is the simplified version.** The real scheme (from the Meteor paper, eprint.iacr.org/2021/686) uses full arithmetic coding, which is more efficient — it doesn't waste the probability mass the way a 2-way split does. But the principle is the same: the secret bits steer the selection within the model's probability distribution.

Yes. But read my interaction with @nprofile…xr8v in-thread.

2026-07-02T17:32:29Z

In reply to nevent1q…ewdu
_________________________

Yes. But read my interaction with provoost (nprofile…xr8v) in-thread.

Ah it's a client thing. I can read it on primal fine.

2026-07-02T17:30:09Z

In reply to nevent1q…rfeh
_________________________

Ah it's a client thing. I can read it on primal fine.

Cool! I also find I can't read that on phone. Does it need a ...

2026-07-02T17:07:19Z

In reply to nevent1q…5qh8
_________________________

Cool!

I also find I can't read that on phone. Does it need a higher res?

Btw I had this non-mathematical way of thinking about it: take markets, like say you're trading USD against EUR in the currency markets. As we all know, part of the volatility of markets is not just the price changing, but the *volume* changing, that is, there are times when the number of trades coming in per second is very high, and there are other periods where very few trades happen. If you plot price vs time, the normal way, it's very bursty, but if you treated the x-axis as 'one tick forwards per trade' not 'one tick forwards per second', it would make the chart smoother and less erratic. There's a very similar mechanic here: Meteor fits bits of hidden-message into the LLM-message at a rate that *matches* the rate of new information in the LLM's chatter. For example if you have "blah blah Tyrannosaurus.." then the next token output of "Rex" is near-guaranteed; there's almost *no information* from that next word. So Meteor by its algorithm doesn't put any new bits into that token. It basically matches the rate of flow of information, and that's why it's perfectly hiding the secret.

I largely agree, but after reading most of the article, I'm ...

2026-07-01T19:25:09Z

In reply to nevent1q…28gy
_________________________

I largely agree, but after reading most of the article, I'm surprised you recommend it ... it seems to be taking a very reductionist position and caricaturing the pro bitcoin or pro cypherpunk position.

I think that's a different problem. But not sure if it's ...

2026-07-01T14:52:19Z

In reply to nevent1q…k8rw
_________________________

I think that's a different problem. But not sure if it's worse or better, probably worse if that's deeply hardwired.

I tried a couple of times, but I'm not inclined to try ...

2026-07-01T13:53:41Z

In reply to nevent1q…c2vj
_________________________

I tried a couple of times, but I'm not inclined to try further; if I'm not in control and am guessing what Anthropic wants me to say, well, no, I'm not going to do that.

I could ramble but you already understand I'm absolutely sure!

DJB is one of his periodic tirades against NSA interference. His ...

2026-07-01T13:50:42Z

DJB is one of his periodic tirades against NSA interference. His current campaign is to argue against the (probably genuinely really bad idea) of forcing everything to PQC instead of PQC+ECC. It's honestly hard to see good arguments why he's wrong other than ... well, the NSA actually backdooring and/or controlling things. I particularly liked this part: "I have a paper that exploits a simpler tightness gap in another lattice-based cryptosystem, FrodoKEM. For example, the paper shows that if you send 240 ciphertexts to a frodokem640 public key then one of the ciphertexts will be decrypted by a large-scale attack that's feasible today. This is beyond an academic demo, but it does disprove an official FrodoKEM security claim. That version of FrodoKEM was then officially renamed "ephemeral FrodoKEM" (which I think means we're supposed to forget this version ever existed) and was officially replaced with a revised "FrodoKEM". " 😄

https://blog.cr.yp.to/20260630-risk.html