search

nostr-protocol / nips

Nostr Implementation Possibilities
2.31k stars 563 forks source link

NIP-13: Preventing pre-computation attacks #137

Open lucash-dev opened 1 year ago

lucash-dev commented 1 year ago

NIP-13 implements a version of the non-interactive HashCash DoS-prevention technique.

The non-interactive variety is vulnerable to pre-computation attacks, when a spammer spends a long time generating valid PoW for certain future time, then sends all the messages at once, overwhelming the victim.

This can be avoided by using either an explicitly interactive mode (e.g. a relay sends a challenge to clients) or by using a beacon (some external source of randomness, such that a value known to have been generated at a certain point in time must be included in the hashes message).

While NIP-13 could be useful even without a countermeasure against pre-computation attacks, it should be easy to allow it in the protocol.

An optional tag "challenge" could be added so that relays can reject notes that don't commit to a specific challenge. The same tag could be used for challenges produced by a beacon.

lucash-dev commented 1 year ago

Alternatively, the "nonce" tag could have an optional fourth element corresponding to the challenge.

Not sure if there's anything against variadic tags though.

BTW

What's the process for updating a NIP? Does it become a new NIP? or can it just be changed if it's backwards compatible?

Ery4z commented 1 year ago

I think you have to do a pr and link this issue this should be enough.

fiatjaf commented 1 year ago

It can be changed if the change is backwards-compatible or if everybody who is known to have implemented it agree to change their implementations.

mikedilger commented 1 year ago

I think this probably belongs on NIP-42 as a POW parameter, e.g. relay sends ["AUTH", <challenge-string>, "28"] requesting a PoW of 28 in the response which must include that challenge. Maybe that isn't backwards compatable with NIP-42 as clients that don't understand the 3rd field won't supply the PoW, but my point is that we shouldn't develop another "interactive mode" unless AUTH proves to be inadequate.

PoW should remain as is for the various uses it has already found.