‘Carbon Dating’ the Internet Archive with OpenTimestamps
petertodd.org
petertodd.org
And I think it's almost what we need at Keybase for timestamping our own database. I figured I'd record here what's important to us in a timestamping service, because I have a feeling (if we're reading it correctly), OpenTimestamps doesn't yet do quite what we'd want.
What we would love:
- to announce that our database has hash H at time T.
- to make all our announcements discoverable to prove we aren't making parallel database announcements around time T.
The latter feature doesn't matter if your only goal is proving data existed on a certain date. Say you want to prove you wrote a story, great, just post its hash. But feature 2 is important if you're also trying to convince people that you aren't telling other people other stories at the same time.
Random examples of someone wanting the second feature:
- a newspaper or website might like to prove that yesterday's headlines or stories were X,Y and Z, and that they were the only stories yesterday. How can we know they didn't publish 1,000,000 different headlines or variations of the stories, just to cover all the possible big news of interest, and then point at the 3 interesting ones later? Or later point at the ones that paint their editorial perspective a certain way?
- a money manager / fund might like to prove they can make good stock picks, so they announce their 10 predictions for the year, and later, when they publish their predictions, you can verify they were their only 10 predictions.
- on Keybase we're trying to prove that we're not maintaining 2 different databases for all our users. If you ask who keybase/chris is, Keybase is giving the same answer to everyone in the world, and not accidentally leaving, say, a revocation off the end of my announcements.
- a government might like to prove that its laws were exactly X at time T, and there weren't some extra ones slipped in as optional extra laws later.
- proof you truly love only one.
This all seems to require an authentication method for posting things, and a way for the timestamp server's data structure to be traversable to a poster's announcements, so you know you're not missing anything.
Right now at Keybase we do this by burning money from a specific address, an address known to be our announcement address. It's clunky. But it achieves that goal: someone can know they're seeing all our announcements. This is expensive and annoying to maintain, and it would be nice to see a general package that manages this kind of thing.
So consider this a vote for v2 supporting parties putting signed statements into open timestamp server! Or a request for clarification, if it already works this way.
(Thanks Peter and others who worked on this! very cool stuff.)
edit: formatting
This, and not the money nonsense, is what Bitcoin does, if you do it right.
Fortunately I have another project to solve your use-case too. I've written up some of the theory behind this here: https://petertodd.org/2016/commitments-and-single-use-seals
I'd suggest using the in-browser implementation of OpenTimestamps on https://opentimestamps.org if you want maximal ease of use. I personally use it all the time on my smartphone.
OpenTimestamps uses a efficient system of merkle trees to aggregate timestamps, which allows us to timestamp an infinite number of documents with a single Bitcoin transaction. In the case of the Internet Archive effort, about half a billion documents with one transaction. Because this is so efficient, we're able to offer the service as a public good.
The actual cost per timestamp is simply bandwidth, which even at the relatively high pricing of the VPS services myself and the other calendar operators are paying, works out to be about a millionth of a dollar per timestamp. I'm sure we'll be able to cover those operating costs indefinitely via donations. Frankly, my only concern is being able to get enough donations to pay myself a reasonable wage for my time, which so far I've had initial success in doing for the core protocol development (I'm doing the Internet Archive work explicitly pro-bono).
You may find my detailed writeup on the architecture interesting: https://petertodd.org/2016/opentimestamps-announcement
Out of a range of ~50,000 years that's not bad at all.
https://raw.githubusercontent.com/opentimestamps/opentimesta...
https://archive.org/download/opentimestamps-calendar-backups...
https://ia801509.us.archive.org/13/items/opentimestamps-cale...
https://github.com/opentimestamps/opentimestamps-client
https://alice.btc.calendar.opentimestamps.org/calendar/ https://bob.btc.calendar.opentimestamps.org/calendar/ https://finney.calendar.eternitywall.com/calendar/
We've really gone back to how it "used to be" :(
I didn't write the website - and I'm not a web-dev myself - but I'm sure the guys who did would appreciate any pull-reqs to improve on the situation: https://github.com/eternitywall/internet-archive-ots
And the same goes for any of them, Chrome, IE, Firefox, Safari, Opera, etc. No single one should have such a huge share above the others, or else exactly this starts to appear all over again.
Though as this was a pro-bono spare time effort, I'm not going to criticize them for that - they put the website together in about a two or three days of work, with essentially no help from me other than some design suggestions and proof-reading.
If my Javascript uses .map() and your browser doesn't support it, too bad. I'm not including the polyfill for everyone just because some small minority of users need the polyfill. Those users can update their browser. Resources spent trying to support people who refuse to update could be better spent on providing more benefit to everyone else.
With rare exceptions, anything that "works best in Chrome" works just fine in Edge/FF. Usually Safari is the new IE6 with everything being broken.
In the 'What's Next' section:
*>Browser Compatibility
Currently the database UI works fine on Chrome, but has issues with Firefox and Safari;
we’re working towards supporting all major browsers.*