Since most clients don’t check signatures I think it would be good to have a public test tool / gag relay that posts a bunch of random stuff pretending to be from people you follow.

Like

“jb55: I hate puppies. I really do. I’m that evil.”

And then several line breaks and a disclaimer “this is an impersonation attack test tool. this message wasn’t written by jb55. if you’re seeing this message, then your Nostr client doesn’t check signatures. be very careful what relays you connect to or you may fall victim to impersonators and phishing scams.”

I know it’s too late but ChatGPT really put some effort in it (took several seconds):

In Silvergate, where crypto once was king,

A bank now faces pressures unrelenting,

Regulatory woes and losses stinging,

The FTX fraud scandal, a blow so upsetting.

Yet once they stood atop a rising wave,

A haven for investors brave and bold,

But now they struggle just to stay afloat,

Their fate uncertain, a future untold.

What once was seen as innovation's dream,

A chance to change the world of finance,

Now faces challenges, it would seem,

And may depart from this world's dance.

Oh Silvergate, we mourn your troubled fate,

Your legacy remembered, though it's late.

That’s a weird way of stating it, but do you mean that SQL servers can’t execute arbitrary queries, especially if the database is big and there are no indexes to support the query? If that’s what you mean you’re obviously correct.

The part about “questioning your lack of senses” is a bit confusing.

Who is doing the questioning?

You can copy it — but the part about hiding metadata while letting users still find their messages still has to be added.

About the incentives issue, you could leak only sender but use a “fake” receiver generated in a way the original receiver can identify.

Or you can use a throw away sender and “fund” it with a small per post payment.

Yet another way is revealing the actual sender only to the relay — but not publicly in the event itself. The public author for the event would be masked in a way only the receiver can identify.

There’s a “sealed sender” thing in Signal I don’t understand that might be useful though.

I recently proposed a minimal improvement just for the sake of being easy to implement — not to discourage better solutions.

I think one “problem” is that there are just so many ways of doing it with different tradeoffs, including different protocols to draw from, that it’s hard to see what would be best

A security vulnerability I reported 3+ years ago has been rescheduled the 10th time for a fix.

😂 why don’t they just say they’re not going to fix it?

Important work is hardly ever glamorous.

Glamorous work is often irrelevant and soul-crushing.

I think your work is very important and the fact you use it as input for deeper reflections quite impressive.

Keep the good work and may the sats flow to you.

The context is above and the content is the same. Copying and pasting and editing in Damus isn’t very easy.

If want to say a fact is merely my opinion be my guest.

But that makes you wrong.

BTW if you want context go read the post the was answering to and point to me where anyone was trying to impose anything on anyone.

“You want to impose your view on everyone”

“What you should be doing”

I have so many questions about HAM.

How you guys don’t just saturate the channels and make it impossible to talk?

Is digital HAM a thing?

Do you guys call yourselves HAMsters?

Is there a protocol for radio broadcast that doesn’t assume people will just not “trespass” on someone else’s frequency band?

Last time I studied radio FM was bleeding edge 😂

Either we aging or we ded

Live in the pod. Eat sugar made by bugs. Be happy.

Quote of the day is a rant about others supposedly trying to impose their views on others (by simply stating their opinion) while the author of the rant tells what everyone should be doing.

Classic cognitive dissonance.

At most it could kill centralized stablecoins.

But I think even that is unlikely.

Bottom line is:

Don’t use a Merkle Tree implementation without reviewing it with your specific use case assumptions in mind.

Have knowledgeable people review it too.

Doesn’t matter if you wrote it or someone else, or if you got it from some place supposed to be battle-tested.

Some cryptographic structures are so simple to implement — and so often implemented in very specialized ways — that you might not be worse off just writing one yourself.

I don’t recommend ever reusing a Merkle Tree implementation outside of its narrow original use case — unless you thoroughly review the implementation.

Most Merkle Tree implementations I’ve seen are either broken or one tiny change or assumption away from being completely broken.

Bitcoin’s implementation is a famous case.

But there are others.

Seen plenty of vulnerabilities in the wild.

Every novel use case for cryptography is dangerous.

Don’t assume yours is safe just because you copied it’s parts from someone else.

While “don’t roll your own crypto” is in general good advice — it can be bad too.

Being fixated with reusing other cryptographic schemes — even for novel use cases — can be just as dangerous.

Before using someone else’s cryptographic scheme be sure that its actually intended for your use case.

If there isn’t something already for your use case, don’t be afraid to combine cryptographic primitives in a new way —

you’re doing risky things anyway, and throwing in something designed for completely different uses will just hide the danger.

Either way don’t do anything before spending some time looking for previous art and understanding it.

HMAC is a specific use case of hashing with a prefix — in that case for authentication.

Using HMAC in taproot would just cause confusion as to what is being authenticated and why there’s no secret involved.

Calling it “tagged hash” and defining it in the specification eliminates any confusion.

The generic term for that use case is “domain separation”. There are other ways of doing it besides prefixing though, so just saying “domain separation” isn’t very helpful.

They also were extra cautious and used prefixes generated in an unusual way.

If the all of Bitcoin used domain separation that wouldn’t have been necessary.

Imagine the masses — and much of the elite! — suddenly realizing they lost an opportunity of preserving or acquiring wealth that will never happen again, and looking at everyone who took that opportunity with anger and greed.

It will be chaotic, violent times.

And then there will be a sudden peace.

“Institutional adoption” is the only way for a “soft landing”.

If the legacy system and governments gets exposure to Bitcoin they might be able to keep a certain level of social peace.

The difference between propaganda, advertising, spam, and actual news is a subjective value judgement — and even the objective distinction between factual and false information can only be evaluated subjectively.

I don’t think a protocol per se can disincentivize propaganda — and I don’t think it’s possible to design a protocol around that goal.

However, any protocol that maximizes subjective value in general can be used to reduce propaganda— if “propaganda” is something people don’t value and they can identify.

I don’t think Nostr is such a system right now — at least not more than other platforms — but maybe it will become one.