That's not a great answer to a very realistic case.
- brilliant exploit by a hacker who was both skilled enough to outsmart many, many world-class developers all working together.
- malicious enough to forgo the generous bounty awarded for disclosing the exploit to the Common Colony security domain.
- detestable enough to willingly crash an enormously successful DAO
If you think one or all of these attack vectors are not something to be concerned about (or worse, be sarcastically dismissive about) you have no business writing smart contracts or anything security related.
The three points above are all valid and absolutely important, and should be consistently and properly considered by anyone developing smart contracts or anything security related. There's no disagreement about that.
popcorncowboy, however, wanted to make an argument that assumed a security breach in order to make a broader point about "code-is-law" and DAOs in general, but was waiting for a response to unveil his second statement (which you can read now). The sarcasm was a response to the rhetorical and argumentative style of popcorncowby, not an illustration of the Colony dev attitudes toward the security of the smart contracts that will comprise the Colony network.
EDIT: phrasing
The many sentences that come before the shrug do nothing to address the very realistic scenario of a breach. The "sarcastic closing comment" was in fact the final truth of it.
You're assuming quite a lot of this hypothetical hacker - the response above clearly addresses the hypothetical by stating "here are the relevant reasons why this hypothetical is impossible or at least unlikely, and here are the relevant sections in the whitepaper for more verbose information".
>The many sentences that come before the shrug do nothing to address the very realistic scenario of a breach.
If you're assuming blackhat success for any conceivable project/company/database regardless of security measures taken to prevent it, what would an appropriate response even look like? What kind of answer would satisfy you?
Yes, by saying "the hypothetical is moot". Moot. And why? Because "in principle" "this should ... prevent the circumstances enabling such an exploit from ever happening.". Moreover, that we should simply trust that the intrinsic balance of economics means successful projects cannot exhibit a state in which a breach would be profitable, and anyway that the combination of someone smart enough, mean enough and motivated enough to breach is inconceivable.
Which could all be acceptable. Except if they're wrong even once, you lose everything.
> What kind of answer would satisfy you?
I see this response a lot on HN, and it's an obviously cheap shot.
If the asymmetry of outcomes in the two types of breaches is not obvious to you, then lets talk it out.
If an attacker breaches your real world company servers, they can cause a lot of damage. No question. They can steal IP, records, etc etc etc. The examples are legion. You're right.
But if they breach your Colony dAPP? They own you. Not metaphorically. They take de facto ownership of whatever value you've created.
No matter how incredibly well you can hack eg. Apple, you can't ever take over total ownership and control. Even if you hacked the Exchanges and somehow reset all the records, even if you compromised key board members, etc etc in the real world we have recourse, we have liability, we have laws and courts and means to make claims and pursue remedies.
But on the Blockchain? All your Colony are belong to someone-else the moment you edge-case a smart contract. Permanently. (Unless you can convince Vitalik et al to re-fork, case in moot point.) The equivalent would be if Apple ran a server that if you could figure out how to breach you could take ownership of Apple and total control of its operations.
So, "what kind of answer would satisfy"? One in which the design did not fundamentally and existentially depend on no-one ever figuring out a combination to a lock that gave them total and immutable control of a store of ever increasing value.
> It really seems like the most appropriate response to this is indeed ¯\_(ツ)_/¯
Except, if you've ever been decently burned by a clause in a contract, you'll know that the actual felt response is not even close to ¯\_(ツ)_/¯
In the real world, with an actual registered company/cooperative, you can call the police or sue people in court as a last resort. This is not possible in a distributed world, so a new kind of recourse needs to be invented, if that's even possible.
I think we have to forego the stereotype of lone wolf havker (or at least not treat as the only hacker stereotype) when considering having a large population put their valuables into a single pot.
I do the same thing when I assume that there will be bugs in my production software, regardless of any security/testing and measures taken to prevent it. Why is this suddenly less likely when we're talking about a DAO?
The answer that satisfies would of course be you still have the power to revert things if necessary, which you've already provided, but I'd never for the life of me imagine disabling it.
The situation you really are getting at is one in which the Common Colony is mature enough that the 'recovery mode' features have been disabled and the contract is in full community control (a reasonable assumption if the Common Colony is pulling down $10M a year as you suggested). In this case, it also seems reasonable that some of that $10M a year will be spent by the Common Colony on bug bounties and internal security, paid to experts who have the highest reputation scores. If somehow there was still some brilliant exploit by a hacker who was both skilled enough to outsmart many, many world-class developers all working together, malicious enough to forgo the generous bounty awarded for disclosing the exploit to the Common Colony security domain, and downright detestable enough to willingly crash an enormously successful DAO... well, the answer is simply ¯\_(ツ)_/¯
Hypothetical 2: This is where the reputation system gets interesting. If you really wanted to try to gum up a colony's inner workings by 'objecting to everything' or somehow interfering with the normal day-to-day workflows, you yourself would need some reputation score to do that. With each objection, you would be required to stake your own tokens and reputation on the outcome of the dispute. If the other members of the colony don't approve of what you're doing (I don't see why they would if you're trying to push the colony into the ground), they will vote against you and you will lose tokens and reputation. So with each unsuccessful attempt to interfere with the colony you hate, your own ability to influence that colony will diminish substantially.
Section 9 in the whitepaper describes these mechanisms in detail.