Terrible idea. Harmful concept. Users will get rekt, attacked, or worse. Do better.
View quoted note →
Login to reply
Replies (110)
... Everything but blind signatures
You can do that attack regardless of on chain zaps or not. I can attach child porn to your pub key on chain if I want to. Anyone can do it. Hiding it won't make it go away.
Nobody is gonna kidnap my kids or $5 wrench attack me because there is “child porn attached ot my pub key on chain” (whatever the fuck that means, please explain).
I guess my main point is this one: on-chain privacy is hard. Lightning privacy isn’t hard.
It is my humble opinion that we should have sane defaults and encourage privacy best practices. Lightning is a sane default for zaps. Lightning has privacy best practices built in. On-chain privacy is very (very) hard, and any mistake you make might haunt you forever.
And once more for good measure: address reuse is really, really bad. For everyone.
I am not sure that you fully understand that there is no privacy in lightning zaps. The zap event is killing any sense of privacy or anonymity you think you have.
Saying that lightning zaps is a "sane" privacy implementation is worse than having public onchain zaps.
But still you can't look at where the zaps are spent afterwards on Lightning.
Correct. But that doesn't mean it's private at all. An attacker still sees everything in and out via zaps, which is how most people use it.
Our defaults have never ever been private.
Please try this tool I just made:
Onchain Zap Forensics
All the zaps that I have received so far, what did I spend them on? Can you tell? Did I even move those sats at all? Where did the sats go after I’ve received them?
Less importantly: Is it possible that some of the zap receipts were faked, and thus there’s “zap events” out there that didn’t even move sats at all?
Even less importantly: I had many lightning addresses attached to my profile up to now. Is it possible that one of those lightning addresses was controlled by someone else, and not me?
> Saying that lightning zaps is a "sane" privacy implementation
That's not what I said.
When it comes to zaps, Lightning is the sane choice, because of its properties. Using on-chain for those public payments is NOT the sane option, since on-chain leaves a trail that is forever auditable. “Forward secrecy” (if you want to call it that) does not exist. Plausible deniability does not exist. The option to say “I never touched that money” doesn’t exist. The option to say “I lost access to this wallet” does not exist either, unless you nuke your nsec.
I made Alby Hub my zap address almost a month ago and I still get zaps to wallet of satoshi every so often.
We stand with President Vitor!
I am having trouble setting up Alby
Let me try to make my point once more:
1) Address reuse is actively harmful for the whole Bitcoin network.
2) On-chain privacy is very, very hard.
3) Lightning privacy is NOT hard
What (3) means is that I can spend the zaps that I have received WITHOUT getting into trouble further. I can spend them at a merchant or whatever, and nobody will know. On-chain makes that way, way, way harder. On-chain is traceable.
Further, nobody knows the current balance of my wallet. I might have spent everything. Or maybe I haven’t touched it. Switching to on-chain makes every user naked, and thus plausible deniability flies out the window.
We are not using "lightning", we are wrapping a lightning proof into signed events with the sole purpose to identify the parties involved.
Yes: forward secrecy doesn't exist, plausible deinalibity don't exist. But not because of some on chain zaps implementation, but strictly because you are singing with public key cryptography and advertising your pubkey key as yourself to everyone. That is the definition of *verifiably* doxxing yourself.
You are arguing against pubkey key reuse while reusing the same nostr key to sign the same thing you want a new key for.. nothing here makes any sense.
Can I opt out of receiving on Chain zaps? Or am I just stuck with it because my npub is public and sending BTC theres doable?
I don't need your balance. All I need is your cash flow to see if you are worth anything.
Plenty of people have a lightning address that isn't theirs as their zap target.
You can't opt out.
Thank you Gigi 🙏
It doesn't matter. On nostr, they are all doxxing that lightning address and those transactions (which is what almost everyone does here). Of course, they can have other lightning wallets and those are not affected.
Similarly, we are not doxying people's main Bitcoin wallet. It's only a wallet for nostr.
Everything else is user education to hopefully not mix funds or keys.
Not good
It matters. It matters a lot. Providing and normalizing the use of long-term footguns is not the way. Building stuff that actively harms the privacy of all on-chain users (that's what address reuse does, remember?) is not the way.
Then we should never have created zaps in the first place.
Anyway, I know that you're gonna ship it anyway but this is too important for me to just shut up about. I hope that a more sane approach will win in the end. Silent Payments, for example. I'll go touch grass now.
Zaps don't promote on-chain address reuse. Are you even trying to understand what I'm saying?
I appreciate the debate. And I hope someone creates a silent payment implementation that can actually work and don't just defer privacy to a trusted monitor provider.
This. I use lightning addresses for my profile and for fundraisers that are controlled by a group. It's not my address, I just have permission to use it.
And I have cycled through various addresses. I even changed the wallet behind the addresses. There's an abstraction and obfuscation and deniability layer to Lightning that on-chain simply doesn't have.
Sure. But they take something very private and turn into something VERY public for the sake of memes.
Any attacker can save those events forever in such a way that they don't even need the chain. In fact, it's even better than the chain because now they can sell databases of past zaps that no one else can find because they were deleted. We created the incentive to sell our info and create that marketplace.
It's really bonkers if you think about zaps from a privacy perspective. Every decision we ever made made lightning worse than on chain transactions.
They're trolling some of us by sending us Bitcoin they know we won't want to touch. If that answers your question.
Which is a grotesque decadence, but okay.
Address reuse is the point. It's the tradeoff we're choosing to make it dead simple. Without that it becomes complex and we fall down a hole, just like the thousand other holes we're already down. Bitcoin lacks focus.
I have my silent payment address in my kind 0 rn. Jumble supports it as well. If anyone wants to try if it works 🥲
I have my silent payment address in my kind 0, can some try this zap feature?
https://jumble.social/users/npub1ftt05tgku25m2akgvw6v7aqy5ux5mseqcrzy05g26ml43xf74nyqsredsh
View quoted note →
Originally created by the real Satoshi:
Scanless Silent Payments
tl:dr: We built a complete silent payment notification system into Sparrow Wallet using Nostr encrypted DMs. When you send a silent payment to a Nostr identity, the recipient is automatically notified via NIP-17 with everything they need to claim the UTXO — no blockchain scanning required.
This is a proof of concept and almost certainly has security issues.
View quoted note →
That’s a horrible trade off are you critically thinking here?
Why not work on bolt12 instead of onchain nightmare?
Btw, I softened wording here and added a comparison table.
Stop being such a puss
I’m with you, @Gigi
Bitcoin on-chain has forward and backward privacy issues. It is not just that you have to unlink the past; one silly mistake in the future, and the unlinked becomes linked again.
Yes, but even if I use a dedicated wallet for on-chain zaps, I still need to fund that wallet somehow for future use — not every user earns sats directly on Nostr.
With a Lightning wallet, nobody can see the transaction flow outside the Nostr ecosystem. But with an on-chain wallet, I don`t have that option.
From my point of view, just because Lightning zaps aren`t perfectly private doesn`t mean I want something much worse and completely doxx my transaction flow to Nostr for the sake of convenience.
Also, as a user, I was able to control whether I wanted to receive zaps on Nostr or not at all (by setting or not setting a Lightning address in my Nostr profile, or changing it whenever I wanted). But by adding this feature (on-chain zaps), anybody can send funds to me against my will.
I never used zaps for that reason.
Nobody knows how much Monero I donated to people here con Nostr if any.
The trolling will really begin when people send Bitcoin from OFAC lists to known npubs and those with bad opsec and then start reporting it to agencies.
Just create a new oc wallet receive some oc zaps, every now and then make a swap oc-ln let it shake for a few weeks in your ln node over tor then swap ln-oc back.
You have conversation with he/him 'something'. Leftard's bs.
Agreed 100%!!!
Did the IRS give him a grant, or something? 🤪
Hi I'm one of silent payments implementers, don't hesitate to ping me if you want to have a chat and try to figure it out. Doing more address reuse is *not* acceptable at this point.
LN fucking rules love it
@Gzuuus @jb55 @cloud fodder @ChipTuner @Gigi @semisol @Enki @MichaelJ @Cody
I'm actually kind of, sort of, low-key interested in on-chain _private_ zaps that don't suck and don't look like a government surveillance wet dream. Especially if clients were clever about it and used addresses from kind 10133 payment target events or w-tags on profiles (so, opt-in!) and recommended Lightning vs on-chain, depending upon the amount sent?
Do we have a working group for that, to come up with a NIP for it, so that client devs like me can implement them? I don't know, if the tech is there, yet, but we could at least get a band together or something.
Do any of you know of anyone working on this, that I didn't tag? Or does anyone want to just reply here and suggest themselves? 🙋🏻♂️
@Vitor Pamplona would you be interested in offering that as an alternative for your users, or even maybe as the default, if we got it to work?
@Alex Gleason strikes me as a polyandrist and nudist IRL
Just a thought. Nostr feels like a natural complement to Silent Payments. The sender can wrap the txid in a NIP-17 encrypted event to notify the recipient, so they know exactly which transaction to verify locally with their scan key. Payments sent without a notification still need to be discovered through scanning, of course.
Monero addresses cannot be re-used.
Bitcoin hinges on the user knowing what they do, which they dont.
Yes. I encourage you to read through the gists posted here: View quoted note →
Why would you ever want to do that?!
Cool, you guys already implemented it!
Suddenly money is not fungible? A Satoshi earned here should be as usable as a satoshi earned there. The more identities and off chain data associated with utxos, the worse fungibility becomes.
I mostly agree Vitor, but it depends on what you mean by "everything". A zap is a public record that one person made a payment to another person
The question is whether the public record should also (implicitly or explicitly, it doesn't matter) point to the on-chain transaction
That appears to be the real issue you all are discussing, and the issue would still exist even if each payment was to a different address
Define "Noisy Payment" as a Silent Payment, but with a public event linking to the txid. Would that be a fix for onchain zaps, because it avoids address reuse; or equally harmful because the public can still see all the transactions?
The fact that "normie user dgaf" is exactly the reason why non-normie users should give a fuck and why devs shouldn't push harmful implementations, practices, or defaults.
We would just need someone with a large npub to kick off a working group thread by publishing a kind 30817 (you can do that from my client) event with a title like "Silent Payment Bitcoin Zaps" and a short text explaining what the goal is. The actual spec could be derived from the discussion or added in a fork and then merged back in.
It would be the first Nostr Core spec written and developed on Nostr, @fiatjaf
It's a proof-of-concept, not a proper implementation. But it's pushing things in the right direction, as opposed to on-chain zaps.
Wrong. It needs to be shouted from the rooftops louder. It's way more problematic than you think it is.
Address reuse - Bitcoin Wiki
I agree. But this path is obviously much harder, and most people tend to choose the easier route.
I also have some ideas for deeper Nostr integration. Notifications could include the sender pubkey and event ID. I’m not sure yet how to pass that to wallets, maybe through QR codes or deep links. If the receiver is willing to make it public, they could publish something similar to a zap receipt event.
The issue starts when (normal) people inevitably connect these coins with their generational stacks either by wanting to zap sb or by moving their received zaps to cold storage.
On-chain privacy is not very hard. Pirate Chain (ARRR) has universal zk-Snarks, a technology that has been reliable for 14 years. Monero has universal ring signatures, a multi-decade-old idea invented by two of the guys whose initials are in RSA. These things are actually very easy to implement, and have been stably universally implemented on more useful blockchains, in the case of Monero, for 12 years now.
Lightning offers no real privacy, nor fungibility. Nobody is actually using Lightning's onion routing, so there's no fucking traffic on the mix network. A mix network with no participants might as well be a straight tube. You aren't making smoothie if you only dump orange into your blender. It is just pulpy orange juice. Your "privacy" with Lightning is a complete illusion. And it's already further impacted Bitcoin fungibility. Got a Binance Japan account? Try to make a deposit with LN. You can't, because Japan's regulators do not like Lightning! You've got no fucking privacy, your mix network is fake and gay just like your retarded protocol, you don't end up with fungible currency at the end.
On-chain privacy is the only way you get privacy. There is no privacy unless the privacy is universally implemented. With the ~$130M USD of real value dumped into Lightning, for virtually no fucking users on a protocol that wouldn't have scaled to accommodate any serious number of them anyways, we could have implemented on-chain privacy ten times over. Monero's upcoming FCMP++ upgrade is a thousand times more innovative and hard to implement than both zk-Snarks and ring signatures.
I am sick of Lightning shills repeating the same tired lies over and over again. None of what you say is true, except #1, and that's only because Core is lazy and decadent and does not care about making Bitcoin actually useful as money, which would require fungibility (and privacy is a side effect of that). They only care about justifying yet another grift of venture capital on yet another feature that no significant number of people will ever even want to use.
The privacy comes with what happens to the coins after you receive them sir, you can't accidently show everyone what exchange address you use to sell bitcoin
just because you can do something doesn't mean you have to actually do it.
Legend.
@Anita Since you boosted/reposted this note, did you notice what is going on with onchain zaps recently here? Amethyst and Ditto have implemented these, and they use your nsec as a Bitcoin wallet, which causes address reuse with all its consequences.
Anyways, you should listen to Saylor on this issue:
lmao
Correct. My goal is to make it available. Each user then decides if they want to use it or not.
they should undress me, altho im already naked
We can make all zaps go through a mixing service before coming out to an exchange if that is the problem.
you're talking to a wall.
Let's do it.. send a NIP on which way to do it that actually works. Right now a bunch of people are talking but nobody is doing shit. We need actual proposals/implementations from people that know what they are talking about.
I looked at Derick's on-chain zap address.. and the entire set of addresses associated with it. Including an address that has seen over 1 BTC in it's lifetime. on the first level 5 addresses were doxed. On the 2nd level it expands to this.
I have no idea how you can think that this is something viable for zaps. That entire cluster of addresses is considered doxed.
I don't think y'all will even be able to move most coins even once let alone mix them once fees are even just 5 sat/vB 🤣 but all good let's see how it goes, I'm interested in your experiment
So, who are the users that you estimate sent to Derick?
Well, since the user cannot opt out that option isn't given. People will receive unwanted on-chain zaps and from what I've seen so far even those who think they're Veteran Bitcoiners have already doxed addresses. (see my other comment). There is plenty of nostr users who haven't been around 2,,3 or 4 cycles and the self-doxing will be insane.
Why? Don't you think Nostr can succeed? It doesn't take much to make a good mixing service..
If you fancy paying me for my time I'll happily spend more of it on this.
The mining fees will exceed the size of the utxos
We could do it in such a way that receiving and sending in and out of Nostr is harder if that is the problem. So, once in, the money stays rotating between nostr keys in an identifiable way like what zaps do. Then in the end, it leaves via a mixing service for instance.
Anyway, lots to work yet.
Wouldn't that be awesome if it did?
I once ran a service called nodeless, perhaps you remember, and when my users couldn't withdraw their money due to fees they didn't think it was awesome. But maybe bitcoin is dead and fees are low forever and who cares it's all moot anyway
It's not that they couldn't, they didnt want to pay for it. Fees have never gotten so high that people couldnt move their money.
It would be classic nostr ux to pay $50 fee to move $20 in utxos so I'm not surprised this is your position
Maybe. But again that would be awesome if it actually happened. People finally using Bitcoin again.. and not this shit that is today.
Is this predicated upon installing and using Amethyst or ditto? So if you do not have these clients installed there is no issue is that correct??
I advise against this, as the feds specifically love to prosecute mixing services.
As far as I can tell, if fungibility is not a property of your coin, then adding it is an overt act of criminal money laundering. Though this might be decided otherwise with Roman Sterlingov's upcoming appeal for allegedly running Bitcoin Fog, I don't know if that is going to work out. Because the community decided to fund Samourai, who had no intention of even going to trial, and gave them millions of dollars. Then they gave Sterlingov, the guy whose case will decide the law for all of us, 0.02 BTC. It is very blackpilling.
Regardless there's Pirate Chain (ARRR) which has complete on-chain privacy thanks to universal zk-Snarks! As long as we are willing to let go of Bitcoin, we can have privacy on chain without custodial LN shenanigans and a completely broken user experience.
Address reuse is not only bad for the privacy of the whole network but also reused addresses will be an easy target for (in case they come) quantum computers as the public key has been exposed in a previous transaction.
It’s already implemented? That I did not realize. I thought it’s a discussion for now.
Yes you probably can and if it's possibly it should be done right from the beginning. The current proposal (or implementation) is basically powerful metadata leakage and deterministic address derivation removes the user’s ability to compartmentalise identities. It may be a convenient approach UX-wise, but from an OPSEC perspective it’s pretty aggressive. Some users may not even realise they are creating a permanent public financial endpoint just by existing on the network.
And this is before we even dive down the UTXO and consolidation rabbit hole. With the current approach
Every public interaction potentially becomes chain-analysis metadata
Every zap can help cluster identities
Anyone can monitor balances, flows, spending timing, consolidation patterns
Counterparties become graphable
Future spending can leak wallet structure and habits
Then, once the UTXO's get consolidated or moved it all turns into potential correlation points and if someone receives enough on-chain zaps and if fees evolve the entire thing becomes economically unsustainable.
Amethyst and Ditto have indeed implemented it already.
It is actually always an issue since if you get these onchain zaps, you are in possession of these coins and your nsec is the private key to these coins. Nostr keys are generated the same way Bitcoin Taproot addresses are generated. Amd everyone can see that you have these coins and how you spend them.
I feel like it's worth mentioning that discussions on "it shouldn't be built because it can be used badly" is rarely a convincing argument. Vitor is right though, so long as we hold a secret key tied to a _public_ key it could always be used by some blockchain or whatever crypto technology to "send" money as we know it's just an identifier signed by the sender. None of us can stop that. Address reuse is bad for privacy yes.
I think we'd be better off building a case for deniability, when we simply don't touch the funds. We can't control what others do, if they send funds to the address, which is public, the utxoset can be scanned. It can be public knowledge that I deny the funds, by not moving them. I'd think privacy is just as bad for senders in this regard.
So as far as I understand this. "Nostr" protocol aside. The secret key holder (as usual) is the one that must derive the receiving address correct? So the receiver must have some service "online" for the sender to request like we do with LNUL. The rest is communication ceremony. We should be able to keep it away from the nsec even further though right? I don't see any reason to have it constantly local to the nsec (part of the bunker).
Could we consider a system that offers a simple http endpoint that responds with a fresh address. We already have lnurl servers running we could make this work also. Has a different surface area but needs no access to any secret keys, no encryption no leakage etc.
> I don't see any reason to have it constantly local to the nsec (part of the bunker).
* Used for encryption yes I know. I mean another solution allowing us to eliminate usage of secret keys entirely for the ceremony.
If we could somehow make that happen, that would be cool.
Raising friction for adversaries is good. Friction incentivizes innovation. This does not mean raising friction is foolish.
You can opt out as much as you can opt out from a comment or a dm on nostr.. Or a random crypto airdrop to your bitcoin address.
You can opt out from caring about it however.
Ffs just use Bolt 12.
very stupid to build this surveillance future
I am one of those retards. Should I not zap? I also don't fully understand address reusability. If I buy Bitcoin should I make a new address each time?
Whenever wallet empty then just dispose it , produce the new one .
Make sure you empty it first .
I am agreed that devs shouldn’t push harm implementation.
Good idea to use always new address Everytime . It’s more privacy.
Sim é bom ter liberdade de decidir
- yes you should zap
- yes you should buy btc and withdraw it to a new address every time
- never use same address again (if you use sparrow wallet it automatically prevents this)
@Vitor Pamplona and @Gigi cheers for having this discussion here, really enjoyed reading it!!
Thanks
The answer to all three: nobody can prove anything. That's the privacy you trade away on-chain.
There are exceptions.
Such as Bolt 12, which provides static payment addresses, but opaque transactions and balances.