Doesn't the bitcoin blockchain provide the same service roughtime does, and without the centralized authority (cloudflare in this case) problem?
As in : hash your doc, create a TX with that hash somewhere in it, sending money to yourself, and once the TX is on chain, the block hash is your timestamp.
The downside are the fees, and the 10mn delay, of course.
[edit]: now that I'm reading about roughtime, I see that the intent is completely different (secure clock sync). However, if the plan is to use roughtime for notarization of documents, I think my remark stands.
> without the centralized authority (cloudflare in this case) problem?
I don't consider it a problem. But FWIW, you can use an arbitrary set of servers - all this is establishing is a relationship between some public keys and the hash. So there isn't really a centralized authority. I would even argue that it's tolerant to byzantine failures, given that the servers cross-certify responses, so misbehaving servers can be weeded out with high probability.
I don't think there is an advantage to using a blockchain but there downsides - and as CiPHPerCoder mentions there are a lot of those.
Your mileage may vary, aka it very much depends on the problem you're dealing with.
For example, if you're in the news and/or wikileaks-type problem sphere and want to timestamp a certain event, then a centralized authority for a crypto notary is a giant problem.
Main selling point? It's not a blockchain, but it solves a lot of the problems that cause people to point to blockchain solutions.
My goal with Chronicle is to ween the industry off of poorly thought-out blockchain projects by demonstrating that they don't need a blockchain after all.
Is decentralization necessarily a desirable trait of such a system?
When you throw that in the mix, you sacrifice either security or efficiency.
I'd rather have a centralized system (single writer) with decentralized mirrors (notaries) that exploit the fact that cryptoraphic ledgers are append-only and totally transparent to solve a lot of engineering problems than a slow, energy-sucking blockchain.
The two caveats of the blockchain is that it's really large, and you don't get much precision it. I'll admit though that not all applications need a lot of precisions, and if you need additional precision you can use good old unauthenticated NTP and cross-check with the time you got from the blockchain.
The Bitcoin blockchain requires mining to solve double-spend - it's computationally infeasible to convince some subset of the network that you're spending a coin in one way, and also another subset of the network that you're spending the same coin in a different way. Notarization doesn't have a double-spend problem because there's no concept of "spending" - if you get the same document notarized by multiple people, that's perfectly fine.
And because of that, you don't have a centralized authority problem. If you don't think people trust Cloudflare, have other Roughtime services sign your message. Each one adds additional confidence that the message was seen before a certain time.
(Because you don't need mining to solve double-spend, you can do this without the effective requirement that any trustworthy Bitcoin-style blockchain must consume a significant fraction of computational power / useful energy in the known universe.)
> It also comes with a client implementation of the roughtime protocol in Go - initially I was not aware that there already was a Go implementation, but that also is not go-gettable. Either way, it was fun to implement it myself :)
As in : hash your doc, create a TX with that hash somewhere in it, sending money to yourself, and once the TX is on chain, the block hash is your timestamp.
The downside are the fees, and the 10mn delay, of course.
[edit]: now that I'm reading about roughtime, I see that the intent is completely different (secure clock sync). However, if the plan is to use roughtime for notarization of documents, I think my remark stands.
source: https://blog.cloudflare.com/roughtime/