• The Great UX Fix
• Identity ≠ ** **Money, and Should Not Be
• Privacy on Bitcoin Is Deliberate, Not Forgotten
• A Brief History Lesson
• nsec Is Hot. Bitcoin Keys Should Not Be.
• Dust Is Not Cute, and UTXO Bloat Is Not Free
• Nostr “Silent Payments”: Peak Vibeslop
• Damned If You Spend, Damned If You Don’t
• Public Service Announcement
• Closing

There is a pattern in Bitcoin that repeats every few years. A clever, energetic developer wanders in, finds the rules frustrating, ignores seventeen years of discussion, ships a feature in a weekend, and announces they have fixed Bitcoin.

In 2013, it was Vitalik Buterin, who came in with similar energy and decided “bitcoin is a bad protocol to build this stuff onto”. He wanted to just do things. He left, built Ethereum, and we got the shitcoin casino plundering the world for a decade.

This week, it is @0461f...474dd with on-chain zaps in Ditto. @aa904...a844b adopted it the same week. Thousands of Nostr users now have their social identity glued to a Bitcoin address by default. Most have no idea, and no context to evaluate what was just done to them.

The pitch: derive a Bitcoin address from an npub and zap on-chain. The promise: “no additional setup for senders OR receivers,” send money to anyone, “whether they’re ready or not”.

Read that line again.

This is not better UX. It is removing consent from the receiver and pushing every Nostr user into unsolicited financial exposure they do not even know exists.

@6e468...eee93 already wrote the measured response in Careful, Icarus. Please read it. We will not repeat his arguments. He summed up the most important argument against it:

“The user does not need to use the feature. Someone can use it at them.”

That distinction matters in Bitcoin. And no, “bitcoin is a public ledger, bro”, “zaps are already public, bro”, is not a clever rebuttal.

At first, this looked like ordinary ignorance: a developer who has not yet internalized UTXOs, dust, coin selection, wallet labels, hot-key risks, backups, or Bitcoin history. But when peers raised the issues (Gzuuus, Derek, Gigi, Calle, L0la and many more) and the response was writing a self-congratulatory victory lap, calling the same peers religious boomers while completely ignoring the issues, the distinction between ignorance, gaslighting, and hostile design stopped being interesting.

Alex may not know this yet, but the religious bitcoin fanatics he refers to wear the Toxic Maximalist badge with honor and duty.

Let us begin.

§The Great UX Fix

Lightning setup is frames as friction and on-chain zaps as the smooth, frictionless solution Bitcoin was supposed to have.

Existing zap UX:

1. Install a Lightning wallet — npub.cash, Primal, Wallet of Satoshi, Phoenix, Alby, Cashu, or run your own node. Pick a custody tradeoff.

2. Paste a Lightning address or LNURL into your Nostr profile.

3. Receive zaps.

Roughly five minutes. Bounded blast radius. The wallet handles routing, channel management, dust, and change. Social identity and monetary history stay separate. The user does not have to know any of that exists. This is good UX engineered around the constraints of a public ledger in an adversarial environment.

Proposed on-chain zap UX, forced on every Nostr user:

• Receive funds whether you opted in or not.

• Learn that Bitcoin is not an accounts system.

• Learn that address reuse is very, very bad.

• Learn that your shitposting key now has monetary consequences.

• Learn coin selection and labelling. (There is a whole BIP for it.)

• Build a mental model of UTXOs, toxic change, dust, fee markets, common-input-ownership heuristics, change detection, social profiling, timing analysis, and chain-analysis correlations.

• Learn that consolidating funds merges histories you may not want merged.

• Learn that moving a UTXO is a public declaration of ownership — goodbye plausible deniability — and not moving it keeps the bullseye on your forehead for $5 wrench attacks or hostile governments. Pick your favourite adversary.

• Learn all this because someone wanted to remove the friction of pasting a Lightning address.

That is not better UX. That is hazing.

You have not removed friction. You have taken five minutes of one-time setup that a custodial Lightning wallet abstracts, and replaced it with a lifetime of subtle, irreversible privacy mistakes paid for by users who just want to shitpost.

People still struggle with twelve words. Twelve.** We have spent seventeen years trying to teach custody, address reuse, backups, passphrases, fees, and privacy. The new proposal is to make every new Nostr user accidentally enroll in an on-chain privacy curriculum because pasting a Lightning address from Wallet of Satoshi felt like too much work for a zap?

And this is from a self-proclaimed Bitcoin fixer who had to google coin control in 2026! No comments.

§Identity ≠ ** **Money, and Should Not Be

