pull down to refresh

TLDR; this shit is retarded

To me all of this is trumped by the poorest spec I've seen in a while:

The recipient's Nostr pubkey is used directly as the internal key of a BIP-341 P2TR output, with no mathematical conversion. The output key is produced by the standard BIP-341 key-path-only tweak (no script tree), and encoded as bech32m (BIP-350) with human-readable prefix bc. Every Nostr pubkey therefore has exactly one corresponding mainnet Taproot address, and anyone can compute it from the pubkey alone.

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):

The first and most important rule to follow is to limit the scope of each key. A key should typically have only a small number of closely related functions. There is sometimes a temptation to reuse keys for related applications—this should be avoided whenever possible. If there is only one certified key pair, it should be used to sign (and perhaps even derive) other single-use public keys

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.

  1. Protocol Interactions and the Chosen Protocol Attack, p10

344 sats \ 3 replies \ @gigi 21 May
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.

That's a shame, but understandable.

Reusing a key across use-cases takes immense cryptographic risk, because weaknesses compound across uses.

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.

  1. See "weakens the cryptography" and the associated footnote

reply

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>.

reply
265 sats \ 1 reply \ @gigi 21 May
and apparently, some of the devs need this too

I was surprised to see this, and it is in part what encouraged me to sit down and write.

previously semi-acceptable software is further impoverished and actively morphing into threat vectors

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.

reply
I'm afraid that it will get worse still.

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.

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.

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.

reply