
‘Carbon Dating’ the Internet Archive with OpenTimestamps - haakon
https://petertodd.org/2017/carbon-dating-the-internet-archive-with-opentimestamps
======
malgorithms
Like everything else Peter Todd does, this is very impressive and extremely
useful.

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

~~~
petertodd
tl;dr: What you want isn't timestamping, and OpenTimestamps very explicitly
doesn't address your use-case.

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](https://petertodd.org/2016/commitments-and-single-use-seals)

------
apo
For those who want to try something like this with little fuss, check out
Proof of Existence:

[https://proofofexistence.com/](https://proofofexistence.com/)

~~~
petertodd
Proof-of-Existence requires you to pay to get a timestamp verifiable back to
the Bitcoin blockchain, because it's a highly inefficient one Bitcoin
transaction-per-timestamp system. The price is also quite a bit higher than
the actual transaction cost - a fixed 5mBTC or $11 per timestamp.

I'd suggest using the in-browser implementation of OpenTimestamps on
[https://opentimestamps.org](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](https://petertodd.org/2016/opentimestamps-announcement)

~~~
EthanHeilman
Awesome work, I've been interested in opentimestamps.org for a while but doing
this for the internet archive makes it very easy to get people excited about
it.

------
nickpsecurity
Anyone interested in this should look into Trusted Timestamping. There's
protocols and companies to study for inspiration of how to improve it combined
with new work like this.

[https://en.wikipedia.org/wiki/Trusted_timestamping](https://en.wikipedia.org/wiki/Trusted_timestamping)

------
ancorevard
Hope it's more vastly more accurate than actual carbon dating.

~~~
abritinthebay
C14 dating can be accurate to ~12 years if you have a large enough sample,
collect beta emission data long enough, and use good methodology & calibration
data.

Out of a range of ~50,000 years that's not bad at all.

------
10165
No Javascript version:

[https://raw.githubusercontent.com/opentimestamps/opentimesta...](https://raw.githubusercontent.com/opentimestamps/opentimestamps.org/master/index.html)

[https://archive.org/download/opentimestamps-calendar-
backups...](https://archive.org/download/opentimestamps-calendar-backups/)

[https://ia801509.us.archive.org/13/items/opentimestamps-
cale...](https://ia801509.us.archive.org/13/items/opentimestamps-calendar-
backups/)

[https://github.com/opentimestamps/opentimestamps-
client](https://github.com/opentimestamps/opentimestamps-client)

[https://alice.btc.calendar.opentimestamps.org/calendar/](https://alice.btc.calendar.opentimestamps.org/calendar/)
[https://bob.btc.calendar.opentimestamps.org/calendar/](https://bob.btc.calendar.opentimestamps.org/calendar/)
[https://finney.calendar.eternitywall.com/calendar/](https://finney.calendar.eternitywall.com/calendar/)

------
haakon
Note: Had to take some small liberties with the headline to make it fit HN's
80 character limit.

~~~
petertodd
Note: I took some liberties with the headline myself: by "the internet" I mean
the Internet Archive of course. :)

------
therealidiot
> tl;dr: You can now use our searchable database (works best on Chrome)

We've really gone back to how it "used to be" :(

[http://i.imgur.com/NXf6Ibz.png](http://i.imgur.com/NXf6Ibz.png)

~~~
uuoc
This is, of course, the reason why some worry about _any_ browser having a
huge market share over all the others. It becomes simply too easy to decide to
just support that one to the detriment of proper open standards simply because
85+% of the usage one sees is "that one browser".

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.

~~~
petertodd
Ironically in this case, I myself kept on nagging the web dev team to try to
have better compatibility, as I'm a Firefox user. :)

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.

