You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Demonstrating data ownership without revealing actual data.
You can publicly reveal the digest and if conflict arises you can prove you had the data that generates the digest. Useful for copyrighted material, patents, etc.
Doesn't say how. I can see at least two ways:
Submitting signed or watermarked documents that can be used as proof to the ownership of both that and the unwatermarked version, by virtue of being dated earlier than yourself or anyone else submitting the unwatermarked version.
Submitting a snapshot of your public web page where you list the (submitted) hashes you own every time you update the page.
Neither method is really optimal (both require extra submissions) and neither is presented on the page.
Perhaps there should be one of the following:
A field for an email address or other public identifier to be hashed and appended (so that the existence of the unique document can be verified without inputting the author).
A field for an email address or other public identifier to salt the hash with (which doesn't create extra data, so will not require weaker hashes). This method is identical to manual solution 1 above.
Encrypting the file with the author's private key to verify that not only did they possess the file at the date, but were in fact the person responsible for registering it. (So that a third party can not use the feature for defamation.)
The text was updated successfully, but these errors were encountered:
Thank you for your well thought out feedback.
I've seen both A1 and A2 being used by https://proofofexistence.com/ users, and as you say, they're not optimal.
As an attempt at a better solution, we are now testing something similar to your suggestion B3. The difference is instead of encrypting the file, we're using PGP signatures.
That's pretty cool, thanks.
My only suggestion is that you could allow people to copy down a blob of text, sign it, and stick it back in, in case they are uncomfortable exposing their private key to their browser environment. (Or your webapp for that matter, that could have been compromised.)
After the feature is finalized anyone using it regularly would still just have it as an automated part of their publishing process (they would probably still want to sign it locally for the API, just like they SHA it locally), but I am asking for a middle ground (which seems trivial to implement)
Also, the pricing is provisionary, correct?
I tried different numbers of signatures and it's always 0.02 BTC there.
Doesn't say how. I can see at least two ways:
Neither method is really optimal (both require extra submissions) and neither is presented on the page.
Perhaps there should be one of the following:
The text was updated successfully, but these errors were encountered: