From aea06810ac92b0ee35f28751e2a69df839f25f61 Mon Sep 17 00:00:00 2001
From: Mike Dilger <mike@mikedilger.com>
Date: Sat, 8 Feb 2025 09:03:59 +1300
Subject: [PATCH] Add Secure HyperLogLog option

---
 45.md | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/45.md b/45.md
index 4866e579..d53924c4 100644
--- a/45.md
+++ b/45.md
@@ -65,7 +65,21 @@ This NIP defines (for now) two filters eligible for HyperLogLog:
 
 ### 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.
+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.
+
+An alternative solution is Secure HyperLogLog:
+
+### Secure HyperLogLog
+
+Because the HyperLogLog input is deterministic (and must be for relays that do not store all of the counted events), there is some potential for gaming the system. Relays that do store all of the events may also return a Secure HyperLogLog value together with the regular HyperLogLog value:
+
+```
+["COUNT", <subscription_id>, {"count": <integer>, "hll": "<hex>", "shll": "<hex>"}]
+```
+
+The Secure HyperLogLog scheme is identical to the HyperLogLog scheme except that instead of operating on the event `pubkey`, the algorithm operates on `SHA256(concat(<subscription_id>, <event_pubkey>))`.  Clients will need to use the same `<subscription_id>` at each relay in order for the resulting data to properly combine.
 
 ### `hll` encoding