PoW on identities

mikedilger commented

2025-09-04 03:26:34 +12:00

(Migrated from github.com)

If we require all pubkeys to end in 28 zeroes (for example), this slows down identity creation.

If identity creation is an order of magnitude slower than spam filtering, this helps mitigate spam. it wouldn't be sufficient in itself, other means would also need to be employed, but it would be a big step towards it.

If we assume it takes on average 10 seconds for a human to assess and reject a spam message (it would be lower under many techniques and situations) then we want to shoot for about 100 seconds to generate a new identity.

BTW, we could also use this to differentiate users from servers, where servers either don't have this requirement, or their keys end in 1s instead of 0s.

This didn't happen in nostr, where the idea came about after many identities were already created, and so PoW was applied to each event. That is much more costly than just once per identity. So the thought that "it didn't work in nostr" doesn't mean it couldn't work, just that it wasn't done right from the start in nostr.

If we require all pubkeys to end in 28 zeroes (for example), this slows down identity creation. If identity creation is an order of magnitude slower than spam filtering, this helps mitigate spam. it wouldn't be sufficient in itself, other means would also need to be employed, but it would be a big step towards it. If we assume it takes on average 10 seconds for a human to assess and reject a spam message (it would be lower under many techniques and situations) then we want to shoot for about 100 seconds to generate a new identity. BTW, we could also use this to differentiate users from servers, where servers either don't have this requirement, or their keys end in 1s instead of 0s. This didn't happen in nostr, where the idea came about after many identities were already created, and so PoW was applied to each event. That is much more costly than just once per identity. So the thought that "it didn't work in nostr" doesn't mean it couldn't work, just that it wasn't done right from the start in nostr.

mikedilger commented

2025-09-04 03:40:38 +12:00

(Migrated from github.com)

If we want generation to be 10x slower than our 10 second spam rejection time, we need something that takes 100 seconds.

Since computers will be getting faster all the time, it would be better to go longer than that.

32 bits takes about 5580 seconds (93 minutes)
31 bits takes about 2790 seconds (46 minutes)
30 bits takes about 1392 seconds (23 minutes)
29 bits takes about 697 seconds (11 minutes)
28 bits takes about 349 seconds (6 minutes)
27 bits takes about 174 seconds (3 minutes)
26 bits takes about 87 seconds (1 minutes)

I think 28 bits is reasonable.

If we want generation to be 10x slower than our 10 second spam rejection time, we need something that takes 100 seconds. Since computers will be getting faster all the time, it would be better to go longer than that. 32 bits takes about 5580 seconds (93 minutes) 31 bits takes about 2790 seconds (46 minutes) 30 bits takes about 1392 seconds (23 minutes) 29 bits takes about 697 seconds (11 minutes) 28 bits takes about 349 seconds (6 minutes) 27 bits takes about 174 seconds (3 minutes) 26 bits takes about 87 seconds (1 minutes) I think 28 bits is reasonable.

mikedilger commented

2025-09-11 08:17:03 +12:00

(Migrated from github.com)

Computing power is highly variable, several orders of magnitude. I consider my computer middle-of-the-road (it is quite fast, but computers are getting faster). So a legit user might be 10x slower, and a spammer might be 10x faster.

At 30 bits, it takes my computer 23 minutes to generate a master key. But that could be up to 4 hours on a slow computer. Unfortunately it could also be only 2 minutes for a sophisticated spammer.

Yet that seems about right. People can wait about 4 hours to generate their master key. And this will slow down spam account generation to perhaps once every 2 minutes, which makes spam far more manageable.

So I'm now leaning towards 30 bits.

Computing power is highly variable, several orders of magnitude. I consider my computer middle-of-the-road (it is quite fast, but computers are getting faster). So a legit user might be 10x slower, and a spammer might be 10x faster. At 30 bits, it takes my computer 23 minutes to generate a master key. But that could be up to 4 hours on a slow computer. Unfortunately it could also be only 2 minutes for a sophisticated spammer. Yet that seems about right. People can wait about 4 hours to generate their master key. And this will slow down spam account generation to perhaps once every 2 minutes, which makes spam far more manageable. So I'm now leaning towards 30 bits.

mikedilger commented

2025-09-11 08:20:00 +12:00

(Migrated from github.com)

Instead of the key itself ending in 30 zero bits, the HASH of the key should start with 30 zero bits. This prevents weakening of the key security. We will use blake3 with 'Mosaic' tag, with a 4 byte output which is enough to find out.

Rows
Columns

PoW on identities #8