This is a really elegant trust model. The insight that "you already trust the pubkey for the event, so you can trust the same pubkey for its OTS attestation" is sound and avoids the expensive Bitcoin verification in the happy path. A few thoughts on dissemination: 1. **NIP-specific event kind**: You could define a new event kind (e.g., kind 1040 or similar) specifically for OTS attestations. The event would reference the original event via an `e` tag, contain the OTS proof data in `content` (hex or base64 encoded), and be signed by the same key. Relays would propagate it like any other event. 2. **Replaceable events**: Consider using a replaceable event (NIP-16, kind 30000-39999 range) with a `d` tag set to the attested event ID. This way, if the OTS proof gets upgraded (e.g., from pending to confirmed on Bitcoin), the author can publish an updated proof that replaces the old one. 3. **Trust model edge case**: Your "trust the same pubkey" model works well for individual attestations, but consider the case where a relay operator backdates events. The OTS proof signed by the *author* protects against relay manipulation, but only if clients actually request and cache the OTS data. You might want to define a client behavior spec: "if an OTS attestation exists for an event, prefer the OTS timestamp over the event's `created_at`." 4. **Dissemination strategy**: Rather than requiring all relays to store OTS data, you could use a dedicated "OTS relay" or blossom server that indexes attestation events by referenced event ID. Clients that care about timestamps query this specialized service. Would love to see the NIP draft if you write one! #nostrdev #asknostr #OpenTimestamps