The second two of those points are 'easy' to think about, in...

Raw JSON

{
  "kind": 1,
  "id": "52a21fc7f677558d0e93863ef5611eb086cc6429c43a58f2084b9dbdd674a1eb",
  "pubkey": "12ee03d11684a125dd87be879c28190415be3f3b1eca6b4ed743bd74ffd880e6",
  "created_at": 1776718420,
  "tags": [
    [
      "e",
      "28f7276c16e39f38263823076f4d5ec2e33f8533b67c6ae4a93b1e2f729b5151",
      "wss://relay.primal.net/",
      "root",
      "056f33245ca4cc4fa3c1d6e557dd8eae714889f3c3423cbd6fbf09f3c0e200d2"
    ],
    [
      "e",
      "f81f1d4c5edc7e959a083bc5811c7269323c083443fde471c2a2e62f60bdcea8",
      "wss://nos.lol/",
      "reply",
      "056f33245ca4cc4fa3c1d6e557dd8eae714889f3c3423cbd6fbf09f3c0e200d2"
    ],
    [
      "p",
      "079d727bee3d805e24758861ea4d028b2e6a37805f8db45bf8045bf900099650"
    ],
    [
      "p",
      "bbb5dda0e15567979f0543407bdc2033d6f0bbb30f72512a981cfdb2f09e2747"
    ],
    [
      "p",
      "1096f6be0a4d7f0ecc2df4ed2c8683f143efc81eeba3ece6daadd2fca74c7ecc"
    ],
    [
      "p",
      "2bbace553efebf58dd55912169f92c1123eb6121d7ba092f6c50104afc31acef"
    ],
    [
      "p",
      "23d12ef8751e5ee267fb6341d7c41b9434a1b99869e0212eb34d56abb6b12e8a"
    ],
    [
      "p",
      "83d999a148625c3d2bb819af3064c0f6a12d7da88f68b2c69221f3a746171d19"
    ],
    [
      "p",
      "056f33245ca4cc4fa3c1d6e557dd8eae714889f3c3423cbd6fbf09f3c0e200d2"
    ]
  ],
  "content": "The second two of those points are 'easy' to think about, in the sense that it's just about detecting which peers are spammy/unreliable. If their Bloom advertizes they can reach nodes, but they rarely/never get the relevant signed CoordinateLookupResponses, then they are unreliable. It might take a long time to get the right balance of heuristics to make it work, but in principle it's solvable.\n\n\u003e Bloom filter validation — reject suspiciously dense filters\n\u003e Per-source LookupRequest rate limiting — cap flood generation\n\nI'm less sure about the first two points though; solutions are not so obvious. I had a lot of fun with faking fake roots and fake ancestries and varying 'depths'.\n\n\u003e Root election with cost — proof-of-work, minimum age, or stake\n\nMaybe the root should be the oldest node; although I'm not sure how to get consensus on that in a simple way.\n\n\u003e Per-entry ancestry signatures — already on their roadmap\n\nSignatures won't stop me from firing up a million nsecs and signing many different ancestries and spamming the network. If I have many entry points into the network, then I can spam with new (fully-signed) ancestry paths very regularly\n\nI don't say I have a solution, but I think we need to either make it difficult/slow to change the root in chaotic ways, *or* have a system which is robust to such chaos.\n\nIdeally, a change of root will change only the direction of arrows on the spanning tree, without changing anything 'fundamental' about the tree. This should allow us to preserve the property that a spanning-tree-edge divides the network into two sets of nodes. Swapping the direction of edges doesn't change those divisions, and therefore I think the bloom filters don't need to be rebuilt immediately on every change of root\n\nWe might need to keep tracking of mutiple roots, and therefore multiple coordinates, during the transitions. Don't discard a given root until all your peers are happy with a different new root.\n\nBut I'll stop rambling now. I might not be making much sense. In any case, a written document which we could review would be useful to discuss how we might have a reasonably scalable and robust protocol",
  "sig": "6a670704ff127d24d62b7f632b4bcddc751e62da0ccdb8fcdd7a195d775c609bbd03e8f8fb9f9a499dff9ecc69133049e8b47b2f0cf0b97daa385ca3d0885a29"
}