Bitstamped
bitstamped.io
bitstamped.io
Bitstamped.io is not aimed at technical users - that's why payment is in USD and not BTC.
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".
I'm with chuckup though, I tend to quickly forget all the sites with names like this (regarding bitcoin specifically). Thank goodness for bookmarks.
"Showing results for Bitstamp" is irritating, but we only launched yesterday, hopefully Google will figure out that Bitstamped is a thing!
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.
Postmortem - http://swapped.cc/certtime
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.
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.
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.
Why can't you just hash your entire dataset once a week or something? Or better yet, do something like a Merkle tree of files.
2. Convert the hash to a BTC address
3. Send 0.0001 BTC to the address you made
4. There you saved yourself $9.99
Deleted comment
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.
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:
http://timestamp.comodoca.com/rfc3161
or
or one of many others that are available. Then click "Work with certificates" in the sidebar and then Timestamp document.
As long as you can convince a judge that these are neutral third parties (very easy to do and there is much precedent) this should be satisfactory.
Or you could timestamp into the block chain, but then be prepared to spend a lot of time explaining to a confused judge why it's 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.
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.
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 can see the value in proving you sent a document, but I don't understand the cost structure here.
I once thought about storing information into the Bitcoin blockchain for another use case, but found out that very few nodes would actually store it.
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?
I don't know
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...
Not asking rhetorical questions, just seeing other peoples thoughts.
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.
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.'
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.
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.
One of the other things I learned there was not letting the perfect be the enemy of the better.
> But it is something that must -- must!! -- be done by every full node from now until the end of the universe.
Don't be ridiculous. Bitcoin is not going to run from now until the end of the universe.
> How many full nodes do you think there will be in the next 100 billion years?
A relatively small multiple of the number there have been. You seriously think humanity is going to exist for 100 billion years?
> That tool could be just as easy to use.
Yes, this hypothetical tool which does not exist, likely will not anytime soon, and which you certainly are not volunteering to write.
Yes, but when the better is significantly better, and only a small marginal cost, it's worth doing.
> Don't be ridiculous. Bitcoin is not going to run from now until the end of the universe.
In a certain form I very much believe it will be, but this is probably not the right venue for that debate.
> You seriously think humanity is going to exist for 100 billion years?
I plan on being around (at least) that long, though that was not the question asked.
> Yes, this hypothetical tool which does not exist, likely will not anytime soon, and which you certainly are not volunteering to write.
Actually I am and have:
https://www.mail-archive.com/bitcoin-development@lists.sourc...
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'.
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.
Might help someone who just wants to see what's inside without creating an account:- http://www.inkfactory.com/blog/bitstamped/ink-factory-launch...
A single flipped byte destroys the entire concept. Tech savvy people can deal with this, but not the average joe.
Cool concept nonetheless.
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.
It's not important who thinks of an idea first, it's important who implements it and gets people to use it.