API to get recent probable permanent block hash

[weex]

In order to provide an early bound on a piece of content, a known block hash can be included in timestamped data. I see the home page lists best block but didn't find an API to get that from OTS. Taking into account reorgs, it would also be useful to get a block hash 6 or 12 blocks from best.

Running a bitcoin node is an alternate way to get this info but I'm not sure if a lightweight client in java that downloads headers only would be much of an improvement over trusting ots servers to report these block hashes.

The other question is, would this APIs be accepted here if a quality PR were submitted?

[petertodd]

So the tricky thing about this is actually using that block hash: random beacons need to be carefully integrated into your data structure to actually be worthwhile. For instance, just putting a random beacon in a file doesn't do much, as you could keep on regenerating the file over and over again. Committing to a random beacon via a signature OTOH does work (something Qubes actually does for their canaries).

I'm hesitant to add API's for this use-case due to how tricky they are to actually make use of; we already have enough issues with users misunderstanding what timestamps actually can do. I think it'd be better to do this as a stand-alone library, preferably integrated into some verification scheme like verifying that a random beacon hash is signed by, say, a PGP signature and making it clear in the API/UI what exactly is being proven.

[cisba]

I sketched a standalone tiny service that provides the merkle root given the height of a block, in order to verify an ots. But I have been reluctant to PR it as a new API of opentimestamp-server for a similar reason. To seriously verify an ots you must necessarily retrive the merkle root of the block from a node you trust.

However, I found recently in the java opentimestamps client a function that queries a bunch of block explorer to verify the ots. if instead a client verified an ots calling the calendar pool instead of block explorers, would it not be more reliable and consistent?

[weex]

I appreciate the confusion about what timestamping accomplishes but also think there's value in adding an early bound on a timestamp to complete the mental model that people have to get. To help make that clear a signature requirement could be added if someone wanted to use an early bound.

My use case would have this block hash and other content signed by software with a key that is associated with a device and by extension a content creator. For that reason, I want to automate getting these hashes trustlessly if possible.

@petertodd When you say standalone-library, do you mean one whose purpose is limited solely to verifying that a block hash exists in the blockchain?

@cisba I noticed the latest block hash is shown on each server's home page so that's what gave me hope here. If this is useful to the timestamping function, I think it's better to query a maintained pool rather than hardcode block explorers. If not in OTS, I'll look more for a header's-only Bitcoin client library.