I think he means relays who don't play by the rules.
A malicious relay coud:
- send the same message(s) multiple times
- send extra messages that don't match the filters
- do this both for stored events (pre EOSE) and for streamed events (post EOSE)
IMO its a viable attack vector, because clients have less resources so by doing the above, a relay could DoS a client.
Even if unexpected events are "filtered out" by the client before showing them to the user, the client still presumably verifies they're valid events, and signature verification is quite intense. So unexpected large events are also an attack vector, they can hit the client CPU hard.
Nostr SDKs used in clients could defend against most of this by
- only returning events that match the subscription filters
- only validating if an event is valid (signature) if the above is true
- not processing and returning events that have already been seen before (much harder to do)
cc Yuki Kishimoto (npub1drv…seet)
Probably not a concern now, because Nostr is small.
(Another defence for clients is to use a semi-trusted relay aggregator like Wine or caching service like Primal)
Carlos
npub1zg…yjdwv
2023-09-17 09:57:33
in reply to nevent1q…005g
Author Public Key
npub1zg69v7z7u7q4w5wzsqzwdnh58x8py4hef2fm750eqqvw9zkvh76q4yjdwvPublished at
2023-09-17 09:57:33Event JSON
{
"id": "0000ecf9ce58ba5589f1b36ba9623955c41d4894ddf49369d127487cb8a241cc",
"pubkey": "123456785ee7815751c28004e6cef4398e1256f94a93bf51f90018e28accbfb4",
"created_at": 1694944653,
"kind": 1,
"tags": [
[
"p",
"68d81165918100b7da43fc28f7d1fc12554466e1115886b9e7bb326f65ec4272"
],
[
"p",
"97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322"
],
[
"p",
"d6dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c"
],
[
"e",
"2cf8af0ebe81133e8509d28f60e390229db0426b465c2dd119e5c92a906c3219",
"wss://relay.nostr.band/",
"root"
],
[
"e",
"61ef06dd2d403fadafd56dc3a4a7312965551c248e26d6d4cb0bb14afb4b7361",
"wss://relay.nostr.band/",
"reply"
],
[
"nonce",
"9223372036854777509",
"16"
]
],
"content": "I think he means relays who don't play by the rules.\n\nA malicious relay coud:\n- send the same message(s) multiple times\n- send extra messages that don't match the filters\n- do this both for stored events (pre EOSE) and for streamed events (post EOSE)\n\nIMO its a viable attack vector, because clients have less resources so by doing the above, a relay could DoS a client.\n\nEven if unexpected events are \"filtered out\" by the client before showing them to the user, the client still presumably verifies they're valid events, and signature verification is quite intense. So unexpected large events are also an attack vector, they can hit the client CPU hard.\n\nNostr SDKs used in clients could defend against most of this by\n- only returning events that match the subscription filters\n- only validating if an event is valid (signature) if the above is true\n- not processing and returning events that have already been seen before (much harder to do)\n\ncc nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet\n\nProbably not a concern now, because Nostr is small.\n\n(Another defence for clients is to use a semi-trusted relay aggregator like Wine or caching service like Primal)",
"sig": "a500d14af43107577298cba5c98bb8bd00eaa677dfa1ea1ea6299a506eb246e1dabd948fa18d37d17afdf54c72fc6315df54b76f69ddd4637e7f0b18f60e5f45"
}