There is a persistent confusion here between public settlement and publicly binding identity to transactions. The moment npub = Bitcoin address, three things happen:

1. Your social graph is bolted to your monetary graph. Forever. Immutably. Retroactively. Especially for the people this “solution” is for, because they have no idea this is happening.

2. Every shitpost, every GM, every #foodstr, every reply, every family photo becomes rich profiling fuel for chain-analysis and criminals. The Feds do not need a subpoena anymore. You handed them the dossier.

3. Every npub becomes a permanent target. $5 wrench attacks, hostile jurisdictions, doxxed family members - whether you are ready or not 🙃.

You are better off zapping through Stripe. At least Stripe is not going to send someone with a wrench to your door.

The exact threat model Lightning was designed to mitigate is the “fix” Alex is proud of. Will Nostr users need a “social npub” and a separate “zap npub” now? Nostr was a niche and sometimes a hard experience. Welcome to a dangerous one.

§Privacy on Bitcoin Is Deliberate, Not Forgotten

A public ledger is not a bug. It is a feature fought for, repeatedly, against every “let’s add native privacy” proposal across Bitcoin’s existence. Public auditability of supply is non-negotiable. Privacy lives in layers. CoinJoin, PayJoin, CoinSwap, Silent Payments (the real one), Lightning, ecash; each with explicit tradeoffs, each chosen by the user.

“Other blockchains like Monero have completely fixed the privacy problem,” Alex writes, “but all the money is in Bitcoin.” He thinks privacy belongs on the base layer. He has no model of threat vectors and measures success by feature count.

He also writes:

“Probably the most compelling case for Bitcoin privacy is that donors to Alexei Navalny’s Bitcoin address are still being prosecuted today.”

Yes, that is exactly the case for not attaching social identity to monetary history.

§A Brief History Lesson

The claim that Lightning was created out of fear from the 2017 bull run is not history. It is fan fiction.

Payment channel ideas are as old as Bitcoin itself. Satoshi shipped a raw payment-channel draft in Bitcoin 0.1 in 2009. Hashcoin proposed unidirectional channels in 2011. Spilman and Hearn shipped working channel code in 2013. Akselrod proposed bidirectional channels in 2014. Decker and Wattenhofer published Duplex Micropayment Channels in early 2015. Poon and Dryja published the Lightning paper in January 2015 - the iteration we call Lightning today.

Nine years of brainstorming before an alpha. Those were the #RECKLESS days, and Alex has no idea about. What took time was building it right against real adversaries, every tradeoff chewed over for years before the protocol crystallized.

That is what real engineers do. They do not slap a button on a weekend vibeslop and declare victory.

§nsec Is Hot. Bitcoin Keys Should Not Be.

An nsec lives in your browser extension, your phone, your web client, and your experimental apps. It signs notes constantly. It is, by design, a hot key. A couple of months ago, about 16,000 nsecs were leaked. In a Nostr-only world, that is painful but survivable. The worst case is someone posts as you.

The moment that key controls money, the threat model changes. You need to secure it the way bitcoiners secure wallet keys. It took a decade and a half of work by world-class cryptographers and engineers to get Bitcoin custody and wallet software to where it is today. Backup is a discipline in and of itself. Nostr has none of that infrastructure. We do not even have key rotation yet.

And the “fix” is to hand a twelve-year-old shitposter a hot key that is now also a wallet, with no concept of backups. What could go wrong?

§Dust Is Not Cute, and UTXO Bloat Is Not Free

Small social payments are cute. Small UTXOs are not.

A lot of this error comes from the accounts-model brain. Nostr feels like an account. Ethereum feels like an account. Bitcoin is not accounts. Bitcoin is UTXOs.

Every Bitcoin transaction creates “coins”, i.e., UTXOs, of fixed denomination. When you spend, you either combine multiple UTXOs or carve out a portion of one. “21,000 sats” in your wallet means one or more UTXOs summing to 21,000 sats. A dust UTXO is one smaller than the miner fee it would cost to spend it. The current relay dust limit is 546 sats and rises with fees. Mempool.space’s UTXO-set report shows about 173 million UTXOs, with roughly 49% below 1,000 sats.

The UTXO set is the working state every Bitcoin node holds for the entire life of Bitcoin until that entry is spent. Bitcoiners have fought hard to keep that set lean - against Ordinals, Stamps, BRC-20 - precisely because UTXO bloat is an externality on the entire network.

Spraying 210-sat on-chain zaps at every Nostr user is a commons attack, and there’s no sugar coating this.

§Nostr “Silent Payments”: Peak Vibeslop

