I think the many sentences that come before the shrug emoji illustrate that the case is not very realistic. You're taking the final, sarcastic closing comment out of context.
You're absolutely wrong. It's this attitude toward security that is a main factor toward most of the Ethereum hacks to date.
- 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.
Whoa, ok, let's back up here for a second, because I feel like this got a little lost in the shuffle: the dismissive sarcasm was a response to something specific, not to smart contract security of the Colony Network.
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.
On the contrary. This is a core project team member saying that in the event a dedicated agent IS sufficiently motivated and DOES manage to compromise a Colony, "well, the answer is simply ¯\_(ツ)_/¯"
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.
It really seems like the most appropriate response to this is indeed ¯\_(ツ)_/¯
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?
> the response above clearly addresses the hypothetical
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.
Not if they are large sophisticated state sponsored attacks.
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.
> 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?
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.
