From 2e31f714db942377736c2ce2d0927b363cdfe043 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sat, 9 Nov 2024 07:59:14 -0300 Subject: [PATCH] nip45: mention hyperloglog attack and its solution. --- 45.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/45.md b/45.md index f6ecbee..a5ce02d 100644 --- a/45.md +++ b/45.md @@ -56,6 +56,10 @@ On the client side, these HLL values received from different relays can be merge And finally the absolute count can be estimated by running some methods I don't dare to describe here in English, it's better to check some implementation source code (also, there can be different ways of performing the estimation, with different quirks applied on top of the raw registers). +### Attack vectors + +One could mine a pubkey with a certain number of zero bits in the exact place where the HLL algorithm described above would look for them in order to artificially make its reaction or follow "count more" than others. For this to work a different pubkey would have to be created for each different target (event id, followed profile etc). This approach is not very different than creating tons of new pubkeys and using them all to send likes or follow someone in order to inflate their number of followers. The solution is the same in both cases: clients should not fetch these reaction counts from open relays that accept everything, they should base their counts on relays that perform some form of filtering that makes it more likely that only real humans are able to publish there and not bots or artificially-generated pubkeys. + ### `hll` encoding The value `hll` value must be the concatenation of the 256 registers, each being a uint8 value (i.e. a byte). Therefore `hll` will be a 512-character hex string.