If NIP-3 is going to change, the most important thing to incorporate into the updated specification is that the item that gets timestamped must include both the *event_id* and the *signature* of the target event. I think including the signature is quite crucial. See below for discussion with @Gzuuus about this issue. The ideal shape for an OTS event should also include something like a p-tag for the pubkey of the target event, a c-tag for the created_at time of the target event, a b-tag for the bitcoin block that anchors the timestamp, and a t-tag for the time of that bitcoin block. I'm using OTS timestamping extensively as part of the Inkan key revocation and replacement system. The above is what I've concluded is needed after a lot of experimenting.

FYI, here is an example of an OTS event that I think has a genuinely useful shape: {"kind":31045,"id":"7093fe9f8c41bbb8164400b02602692bd231779683aed2df4015d35cf6983223","pubkey":"d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23","created_at":1773959239,"tags":[["d","dbe68638908a66bb601f681b5a92a41d9fd9683fb97330a1f6e7f8fe687b4277"],["p","d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"],["s","88a9c8fa5dd283ecbd279b4fa685e52538a56023e5b156888101e3bc110df10f10e18cc50929dc26c4357b8e1508eebc0690da6159bf29882f1233e2821efd2f"],["b","941226"],["t","1773885646"],["alt","Complete Bitcoin Timestamp"],["c","1773869515"]],"content":"AE9wZW5UaW1lc3RhbXBzAABQcm9vZgC/ieLohOiSlAEIF8ix1mwNjSi1x3QDaWiATLFG1FeFNwqUzUM2Dwrg0WnwEJqGZ+Q8rtYicUfEAW5jkT8I8CB8KXAv2mx0tQeLRWlZbL+kbJD6Ssxx4UrsMG1JtNeVzQjwCLOXttmKfifZCPAQ9UNbNUqqIUotzkiYUwu18gjwIMb81Y7BHsiD6bU8J3rGgosReKIpWZ78B2p8g0cC6qTZCPAgtabc7DMwqS1WLAy2OSaWKkUtkg8r34CgvKwlcVwVCYsI8CCSX0Z2KX7lq/OFyrcdZ0VbVfrMXqjnDMKQe68VTfB71AjxBGm7VFrwCOfo3bNvvtLu/wCD3+MNLvkMji4taHR0cHM6Ly9hbGljZS5idGMuY2FsZW5kYXIub3BlbnRpbWVzdGFtcHMub3JnCPEg2mZxBLwldRmJuuB21O0dKjsWofBWf+iwZGTnepTJfAYI8SATG/+UVekcsl3ctl6P/WpxlgiiJzWY2hbrdphFdieFEQjxIFjLlCaepfhN+V8DLt0YR3StDhipbg2CysJ4KPXik0C8CPAg0i7rEsb2vhLM4aArpzd5/AdzZw77ohKNRrJp5k6FuZAI8CAOlXet5AnHEr0Bbj03yJEuoE2vE07KYzzN66o5gNZg+gjxIK5RQVFLDfbf4rFYEFti8w1ZuvsnXm9OHU858GQlXZ+fCPAg9yDD1lmTqLNtNF8LyEsv/4rlrTixXOGemd95xkj1SIMI8SA5qNPArCPbagMK1SZcqOlZ1DIIx4gBqODIFDkHPlFc9QjwICC4oOB2zpJV6Dld2tqfKgDty5lLKkAtv5Qp/F+Oj9pkCPAg+CotBs1A7T/29J+wx0qyk0lpKJ13o2wbKkVYq3zlDGwI8VkBAAAAAQtrFQrxPs1mMb5QvPQggkThTuO35P4Z5BmBJ0GPCSUzAAAAAAD+////AmrTAQAAAAAAFgAUKeXwHpjozmyTVzqFtvo+hN6fdJcAAAAAAAAAACJqIPAEqVwOAAgI8SDlO0E2ZEReuEAXK64wU4gCtlACyaeWh5fJIzJFEolvJwgI8CDPx2heltL2U7BGCh/fubw9ZrsMfaT7EL92dwEfR1/CrwgI8SAUUtj8gA6ZEaJbiEAQYeDTPy7utv7SR1qcSsbZw9VWmggI8CDxMRe7nTdYmw4s+5LegP2Ys79vcqzowpBwxxI7pobpBggI8CADsy2twW7hhOWeH4wOPQETd83gIgm5RA8u6B5pWJ3bUAgI8SA6LixY6ofZMVzQBV0x6bG+nVOzVK1vyhZr9ej5iazYkAgI8CC7EpcskiXBYFW53WhYjwbCBC8T9qgUFKOE/ESO0WPU6wgI8SAtfcDaUyUnguG2MSzQwMKS0ha8FpU8BoDG7hK7DqEGYQgI8SBn3y+8o3STgJYcwd3fVa2x0uqBbYlao5g3CmLCfSq/iwgI8SA2sVBmSpaKZ2NPUn+dvoZEb0olcrvxF2eTLBV8uE10KAgI8SCtSpu38MlirqgD/dQxVOlYtzGjV/VyCf6yZHINuW1BVQgI8CBBIrMQvkQOzs4H6Huhuu6aSO24eMoq6wnWqj4RDabOLwgI8CBvE1xbeLllbcHoy6YdR5HUOgh8sCDp18jJCjmROp36RQgIAAWIlg1z1xkBA6q5OQ==","sig":"2aa6c46117b27171a5aab7e72266ec603402746cea74ab83ebf467d6ad4589b629e1640b94ae55a552aed6674fd098c686d1930bca8464a68ba8ffe2cc27891b"}

