This guy is building 👀 View quoted note →

GM 🦖

GM🌞

One of the most difficult lessons to learn about privacy and how it works in the digital world is that you don’t realize you need it until it’s too late; at that point you wish you had been more conscious of it from the beginning, but it’s already too late.

What if a user could publish a silent message string (exactly the same idea behind silent payments) and others could derive one-time npubs from it to send private messages? You’d need relay hints in the string, and it’s clearly better for 1:1 than groups, but it seems very possible. We discussed this during the last #soveng Free idea.

GM 🌞

I'm enjoying this onchain zap episode and discussion, it's raising awareness among users while also generating educational content, which is always beneficial. Some users will become more conscious, while others might get rekt, but hopefully they'll learn along the way.

Ups, I forgot an important point. There is another option for on‑chain payments in Nostr, Silent Payments, which has similar properties to Bolt12. It is a static address that preserves your privacy and can be attached to your Nostr profile. No servers or intermediaries are involved, which is why it is private. The downside is that you need to analyze blocks to claim transactions that belong to you, but nowadays this is a very efficient operation. By the way, this would be the proper way to do on‑chain payments in Nostr. View quoted note →

Some thoughts about the ongoing “on‑chain zaps” discussion. I think that, at the end of the day, this is good in the sense of bringing awareness to people so they understand the implications and trade‑offs of the different solutions we have nowadays for transacting on Nostr. Not everyone understands what all of this means, and technical concepts can be a bit intimidating, so here is, from my perspective, the important things to know in order to navigate this discussion. Nostr and Bitcoin have something in common: the underlying cryptography used to generate key pairs. This means that a Bitcoin address and a Nostr address are effectively the same. You can receive btc to your nostr public key and spend using your nsec. This is not new; it has been the case since Nostr was conceived. Since that moment we could use Nostr addresses as Bitcoin addresses, nothing new. So why haven’t we used this “magic” property of Nostr from the beginning? Because of address reuse. Address reuse can seriously harm your privacy when using Bitcoin. Address reuse is simply the practice of using the same address for sending or spending multiple times. This was a concern since Bitcoin’s early days, and it is a well known bad practice, nothing controversial, nothing new. The good news is that there is an easy way to mitigate this: simply do not reuse addresses. The reason “on‑chain” zaps have never been promoted, even though they have always been possible, is because of this. Address reuse is bad, very bad, it makes your balance, and transactions public and traceable, also from your counter part, and it gets even worse if the same address you receive to and spend from is also linked to your identity (e.g., your username, social activity, contacts, or even your IP address if you are a relay operator). You do not need to be a Korean hacker to collect all of that information, and build a strong model of who you are, your environment, etc. If someone considers you a valuable enough target, they may attack you. This is what the “wrench attack” expression refers to. Nothing of this is new. Bitcoin users, and not just Bitcoin users, have suffered these kinds of attacks because of address reuse, lack of privacy, and lack of awareness. So yes, address reuse is bad, but an address alone is less harmful than a Nostr key, which has more attached metadata. If you do not care because you think your environment and community are secure, that is fine; not everyone has that privilege. However, wrench attacks are not the only risk. Governments, regulators, and three‑letter agencies would also have a clear picture of all this, and again, if they consider you valuable enough, you will give them all this information for free. Enough about that. As I mentioned, there is a lot of text discussing the dangers of address reuse, and it is nothing new or controversial, everyone in the space understands it is harmful. I mean, maybe not everyone... but still, nothing controversial; derivation of addresses is implemented in all wallets, and normally wallets not allow you or will warn you of address reuse. So what options do we have for transacting in Nostr, and what are their trade‑offs? Zaps were the first solution. This is NIP‑57 and it uses Lightning to perform payments. The way they work is that you attach a payment address to your profile metadata. Unlike on‑chain zaps, this is optional and opt‑in: if you want to receive payments, you can set a LN address or an LNURL string on your profile, whichever you choose, and you can change it at any time. The spec also defines a way to publicly signal when a payment is made so users can make these public, but the important part is that it is optional, and you can make the payment very private, with no need for social signaling; only the sender and receiver know it happened. A better version is Bolt12, which is a newer standard and provides a more private way to have a static address that people can reuse without a server in the middle and without compromising privacy. How is that possible? A static address meant for reuse that does not leak metadata sounds like black magic, but it simply leverages some of Lightning’s properties. You can read about it in detail, but in any case it is another possibility for private Nostr transactions; you can simply attach the Bolt12 address to your profile metadata. In the case of Bolt12, social signaling would be a bit awkward, but if your point is to transact publicly you can just use regular zaps. Cashu is another option, and I think it is the best if you just want to “throw money” to a user, similar to what on‑chain payments give you. The advantage is that it is much more private. The trade‑off is that it introduces a mint in the middle, which weakens the custodial model a bit. But you know, there are no perfect solutions; there are always trade‑offs, and understanding them will give you the best fit for a given case. You can also reclaim Cashu tokens if the receiver never claims them, which is an additional benefit. Nut‑zaps just add the social signaling part to sending Cashu tokens. There are other solutions, such as BIP‑47, but they present some points of friction. In summary, I hope to give you the keys to navigate this ongoing discussion. On‑chain zaps are a reckless solution that puts users at risk. Understanding their privacy implications is not easy and requires education. Non‑technical users usually do not have the time or confidence to dive into these details, and pushing something without proper caveats or disclaimers is harmful. It compromises users without their knowledge, which is why some people are speaking up and why I am writing this post. You should know the implications.

Spook View quoted note →

Carl Sagan was one of the greatest. Big influence in the way I think... And dream View quoted note →

Nostr... Once was a cypherpunk dream, now is becoming a cypherpunk nightmare

A protocol that does not learn from the mistakes it made in the past is doomed to repeat them