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.
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.
But now for a mostly different reason: web standards. Chrome is usually leading the pack with implementing new Javascript features, CSS features, performance optimizations, etc. Browsers with weird quirks or that aren't properly written to spec (eg: older IE versions of Flexbox) won't work as well. Some developers, such as myself, think users should be updating their software if they really care that much about some things being broken.
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.*
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 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).
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.
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.
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.)
I almost forgot another interesting use of this second feature: package managers and binary distribution. Knowing that version 1.2.3 of some app was published a month ago is nice. Also nice is knowing that for the last month it's the only version 1.2.3, and everyone in the world has been getting the same one.
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.
19 comments
[ 2.8 ms ] story [ 43.4 ms ] threadWe've really gone back to how it "used to be" :(
http://i.imgur.com/NXf6Ibz.png
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:
https://proofofexistence.com/
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
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/
Out of a range of ~50,000 years that's not bad at all.
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
https://en.wikipedia.org/wiki/Trusted_timestamping