An idea for nostr:npub1y0gja7r4re0wyelmvdqa03qmjs62rwvcd8szz...

SatsAndSports

npub1zthq85gksjsjthv8h6rec2qeqs2mu0emrm9xknkhgw7hfl7csrnq6wxm56

hex

cb20997eff022c774dd53cc30cb85dfbade7773b129f3373fc3f3a90ff8b2462

nevent

nevent1qqsvkgye0mlsytrhfh2nescvhpwlht08wua398enw07r7w5sl79jgcsprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsp9msr6ytgfgf9mkrmapuu9qvsg9d78ua3ajntfmt580t5llvgpes74qfz9

Kind-1 (TextNote)

2026-05-03T20:09:54Z

An idea for nostr:npub1y0gja7r4re0wyelmvdqa03qmjs62rwvcd8szzt4nf4t2hd43969qj000ly , to allow more (transitive) signing within ancestries, while retaining the obfuscation/privacy benefit of hiding the 'real' npub:

TL/DR: the node_addr should be a tweaked public key, not just an arbitrary hash of the pubkey key.

Your node has a keypair: the secret s and the corresponding public key p. We usually see the p in it bech32 representation (npub...)

Currently, the node_addr is the (first 16 bytes of the) sha256sum of the pubkey. I propose to change that

First, define a tweak:

t = sha256("FIPS_node_addr" || pubkey)

Then we have a tweaked pubkey

p' = p + tG

and the corresponding tweaked secret (don't forget BIP-340), which will allow your node to sign for p' just as easily as it can sign for p.

Now, let's define the node_id as p', and the node_addr as the first 16 bytes of that.

With this scheme, if my node tells you that my ancestry is

[node_id(me), node_id(A), node_id(B), node_id(Root)],

then the ancestry will include multiple relevant signatures. You won't directly see the pubkey B, but you'll B'=node_id(B). And you will see a signature by B' that it's parent is node_id(Root).

Of course, signatures don't prove that all the data is genuine. But over time, we can see which node_ids are reliable and which are not. For example, the signature will stop a hacker from pretending that you (a reliable) node has selected the hacker as its parent

Raw JSON

{
  "kind": 1,
  "id": "cb20997eff022c774dd53cc30cb85dfbade7773b129f3373fc3f3a90ff8b2462",
  "pubkey": "12ee03d11684a125dd87be879c28190415be3f3b1eca6b4ed743bd74ffd880e6",
  "created_at": 1777838994,
  "tags": [
    [
      "p",
      "23d12ef8751e5ee267fb6341d7c41b9434a1b99869e0212eb34d56abb6b12e8a"
    ]
  ],
  "content": "An idea for nostr:npub1y0gja7r4re0wyelmvdqa03qmjs62rwvcd8szzt4nf4t2hd43969qj000ly , to allow more (transitive) signing within ancestries, while retaining the obfuscation/privacy benefit of hiding the 'real' npub:\n\nTL/DR: the node_addr should be a tweaked public key, not just an arbitrary hash of the pubkey key.\n\nYour node has a keypair: the secret s and the corresponding public key p. We usually see the p in it bech32 representation (npub...)\n\nCurrently, the node_addr is the (first 16 bytes of the) sha256sum of the pubkey. I propose to change that\n\nFirst, define a tweak:\n\nt = sha256(\"FIPS_node_addr\" || pubkey)\n\nThen we have a tweaked pubkey\n\np' = p + tG\n\nand the corresponding tweaked secret (don't forget BIP-340), which will allow your node to sign for p' just as easily as it can sign for p.\n\nNow, let's define the node_id as p', and the node_addr as the first 16 bytes of that.\n\nWith this scheme, if my node tells you that my ancestry is\n\n[node_id(me), node_id(A), node_id(B), node_id(Root)],\n\nthen the ancestry will include multiple relevant signatures. You won't directly see the pubkey B, but you'll B'=node_id(B). And you will see a signature by B' that it's parent is node_id(Root).\n\nOf course, signatures don't prove that all the data is genuine. But over time, we can see which node_ids are reliable and which are not. For example, the signature will stop a hacker from pretending that you (a reliable) node has selected the hacker as its parent",
  "sig": "814600e52af20f394d527c0d6b6aa25e416b11528c68cc7463d3f32daf1910ab36fae35c3b53650d55f0e0e161afac4c6721a6c73e250cd099e70414146cf556"
}