Hi,
I've released an ethereum smart contract + a client app for creating and verifying trusted timestamp on the ethereum blockchain. The service works in a similar way than BTProof [0] but using a generic/turing-complete blockchain makes it more efficient and cheaper for the user. Basically the idea is to calculate the `sha256sum` of a given file and then submit a transaction to the contract containing this hash. The contract goal is to associate the hash to the block timestamp, which is literally three lines of code [1].
With the latest C++ ethereum client (the `develop` branch) open
http://ethereum-chronos.meteor.com in the embedded web browser. Then you can simply drag and drop a local file. If a *proof of existence* exists in the blockchain for this file, the application will show you the associated date. Otherwise, a single click button will allow you to create such proof. As the contract, the app is open source and available on github [2].
I have attached some screenshots of the application, feel free to share your thoughts!
[0]
https://www.btproof.com/[1]
https://github.com/mquandalle/chronos/blob/master/contract.lisp[2]
https://github.com/mquandalle/chronos/tree/master/client
Comments
[0] https://github.com/meteor/meteor/blob/devel/packages/deps/deps.js
For instance hypothetically there could be graph of how things are derived from each other exists. Basically you'd timestamp a document, and tell a list of things it claims it derives from. Then others come and judge that, or say 'no, he plagiarized this other timestamp' or just 'derives from this too'.(the tricky bit is how to incentivize correct assessments and scalability of ethereum) The idea being that a system gathering payment(for advertising)/donations would send coin downstream.
Think that actually fits in one contract, but if that contract could talk to chronos, it could take over the timestamps. Perhaps there are other approaches too, for instance publication DAOs wishing to allow some guarranteed methods to report plagiarism.(feel those may be weaker though)
You may be interested in this thread of mine. I have not thought about 'linking', or what the effect should be at all yet!
But as said i do worry about the scalability of ethereum if used for things that are really quite granular. Essentially everything you do is a transaction.. I expect that the ethereum network will cope by increasing the fees, possibly making the 'business model' of some contracts inpractical.
Different approaches put different 'weight' on the system. For instance in the 'Publishing DAO' i suggest in the link probably weighs quite a bit less than the idea where you try illuminate who created what content. There are also tricks, like side chains, and probably more approaches that for instance use Merkle trees.
Currently only have the quite possibly infeasible idea to try measure the extent works are derivative of each other, and couple it with sort-of automatic monetization, and feeding back the profits to creators. But i cant tell if that is the end of the uses. (hmm maybe should look at as if there is an oracle..)
Perhaps what you're longing for is a more clear distinction between read type operations vs. write type operations. This is probably something that is better left to the higher level languages, with CALL serving as the fundamental low level implementation. AFAIK this is not a feature inherent to Serpent, but you could certainly implement your own convention for your contracts.
are there any updates since May?