Using roughtime as a “cryptographic notary”
blog.merovius.de
blog.merovius.de
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.
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.
Oh god, I can only imagine the horror of trying to use Bitcoin as a public notary service.
The whole point of an append-only data structure is that you can replicate it and if someone's node is being dishonest, they cannot do so silently.
You'd be better off with something like Trillian (and/or Certificate Transparency; see https://wiki.mozilla.org/Security/Binary_Transparency for more).
I wrote something in this vein called Chronicle: https://github.com/paragonie/chronicle
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.
Isn't Trillian just a simple Merkle tree implementation?
And if so, how does it solve the decentralization part?
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.
One man's trash is another man's treasure: http://deedbot.org/faq.html
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 :)
I thought I invented them when I sketched this PoC a long time ago:
https://github.com/Miserlou/CitizenMediaNotary
but blockchains blew up since then and made my design irrelevant.