> 1. Edge case leaks 87% of tokens to a dedicated hacker. Sorry?

The level of code safety in smart contracts is abysmally bad today, Ethereum didn't further the state of the art with EVM/Solidity (quite the opposite), and this needs to be fixed before any serious business can rely on a DApp.

Smart contracts are like aerospace engineering, not like iStore apps development; delivering slightly buggy code, written as fast as possible, by easily interchangeable developers, doesn't cut it. It's worse than for aerospace actually: when you design a plane, your opponents are the laws of physics, which merely don't care about you. When designing a smart contract, hackers are specifically after you, and statistically, some of them are smarter than you and your code.

> 2. I locate and bribe/extort your main influencer/s

How is it different from the current practices of bribing executives and misleading shareholders (naively supposing that shareholders need to be mislead in order to pass bad, narrow-sighted judgements)?

> There are so many other fun problems with code-as-immutable-law for human institutions.

Indeed!

> It's concerning that none of these are even remotely addressed in the Colony literature

I take Colony as an experiment. As hinted above, I think you'd be a fool to bet your livelihood on some Solidity code. I don't think we're able to foresee which of those problems matter, nor the compromises which best mitigate them. Like in code optimisation, you need to measure before acting; Colony will meet those issues, will try to address them, and may or may not survive the process. Whether the lessons learned benefit Colony 2.0 or another project raised from its ashes, it's hard to say, but in the great scheme of things, it doesn't matter much.

Precisely.

> ...bribing executives and misleading shareholders

You raise an interesting point - in a Colony there is presumably no concept of enforceable fiduciary duty to shareholders (because there are none - we're not trading securities, we're trading plastic house chips on a blockchain). There are no legislated considerations for other members/colonists/dappsters/etc. I can vote/act with impunity, regardless of value creation/destruction potential. Welcome to the legal grey zone.

> I take Colony as an experiment.

As do I, and one I hope succeeds. But I'm not sure THEY do, which means early adopters are riding a bet that Colony gets it right the first time.

Once large amounts of real money are be involved there would be an amazing clash of conventional corruption attacking the heads, a computer security battle attacking the basic building blocks of the influence mechanisms, the demagogic tactics known from online discussion boards trying to sway opinions of the masses of low influence individuals, the gray "pay for likes" business that exists in the shadow of big social media sites, and all the gaming-the-system tricks with multi-accounts and the like that are rampant in open, long-running multiplayer games.

Oh, the drama! It might be compelling to join as a perfect substitute for an HBO subscription, who needs game of thrones. You might see a group forged in a decade of Eve online alliance warfare fighting mob hackers fighting two competing factions of hedge fund managers fighting a 4chan prank.

On the other hand, sufficiently boring organizations (e.g. stewardship of some greying enterprise software open source) with peeexisting informal trust networks should be perfectly safe. But would they need "colony"?

Just cause you hand out pieces of plastic (or tokens on a blockchain) instead of paper doesn't make it not a security. (As the ICOs are finding out!)

Security is as security does in a lot of these cases, so if it functions as a security, you're likely to run into encounters with the SEC.

With actual people you can informally convince either colleagues or the state that an exec is acting in bad faith of outside the policy framework of the company. And this can trigger formally defined actions. A sort of protection against deceit is built in by the fact that regulations are merely social conventions and not physically binding.

How do you informally convince code to stop trusting a certain influencer? You'd have to put in code paths managing this first, because code is a physically binding regulation.

Hypothetical 1: Contract security is taken very, very seriously, and discussed in section 2.2 of the whitepaper. The short answer is that colonies will have a 'recovery mode' whereby whitelisted addresses have the ability to alter some state of the colony contract directly. This should, in principle, prevent the circumstances enabling such an exploit from ever happening. In that sense, the hypothetical is moot.

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.

> well, the answer is simply ¯\_(ツ)_/¯

That's not a great answer to a very realistic case.

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.

EDIT: phrasing

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 ¯\_(ツ)_/¯

> What kind of answer would satisfy you?

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.

> I locate and bribe/extort your main influencer/s to push your project into the ground (block work, object to everything, whatever) or in my preferred direction

How's that any different from the current state? Execs of current companies are humans with power to run the company into the ground. You can extort/bribe them like that as well. How does it change anything?

fab13n made a similar comment on this line. So thanks to both of you for illustrating the point (genuinely):

> "How does it change anything?"

The action itself may appear the same, but in code-as-law systems the consequences of this action change everything. The system of governance is immutable. If I can coerce your primary influencer to destroy your Colony _there is nothing you can do about it_, because the system is still _working exactly as designed_. Like an AI auto-pilot flying you into a mountain at high speed because it got a correctly formed override instruction to do so.

In the real world we have multiple interpretive, negotiated, social conventions to deal with bad actors, agents and outcomes that violate the spirit or intention of underlying agreements.

The lack of these are EXACTLY the problem in a "code as law" system - and worryingly it shows that most of our intuitive responses to bad agency in these type systems is still "but it's the same in the real world". Except of course for the existential threat posed by immutability of consequence and recourse.

You cannot remove trust from collective human agency, you can only put it somewhere else and pretend like it doesn't matter anymore. Right up until it does.

> Execs of current companies are humans with power to run the company into the ground.

I get what you mean, but in practice you can't wilfully do this without serious consequence. To destroy value is to take it from someone. Fiduciary duty is a legal reality.

I think it's good to press hard on how newly proposed code-as-law systems work, but at the same time, how are gaps between code-as-law larger or different from say an executive that skims money out of a company, transferring it to other bank accounts. The banking system isn't enforcing any legal contracts in that transaction, and if the malfeasance is discovered then some legal recovery action would order or capture assets to be transferred back. Couldn't a court of law order assets be transferred to a wronged party in a code-as-law system?

Edit: I do think a good "control test" of many of the code-as-law systems is to compare against cases about how it would be different than a ledger managed by a person & the existing legal framework around it, and then a centralized database with security around certain operations.

Well, there is actual law against it? https://www.nytimes.com/2015/12/02/nyregion/ex-citigroup-con...

It happens, but when it does happen, people have recourse to a totally different system: the courts. I think of it like raising the issue up out of the system Corporate Management and into the system Legal Enforcement.

It is patently not a perfect system, but the failures are notable because they are not common. Most shareholder lawsuits against management are resolved before anyone ends up in headlines.

For 1: The colony fixes the bug and creates a fork of the contract state (balances, etc) before the hack, so everyone has the same balance but there is no longer a bug. There should be consensus on using this fork going forward because everyone that has created value or invested is incentivized to do so.