[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/hashtag",{"_7":8,"_9":10,"_11":12},"articles",[13],"authors",{},"tag","otsuite",{"_14":15,"_16":17,"_18":19,"_20":21,"_22":23,"_24":25,"_26":27},"content","NIP-3B\n======\n\nOpenTimestamps over Signed Events\n---------------------------------\n\n`draft` `optional`\n\nThis NIP defines a Bitcoin time-attestation scheme for Nostr events that\nbinds the attestation to the **signed** event — i.e. the event id together\nwith the Schnorr signature — instead of the canonical event id alone.\n\nIt also specifies a non-canonical, in-event JSON transport for the proof\n(\"side-car\"), so a single network roundtrip can carry both the signed event\nand its time-attestation. As a courtesy to legacy consumers it includes a\ndemo profile that re-uses the same transport for [NIP-03] proofs.\n\nThis NIP is a *companion* to [NIP-03], not a replacement: NIP-03 proofs\nremain interoperable; clients that wish to keep them MAY still produce or\nconsume kind:1040 events. NIP-3B specifies what to do when you want a\nproof that actually attests the signature.\n\n## Why a new scheme\n\n[NIP-03] specifies an OpenTimestamps proof over `event.id`:\n\n> The OpenTimestamps proof MUST prove the referenced `e` event id as its\n> digest.\n\n`event.id` is `sha256(canonical_serialization)` — i.e. the canonical fields\n`[0, pubkey, created_at, kind, tags, content]` hashed. Since the signature is\nnot part of that hash, an OTS proof of `event.id` says nothing about when the\nsignature was produced. An attacker holding a pre-existing canonical event\nserialization can forge a Schnorr signature over the same id at any later\nmoment; the original NIP-03 proof would still verify, even though the signed\nevent \"did not exist\" in any meaningful Nostr sense at the attested time.\n\nTo bind time-attestation to the signed event itself, NIP-3B uses a leaf\ndigest that commits to **both** the canonical id and the signature:\n\n```\nleaf = sha256( event.id_bytes || event.sig_bytes )\n```\n\n`event.id_bytes` is the 32-byte hex-decoded id; `event.sig_bytes` is the\n64-byte hex-decoded Schnorr signature. The OTS proof is built over those 96\nbytes hashed.\n\nBecause Schnorr signatures over `secp256k1` cannot be forged without the\nprivate key, an OTS proof of `sha256(id || sig)` proves that BOTH the id and\na valid signature over it existed before the attested Bitcoin block.\n\n## Transport\n\nNIP-3B specifies two transports for the same proof. They are interoperable\nand either may be used; relays / clients SHOULD support both on read.\n\n### A. Kind 1041 — \"OpenTimestamps Attestation over Signed Event\"\n\nA regular event whose `content` carries the base64-encoded `.ots` blob:\n\n```json\n{\n \"kind\": 1041,\n \"tags\": [\n [\"e\", \"\", \"\"],\n [\"k\", \"\"],\n [\"p\", \"\"],\n [\"digest_alg\", \"id+sig\"]\n ],\n \"content\": \"\"\n}\n```\n\nThe `.ots` blob's leaf digest MUST equal `sha256(target.id_bytes || target.sig_bytes)`.\n\nTag rules:\n\n- `e` (REQUIRED) — the target event id (64 hex chars). The third element is\n an optional relay-url hint per [NIP-01].\n- `k` (REQUIRED) — the target event's kind, as a decimal string.\n- `p` (REQUIRED) — the target event's pubkey (64 hex chars).\n- `digest_alg` (RECOMMENDED) — `\"id+sig\"`. Reserved for future schemes.\n\nThe `content` field MUST be the base64-encoded full bytes of an `.ots` file.\nThe file SHOULD contain a single Bitcoin attestation; pending calendars\nSHOULD be elided in published copies (clients that produce calendar-pending\nproofs SHOULD upgrade and re-publish, or keep them in private storage until\nupgraded).\n\nThis is parallel to NIP-03's kind:1040, with three differences:\n\n1. The leaf digest is `id || sig` instead of `id` alone.\n2. The `digest_alg` tag is REQUIRED to distinguish the schemes when both\n appear (a relay holding both 1040 and 1041 attestations for the same\n target is normal during migration).\n3. The `p` tag is REQUIRED so consumers can resolve the target pubkey\n without looking up the original event.\n\n### B. In-event side-car (`ots_proof`)\n\nWhen the publisher of an event holds a proof for that same event, the proof\nMAY ride along inside the event's JSON as a top-level field:\n\n```json\n{\n \"id\": \"\",\n \"pubkey\": \"\",\n \"created_at\": 1234567890,\n \"kind\": 1,\n \"tags\": [],\n \"content\": \"the post\",\n \"sig\": \"\",\n \"ots_proof\": \"\",\n \"ots_alg\": \"id+sig\"\n}\n```\n\n`ots_proof` and `ots_alg` are NOT part of the canonical signing input and\nare NOT inside the `tags` array. The signature is computed over only\n`[0, pubkey, created_at, kind, tags, content]` exactly as in [NIP-01].\n\nThe `.ots` file's leaf digest MUST equal `sha256(id || sig)` of the same\nevent. `ots_alg` MUST be `\"id+sig\"` for the scheme defined in this NIP;\nthe field is reserved so future schemes can carry the proof in the same\nslot without ambiguity.\n\nThe side-car MAY be stripped by any relay or client that does not wish to\ncarry it. Stripping leaves the canonical signed event intact; the\nsignature continues to verify; only the time-attestation is lost. This\nmakes the side-car opportunistic by design: a publisher SHOULD also\nproduce and broadcast a kind:1041 event so the proof can be obtained out\nof band when the side-car is not available.\n\nA relay or client that wishes to retain side-cars across writes SHOULD\nemit them on outbound EVENT frames whenever the consumer has signalled\nsupport — for example via a connection-time hint (`?ots_sidecar=1` is a\nreasonable convention). When no such signal is present, the relay SHOULD\nemit canonical events unchanged so unaware Nostr clients keep working.\n\n## Verification\n\nA NIP-3B proof is valid when ALL of the following hold:\n\n1. The signed event verifies under [NIP-01] (canonical id + valid Schnorr\n signature).\n2. The proof's `.ots` file deserialises and walks to a Bitcoin block\n header against the verifier's local chain (no external trust required;\n any standards-compliant OpenTimestamps verifier suffices).\n3. The leaf digest the proof commits to equals\n `sha256(event.id_bytes || event.sig_bytes)` for the kind-1041 form, or\n `sha256(id || sig)` of the carrying event for the side-car form.\n\nEach consumer SHOULD verify independently with its own miniots / OTS\nverifier and its own Bitcoin headers store. Consumers MUST NOT rely on a\nrelay's accept-rules as a substitute for verification.\n\nThe earliest Bitcoin block height across a verifying proof's attestations\nis the canonical \"this signed event existed by block N\" claim. When more\nthan one valid NIP-3B proof exists for the same event, consumers SHOULD\ntake the **earliest** block height as the canonical attested time.\n\n## Demo profile: NIP-03 over the side-car transport (`oldnostrots`)\n\nTo exercise the in-event side-car *transport* with the existing fleet of\n[NIP-03] kind:1040 attestations, this NIP optionally specifies a second,\nnon-canonical field on the event JSON:\n\n```json\n{\n \"id\": \"...\", \"pubkey\": \"...\", ..., \"sig\": \"...\",\n \"oldnostrots\": \"\"\n}\n```\n\n`oldnostrots` carries an OTS proof whose leaf digest commits to\n`event.id` ALONE (the legacy NIP-03 scheme). A consumer that already\nholds a kind:1040 event referencing some target event MAY repackage the\nproof into the side-car format by emitting the canonical target event with\nthe `oldnostrots` field added.\n\nThis is **explicitly a demo of the transport, not of the digest scheme**.\nA proof in `oldnostrots` does not bind the signature and inherits the\nNIP-03 weakness described above. It exists so:\n\n- Existing NIP-03 attestations can be transported alongside their signed\n events without introducing kind:1041 events that would re-attest under\n a stronger scheme they cannot satisfy.\n- Implementers can validate the in-JSON side-car transport end to end —\n publishing, relay storage, on-the-wire reattach, downstream verification\n — using the existing corpus of Bitcoin-confirmed NIP-03 proofs.\n\nA consumer MAY treat `oldnostrots` as a \"this event id existed by block N\"\nhint, but MUST NOT treat it as a binding time-attestation of the\nsignature. New deployments SHOULD always use `ots_proof` (id+sig) and not\n`oldnostrots`.\n\n`ots_proof` and `oldnostrots` MAY appear on the same event. When they do,\neach is independently verifiable; verifiers SHOULD prefer `ots_proof`.\n\n## Redundant-attestation cleanup\n\nBecause OTS proofs accumulate calendar-pending stubs and may carry multiple\nBitcoin attestations, an in-event side-car blob can be considerably larger\nthan the minimal proof needed to verify the attested time. A side-car\nholder MAY prune the proof by:\n\n1. Re-running the OTS proof through any pruner that retains the earliest\n verifying Bitcoin attestation and discards pending calendars and later\n attestations.\n2. Replacing the `ots_proof` (or `oldnostrots`) value with the pruned\n bytes.\n\nThe `event.id`, `pubkey`, `tags`, `content`, and `sig` MUST remain\nunchanged. The pruned proof MUST still verify against the same leaf\ndigest. Consumers receiving a pruned proof for an event whose unpruned\nform they previously held SHOULD prefer the smaller blob (the pruned form\nis strictly more compact while semantically equivalent).\n\n## Comparison with NIP-03\n\n| Property | NIP-03 (kind:1040) | NIP-3B (kind:1041) | NIP-3B (side-car) |\n| --------------------------------------- | ------------------ | ------------------ | ----------------- |\n| Leaf digest binds event id | yes | yes | yes |\n| Leaf digest binds Schnorr signature | **no** | **yes** | **yes** |\n| Separate Nostr event for the proof | yes | yes | no |\n| Carried inside the target event JSON | n/a | n/a | yes |\n| Removable per relay / per client | yes (own event) | yes (own event) | yes (just strip) |\n| Verification needs external lookup | yes (target event) | yes (target event) | no |\n\nNIP-03 and NIP-3B are not in conflict; both kinds may coexist on the same\nrelay for the same target event. Consumers SHOULD prefer NIP-3B when both\nschemes claim the same target.\n\n## Migration\n\nFor a target event already carrying a NIP-03 attestation, the publisher\nMAY:\n\n- Continue to publish NIP-03 kind:1040 events.\n- ADDITIONALLY publish a NIP-3B kind:1041 event whose `.ots` proves\n `sha256(id || sig)` of the same target.\n- ADDITIONALLY include `ots_proof` (NIP-3B) and/or `oldnostrots` (the\n NIP-03 demo profile) on the target event when re-broadcasting it.\n\nThere is no requirement to retract NIP-03 attestations. They remain\nvalid as id-only timestamps; they simply do not provide the stronger\nsignature-binding guarantee NIP-3B does.\n\n## Examples\n\n### Kind 1041 attesting a kind 1 note\n\n```json\n{\n \"kind\": 1041,\n \"id\": \"53a3a26844ac13ceb677c73bf3463650bd9681c080eb4bee574d252ff33be298\",\n \"pubkey\": \"6d7124d023574010cd5d3aea61b262a2b96e9dff41889102d2c34a058a859ec2\",\n \"created_at\": 1778100210,\n \"tags\": [\n [\"e\", \"7e0c8cbe361180827fe9ee2f4b7658218ded36838e9009216ebd793e92532e29\",\n \"ws://127.0.0.1:4849\"],\n [\"k\", \"1\"],\n [\"p\", \"6d7124d023574010cd5d3aea61b262a2b96e9dff41889102d2c34a058a859ec2\"],\n [\"digest_alg\", \"id+sig\"]\n ],\n \"content\": \"AE9wZW5UaW1lc3RhbXBzAABQcm9vZgC/...\",\n \"sig\": \"...\"\n}\n```\n\nThe `content` is the base64-encoded `.ots`. Its leaf digest equals\n`sha256(\"7e0c8cbe...\".bytes || \"\".bytes)`.\n\n### Kind 1 with `ots_proof` side-car\n\n```json\n{\n \"id\": \"97369303c3119d0f06fe0b11043ccd24db6a4910c8c1c44f8c332ce7a9735210\",\n \"pubkey\": \"6d7124d023574010cd5d3aea61b262a2b96e9dff41889102d2c34a058a859ec2\",\n \"created_at\": 1778115277,\n \"kind\": 1,\n \"tags\": [],\n \"content\": \"OTSuite end-to-end via supervisor\",\n \"sig\": \"...\",\n \"ots_proof\": \"AE9wZW5UaW1lc3RhbXBzAABQcm9vZgC/...\",\n \"ots_alg\": \"id+sig\"\n}\n```\n\nThe signature is over `[0, pubkey, created_at, kind, tags, content]` per\n[NIP-01]; `ots_proof` and `ots_alg` are outside that scope. The `.ots`\nfile's leaf digest equals `sha256(id || sig)`.\n\n### Kind 1 with the demo `oldnostrots` field (legacy id-only)\n\n```json\n{\n \"id\": \"430bf2069503bae5af8bc0514d73a8aa0ed6d8fd616e2048599a82b88e818530\",\n \"pubkey\": \"...\",\n \"created_at\": 1778097096,\n \"kind\": 1,\n \"tags\": [],\n \"content\": \"...\",\n \"sig\": \"...\",\n \"oldnostrots\": \"AE9wZW5UaW1lc3RhbXBzAABQcm9vZgC/...\"\n}\n```\n\nThe proof commits to `event.id` alone — see the warning in the demo\nsection above. New deployments SHOULD use `ots_proof` instead.\n\n## Implementation notes\n\n- A relay that strips unknown top-level fields will discard side-cars; the\n signed event remains intact. Side-cars are opportunistic.\n- A relay that wishes to preserve side-cars across writes SHOULD store the\n proof bytes by event id in its own storage and reattach them on outbound\n EVENT frames when the subscriber has signalled support. A simple HTTP\n side-channel (e.g. `GET /sidecar/` returning the raw `.ots`)\n is also a reasonable transport for consumers that don't want to opt in\n on the WS layer.\n- The proof in the side-car SHOULD be identical to the proof in the\n matching kind:1041 event when both exist. A consumer that finds two\n proofs for the same target SHOULD reject any inconsistency\n (different leaf digests, different earliest Bitcoin heights) and\n prefer the verified one.\n- For verification, consumers SHOULD use a local Bitcoin headers store\n rather than trusting a third party. Each verifying component in a\n pipeline SHOULD perform its own check.\n\n## References\n\n- [NIP-01] Basic protocol flow description\n- [NIP-03] OpenTimestamps Attestations for Events\n- [OpenTimestamps] Bitcoin-anchored time attestations\n\n[NIP-01]: 01.md\n[NIP-03]: 03.md\n[OpenTimestamps]: https://opentimestamps.org/","created_at",1778123870,"id","30b085031e3fb85956741c54f7416d2b74eb11614fbefa2aab43a33db5c20345","kind",30023,"pubkey","6d7124d023574010cd5d3aea61b262a2b96e9dff41889102d2c34a058a859ec2","sig","ed49d2fc2d91286fe4f08deb4ceacb022e91cf53303a64ececa761b7c1000ad8ae53698bf516a4d89dea49042bb22095e8de6f09382c4221f2904752000beff1","tags",[28,29,30,31,32,33,34,35,36],[48,49],[46,47],[44,45],[42,43],[37,41],[37,40],[37,39],[37,38],[37,12],"t","bitcoin","opentimestamps","nip","nostr","published_at","1778123855","summary","OTS attestations that bind both event.id AND the Schnorr signature, plus an in-event JSON side-car transport. Companion to NIP-03 (which only commits to event.id).","title","NIP-3B — OpenTimestamps over Signed Events","d","nip-3b-otsuite-draft"]