Live data from Hacker News

Service lets you "certify" a document using the Bitcoin blockchain

proofofexistence.com

71–80 of 86 posts

Re: Service lets you "certify" a document using the Bitcoin blockchain

#71
post #45

This is definitely a cool idea, but there could be potential issues if it is to be relied upon for long periods of time. If at any point in the future the hash algorithm used (SHA256 right now it seems) is found to be vulnerable then it could invalidate all past certifications. You don't really even need a full collision attack, a chosen prefix collision attack is enough to completely destroy the system's validity. M…

an application of each once? Btw my crypto is weak, but do answer this. if i apply a hash algorithm on something, it outputs a relatively small number of bytes. Correct me if i am wrong but the strength of the hash lies in the fact that the input space is vastly huge so its difficult to create an input-output mapping for reversing the hash. Now if we use one hash over another, aren't we restricting the input space of the 2nd hash? Wouldn't that make it easier to crack the 2nd hash for this particular usage? And if my above statements are correct then the strength of sch a mechanism only lies in the strength of the first algorithm

Re: Service lets you "certify" a document using the Bitcoin blockchain

#72
post #19

Can anyone eli5 exactly what this accomplishes. What sort of scenario would this work for. I'm assuming some sort of legal purposes.

It's a way to use the bitcoin blockchain as a non-centralised way to record the fact that you were in possession of a particular file at a particular time, without exposing what that file is, or who you are. The problem has been around for a long time, especially when dealing with semi-intangibles like Priority for scientific discoveries, or proof of first invention for patents[1] One solution is to present proof to…

One question. I know that its nearly impossible to reverse a good hash or to create a doc that will knowingly return the same hash. So PREDICTING a collision (finding a doc that will collide with a given doc) is very very very difficult. But Due to the size of the output and input space we know for a fact that collisions do exist (right?) So if a very large number of documents are timestamped using this, their hashes WILL collide right? I mean there is a POSSIBILITY that you may find proof for a doc that wasn't actually stored here, right?

(Just wondering. Not throwing criticism. I actually LOVE this idea!)

Re: Service lets you "certify" a document using the Bitcoin blockchain

#73

Couldn't I also publish the checksum on Twitter? Although it's not decentralized, it's probably equally trusted in the eyes of the legal system.

But that's kinda centralizing it. What if twitter shuts down? What if twitter's DB is compromised? With bitcoins, it kinda makes all this impossible (cryptographically) and making it super decentralized

Re: Service lets you "certify" a document using the Bitcoin blockchain

#74
post #57

Earlier quoted context omitted.

Are there any documented cases where that would help? It seems to me that the real problem is convincing a jury that a prior piece of work is related to a patented piece of work.

yes you might be right, NIST standardized timestamping methods are themselves full of patents. And I believe Jury would accept only those + a certified authority which would want to be testify in front of Jury.

NIST standardized timestamping methods are themselves full of patents

hu?

And I believe Jury would accept only those + a certified authority which would want to be testify in front of Jury.

I think you've missed my point. I'm saying that the problem isn't the TIME of the prior art, it is proving to a civilian jury that prior art relates to a patent.

Re: Service lets you "certify" a document using the Bitcoin blockchain

#75

Couldn't I also publish the checksum on Twitter? Although it's not decentralized, it's probably equally trusted in the eyes of the legal system.

Yes you could, however, this isn't only about the trustworthiness of your claim. More importantly it's about the trustworthiness of the longevity of the data.

Twitter can remove a single post or turn off their servers and your prove is gone. That's not so easy for a BitCoin transaction. Once it's added to the blockchain it's there for as long as anyone is running a bitcoin node.

Re: Service lets you "certify" a document using the Bitcoin blockchain

#76
post #45

This is definitely a cool idea, but there could be potential issues if it is to be relied upon for long periods of time. If at any point in the future the hash algorithm used (SHA256 right now it seems) is found to be vulnerable then it could invalidate all past certifications. You don't really even need a full collision attack, a chosen prefix collision attack is enough to completely destroy the system's validity. M…

Collisions are a problem if you want to corrupt data, not if you specifically want a human validate it in a single document.

E.g.:

I claim that I authored the string "foo bar" with hash "1f2ec52b7743687..".

Now you find a collision and go to court arguing:

>> Your honor, but "3HSSHog*8FF9 z!!!!ady94765&$^#" also has the same hash!

I think the court will still assume that "foo bar" is the correct original, not the garbled collision data you produce. And you still can't deny that the original produces the correct hash.

Re: Service lets you "certify" a document using the Bitcoin blockchain

#77
post #12

Can anyone eli5 exactly what this accomplishes. What sort of scenario would this work for. I'm assuming some sort of legal purposes.

I wrote a haiku to run through a hash function and send to strangers. Every time this document is run through a particular function, it returns: > d15396b27a2b176e6315c9fbbec09e2c2e042e595755902e5ff5eccec1ca634b If I changed a single character of the document, the function would return an entirely different string. This means it's very, very difficult to come up with another document that returns the same string when…

This means it's very, very difficult to come up with another document that returns the same string when run through this same function.

This isn't entirely true for some hashes (like MD5). However coming up with another Haiku, in English, that makes sense and has the same hash, is probably close to impossible.

So this probably wouldn't work that well as a service to see who first generated a random string, but works very well if we know something about the structure of the string in question (like that it is in a known human language and makes sense)

Re: Service lets you "certify" a document using the Bitcoin blockchain

#78
post #45

This is definitely a cool idea, but there could be potential issues if it is to be relied upon for long periods of time. If at any point in the future the hash algorithm used (SHA256 right now it seems) is found to be vulnerable then it could invalidate all past certifications. You don't really even need a full collision attack, a chosen prefix collision attack is enough to completely destroy the system's validity. M…

Collisions are a problem if you want to corrupt data, not if you specifically want a human validate it in a single document. E.g.: I claim that I authored the string "foo bar" with hash "1f2ec52b7743687..". Now you find a collision and go to court arguing: >> Your honor, but "3HSSHog*8FF9 z!!!!ady94765&$^#" also has the same hash! I think the court will still assume that "foo bar" is the correct original, not the gar…

That's not why it would be a problem.

The problem is that I can author "foo bar" and "moo bar" constructed to hash the same, and then assert retroactively which one I meant. While collisions are likely to have random binary garbage in them, it may not matter - I am on phone now, but IIRC I have two PDFs on my desktop that have the same MD5, one of which viewed is an airbus pamphlet, the other being a Boeing one. (created by Dan Kaminski, IIRC)

Re: Service lets you "certify" a document using the Bitcoin blockchain

#79
"Your document will not be uploaded. The cryptographic digest is calculated client-side."

That's great, but I have to trust you there. For a document that really matters, I don't think I would.

How about a box that allows me to specify my own SHA256 instead?

Post reply on HN