But the biggest flaws as nostr:npub180cvv07tjdrrgpa0j7j7tmny...

930ccef12372dd2f...

npub1jvxvaufrwtwj79s90n79fuxmm9pntk94rd8zwderdvqv4dcclnvs9s7yqz

hex

70a03ea4a9ffd4124dad588bb06288f34b05253589e430f5d66c733c56e31b57

nevent

nevent1qqs8pgp75j5ll4qjfkk43zasv2y0xjc9y56cneps7htxcueu2m33k4cprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsfxrxw7y3h9hf0zczhelz57rdajse4mz63kn38xu3kkqx2kuv0ekg5apsns

Kind-1 (TextNote)

2026-04-20T19:08:08Z

↳ Reply to Technical Debt (npub14w4qnk43lsllls2qnldj3vfcxtx5qvtsf3xlvxv9yha8afrxhmfqju3rwx)

I don’t think WoT is enough on its own but the friend request thing doesn’t scale alone either. The attacker has an unlimited supply of identities to...

But the biggest flaws as nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 noted in that thread is the unwieldiness of the Blockchain especially Ethereum. I mitigate that by;

  1. I don't bloat the Blockchain state so the expense doesn't get out of hand.
  2. I use the Blockchain for as little computation as possible to keep the cost low.
  3. I only use a smart contract to track an accumulator of previous submitted opaque data.
  4. I use Rootstock which is a merge minded PoW chain, so I can have a super light client to find the fork choice.
  5. Once I get the light client proof of the latest blocks, I read the accumulator from the contract state, all of that is merkle binary tree stuff, so very light.
  6. I ask nodes for the state of any ID, and they give me; A) the state. B) a merkle proof from the state to the root of the entire IDs set merkle tree. C) a ZK STARK proof that given a history that accumulates into the accumulator hash from step 5, you should get a full state with the merkle proof from step B.

This way, light clients don't even have to download the history, neither the history of Bitcoin, nor Rootstock, nor the events published on Rootstock.

At least this is the rough plan, I still need to prove that all this actually works

Raw JSON

{
  "kind": 1,
  "id": "70a03ea4a9ffd4124dad588bb06288f34b05253589e430f5d66c733c56e31b57",
  "pubkey": "930ccef12372dd2f16057cfc54f0dbd94335d8b51b4e2737236b00cab718fcd9",
  "created_at": 1776712088,
  "tags": [
    [
      "e",
      "861170a0d3153c48e2b55c8a9f7de1f46950993ee424843f071d07c4d6cfcbfa",
      "wss://relay.primal.net/",
      "root",
      "930ccef12372dd2f16057cfc54f0dbd94335d8b51b4e2737236b00cab718fcd9"
    ],
    [
      "e",
      "043a2deea3b344a207ed5c8dc98a93215b1ee57fca6f65c47354c401fab2e668",
      "wss://relay.primal.net/",
      "reply",
      "abaa09dab1fc3fffc1409fdb28b13832cd4031704c4df6198525fa7ea466bed2"
    ],
    [
      "p",
      "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
    ],
    [
      "p",
      "50809a53fef95904513a840d4082a92b45cd5f1b9e436d9d2b92a89ce091f164"
    ],
    [
      "p",
      "abaa09dab1fc3fffc1409fdb28b13832cd4031704c4df6198525fa7ea466bed2"
    ]
  ],
  "content": "But the biggest flaws as nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 noted in that thread is the unwieldiness of the Blockchain especially Ethereum. I mitigate that by;\n1. I don't bloat the Blockchain state so the expense doesn't get out of hand.\n2. I use the Blockchain for as little computation as possible to keep the cost low.\n3. I only use a smart contract to track an accumulator of previous submitted opaque data.\n4. I use Rootstock which is a merge minded PoW chain, so I can have a super light client to find the fork choice.\n5. Once I get the light client proof of the latest blocks, I read the accumulator from the contract state, all of that is merkle binary tree stuff, so very light.\n6. I ask nodes for the state of any ID, and they give me;\n  A) the state.\n  B) a merkle proof from the state to the root of the entire IDs set merkle tree.\n  C) a ZK STARK proof that given a history that accumulates into the accumulator hash from step 5, you should get a full state with the merkle proof from step B.\n\nThis way, light clients don't even have to download the history, neither the history of Bitcoin, nor Rootstock, nor the events published on Rootstock.\n\nAt least this is the rough plan, I still need to prove that all this actually works",
  "sig": "7e203d2b8e30cf1ef6f5afb9086a993f833f82ce139b92f0dcddd44569addf2d11cb1c3ebf041abe865f85cb6e1ab90027cdf0c11662c0317f492e9cb652e4b8"
}