
Service lets you "certify" a document using the Bitcoin blockchain - obiefernandez
http://www.proofofexistence.com/
======
machrider
This idea is generally called "trusted timestamping":
[http://en.wikipedia.org/wiki/Trusted_timestamping](http://en.wikipedia.org/wiki/Trusted_timestamping)

One example would be to take a photo of a rental car showing damage at the
time you rented it and be able to prove it was taken at that time. Then the
rental company cannot later claim you caused the damage.

This is a pretty clever use of the blockchain as a publicly-visible and
authenticated timestamp. This way, the site's owners do not have to establish
themselves as a legal authority on timekeeping in order for this to be a
trusted service.

~~~
diminish
I was developing a similar online notary. My idea is to timestamp open code,
docs etc create a prior case database against patent trolls and goliaths.

~~~
nl
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.

~~~
diminish
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.

~~~
nl
_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.

------
jd007
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. MD5 is already vulnerable to chosen prefix
attacks, maybe in 5 or 10 years SHA256 will be too...

Perhaps using a combination of different hash algorithms that we know are
secure today to certify a file together would be a potential solution to the
problem. It's not perfect, but at least this way all the algorithms used need
to be compromised for the certification to break.

~~~
skriticos2
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.

~~~
beagle3
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)

~~~
adamryman
Can we see them?

~~~
beagle3
I guess they are on a backup or misremembered - but examples are really easy
to find on the net if you want them:

[http://th.informatik.uni-
mannheim.de/people/lucks/HashCollis...](http://th.informatik.uni-
mannheim.de/people/lucks/HashCollisions/)

