Lightning doesn't "lock" you to a provider.
Neither does Cashu. Unilateral exit is a thing.
On-chain zaps, however, will "lock" your nsec to a bitcoin address. Forever.
Login to reply
Replies (43)
this is all so retarded I'm legit losing my mind
please lets not associate onchain zaps to this current disaster of a spec. I have an onchain silentpayments zap spec cooking
🤔
Does it require scanning the entire blockchain?
This is literally the entire point of Nostr. This is how Nostr works.
Already happened: View article →
I’m so thankful for all the discussion around on-chain zaps. 🙏 Reminds me of twitter when I joined it 2017. Direct in your face truth. I’m curious when the insults will kick in.
These aren’t zaps
I haven't seen you on fire like that for a long time 🔥
Same.
Tiresome.
Ok, please publish as a custom NIP to nostrhub.io when you're done. Maybe I can implement this in my Ditto fork as well.
💯 👌🗽
Thanks for explaining 😬
Keeping my nsec clean and my channels open. This is the way. 🫡💜
Luckily we have relays that can do some scanning for us...
any chance to make any part of it dynamic?
Also you need to just scan from the time when you created the wallet. So the first time right after creation this is fast...
you also have to scan the blockchain for regular txs as well, so I don’t understand the point. Its just a bit slower on the initial scan because it has to do ecdh with every output to see if there is a matching address
Those transactions are indexed
Indexed where?
they are only indexed after they are scanned and found in a block …
silent payments are no different 😑
Talk practice, not theory. Can I get my balance from mempool.space (or other Esplora-compatible APIs)? The user is not running a full node on their phone. How can we get the data we need quickly to figure out the user's balance definitively?
this doesn't make sense to me. your first "lock" implies that your funds are trapped there. your second one implies that your identity is associated with them. those are totally different things, making it difficult to reply
Freedom requires intentionality
This highlights a problem with nostr key management more than anything else
Dependency would do... But all our needs are met... So... Its either intentionality or nobody comes together...
Yes it's retarded, bit I am not worried because it's such a stupid idea that nobody will use it
Cashu does lock you in to a mint.
The ones that know what a UTXO is will not use it.
The key is to find the use that exploits the fact that on-chain zaps are NOT private and forever binding:
To explain, a "Closed-Order" is an organization that requires a rigid hierarchy to define its system of governance. A "Ceremony" is an event that changes the state of that governance hierarchy. "Recordkeeping" is self explanatory.
For social hierarchies to work, they require the positions within it to be fairly stable, changing only as significant need requires. This maps 1-to-1 onto the mechanics of Bitcoin transactions. The utxos are stable, and only great need produces a signed transaction to alter that state.
The fact that a Nostr identity maps deterministically onto an on-chain Bitcoin address makes it a valuable primitive for encoding organizational hierarchies on chain using only the simplest transactions and <80-byte OP_RETURNs.
Yes it's true I didn't read this NIP before publishing it. But rest assured that when I vibe anything, it's a class above anything you've seen before. I might be retarded, but I'm rarely wrong when I need to be right.
NostrHub
NostrHub | Discover and Publish NIPs
Explore official NIPs and publish your own custom NIPs on NostrHub.
Why is everyone talking about this rn? Who's idea is this?
The entire point of nostr is destroying Bitcoin onchain privacy?
"On-chain zaps, however, will "lock" your nsec to a bitcoin address. Forever." This has always been the case, even before on-chain zaps were a thing. It's a logical consequence of Bitcoin and Nostr using the same elliptic curve: secp256k1.
I always found that fact remarkable. Now the consequences of that design choice are getting real.
Excited to see this spec. I was able to create a silent payment address from a users npub but I have no idea how zaps could ( or should ) be implemented
Yeah it’s a bit more nuanced and delicate due to privacy concerns. Will definitely be a private component. Not sure how public zap will work without heavily blinded amounts
Yep. A public zap is useful social proof, but it gets spicy fast if identity, amount, and timing all land on the same graph. Default-private receipts + selective disclosure feels saner than bolting privacy on later.
Ok fair point.. destroying subanonymity and make it completely plain and visible sounds better?
How exactly? Signing with your nsec doesn't lock it no a wallet.
Using the same crptographic algorithm doesn't seem to have anything real to do wit the claim.