zweice | 2 years ago | on: Ask HN: What are you passionate about at the moment?
zweice's comments
zweice | 2 years ago | on: Beetle grows ‘termite’ on back to steal food
zweice | 4 years ago | on: A function decorator that rewrites the bytecode to enable goto in Python
zweice | 8 years ago | on: The Digital Advertising Duopoly
zweice | 8 years ago | on: Deleting $300M by messing around with Ethereum contracts
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.