Note that this appears to be a $9.99 version of http://www.proofofexistence.com/, a free service. Also, this does not appear to be affiliated with the popular bitcoin exchange Bitstamp.
When deciding what to name your Bitcoin site, anything with the word "bit" or "coin" in it should be avoided. Please! Otherwise, you just join the list of other unmemorable bit/coin sites.
And, this goes without saying, pick something that, when you google it, google does not say "Showing results for Bitstamp".
While the method using to sign documents is identical (as posted by inkfactory), the main difference is that bitstamped is also hosting your files. This can be regarded as both an advantage or a disadvantage over proofofexistence, depending what your position is regarding the remote hosting of the document.
I killed almost a year on a similar project and it flopped majestically.
I even worked out how to do the whole verification part that it works out of the box without the need for any software or 3rd party service. You just needed a Windows box. Still that made no difference whatsoever, because ultimately selling this sort of service is like selling insurance. You have to force people to think about bad things that could happen in order to make a sale, and that's just not everyone's cup 'o tea.
I found your project when I was researching to see if anything like Bitstamped.io already existed.
One of the key differences with Bitstamped is that the publicly verifiable time-stamp (the QR code link) is circulated with the printed document.
So as well as the proof, it might also be a deterrent against plagiarism.
I bet a lot of start-up founders go through that anxious "what if someone steals my idea" phase whilst they're pitching it around.. Having some part of the business plan (doesn't have to be all of it) Bitstamped might just help alleviate some of that anxiety. Maybe.
Nice writeup, I think your conclusion is pretty spot on. People neglect to buy insurance, don't back up data, and ignore safety margins. Why would they start timestamping their files.
That being said, I really like how the service worked. If I understand it correctly, I would download the signed work (signed .exe with content included), which also means that I would have proof after the service got shut down.
It used AuthentiCode executable signing to bind VeriSign's timestamps to the documents. Basically, this allows for an unlimited use of VeriSign's mature and robust timestamping infrastructure for a cost of a single signing certificate ($150/year or thereabouts). Not to pat myself on the back, but I think it was nothing short of ingenious :)
What kills you with Bitcoin timestamping is transaction costs. It's fine for timestamping that one brilliant screenplay, but not timestamping every photo you ever take, every video created by your security system, every file pushed out to your distributed, decentralized backup network, etc. It doesn't open up any cool applications that aren't served by existing, cheap-but-not-free systems.
So with Crypto Stamp, they combine all the hashes for a given day into a single Merkle tree, and just store the root hash in the blockchain once a day. The tradeoff is, for each timestamp you have to store locally the few hundred bytes representing your branch of the Merkle tree. But in exchange, you can timestamp effectively unlimited files for effectively zero real cost. That opens up the kind of wacky game-changing applications that make Bitcoin interesting in the first place.
I think you're right about the costs - Bitstamped is definitely better suited to use with a printed document, possibly just for a short period of time until formal legal protection can be secured, or even just for the purpose of quickly assuaging anxiety about an idea being copied..
Of course you could put a load of photos into one ZIP file and upload that, but that's not the intended use of the service.
Practically speaking, couldn't I just tweet the SHA1 hash and let Twitter be my trusted timestamp authority? Assuming I don't work for Twitter, it's unlikely I'm able to modify the timestamp on a tweet. (The blockchain has a lot more confidence due to its distributed nature, but in the minds of say, a jury of your peers, I bet it actually appears shadier than Twitter.)
Yes, but that would be a centralized solution. When Twitter dies (wont happen, but still) or a rogue admin changes the timestamp, etc. - It requires a trusted party - Twitter - instead of the blockchain.
Hash extension attack yes, but only if you already have a valid hash and document and wish to add more to the end of your document. This however will change the hash.
I also meant to type SHA2, but it would make no difference since you can still do length extension with it. In fact, you can do length extension with anything that uses Merkle-Damgard.
If I have to pay, then why shouldn't I adopt a RFC 3161 or X9.95 timestamp service? Some jurisdictions recognize them as notary-equivalent certified timestamps.
If what you want is legal protection then indeed there is no reason. Signatures vended by timestamping authorities are good enough for all uses I can think of unless you absolutely need decentralisation, in which case paying $10 to this company defeats the point.
To get this service for free, just print your document to PDF, grab the free Adobe Reader, go to settings, signatures, click "Configure timestamping", then add a TSA server like:
I find it interesting that you believe that it would be easier to convince a judge that some random centralized "authority" is trustworthy than it would be to explain how a hash written to the blockchain guarantees that that the timestamp is valid.
The technology used by such an authority would be just as complicated and difficult to explain as the blockchain approach to timestamping. What you're counting on is that the judge would give more weight to legal representations made by an otherwise unverified "neutral" private entity than she would to a detailed explanation of the blockchain.
What is it that explains how the blockchain--which doesn't require trust--would loose out to a private entity simply because bitcoin tech is complicated, and because a representative of that time-stamping authority would be able to sit in court and say "trust us, we have no stake in the outcome of this decision"?
A lack of trust is supposed to be the primary benefit of the block chain, but it seems that in your view in this case it is more of a liability.
You're right, a judge is not going to want to master the details of the technology, which is why trying to explain it would just yield confusion and annoyance.
Ultimately it matters when there's a dispute over the integrity of the timestamp. Even if in theory a judge could verify a block chain timestamp for themselves, they won't ever do this, they'd just say "go find an expert witness you can both agree on" and then the judge would assume the neutrality of the expert witness based on their credentials. You always end up back at the neutral third party no matter what, whether it's a TSA or someone who is interpreting the block chain.
That's not to say block chains are useless for timestamping, far from it. But for the specific case of timestamping traditional documents in case of a civil legal dispute, you may as well use the fast, instant, widely used, well integrated and free option instead of paying a $10 fee to use Bitcoin.
But this method might be too complicated for most users.
The benefit of Bitstamped is the simplicity of uploading the file and getting a QR code to insert in a document so anyone reading it can scan it to satisfy themselves of the date it was created.
The file that gets Bitstamped could be anything - for example I could doodle my new algorithm on a napkin along with the words "designed by Me" and get it Bitstamped before I finish lunch, later, I add the QR code to my business plan (for example) to link the ideas therein with the napkin photo.
"I've heard good things about the team at X.", if you've actually heard good things about them. "Those guys at X claim they can do Y.", if you have the folks at X on record actually claiming Y. Otherwise, you're just repeating something you heard, or wish you had heard.
There are better ways to do this. You shouldn't be pushing this kind of data into an OP_RETURN output where you are burdening the entire network to store, retransmit, and validate that information from now until the heat death of the universe.
No, put your data into a Merkle hash tree, and do a single 32-byte commitment as frequently as you need to. You can even work with your competitors on a common format and have no more than one commitment per block.
The OP_RETURN is provably unspendable, so it's technically superior to dumping data in unspent outputs. UTXO actually does have to be kept around forever, unlike OP_RETURN which can be pruned.
The issue isn't OP_RETURN, it's one vs many OP_RETURN outputs per block, and stuffing data in the block chain vs compressing it via hash functions to 32-bytes per block.
If everyone is supposed to share one OP_RETURN, either you're building the tree by consensus or centralized control?
It would be an interesting feature to collect the OP_RETURN's into a merkle tree as part of a consensus protocol. But one question immediately comes to mind...
Publishing the root node is useless, unless you know where your node is located in the tree, and all the sibling nodes all the way up to the root. You know, so that you can actually prove your node was part of the tree. Just having the root is not enough.
Where is the full tree being built, stored, how is it shared, how do I get a copy of it, so that I can find my node in it? If the tree is built from collective inputs, what are the anti-DDoS mechanisms? Etc...
Peers would need to share this data structure for some amount of time after the block is published (not indefinitely). Anyone who thinks their hash is part of certain block's tree would need to retrieve the full tree for that block, and if they find their node in the tree, keep their own record of the log(n) hashes required to get from their node to root. It's a big trade-off to impose this external data storage requirement!
All these questions / complexity, and what is the actual benefit? Again, these are prune-able OP_RETURN outputs so they don't pollute UTXO in the first place. The relay fee is more than enough to cover the cost of < 100 bytes that never hit UTXO.
No, there are not. What there are are ways which are slightly cheaper on a few dimensions which are irrelevant compared to the dimensions of reliability, cost, explainability, and ease of use which are totally trashed by your alternative suggestions.
> No, put your data into a Merkle hash tree, and do a single 32-byte commitment as frequently as you need to.
'Did you just tell me to go fuck myself?' 'I believe I did, Bob.'
> No, there are not. What there are are ways which are slightly cheaper on a few dimensions which are irrelevant compared to the dimensions of reliability, cost, explainability, and ease of use which are totally trashed by your alternative suggestions.
That has no relevance. You build a standard for these proofs, and they are passed around as blobs. It doesn't matter what their internal structure is.
Your reply makes no sense. It's like you didn't read anything I said in pointing out that sending to a Bitcoin address is simple, easy to understand, easy to use, and secure, while its main disadvantage is using a tiny amount of space which would require enormous increase in the use of timestamping to make any meaningful difference to full nodes.
Gwern, as a LW'er you should know about scope insensitivity and the danger of discounting possible futures. Yes the energetic and capital cost of transmitting, validating, storing, and keeping on hand a few dozen bytes is a minor thing like a speck of dust. But it is something that must -- must!! -- be done by every full node from now until the end of the universe. How many full nodes do you think there will be in the next 100 billion years? That's a lot of specks of dust.
Regarding simplicity, the complexity of the underlying protocol has no bearing on that. You can just as easily write an application where you drag and drop a file, and then it does the magic of sending p2p messages to negotiate a position in the timestamp tree, and making a micropayment to pay for it. That tool could be just as easy to use.
> Yes, but when the better is significantly better, and only a small marginal cost, it's worth doing.
No, it's not significantly better, and I'm not sure if it's better at all. Timestamping in the Bitcoin block chain is easy to use, cheap, convenient, highly secure, and relatively easy to explain to others. Your solution does not exist yet, and from the sound of it, even when it exists will have only one of those properties (highly secure), optimistically.
> though that was not the question asked.
Indeed. I don't expect humanity to be around in 100b years. I don't expect money to be around in 100b years. And I certainly don't expect SHA-256 or the elliptic curves used in Bitcoin to all remain intact over 100 billion years. (What's the longest a cryptographic hash in wide use has ever survived so far? 30 years? What about public key systems? 40 years maybe?)
> Actually I am and have:
I see. I upgrade my assessment of you from 'preachy asshole' to simply 'clueless person who doesn't understand people and their needs and builds castles in the air'.
No, in all seriousness I think the key to services such as these is trust. Trust that no matter what the company won't falter and nip into the database and change a few dates.
When people actually need this service, they'll really need it and I'm wondering without an accredited and independent survey of the site and company (as well an employees) whether this will be worth anything legally and in a court of law?
They're using the Bitcoin blockchain to post the one-way hash proving that the document existed at a certain time. They wrote: "This is possibly the first non-currency application of the Bitcoin Blockchain packaged in a commercial way for non-technical users."
That's precisely what Bitcoin is solving: it's the first system allowing to have trust without a chain of trust, without a central authority. And this is why IMHO Bitcoin is huge.
In a way Bitcoin-the-cryptocurrency is "just" one application of that decentralized trust.
Now that said that technique is known since a long time: if I'm not mistaken people have been using SHA256 of documents as private (?) keys to make a tiny transfer in the Bitcoin blockchain since basically as long as Bitcoin existed.
It's good to see it as an easy-to-use service although apparently there are already free alternatives...
No no, I read. I'm just wondering in 10 years time whether the blockchain ledger will still be available, or still within it's current ownership. In my opinion the nature of using this kind of service is that you may not need it until many years ahead, some could argue that bitcoin may not be around then, or may not be a in strong position; people may lose interest etc.
Not asking rhetorical questions, just seeing other peoples thoughts.
I understand that this concept has the upside of not having to trust a central authority, but is this really any better than trusted timestamping[0], at least from a legal perspective?
I wonder how this deals with like .docx files or .xlsx (Excel) files. Even of you change 0 fields it might end up "mutated" and the Proof does not longer work.
A single flipped byte destroys the entire concept. Tech savvy people can deal with this, but not the average joe.
I'm pretty sure any industry that handles documents etc. that would require a non-forgeable timestamp would not want (or are allowed due to regulation) to upload a billion dollar contract, legal document or patent to a website. No offence.
They would want an in-house, closed system with (of course) blockchain communication for the verification part. Or maybe a tool that creates a "Magic" executable that contains the a) file and b) a "Check" button to do the blockchain verification.