Silent Payments is a serious Bitcoin proposal. BIP-352 specifies hardened derivation of static payment addresses without on-chain linkability of payments. The point is to reduce address reuse without requiring a new receive address for every payment.

The Nostr Silent Payments proposal, which Alex calls a “major breakthrough”, tries to preserve the “send to anyone from their npub” convenience by deriving an NSP address deterministically from a known npub - even if the identity owner never explicitly published or acknowledged it.

That may be interesting as an experiment. But a silent payment address derived deterministically from a public identifier is an oxymoron.

The caveats are not nitpicks. To quote @1739d...136ef from the comments:

“**The scan key is the nsec .. this scheme allows for trivial loss of both funds AND identity”.

If you use a public scanning service. So the alternative is for the user to run their own blockchain scanning infrastructure. Wasn’t this supposed to be a better UX because pasting a Lightning address was too much friction?

This is what happens when you let an LLM draft your cryptographic protocol and stop reading at “You’re absolutely right!” Pablo summed it best:

“‘You don’t know what you don’t know’ hits different when you can vibe truly dangerous things into existence without understanding their basic nature.”

Since publishing NSP, @06b78...8327c has acknowledged the issues with his proposal, and credit for that. But burying the caveats in a mountain of prose and AI-generated images does not help; people rarely read what their LLM writes to them. It needs a giant warning at the top in flashing red:

This is exactly how not to do Silent Payments. Use BIP-352 instead.

§Damned If You Spend, Damned If You Don’t

On-chain zaps are not opt-in. Anyone can push a UTXO to any npub. Every Nostr user is now in one of two states:

1. Move the funds. Declare intent, prove ownership, and surrender plausible deniability.

2. Leave them. Accept a permanent on-chain marker, a public bounty tied to your nsec. The higher the balance, the more your nsec and your physical safety are worth. Even if you rotate keys, an attacker who knew the old npub knows the bounty exists and keeps watching. And you have added a permanent entry to the UTXO set, griefing Bitcoin for zapping a “GM”.

§Public Service Announcement

There are so many attack vectors here that the absence of a meaningful threat-model evaluation is appalling. Instead, Alex writes:

“Most people won’t be targeted, so I am truly not worried about the LARPers on Nostr.”

Try this. I want to take down person A. I on-chain zap a bounty to their npub and to an OFAC listed address. I have just recruited every criminal and every government into attacking them. Cheap. Repeatable. Untraceable to me. Person A now has to actively defend themselves against the entire world.

What you have done is turn Bitcoin, the best passive defensive tool we have, into an active attack tool, weaponised through Nostr.

This is a developer casually sacrificing Nostr users for the convenience of a button. While in Bitcoin, we worry about what happens to legacy addresses in 2140.

Muh friction!

Now that the cat is out of the bag, there is no going back. Being on Nostr just turned adversarial, and all we wanted to do was shitpost. The logical things to do now:

• Treat your npub as a burn address. Add a line to your bio: **“Not receiving on-chain zaps. Any on-chain balance found on this npub is an attack on me and will be sent to <burn_address>.” You can find public burn addresses here.

• Actively monitor any balance on your npub. If it grows material, send it to the burn address, rotate your npub, or quit Nostr socially - especially in hostile jurisdictions. Physical attacks on Bitcoin holders are more common than people think.

• Use Lightning. Phoenix, Wallet of Satoshi, Cashu. Pick a custody tradeoff. Paste the address. Move on with your life.

• Demand opt-in defaults, warnings, and key separation. Stop using clients that enable this by default. Whether the harm is from ignorance, hubris, or by design is irrelevant.

§Closing

No. You re-shipped a bad idea experienced people already weighed and rejected, with worse threat-model awareness, to thousands of users who cannot evaluate the consequences. When engineers offered feedback, you wrote a hit-piece calling them religious boomers. The correct term is Toxic Maximalist. At least get the pop culture right.

Bitcoin is push-only. That is a feature, not a UX failure. You do not mail a driver’s license to every eighteen-year-old. You require them to learn enough not to kill themselves or others. That is not friction. That is education.

Choosing between custodial LN, self-custodial LN, Cashu, running your own node, or not being zapped at all is an informed, voluntary choice. That matters. On-chain zaps remove the choice, auto-issue the license, hand over the keys, and tell the user “vibes, bro.” When they crash, they will blame Bitcoin and Nostr for being complicated and dangerous.

Sometimes you should not just do things. Especially not with other people’s keys, money, and lifetime attack surface.

And maybe, just maybe, someone has something you can learn from. It is possible.

Now I will go touch grass, for I need some fresh air and leave you with..