Implements proof of historical data possession on the Ethereum blockchain
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
contracts
docs
migrations
test docs is now more extensible Nov 18, 2017
.gitattributes adding syntax highlighting support for solidity Feb 14, 2018
.gitignore adding github pages and truffle.js Nov 11, 2017
LICENSE
README.md
addEntry.js
secrets.js.example
set_factory.py
truffle.js

README.md

ProveIt

At long last, we have the technology. You can finally prove to your friends that you liked that band before they were cool! 👌

To Interact with ProveIt

Visit the shiny and highly functional ProveIt website!

Some Semi-Technical Background

ProveIt implements proof of historical data possession on the Ethereum blockchain. What this means in practice is that any Ethereum address can submit a 32-byte cryptographic hash to ProveIt's ledger and gain the ability to prove that the owner(s) of this address wrote/possessed the text/data that resolves to the hash at a particular time. The ledger also allows addresses to stake arbitrary amounts of Ether alongside their entries, lending credibility.

Hypothetical Use Cases

  • Alice is a rabid Elon Musk fan, and wants to make a prediction about Musk's glorious future endeavors. Using her Ethereum address AddressAlice, Alice could submit By 2030, a company founded or owned in part by Elon Musk will have delivered a human to the surface of Mars. to the ProveIt ledger at time T. At any point from now until 2030, Alice could submit evidence of her ownership of AddressAlice in standard ways (i.e. by signing a credible message via something like the Etherscan verifySig tool), thereby proving that she made this statement at time T. This makes her seem prescient, and more importantly, affirms her Musk fanhood. One could imagine, however, that a rival Musk supporter Bob might submit many such messages, varying the year, and revealing only the one that makes him appear most credible. To combat this issue, Alice can lock up an arbitrary amount of ether, x, alongside her statement. This amount cannot be recovered without destroying the associated ledger entry. If we assume that Bob must submit 20 different entries to have a high probability of ending up with at least one very close prediction, he’s forced to lock up 20*x ether to guarantee that his revealed entry will have the same amount of credibility as Alice's, dissuading him from attacking.
  • Alice also moonlights as an amateur paparazza, and manages to snap an incredibly compromising flattering photograph of Elon at time T. She’s desperately worried that the photo will be stolen and published by Bob at T+1, depriving her of all potential proceeds. If Alice wants to be able to prove that she possessed this photo at T she could simply make a (cryptographically secure) 32-byte hash of this photograph, and store the hash in ProveIt. The data that produced this hash will of course be unknown at T, but upon Bob's release of the photo at T+1, Alice could prove her prior possession by letting anyone see that the photo hashes to the entry that she made in ProveIt at time T.
  • Alice's day job is as a professional economist. She runs a lot of randomized controlled trials (RCTs), and in the spirit of value-free scientific inquiry, she often wants to publicly commit herself to a particular statistical hypothesis H0 before running an RCT to prevent ex-post p-hacking. She could of course use the American Economic Association's RCT Registry, but centralized solutions are so 2017. A better idea would be to formulate an appropriate H0, store its hash in ProveIt, and reveal it after the RCT has concluded. In addition to the commitment mechanism, this method has the benefit of not revealing H0 to rival economists (looking at you Bob) who might steal her idea. Of course, nothing prevents Alice from submitting many H0 s, and only revealing the most favorable one ex-post. To combat this, verifiers should only trust Alice if she submits her hash to ProveIt, publicizes it along with her name, and associates it with her current project, all before running the RCT. This reputationally commits her to a single H0.

Technical Notes

  • While building ProveIt, I realized that having set functionality would be helpful, so I implemented it in contracts/Sets.sol. It's quite efficient, with O(1) insertion, removal, and existence checks.
  • Contracts of interest are deployed at:
Contract Address Link Network
Prover.sol 0x117ca39dffc4da6fb3af6145dfff246830637fe2
0x286e1143ab350d0238be4494da6dab9ca3662517
0x286e1143ab350d0238be4494da6dab9ca3662517
verified on Etherscan
Etherscan
Etherscan
Mainnet
Rinkeby
Ropsten
Hash.sol 0xca260ffffb0270ee07ec6892fa9d44f040454e4d
0x125bbe680d2c6665151ad8c9c89727a64683fdcb
0x125bbe680d2c6665151ad8c9c89727a64683fdcb
verified on Etherscan
Etherscan
Etherscan
Mainnet
Rinkeby
Ropsten
Sets.sol 0x48d904b3bf1cfcd7e1ce2dbcf7dcaecf0b0575c6
0x2aacb774a7214075372b52e24ff7391a4e3ea883
0x2aacb774a7214075372b52e24ff7391a4e3ea883
verified on Etherscan
Etherscan
Etherscan
Mainnet
Rinkeby
Ropsten

Tips

Accepted, not required! ETH: 0x8688a84fcFD84d8F78020d0fc0b35987cC58911f