[http://www.win.tue.nl/hashclash/ChosenPrefixCollisions/](http://www.win.tue.nl/hashclash/ChosenPrefixCollisions/)
has a multicollision: 12 PDF files with different content and the same MD5
hash.

------
nadaviv
I also developed a similar project:

[https://www.btproof.com/](https://www.btproof.com/)
[https://news.ycombinator.com/item?id=5790382](https://news.ycombinator.com/item?id=5790382)

Recent changes to Bitcoin made the method I'm using to timestamp the data on
the blockchain somewhat problematic [1], but I'll be working on an update once
I release another Bitcoin-related project I'm currently working on (hopefully
in the coming days).

[1]
[https://github.com/shesek/btproof/issues/1](https://github.com/shesek/btproof/issues/1)

------
gnerd
The idea is cool but it might be too early for people to use the blockchain
like this as right now BitCoin can support 7 transactions per second.

Once that hard limit is lifted, and things like this can scale and support
demand, applications like this could be very interesting.

One thing though, it says the BTC involved in the transaction is unspendable,
isn't that a bad thing? I imagine an idea like this that didn't render any
amount of BTC unspendable would be ideal.

[https://en.bitcoin.it/wiki/Scalability#Current_bottlenecks](https://en.bitcoin.it/wiki/Scalability#Current_bottlenecks)

~~~
SilasX
Wow, didn't realize that! That's bad news, since the current daily transaction
rate (~100k) is within an order of magnitude of the daily limit (~600k = 7 x
3600 x 24).

Fortunately, the doubling time is, from eyeballing the chart below, about 6
months, so that allows ~1-2 years for a fix.

[https://blockchain.info/charts/n-transactions?timespan=30day...](https://blockchain.info/charts/n-transactions?timespan=30days&showDataPoints=false&daysAverageString=1&show_header=true&scale=1&address=)

~~~
gnerd
Well I was expecting there would be a significant jump in transaction volume
as news spreads, prices rise, more services were offered in BTC and more
countries get local exchanges. You also seem to miss that its not the total
number of transactions per day you need to worry about, its the transactions
per second.

There are surely periods of frenzy in the day where we cannot support 7
transactions per second as more economic activity takes place, even if the
total transactions for the day is well under 600000. Its not like the
transactions are neatly distributed on a flat line throughout the day.

There must also be some consideration that each time this is done, the BTC in
the transaction is rendered unspendable and so it is taken out of the market.
So I guess its not good if something like this could scale on top of BitCoin.

------
martin_
A couple of great developers from HackTX a couple of weeks back created
something similar during the hackathon there in just 24 hours.

[https://www.hackerleague.org/hackathons/hacktx/hacks/proveme](https://www.hackerleague.org/hackathons/hacktx/hacks/proveme)
with a demo copy @ [http://162.242.216.46/](http://162.242.216.46/)

~~~
wyager
I'm one of the two developers.

I got the proof server working again so you can play with it.

Try proving data and typing in "testing" (lowercase). It will tell you when we
put it in the blockchain. This file should also work:
[http://s3.amazonaws.com/rapgenius/filepicker%2FvCleswcKTpuRX...](http://s3.amazonaws.com/rapgenius/filepicker%2FvCleswcKTpuRXKptjOPo_kitten.jpg)

It's a little patchy, but it does work! Payments are fake, and don't do
anything! So don't pay! I don't know how much our Bitcoin wallet has left in
it. I'll try to remember what we've uploaded so you can try it out.

Bitcoin/crypto code here: [https://github.com/wyager/hacktx-
proveme](https://github.com/wyager/hacktx-proveme)

------
wyager
My friend and I did this as well for a hackathon (HackTX) a few days ago!

162.242.216.46

Try proving data and typing in "testing" (lowercase). It will tell you when we
put it in the blockchain. This file should also work:
[http://s3.amazonaws.com/rapgenius/filepicker%2FvCleswcKTpuRX...](http://s3.amazonaws.com/rapgenius/filepicker%2FvCleswcKTpuRXKptjOPo_kitten.jpg)

Here is our bitcoin/crypto stuff. [https://github.com/wyager/hacktx-
proveme](https://github.com/wyager/hacktx-proveme)

It's not up to my usual quality because we did it in 24 hours with a sleep
break! Please don't judge me on this :p

------
taway2012
Couple questions.

1) AFAIK, bitcoin has "comments" within transactions. Why not embed the
checksum as a comment in a transaction between wallets you control?

2) In the approach described here, no coins are being sent with the
transaction (right?). Are blockchain participants really accepting NOP
transactions involving 0 BTC transfers. Maybe I missed something.

3) As others pointed out, requiring the whole file to be uploaded is a non-
starter for anybody savvy enough to be using this service. Users should be
able to directly specify the checksum.

~~~
clarkmoody
1) Comments are enabled as a service by blockchain.info. For details on how
the Genesis Block (and comment by Satoshi) was formed, look at the Bitcoin
Wiki[1]

2) Coins are being sent. The Developer page says you must send at least
0.00000001 BTC. _Edit: actually 500000 Satoshi._

3) Agree. So does the service. See the Developer Page[2]

[1]
[https://en.bitcoin.it/wiki/Genesis_block](https://en.bitcoin.it/wiki/Genesis_block)

[2]
[http://www.proofofexistence.com/developers](http://www.proofofexistence.com/developers)

~~~
Natanael
5460 satoshis is the current default minimum that Bitcoin itself allows (other
transactions are valid, but won't be forwarded, thus you need to hand it over
to a miner yourself for inclusion in a block).

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

~~~
shabble
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 a trusted but private notary, who can copy
or stamp or otherwise indicate that he has seen your documents and so they
must have existed at least since the date indicated.

But counterfeiting, forgery, untrustworthy notaries, etc, all make this a less
than ideal solution. So we add computers & crypto.

The document in question is condensed down to a single cryptographic hash,
which (should[2]) to all intents and purposes be unique for a given document,
despite being only a few tens of characters long, regardless of the size of
the original input.

This hash then serves as proof[3] that you have the source document, without
anyone being able to turn it back into the original document. This is a very
one-way process.

Then, you need to find someone to vouch for your hash and indicate when they
first saw it. You can do this with lawyers/notaries again as before[4], which
partly solves the forgery problem, but not the trust one.

The solution proposed here is to store that hash in the bitcoin block-chain,
which is a distributed log of all transactions on the bitcoin network, which
has 3 nice properties:

1\. It's append-only. Once your hash is encoded in there, it's staying there
as long as bitcoin exists[5].

2\. It's peer-to-peer/distributed. There's no single controlling organisation
you need to trust for answers.

3\. It's updated regularly enough that timestamps can be relatively fine-
grained.

So you stuff it in there using this tool or whatever, and then X years hence
when you need to prove you'd actually created that file in 2013, you should be
able to prove that to most people's satisfaction.

This is a loose take on the matter and glosses over whole swathes of other
complexities involved, but is probably close enough for [non]government work
:)

[1] That is, who discovered/did something first. You may want to be able to
claim you did in future, but without making it public at the time, because you
might tip your rivals off to the idea before you've fully developed it. See:
[https://en.wikipedia.org/wiki/Scientific_priority](https://en.wikipedia.org/wiki/Scientific_priority)

[2] Breaking (or "colliding") hashes is a whole subfield of cryptography
research, and some pretty impressive things have been done there. It's why you
probably shouldn't use MD5 for anything nowadays, for example. But again,
we'll handwave "Done Properly = unique identifier".

[3] Well, in the same way that a password proves that you're the/a person who
knows that password - if you did it right and never told anyone, it should be
exclusively you. But if it leaks somehow, others could represent the hash as
belonging to something they own. But if they only have the hash and not the
original source document, there are relatively easy tests that could
distinguish them. That's not very important here though.

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

[5] well, mostly. But it's _really_ hard, and the same capabilities let you
defraud the rest of the bitcoin network with double-spending and whatnot, so
unless your timestamp priority is super-important, you're probably ok.

~~~
xerophtye
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!)

------
twakefield
I wonder if these concepts could be used to change the way land records are
maintained and eliminate the need for title insurance [1] in the U.S. I am no
expert but the current system doesn't seemed to have changed much in the past
century or so. This results in a lucrative business (title insurance) that
effectively insures against book keeping mistakes.

[1]
[http://en.wikipedia.org/wiki/Title_insurance](http://en.wikipedia.org/wiki/Title_insurance)

~~~
dminor
If some claim to title is omitted from the public record, how exactly would
this guard against it?

------
spiritplumber
Two thoughts.

1) Will this have legal weight? I know that the whole "prove paternity of an
invention by sending a certified letter containing the design through the
mail, and not opening it until you need it" thing doesn't very much work, if
it goes to court you tend to be told "OK, what you say is true in the physical
universe, but you did not go through our blessed channels, so nyah nyah nyah".

2) Anything that makes bitcoins more legitimate / part of the world's
infrastructure decreases the chance of bitcoin going away as a system. I think
the idea for the bitcoin community is to make the system as a whole "too big
to fail" before governments decide that they want to get rid of it.

~~~
nwh
> _Will this have legal weight?_

I doubt it. If I have to fax something for it to be a legal document, such an
antiquated system will ignore any advances made around it.

~~~
bjt
The law doesn't pretend that signatures and fax machines are magic. Contracts
written on bar napkins can be enforced.

Any time you introduce evidence, you have to establish its credibility. The
first time a signing system like this is used it's likely to take the court
some time to understand, but there's no legal doctrine forbidding it.

Source: I am a (not practicing anymore) lawyer.

------
yonilevy
I believe you could implement it in such a way that the coins involved are
spendable, relying on "Pay to script hash":
[https://en.bitcoin.it/wiki/BIP_0016](https://en.bitcoin.it/wiki/BIP_0016)

------
rlpb
"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?

~~~
nsomaru
There is a developer API that allows you to do this:

    
    
        http://www.proofofexistence.com/developers

~~~
rlpb
That's not the same as making it available for users though, is it?

------
flashmob
How about miner's fee, is that added to the transaction?

In the About, they say that they make 2 undependable dust transactions.

Would there be any incentive for miners to confirm these transactions and
store them in the blockchain? If there's no incentive to confirm the
transactions, then the miners might find a way to filter these out of the
blockchain.

See also dust transactions:

[http://bitcoin.stackexchange.com/questions/10986/what-is-
mea...](http://bitcoin.stackexchange.com/questions/10986/what-is-meant-by-
bitcoin-dust)

[http://bitcoinfees.com/](http://bitcoinfees.com/)

------
eddywebs
nice concept ! apparently sha-1 is vulnerable to collisions
([http://eprint.iacr.org/2008/469.pdf](http://eprint.iacr.org/2008/469.pdf))
how are they handled ?

~~~
sp332
It uses SHA-256, not SHA-1.

------
richardlblair
So, if I could automate this, could I use this to prove in court that logs
were created, and not tampered with?

Just trying to think of practical uses of this cool project, and it's the
first thing that came to mind.

~~~
delinka
Yes. Or that a contract was not created before a certain date. Or, as another
poster suggested, that a photo of a damaged rental car was taken before you
took possession of the car.

~~~
tghw
_Or that a contract was not created before a certain date._

I think you have that one backwards. You can demonstrate a contract _did_
exist at a certain date. There is no proof of non-existence before that date.

~~~
GhotiFish
you're right, it can be used to prove that a contract with both signatures
existed before a date, not after. So if Alice makes an agreement with Bob,
Alice can't turn around and say that the contract was only ratified after
Alice failed to meet certain obligations.

Then again, digital signatures come with a timestamp, Alice could lie about
that timestamp, but it would be obvious to Bob that she did.

Fun to think about.

------
Mizza
Cool! I worked on something similar before:
[https://github.com/Miserlou/CitizenMediaNotary](https://github.com/Miserlou/CitizenMediaNotary)

I've also got an idea related to this which involves a global array of
satellites in order to add a geo component to this kind of verification..

------
EGreg
This would help to certify that a contract was signed at a particular time by
both sides, and then included in the blockchain.

It would also help certify that a particular person created a document, once
again because it was signed by their personal key and included in the
blockchain.

It basically functions as a certain timestamp.

------
runn1ng
well... you can save actual files to namecoin blockchain if you try a little.

my script that does exactly that (not updated, maybe won't work now)

[https://github.com/runn1ng/namecoin-
files](https://github.com/runn1ng/namecoin-files)

------
Crito
It would be nice if you included some UI for just pasting in a bunch of hashes
myself.

------
tlo
Article about this topic: [http://erratasec.blogspot.de/2013/05/bitcoin-is-
public-ledge...](http://erratasec.blogspot.de/2013/05/bitcoin-is-public-
ledger.html)

------
jmcqk6
Now this is fricken awesome. I can imagine all sorts of instances where this
is applicable. What about as a replacement for a notary public in some cases?
Very nice work, and a genius idea.

------
superuser2
Would this have any legal standing? Legally valid but insecure will trump
secure but inadmissable in nearly. situation where having a certified
timestamp is useful.

------
deepinsand
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.

~~~
resonator
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.

------
iand
I was thinking along similar lines today, but geared more towards proof of
title.

------
orenmazor
brilliant.

