probably faster since it was built for this purpose, throwing an error would have to at least create an exception object, then create stack trace and the other setup stuff.
As i said I code for almost 20 years and I only had to use it once so far, but people that maybe work a lot more with stuff that needs a lot of performance might use it much more often.
If code reviewer doesn't report a bug before the contract is deployed he then can become the 'bug finder' taking all ether from the bounty + his own.
Even if the code reviewer is honest there are some economical problems:
- Code reviewer will find a balance between time spent, amount to put into the time dependent 'bounty' and probability of a bug that didn't come up during review --> little-at-stake problem
- If you force the code reviewer to put in a significant amount of ETH into the time dependent bounty you won't find any reviewers willing to work for you because of the huge risk for them --> risk problem
How would that have worked with the the Parity 'hack'?
- Parity deploying their multisig contracts, having a bounty with code reviewers. AFAIK it wasn't even a bug but a not-well-deployed contract library. So the reviewers would have said that Parity should go on and deploy their multisig contract. Parity would have deployed it in a wrong way (as they did). The 'hack'/accident would still have happened.
If your time dependent contract was separate from Parity's multisig the reviewer would still get his ETH back after the time lock releases. Alternatively the reviewer's funds would also be frozen.
Hopefully formal proof of contracts will save us sometime. Alternatively blockchain with some governance scheme that takes care of something like that would also be useful. Wait a second... Am I describing Tezos? Let's wait for them to launch and see if that works better.
