After the edit window closes on a post/comment, we now timestamp posts/comments in the timechain using OpenTimestamps. The resulting proof allows stackers to know a piece of content is at least as old as the bitcoin block that it's in. While maybe not super or immediately useful for SN, it's pretty cool.

This only applies to content created from this point forward so long as it's a post or the child of a post that's been timestamped. We might at some point timestamp historical content but we don't yet. We also don't upgrade timestamps to be independently verifiable, instead relying on the calendars we submitted the hashes to.

How this works:

  1. After the edit window closes, we sha256 hash a canonical json object of the post/comment.
    • the preimages of comments include the hash of their parent
  2. We then send this hash to OTS for timestamping.
  3. At this point, you can view the OTS info by appending /ots to the item's path
    • if you attempt to view the OTS info before we've submitted the timestamp or on a piece of content that wasn't timestamped, you'll 404
    • because when we delete items we actually delete them, the preimage is not available on deleted items ... however, the hash and the resulting timestamp is kept
  4. You can download both the preimage and the ots file and verify the timestamp for yourself.

We might at some point make it easier to see the ots info, but for now you'll need to do the url stuff.

Assuming the edit window on this post has closed, you can view the timestamp.

related

I wonder if you're hashing images... Let's try:

OpenTimestamps

...and no:

1{"parentHash":"e945eca22d6a5bddfcd30b7328ae80635a4ceaf0ff3a0cb7726197edcb0fabfd","text":"I wonder if you're hashing images... Let's try:\n\n![OpenTimestamps](https://opentimestamps.org/assets/images/logos@2x.png)","title":null,"url":null}

I guess it doesn't make much sense while you're not hosting images. But it would definitely be better if images were hosted on stacker news and hashed.

Yes agreed. Those images can be changed

Maybe hashing the full raw markdown including image urls would help?

That's how it already works. The problem is URLs aren't cryptographic, so you can change the contents without breaking them. Though I vaguely recall there being an extension to HTML that fixes this.

10 sats \ 0 replies \ @nout 23 Jan

Oh, you are right, I mis-read the JSON.

Who pays for the on-chain OTS transactions?

Wouldn't this introduce an attack vector for someone wanting to financially harm Stacker News?

195 sats \ 1 replies \ @k00bOP 22 Jan

OpenTimestamps does - afaict each calendar only has one small tx per block as they are only submitting the merkle root of everything they're timestamping.

We don't need or rely on OTS for anything critical. This is just for fun ... OTS is way ahead of its time and we probably aren't the ideal end user.

That's correct. The four calendars are all funded by donations. You can see the donation addresses on the status pages of the calendars, eg mine: https://alice.btc.calendar.opentimestamps.org/ and https://bob.btc.calendar.opentimestamps.org/

To reinforce your point: "everything" really is everything. Via the magic of merkle trees the entire world can use a single transaction.

LETS. FUCKING. GO.

Awesome.

And in the future, the only thing we will trust is signed, and by extension, timechained.

only thing we will trust is signed

I mean, it would be good if stacker.news also signed items/comments as well as timestamping them...

Cool!

Suggestion: just use the term "message" or "item" instead of "preimage" on the /ots page. The term "preimage" doesn't really suggest what you're actually doing.

any particular reason that the preimage json doensn't include the author?

The author can change their nym. I thought it best to include things that weren’t possible to change under normal circumstances.

50 sats \ 1 replies \ @nout 23 Jan

Cool! Maybe add a link to /ots in the "flag" dropdown? ("Show verified timestamp" could be a label)

Yes I think that's where it belongs in the long run.

0 sats \ 0 replies \ @pi 23 Jan

Nice!

Nice work! Solid developments on a road the further improvements. OTS info would be great as well. Keep going!

deleted by author

deleted by author

When you delete, you delete the pre image. The hash is still timestamped, viewable, and verifiable.

Eg if I say something regarded, you can store the pre image yourself if you’d like, and prove to people it was said when it was said regardless of its deletion status.

Note from the preimage in some cases someone could brute-force the deleted message. You could fix this by creating a 128-bit nonce for every item and including that nonce in the hashed data - OpenTimestamps itself does to prevent the OTS calendars from learning anything about what is being timestamped.

Correction: from the hash digest of course. Not the preimage. That doesn't need bruteforcing!

0 sats \ 0 replies \ @ama 23 Jan

Outstanding!

How do you see the item number of a comment?

Click on the time, e.g. 35m, or the 1 replies.