Editing Exploit markets (section)

== Technical details ==

'''1. contract_tx = Hash(binary_file) as H1, URL(binary_file) as URL1''' * Setup the smart contract with the bug bounty information. Valid bugs are expressed in terms of input to the program via user-input, network, and/or files, in accordance to templates or custom rules. E.G. Bug validity is determined based on whether or not a bug can cause privileged actions to happen within the context of the process space. This is testable.

'''2. exploit_tx = Hash(exploit_code + payout_pub_key) as H2''' * Commit to a hash of an exploit and payout address that satisfies the bounty conditions against the binary_file. * Commit to a collateral payment that gets given to the miners if the exploit is invalid to avoid attacks.

'''3. disclosure_tx = RSA_Encrypt(exploit_code, vendor_pub_key) as E''' * Publicly release an encrypted version of the exploit using the vendor’s public key. This is done with no random padding such that the same plaintext always produces the same ciphertext (YOLO.)

'''4. Vendor receives encrypted exploit''' * Vendor decrypts the exploit code with their RSA private key from the blockchain and validates it against their software.

'''5. The vendor (actually) pushes a patch to their customers on time.''' Because if they don’t the smart contract punishes them. Can you hear the trolls singing?

'''6. confirm_tx (optimal)''' The vendor signals to the researcher that they may disclose the exploit now.

'''7. release_tx (the researcher actually gets paid for once)''' The researcher releases the exploit code and claims the reward. Input = Release exploit_code + payout address such that H(exploit_code + payout address) == H2. Output = anything. Sig = Must be signed with the ECDSA key pair used for payout address!

'''8. Validate the release TX''' * The network validates the exploit against the binary file in accordance with the rules listed for the contract. Exploits are executed in virtual machines and the validity forms the consensus rules for allocating rewards. * The network looks at whether or not the vulnerability was disclosed to the vendor by doing RSA_Encrypt(exploit_code, vendor_pub_key) == E. If it was it looks at how many blocks have elapsed since disclosure and release to calculate to what extent a penalty or reward is justified. * If an exploit was disclosed too early the smart contract can specify a penalty to the researcher (like reduced reward or even taking away researcher collateral if that is used to submit “solutions.”) One issue with this idea is that if another person finds a vulnerability and discloses it early it is impossible to prove if the original researcher was the one who actually did this so this opens up an attack vector. After thinking about this some more from what I can tell it really only makes sense to have early disclosure penalties for highly paid flaws / serious bugs. * Optional: Reward is initially given as a fraction of the number of outstanding exploits against the software version, N / reward_size but as exploits are released you get to see who was first to claim a bounty so that the rest of the reserved fractions become available to the same researcher. This allows rewards to be split for duplicate bugs.

'''9. patch_tx = Hash(new_binary_file) as H3, URL(new_binary_file) as URL2, code_changes as diff''' * Vendor uses an ECDSA private key to sign a new transaction to point their software to an updated version. This updates the contract meta-data and proves to the network that the exploit has been fixed.

'''10. Validate the patch TX.''' * Patches can be expressed as small programs that alter the code for the original software. The network can then use these additions to rebuild the original binary files from a deterministic build system, run test cases, and run the original exploit against it to see if it succeeds or fails. * The network also looks at how long it took the vendor to initiate a patch TX. Rewards and penalties are therefore assigned based on the rules originally set forth within the contract_tx.

'''Goto: step 1 again.'''

'''1. Continue running exploits and allocating rewards.''' * Because exploits are written against a particular version its possible to track at what point in the chain a patch defeated a particular set of exploits. This makes it possible to see what researchers submitted duplicate bugs and to give them a split of the reward (if specified.) * To avoid attacks all exploits must be disclosed within a reasonable number of blocks regardless of a patch TX. This ensures that rewards are given out on time and that rewards that have been allocated as a potential split between researchers are progressively given out to the first person in the chain to have demonstrated the bug. Perhaps penalties for false exploits can be given to the first researcher whose time was wasted. * A DAO between researchers and vendors can be established to verify patches if this patch system doesn’t work.

Most of the complexity for this scheme is to stop people from stealing exploits and saying that they wrote them. Because if you didn’t use commitments someone can just copy the exploit hash directly from your transaction and try confirm it before you. I suppose this isn’t that much different from how blockchain notaries work if that helps.<span id="scalability-and-incentives"></span>