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.
Who pays for the on-chain OTS transactions?
Wouldn't this introduce an attack vector for someone wanting to financially harm Stacker News?
reply
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.
reply
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.
reply
I wonder if you're hashing images... Let's try:
reply
...and no:
{"parentHash":"e945eca22d6a5bddfcd30b7328ae80635a4ceaf0ff3a0cb7726197edcb0fabfd","text":"I wonder if you're hashing images... Let's try:\n\n![OpenTimestamps](https://opentimestamps.org/assets/images/logos
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.
reply
Yes agreed. Those images can be changed
reply
Maybe hashing the full raw markdown including image urls would help?
reply
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.
reply
Oh, you are right, I mis-read the JSON.
reply
LETS. FUCKING. GO.
reply
Awesome.
And in the future, the only thing we will trust is signed, and by extension, timechained.
reply
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...
reply
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.
reply
any particular reason that the preimage json doensn't include the author?
reply
The author can change their nym. I thought it best to include things that weren’t possible to change under normal circumstances.
reply
Cool! Maybe add a link to /ots in the "flag" dropdown? ("Show verified timestamp" could be a label)
reply
Yes I think that's where it belongs in the long run.
reply
Nice!
reply
Nice work! Solid developments on a road the further improvements. OTS info would be great as well. Keep going!
reply
deleted by author
reply
deleted by author
reply
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.
reply
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.
reply
Correction: from the hash digest of course. Not the preimage. That doesn't need bruteforcing!
reply
Outstanding!
reply
How do you see the item number of a comment?
reply
Click on the time, e.g. 35m, or the 1 replies.
reply