Skip to content

DIVERGENCES.md

Latest commit

 

History

History
62 lines (42 loc) · 2.65 KB

DIVERGENCES.md

File metadata and controls

62 lines (42 loc) · 2.65 KB

Spec vs. Real-World Divergences

This document tracks cases where real-world Nostr event data diverges from what the NIP specification prescribes. Schemata schemas are adjusted to reflect observed practice when the divergence is widespread, cryptographically valid, and non-harmful.

Each entry includes the NIP reference, what the spec says, what clients actually do, the schemata decision, and evidence from validation runs.

D-001: NIP-61 pubkey tag prefix (02 vs 03)

Field Value
NIP NIP-61 (Nutzaps)
Kind 10019 (Nutzap informational event)
Tag pubkey
Schema nips/nip-61/tag/pubkey/schema.yaml
Discovered sherlock#75

What the spec says

"Clients MUST prefix the public key they P2PK-lock with "02" (for nostr<>cashu compatibility)."

This implies the pubkey tag value should always be a 66-character hex string starting with 02.

What clients actually do

Both 02 and 03 prefixed compressed secp256k1 keys appear in the wild. Out of 109 kind 10019 events scanned, 103 failed validation because they used 66-character compressed keys (with either 02 or 03 prefix) against the original schema that expected 64-character x-only Nostr pubkeys.

Example from real event:

["pubkey", "0329f1fad861410f3dcabb3cd75ceb0e8b7cc6a8d1fa17dbd10e8133c000326a96"]

This is a valid compressed secp256k1 public key with 03 prefix (odd y-coordinate), 66 hex characters.

Why 03 is valid

Compressed secp256k1 public keys encode the x-coordinate (32 bytes) plus a prefix byte indicating the y-coordinate parity:

  • 02 = even y-coordinate
  • 03 = odd y-coordinate

Both represent valid points on the secp256k1 curve. The NIP-61 MUST for 02 is a convention for determinism, not a cryptographic requirement. Rejecting 03 would invalidate otherwise correct events.

Schemata decision

Accept both 02 and 03 prefixes. Pattern: ^(02|03)[a-f0-9]{64}$

Rationale:

  • Both are cryptographically valid compressed secp256k1 keys
  • 94.5% of real events use this format (the original 64-char pattern was wrong regardless)
  • Schema validates format correctness, not client behavior conventions
  • Rejecting 03 would create false negatives with no security benefit

Evidence

Metric Value
Events scanned 109
Failed (old schema) 103 (94.5%)
Passed (old schema) 6 (likely missing pubkey tag)
Key prefix distribution Both 02 and 03 observed
Source Sherlock v1 validation run, 52 event kinds, 655K total events