This is a pretty solid takedown of onchain zaps. I can see how people think the idea is cool, but I don't think this is a good implementation.
Before I get into the “why it’s bad” part of it all I’ll try to steelman Vitor’s arguments as I understand them. In short:
- Zaps are public anyway
- Lightning setup is complicated
- No setup required for on-chain, less friction for users
- We have already built it and it works, so why not give users the option
I don't understand how the pro onchain zap people don't get that lightning zaps are pretty easy to keep separate from your stack but onchain zaps would be much more difficult to keep separate.
I'm sympathetic to lightning being difficult and people want to solve it, but it's like...not this way. Gigi does an excellent job going through the reasons why onchain zaps really, really don't come with a good set of trade-offs.
In short: using on-chain addresses for zaps is a terrible idea precisely because it reveals more than necessary. And to add insult to injury, it automatically makes this oversharing permanent.
He almost takes it too far, but I think his fervor is justified:
You might not even know about the money, but by using your nsec to sign messages (read: you simply using nostr, logging in to something, or pressing a like button here and there) proves without a shadow of a doubt that you are still in control of your keys, i.e. the keys that can move the money. Bad for users. Fantastic for criminals. A wet dream for prying eyes.
So: don't do this onchain zap thing.
TL;DRTL;DR
On-chain zaps are bad, because:
- They strongly link identity and money
- They remove any and all plausible deniability
- They provide full insight into a user’s finances forever
- They can’t be disabled, revoked, denied, or redirected (dust)
- They encourage horrible privacy practices for sender and receiver
- They have negative effects on EVERYONE ELSE on the bitcoin network
TLDR; this shit is retarded
To me all of this is trumped by the poorest spec I've seen in a while:
Reusing a key across use-cases (or even within use-cases because you wanna roll without
random) takes immense cryptographic risk, because weaknesses compound across uses. Do you really want to secure your money with the same static key that secures your throwaway nostr nym that holds literally no value? Insult to injury: this risk is taken with other people's money and promoted with endless banter.Don't take my word for it, let's look at what Schneier & co said about exactly this [1] (I recommend reading the whole paper):
This is why we have things like key derivation. You know... like BIP-32. Why using BIP-44 or BIP-84 has a hardened path on their specs (the first derivation in the path is
m/44'/m/84'). I could go on forever, but I'm getting to a point where I consider removing myself with great distance from nostr vibes, even before we talk about the whole bitcoin-specific privacy chain of concerns this introduces.Protocol Interactions and the Chosen Protocol Attack, p10 ↩
That's a shame, but understandable.
Yes, that's one of the worst things about it all, and I only mentioned it in passing[1] because I don't even want to go into the cryptographic mess of it all.
It's a bad idea both cryptographically and in principle, and I think the latter is easier to understand than the former.
See "weakens the cryptography" and the associated footnote ↩
Missed the footnote, apologies! (and also I kind of needed to rant away my anger, haha)
Please, by no means view my comment as criticism at your article; you're doing a great thing because you're educating people in a way they're more likely to understand, and apparently, some of the devs need this too.
That last part is what I am grumpy about. Now that the barrier to producing working software is gone, poor software is increasing, and worse, previously semi-acceptable software is further impoverished and actively morphing into threat vectors - recently this phenomenon is exploding in the nostr space.
I feel that this is a net loss to the community, and since there is a large cross section between the nostr and Bitcoin communities, this directly affects bitcoiners too. If the dev behavior I'm perceiving becomes the defacto standard in any way (and if both Amber and Amethyst ensloppify within a month, this is a sign), then maybe it is time to move away from this crowd.
A protocol that only has poor implementations is no better than a poor protocol (and if I'm being real, nostr has never been the cherry on the protocol cake to begin with.)
Maybe there is hope. Your message definitely gives hope. But is Claude 6.0 going to get trained on your message? Because if not, no one is going to care: per the NIP discussion, "Claude said x" and currently,
x != <gigi's message>.I was surprised to see this, and it is in part what encouraged me to sit down and write.
On point. And I'm afraid that it will get worse still. Deliberation and care fly out the window once you have LLM brain, and we haven't peaked yet.
Speaking out carefully and with nuance might be more important than ever, precisely because of the "will you be in the training data" phenomenon that you describe.
Not sure what needs to happen for things to turn around. But whatever happens, I'll be the grumpy old man who is yelling at Claude.
Me too, and it's already pretty bad. For the first time in decades I am removing software without having an alternative. I'm abandoning functionality. I think the previous and, to my questionable memory, the only prior time I did this was when I abandoned interop with the rest of the world (but retained partial old file version compatibility) by no longer having access to MS Office after banning Windows and MS software in general from every device... more than 2 decades ago.
The challenge now is to bespoke build the tools I need, just-in-time (this is still a challenge.) I guess a functional basic but non-leaky nostr signer is pretty high on the list now. 99% chance that I'll use the same Claude or GPT... or do a crazy experiment and try it with Gemma. Won't publish that though, so it'll bother no one but me. My slop > someone else's slop.
Yes. The other option is to enforce things prompt-side. Can always just inject a link to your blog post in a context section of a prompt and reference it in instructions during design, implementation, review, bugfix automation... That requires discipline and a sense of what is relevant (experience? knowledge?) on the viber's part and that's what imho is missing right now. Vibe coding is still hard work.
I think some explanation is likely in order. (I had to work through some of these questions myself).
What is an on-chain zap?What is an on-chain zap?
(Simplifying) It's a way to send bitcoin on-chain directly to an npub. (You essentially derive a bitcoin address from the npub, I think. The owner of the npub can spend from that address using their nostr key).
Why is it good?Why is it good?
It simplifies the act of zapping on nostr without needing an online lightning wallet.
Why is it bad?Why is it bad?
The address that the funds are received into is permanently tied to that npub. This means:
Another reason it's bad is that no one needs permission to zap into your npub-derived address. It basically gives anyone with a desire to dox you the ability to target you with a dust attack.
So: the recipients are not forced into any privacy loss. But they are definitely forced into an uncomfortable and risky privacy tradeoff.
One thing to keep in mind is that on-chain zaps are already possible and no one needs permission to do it. So the bigger debate is about whether it should be normalized. Personally, I don't think that would be a good idea due to the downsides already described. Moreover, it seems like it would pollute the chain with lots of small, uneconomical UTXOs.
Good for miners, though, maybe?
Precisely.
Correct.
Not only that, but given the fully transparent nature of onchain transactions you could get people into all kinds of trouble very easily.
Imagine being a politician in Bangladesh (or a similar high-profile person, in any country that deems bitcoin an illegal substance). Any political opponent can provably send you this illegal substance, prove that you are "in possession" of it, and either prove that you did something with it (or prove that you are still in possession of it) without they themselves revealing who they are.
Politicians are on nostr right now. Leopoldo Lopez is one example.
That's just one attack vector of many, and I tried to make a similar point when I talking about the OFAC list.
Good point here. And I think Gigi mostly focuses on it: he seems concerned that it will catch on with unsuspecting users.
It seems to me that the really bad combination is a public identity tied to a reused Bitcoin address. You are making it very easy for someone to follow you if you ever consolidate those sats.
Also on chain zaps wouldn't be instant which is just sad.
Convenience is the enemy of security. The fact that people do not immediately see the issues with on-chain zaps just shows how far we have to go. Honestly, that is pretty discouraging.
Lightning is hard...
I guess... maybe. Not really. Running your own node maybe. The idea that the tradeoffs of on-chain connected to you npub is less of a risk than throwing some bitcoin in even a echash wallet or a Zeus wallet makes no sense to me.
Bitcoiners should know better. No excuse.
We would need silent payments combined with wasabi or preferably joinmarket. That way addresses don't get reused and the user is more or less one click away from coinjoining everything.
It may not defeat the NSA (highly unrealistic) but it keeps things private enough from criminals and prying eyes to know where the sats go and how they get spent.
If they at least used silent payments...
I read the whole write up and let me play the devil's advocate.
On-chain zaps if used with a wallet like wasabi could be a net positive for bitcoin. Its not like fees are that high. And after the zaps are conjoined they could be swapped to lightning, used to open a lightning channel, spent on something, sent to a satscard, or possibly just donated to a nonprofit or internet-freedom group (open source developers). They wouldnt go anywhere near your 'main stack' and now that the use of sub-1-sat vbyte transactions is common...
Even relatively small amouts of dust could be trivial to spend/conjoin or consolidate.
I personally would donate a small on-chain zap... Like small change in a physical wallet to good causes. Or let that dust 'build up' before sending it to a swap service, or swapping it to lightning which has enormous privacy benefits.
In short I don't think on-chain zaps are a "good" idea... They probably aren't for everyone. But for an advanced user they open up the possibilities for how and when to use bitcoin.
I think the bigger question is... And as far as on-chain goes... I want to know why exactly we need on-chain zaps to begin with. Lightning is mature enough to accept relatively large transactions (most zaps are under 100 sats anyway) its much cheaper and near-instant. Maybe we could make the argument that its good for the fee market but probably the better thing is... More people opening lightning channels which is good for the fee market.
I'm open to this idea but I see it as a tool to make coinjoins easier and more relevant... If I only received one zap a month it wouldnt even be worth it I would just donate it. But on the other hand built into something like wasabi or joinmarket I could see it being useful.
I think some of the argument is that lightning is hard to get started for a newbie -- setting up a channel requires some amount of sats already, but if you do this npub->taproot address thing, you just sign up to nostr (create a keypair) and start receiving. I see the allure.
The flow you describe probably works, but isn't it still a really big foot-gun? In a way these sats would be even worse than kyc sats because the identity attached to them is trivially identifiable to the whole world. That seems like it's pretty radioactive.
And, like you say, why not just use lightning? If the primary use-case is newbies or nocoiners, then we can't expect them to be hyper-privacy conscious and careful. Maybe they move some of these sats into a wallet and forget how they got them and then later get serious about bitcoin and build a stack in that wallet. without thinking about where their initial sats came from. I could see many ways this goes badly.
Zeus imo has the right idea. Newbies use an ecash wallet until they have enough to open a lightning channel. Then they get the lightning channel through the LSP then they move on-chain when they have enough that they can't or don't want to keep in lightning.
Lightning is relatively easy in this way... I think the harder issue believe it or not is talking about bitcoin with people to begin with they don't 'get' it or why its necessary.
On-chain SATs I agree with you is not for beginners, that's what lightning is for. I think that newbies would have a hard time with the 6 confirmations thing... They would expect lightning to be instant like anything else they use so they wouldn't know what on-chain was or what not to do. DerGigi has a great point there imo
Zeus is fantastic indeed.
And allow me to point out once more that npub.cash has existed for a while now. And nutzaps are a thing too.
To quote Calle:
Clients could set this up automatically, of course. Same principle, without the footguns.
they shoulda just done on-chain monero if they were gonna do this to be honest...not shilling but makes more sense to me.