{"id":"f053181936f70474229b3c60a8d6e022efc45ba17e57d5a1ba8c20197fe131aa","pubkey":"2e17b86d692c979bb5b7c2ddb9f70e02e76bbc358afa95ac68135047bbe10e02","created_at":1782827725,"kind":30817,"tags":[["d","nip-xx-bitcoin-otc-identity-linkage-proof"],["title","NIP-XX: Bitcoin-OTC Identity Linkage Proof"],["alt","Nostr Implementation Possibility: NIP-XX: Bitcoin-OTC Identity Linkage Proof"],["k","37773","Bitcoin-OTC Identity Linkage Proof"],["client","NostrHub"]],"content":"# NIP-XX: Bitcoin-OTC Identity Linkage Proof\n\n## Status\n\nDraft\n\n## Author\n\nAlwin/@TheButterZone\n\n## License\n\nMIT\n\n---\n\n## Abstract\n\nThis NIP defines a method for linking a Nostr public key (`npub`) to an external identity (bitcoin-otc nickname) via a self-attested cryptographic proof.\n\nThe proof consists of a signed assertion produced by the holder of an external cryptographic key (PGP or Bitcoin) binding that identity to a Nostr pubkey.\n\nThis enables offline-verifiable identity claims without external APIs, scraping, or trusted third-party verifiers.\n\n---\n\n## Motivation\n\nBitcoin-OTC is one of the earliest Web-of-Trust systems in the Bitcoin ecosystem, using PGP and Bitcoin-signed messages to associate persistent nicknames with reputation signals.\n\nThis identity space is not interoperable with Nostr.\n\nThis NIP enables:\n\n* Linking external bitcoin-otc identifiers to Nostr pubkeys\n* Preserving legacy identity associations as portable cryptographic claims\n* Offline-verifiable identity binding\n* Client-side interpretation without centralized attestation services\n\nThis NIP does not define bitcoin-otc as an authoritative registry.\n\n---\n\n## Specification\n\n### Event Kind\n\nThis NIP defines a parameterized replaceable event:\n\n```text\nkind: 37773\n```\n\nOnly the latest event per `(author pubkey, d tag)` is considered authoritative.\n\n---\n\n### Tags\n\n#### Required tags\n\n```json\n[\"d\", \"ext:bitcoin-otc:<nick>\"]\n[\"proof-type\", \"pgp\" | \"btc\"]\n```\n\n* `d`: External identity namespace and identifier being claimed\n* `proof-type`: Cryptographic method used to produce the signature\n\n---\n\n#### Optional tags\n\n```json\n[\"uri\", \"https://bitcoin-otc.com/viewratings.php?nick=<nick>\"]\n[\"key\", \"<pgp-fingerprint OR bitcoin-address>\"]\n[\"ts\", \"<unix timestamp>\"]\n```\n\nThe `key` tag, if present, MUST match the public key used to verify the signature.\n\nIt is informational and MUST NOT be used for any external identity resolution or validation.\n\n---\n\n### Content\n\nThe `content` field MUST contain the exact message that was cryptographically signed.\n\n#### Required format\n\n```text\nI, <external-identity>, assert control of Nostr pubkey:\n\n<npub>\n\nThis is a self-attested statement associating external identity \"<nick>\" with this Nostr identity.\n```\n\nImplementations MAY include a nonce to ensure uniqueness.\n\n---\n\n## Verification\n\nClients verifying this event MUST perform the following steps:\n\n### 1. Parse event\n\nExtract:\n\n* author pubkey\n* `d` tag\n* `proof-type`\n* `content`\n\n---\n\n### 2. Obtain verification key\n\nThe verification key MUST be provided either via the `key` tag or supplied by the verifier.\n\nNo external system (including bitcoin-otc) MAY be used to derive or infer the verification key.\n\n---\n\n### 3. Verify signature\n\n#### PGP\n\nVerify that `content` is a valid clearsigned PGP message under the provided public key.\n\n#### BTC\n\nVerify the Bitcoin Signed Message using standard Bitcoin message verification against the provided address.\n\n---\n\n### 4. Validate binding\n\nClients MUST ensure:\n\n* The event author pubkey MUST match the public key that verifies the cryptographic signature\n* The external identity string MUST be identical across the `d` tag and the signed message content\n* The cryptographic signature is valid\n* Client UI MUST reflect only the result of cryptographic verification and MUST NOT imply identity, registry, or external authority validation\n\n---\n\n### 5. Result\n\nIf all verification steps succeed, the event is considered cryptographically valid with respect to the supplied verification key.\n\nClients MUST NOT infer or imply validation of any external identity, registry, or authority from successful verification.\n\nClients MAY present the result of signature verification to the user.\n\n---\n\n## Replaceability\n\n* This is a parameterized replaceable event (PRE)\n* Uniqueness key: `(pubkey, d)`\n* Only the latest event per `d` is considered valid\n* Clients MAY display older events but SHOULD mark them as superseded\n\n---\n\n## Security Considerations\n\n### Replay resistance\n\nReplay attacks are not meaningful, as signatures bind the statement to the signing key. Reposting does not alter validity.\n\n---\n\n### Key rotation\n\nIf a user changes:\n\n* PGP key\n* Bitcoin address\n* Nostr key\n\nthey MUST publish a new event replacing the previous one.\n\n---\n\n### Trust model\n\nThis NIP introduces no trusted third parties.\n\nTrust is derived solely from:\n\n* possession of an external cryptographic key (PGP or Bitcoin)\n* possession of a Nostr private key\n\nThis NIP defines identity claims only and does not define verification of external registries.\n\n---\n\n### External dependencies\n\nThis NIP does not require:\n\n* bitcoin-otc API access\n* HTML scraping\n* CORS-enabled endpoints\n* OpenTimestamps\n* blockchain anchoring\n\nAll verification is performed locally by clients.\n\n---\n\n## Client behavior (optional)\n\nClients MAY:\n\n* indicate that the cryptographic signature was successfully verified;\n* display the claimed external identity;\n* display the proof method (PGP or BTC);\n* link to the external reference specified by the `uri` tag;\n* allow filtering or searching by external identity.\n\nClients SHOULD distinguish between successful cryptographic verification and validation of an external identity.\n\nClients MUST NOT present the external identity as verified by an external registry unless another protocol layer provides that guarantee.\n\n---\n\n## Example event\n\n```json\n{\n  \"kind\": 37773,\n  \"pubkey\": \"npub1xyz...\",\n  \"tags\": [\n    [\"d\", \"ext:bitcoin-otc:alice\"],\n    [\"proof-type\", \"pgp\"],\n    [\"uri\", \"https://bitcoin-otc.com/viewratings.php?nick=alice\"],\n    [\"key\", \"FINGERPRINT123\"]\n  ],\n  \"content\": \"I, alice, assert control of Nostr pubkey npub1xyz... This is a self-attested statement associating external identity \\\"alice\\\" with this Nostr identity.\",\n  \"sig\": \"...\"\n}\n```\n\n---\n\n## Rationale\n\nThis design:\n\n* avoids external dependencies\n* avoids verifier services and centralized attestation systems\n* enables offline verification of cryptographic claims\n* separates identity claims from registry validation\n* aligns with Nostr’s event-signed, client-interpreted model\n\n---\n\n## Changelog\n\n### v0.2.1\n\n* Separated protocol requirements from user interface recommendations\n\n### v0.2\n\n* Clarified trust model as self-attested cryptographic claim\n* Removed any implication of bitcoin-otc as an authoritative registry\n* Renamed terminology to “external identity” binding\n* Strengthened separation of claim vs verification authority\n* Refined client UI constraints to avoid semantic overreach\n* Preserved parameterized replaceable event structure\n* Retained PGP and Bitcoin message verification support\n\n---\n\n## References\n\n* [https://github.com/nostr-protocol/nips](https://github.com/nostr-protocol/nips)\n* NIP-01: Basic protocol flow\n* NIP-18: Reposts\n* NIP-33: Parameterized replaceable events\n* Bitcoin Signed Message Format (Bitcoin Core ecosystem)\n* RFC 4880: OpenPGP specification\n* [https://bitcoin-otc.com/](https://bitcoin-otc.com/)","sig":"c83fc7afa878764d0c9989f09505f8c05fd370797758a706b616507f530f05de950466e612a8dcfb77686e2933be4a462b1107fbfde558d2588d2af3b96a821a"}