The Jar Learns to Hide Which Jar

SEPTEMBER 29, 2026

Quick follow-up to the review I wrote in September. A text from the wallet's author last night: Lightning in a Jar now sends and receives silent payments, with the first inter-wallet transactions running that same night. A disclosure and a caveat, both upfront, same as last time. The disclosure: he's a friend, and this is a text message, not a press release. The caveat: I went and checked the public repository before writing this, the way I did for the original review, and as of this morning it shows the sending half working and tested — receiving is noted in the code as not built yet. That's expected; a text at 11pm about a feature that ships "tonight" can outrun a public repo by a day. I'm reporting what he told me as what he told me, and what I could verify in the code as what I verified. Don't conflate the two.

What I can confirm, because it's sitting in the source: the send side speaks BIP-352, the actual Bitcoin standard for silent payments, not a lookalike — the wallet's code implements the BIP's own math and runs the BIP's own published test vectors. That's the right way to build this, and it's consistent with everything else I found reading his code in September.

What a Silent Payment Actually Is

The problem silent payments solve is narrower and more specific than "bitcoin isn't private," and it's worth being precise about which problem, because the precision is the whole point. Ordinary bitcoin addresses are meant to be used once. Reuse one — post it on a website, hand it out as a tip jar, use the same receive address for every paycheck — and every payment to it is now visibly the same recipient on a public ledger anyone can read. That's not a bug in any particular wallet; it's just what a reused address is. Silent payments fix exactly that: you publish one address, permanently, the same one every time — but every payment that arrives at it lands at a different on-chain output, one only you can find and spend, computed from a bit of elliptic-curve math between your public key and the sender's. Nobody looking at the chain can tell those outputs belong to the same address, because on the chain, they don't — there is no reused address to look at. You get the convenience of a static, postable address without paying for it in linkability.

Does This Make Bitcoin Private for the Rest of Us?

Here's the honest answer, not the exciting one: it closes one specific leak, and it's a real leak worth closing, but it's not a privacy cloak, and nobody using this wallet should walk away thinking their bitcoin has gone anonymous. A few things silent payments don't touch:

It's an on-chain feature, not a Lightning one. The payments that move through channels — the thing this wallet mostly does — already have reasonable privacy from onion routing; the LSP that opens your channel can't see the final recipient of a payment that passes through it. Silent payments are about the on-chain side: opening a channel, closing one, receiving a deposit. That's where address reuse was the actual risk.

It doesn't hide the amount. Every bitcoin transaction publishes exactly how much moved, silent-payment output or not. A privacy technique that hides who without hiding how much still tells a patient observer a lot.

It doesn't erase where the coins came from. A silent payment protects the receiving address from being linked to future payments. It says nothing about the history of the coins the sender uses to pay you, or the history of the coins you already hold and later spend onward. If those coins trace back to an exchange that verified your name — which is where most people's bitcoin starts — that link exists independent of anything this feature does.

It doesn't hide your IP address, your device, or your habits. Chain analysis is one slice of how privacy gets lost; network-level observation and simple behavioral patterns (same wallet, same times of day, same rough amounts) are others, and none of them are this BIP's job.

So: a genuine, well-specified improvement, aimed correctly at a real and well-understood problem — and one more reason this remains the kind of project worth watching. It doesn't move my verdict from the original review, which was never about any single feature. The three things I said would change "not yet for strangers" to "yes" are unchanged: an LDK catch-up, an outside reader of the patch set, a second registered LSP. This is a good feature landing on schedule. It's not one of the three.

Update, Same Night: Why He Actually Built It

A couple more messages came in while I was writing the above, worth folding in here rather than banking for a separate post, because he's clearly still mid-build tonight — more on that in a second. He volunteered, unprompted, the same reservation this post just spent several paragraphs on: that silent payments are a more complicated feature than the name suggests, and don't actually make a payment invisible on the chain. When the builder raises your own caveat before you ask him anything, that's a good sign about the builder, whatever it says about the feature.

What moved him from reservation to shipping, roughly: two upsides, then a third that settled it. The two — the address he publishes stays reusable, post it once, same as today, while the actual on-chain output it resolves to changes on the backend with every payment (the mechanism above, under fancier language), and that makes it meaningfully harder for chain-analysis firms to link his users' payments together. The third, the one he credits with actually getting this shipped: he says he worked out a standard way to recover on-chain silent payments from a wallet's seed, using an approach similar to how Lightning in a Jar already recovers Lightning funds. That's the less glamorous half of any rotating-address scheme — a wallet that scatters your coins across unpredictable outputs still has to be able to find them all again from twelve words on a new phone — and by his account it was the unsolved piece standing between silent payments being a nice idea and silent payments shipping.

Same rule as above: that's what he told me, not what I've verified. The public repository hasn't moved since the commit I checked for this post — last push 2026-09-26 — so the recovery scheme isn't there yet to read. He says he's testing it today, alongside a pass at cleaning up the wallet's menus. Genuinely don't know yet whether either lands as described; I'll look again before the October recheck, and sooner if he tells me it's live.