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.
inkan's avatar inkan
I think we should timestamp "event_id + sig" That's what I've been doing for Inkan.
View quoted note →

Replies (2)

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"}
Constant's avatar
Constant 4 months ago
you are correct on the ID + Signature thing, i never realized that the consequence of ''The OpenTimestamps proof MUST prove the referenced e event id as its digest.'' would be that the signature could be made after the OTS proof was created for an event. The sollution should be simple i think, you could indeed use ID + Sig, submit that resulting hash to the timestampingserver, then when you get the proof back, add the sig to the merkleproof and thats it. As for the other stuff, The p-tag we already agree; The c-tag i can understand for querying and quick filtering purposes As for both the blockheight and the timestamp of the block.... I have to think it through, but i guess the point of OTS is that you need very little actual Bitcoin data, do verify the proofs. So the assumption is that you run a bitcoin client, but you dont have to store anything other than the merkle root and the blocktime. So given that info should be at hand anyway, its easy to get both blockheight and time. So the question is if both are usefull for indexing/querying purposes to warrent being in the event explicitly. Generally you want to reduce overhead as much as possible, because these kind1040 events are basically mostly just overhead already.