Posted this to /r/ethereum but had zero comments. Tell me what you guys think of the concept
Here's an idea for a new smart contract that creates an autonomous bug bounty system. It can be used to create self-patching software that crowd-sources human expertise to hack software and then fixes it without the need for trusted payments.
Here's how it works:1. Create a contract with a hash of a binary file and a URL to download the file (contract TX.)
2. Commit to a hash of (an exploit binary + a reward address) (exploit hash TX.)
3. Reveal the exploit in private to the vendor and give them time to patch the software. To do this they create a new transaction that updates the binary hash and URL in step 1 (update TX.)
4. Reveal the exploit content by proving the hash in step 2 (reveal exploit TX.)
The network then validates the exploit based on the rules set forth in the contract. The binary file is downloaded and run in a virtual machine and an exploit is expressed in terms of user-input to the program (via network e.g. remote code execution; via disk / file input, or via user-input, etc.) That is: the program is run deterministically by full nodes against an input as part of the consensus rules for that blockchain.
If the exploit can successfully set some protected memory region (or whatever conditions are specified in the contract), then money is taken from the bug bounty pool used to fund the contract and given to the address in step 3 (based on using the blockchain to record who first defined a given exploit in the case of two auditors releasing duplicate vectors.)
Benefits:- Auditors are now guaranteed payment for exploits. In the past security work has been poorly rewarded or not rewarded at all (contrary to so-called bug bounty policies for a given company.)
- Validation is automatic and payment is always on time. There is no waiting around via email to get a reward.
- The bug bounty program is clearly defined. Auditors aren't going to attack private network resources with this model.
Now there are some unexpected game-theory dynamics that this opens up which could benefit consumers. Namely, you can set penalties within the smart contract to occur against the vendor if they take too long to patch the software and you can also set a time frame that must elapse before a reward can be given out (after which the auditor can release the exploit and claim the reward.)
This will give the vendor time to patch the software and it forces the auditor to wait before releasing a working exploit in the wild. The whole process here clearly defines the responsibilities of both parties so that when an exploit is executed against the old software customers aren't automatically going to be screwed.
Patch contractsAnother idea is the inverse of exploit contracts - patch contracts. If patches are expressed as small programs that can only add or remove a certain number of lines of code from the original software (which is recorded as a deterministic build system with comprehensive test-cases), then it might be possible to actually verify whether the software has been patched. And if that's the case then that can also be added back into the original smart contract.
Hell, you can even crowd-source patches and create incentivized, self-patching programs. Thoughts?
