If starting over, proof-of-work might work.
Nostr software has explored a number of spam prevention mechanisms. Some of them are quite good. But one that didn't gain widespread adoption was proof-of-work.
I'm thinking of a PoW on public keys. If public keys must end in 28 zeroes or be rejected as invalid keys, this would require about 100 seconds of delay for someone to create a new identity. If handling a spam message takes only 10 seconds (probably less), then spammers would have to work 10x as hard as spam recipients to keep the spam flowing. That might not be enough to deter spammers entirely, but it would be an unavoidable cost in the equasion that could slow spam down. And of course other spam prevention techniques could also be in play, it doesn't interfere with any of them.
What do you think? If this isn't useful, or makes something important too hard to do, let me know. This would be for mosaic, not nostr, since nobody uses mosaic it can get these kinds of changes.
Replies (18)
I like the idea of collective PoW: every now and then my client sends out another PoW for people that I follow. But you can't expect individuals to PoW themselves because things are so asymmetric. A laptop does nip13 100 times faster than most phones. Some GPU optimized version might go orders of magnitude faster than that. The people that you want to exclude have vastly more resources than the people you want to keep in. Same thing for bitchat
https://github.com/ynniv/nip13_minerBoss alas some moss loss alas some alas some moss loss
Nice repo. Did you look at rana? Or other client PoW code? Or just start fresh?
While computing power spans a wide range, as you say, even a little bit of PoW makes creating a new account ONE MILLION times harder. That takes less than a second though. There is no ideal amount of PoW that keeps out spammers, but if you can slow them down one-million fold with a trick that costs very little, it still seems worth it.
I just vibe coded something to make a point... It's based on hashcat.
The problem is the asymmetry. Either you make spam easy, or you shut out normal people. The problem is more equitable if you expect people to pay others to mine for them, but now there's an entrance fee
I just had the thought that the gating factor is the network connection to drop off the spam on the server. It doesn't matter if keypair generation is super fast without PoW, any slowdown by requiring PoW that doesn't exceed the gating factor of the network connection makes no difference, until it exceeds that. So "one million times slower" is of no practical effect.
#nosternity solves this using aeternity/sophia, a PoW blockchain, an erlang implementation of bitcoin-ng which was an early bitcoin fork (?)
🤓
nostr:nevent1qqs2t5dlclttl2jxarwa9rpaccqg7kmq2kywllm8cp9kqgx5j04hf5cppemhxue69uhkummn9ekx7mp0qgswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgrqsqqqqqp9ulkhf
That would make reusing seed phrases a little annoying but still sounds like a good idea.
Another thing to look into is the concept of message stamps (as seen on nostr:npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8 ), and “while we’re at it”, make micropayments a way to fund relays as to make some market incentive to get more people running relays and fund fat media storage.
It's ... hard. But consider my idea of people randomly PoWing the people they follow. Even mobile-only people would occasionally get some server PoW. Over time pubkeys would accumulate a lot of it, and new accounts would have just a little. It's not perfect, but at least no one would wonder which nostr:npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m is the real one, and maybe some new variant will work even better
It's similar to follower count, except you can easily make new followers. Also similar to zaps, but you can game zaps.
Can't game PoW, but it favors server hardware so you need to use it a certain way
check my npub
PoW without difficulty adjustment is near useless in the grand scheme of things. Satoshi’s genius was the difficulty adjustment. HashCash existed long before — there’s a reason it never caught on for preventing e-mail spam.
100% a good idea IMO. The problem is, how does this get implemented? Relays can require it, but they'd prefer to just require a zap which is purchased PoW, if a client allows users to require it a user might want to turn it off because they already follow people with keys that dont have it already. And how does it get communicated to others? If I send a guy a message, I want to know that he won't get it because my key isn't compliant with his requirements.
mining NPUBs is retarded ( as is mining bitcoin )
whoever invents the network should simply own all possible NPUBs and SELL THEM to anybody wishing to use the network
kind of like "Satoshi" ( CIA / NSA ) started out with the ownership of a fuckload of BTC
nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
Yeah, difficulty adjustment I can do. I would just start at some difficulty, and announce ahead of time (maybe 6 months ahead) of the new difficulty. People would have to roll over their device keys before then if their PoW wasn't already high enough.
But I think nostr:npub12akj8hpakgzk6gygf9rzlm343nulpue3pgkx8jmvyeayh86cfrus4x6fdh 's point is the biggest problem. People's hardware is just too variant. Smartphones can't compete with spammer dedicated hardware, so there is no PoW which is easy enough for a smartphone and still too hard for a spammer with dedicated hardware.
And my point about the key generation not being the gating factor also has convinced me that this line of thinking is a dead end.
This is only for a situation where, from day 1 you say "pubkeys all end in N zeroes else software should reject them". So for Mosaic, a nostr-like protocol I'm writing that nobody is using, it could be done. But it can't be done in nostr. Nonetheless I'm now against the idea (read the other thread replies for why).
i'm so glad to hear this because i figured out about 7 years ago that proof of work can only work for one distributed system on the planet: bitcoin
the reasons being exactly what you just said - it's not possible for users to crunch this many hashes to get there, and because coordinating (difficulty adjustment) is difficult even with a strict and clock-driven adjustment consensus, based on the block discovery cycle being measured and averaged to target a specific time interval.
the only solution for spam resistance for the rest of the internet outside of the bitcoin protocol, is payments, and we have zaps, so it's really not that complicated, just that nobody has built it yet.
Sadly yes, and this logic also applies to payments, so those saying micropayments of some kind to take in the network part fixes this are not entirely correct.
Spam is an industry. Dedicated spammers will always earn from their spam, be it via simple impressions, or as a front door to some scam or another, or taking payment to bring someone else's system down, and so on. And it's the dedicated spammers you need to keep out, they will always appear at some point, typically once the impression base seems big enough.
However the amount dedicated spammers can earn from spamming the network is almost always more than what a user in a less developed country can pay to take part in the same network. And sometimes in a more developed country too.
So you end up at the same failure mode.
I'm not quite following. Would you elaborate? Seems to me, a bottleneck on keypair generation would reduce the number of accounts that can be generated for spam, so it would significantly reduce spam as spammer have to continuously generate new keys as they're blocked or filtered by relays.
This of course doesnt take into account message level PoW, where one must be in the hash of the messages themselves, which clients and relays could implement.
And none of it addresses how PoW requirements are communicated between parties, both users and relays, to ensure that everything doesnt just become some standard, which is sure to be a difficulty of 0 in that case. I should he able to set a PoW as a user for DMs from users not in my follows list, for example, or something like that. Seems to me it would be better than WoT because it wouldnt shut new keypairs out of the network effects.