Thanks, I think including the signature will be a crucial improvement to NIP-3. FYI, for the example 31045 event that I pasted below, here's the string that was hashed for timestamping: {"ID":"dbe68638908a66bb601f681b5a92a41d9fd9683fb97330a1f6e7f8fe687b4277","sig":"88a9c8fa5dd283ecbd279b4fa685e52538a56023e5b156888101e3bc110df10f10e18cc50929dc26c4357b8e1508eebc0690da6159bf29882f1233e2821efd2f"} And here is the hash that was timestamped: 17c8b1d66c0d8d28b5c774036968804cb146d45785370a94cd43360f0ae0d169 You can verify this using the OTS proof in the content field of the event. If you're interested, I'm happy to send a quick script that produces this string and the hash from a given event_id and sig pair. In my above list of tags that I recommend be included, I had forgotten to mention one: I think an s-tag for the signature of the target event should be included as well. This is necessary to be able to verify the "internal consistency" of the OTS event without needing to fetch the target event. The 31045 sample event I sent you includes this tag. A few further thoughts on including p-tag, c-tag, s-tag, b-tag, t-tag : While working on Inkan I was frequently running into situations where I needed timestamp information quickly without fetching the target event and without doing a verification against Bitcoin. I realized that, in some circumstances, you can make limited trust assumptions regarding OTS events that are signed by trusted keys. Often you will trust the signer of the target event already to some extent, and if the OTS event is signed by the same signer, you can tentatively trust the content of the OTS event to a certain extent. For that reason, reading info like bitcoin block and bitcoin timestamp directly from tags in the OTS event can be quite helpful in practice in certain situations. And if there are any doubts as to the correctness of that information, you can always audit it against Bitcoin.

Actually the signature is *not* in the proof, and you can't extract it from the proof. Only a hash of a string that combines the event_id and the signature is in the proof. Including the signature in a tag is not redundant. To verify that the proof in the content field of the OTS event is consistent with the information provided in the tags, you do need both the "d" tag for the target event ID and the "s" tag for the target event signature. Or otherwise you'll have to fetch the target event to inspect its signature, which can under some circumstances be inconvenient. I wish I had realized these things earlier while working with these events, would have saved me a lot of hours ...

you can just extend the proof is what i am saying. You submit the hash of the id+sig, and when you get the proof back from the Timestamp server, you just add the sig to the merkle proof, extending it 1 step. The proof still resolves to the event ID, but the first step in the proof is now the signature

As for this: "Side not on that; when comparing times, the time of the original event might be later than the time of the block the proof for that event refers to, because blocktime is fuzzy, so people should take such edgecases into account." Agree that the target event's created_at being later than the time of the block that encodes the proof is not a problem. The only problem is if the time of the block is much later than the created_at of the target event. In Inkan, I let users manually set the maximum permitted time differential between the created_at of the target event and the time of the block that records the event. The default setting is 4 hours. If the time differential is greater than that, the target event gets filtered out.

I'm not completely following these two bits: -- "you just add the sign to the merkle proof, extending it 1 step" In what sense can one manually "add" a signature to a merkle proof? Not sure how this is supposed to work. -- "The proof still resolves to the event ID" If, as you seem to stipulte above, you "submit the hash of the id-+sig", then the proof will not resolve to the event ID. It will resolve to a hash of the id+sig. Neither the ID nor the sig can be reconstructed from that hash. However, if you already have the id+sig, you can reconstruct the hash from these.

a signature is just the same 32byte string as a hash would be, so you can just pretend its a hash in the proof. The proof you get back from the timestampserver indeed goes to the ''id+sig'-hash, and then when you get that proof you just slap the last part, that is the sig, onto the proof.

But what is the purpose of slapping the signature onto the proof? I mean nothing further gets recorded on Bitcoin or otherwise proven by appending the signature to the proof, as far as I can see? So why would one want to do so?

the signature is recorded in bitcoin, its part of the merkletree due to the fact that you submitted ID + SIG, like you would with all the other pairs in the merkletree

I agree that the signature is recorded on Bitcoin in the sense of its being (together with the event_id) merkle-included in the hash that's placed in the relevant Bitcoin block. Of course you cannot re-construct the signature from the merkle root that's recorded on Bitcoin. But the above does not explain what purpose would be served by "appending" the signature to the OTS proof. I mean an OTS proof in human-readable form looks like the below - what would be achieved by appending the signature to that?