TL;DR -

• VB is in support of secession and even a divergence of ETH into two or more blockchains according to consensus. This is supported by past interviews with VB.
• Fragmentation of currencies is not only "not all that bad" but inevitable given their nature.
• VB does not believe in Hard Forks being the primary method for resolving crypto thefts. In this case stolen funds were locked in place for 35 days preventing widespread roll back of transactions.
• VB supports the use of Hard Forks in certain cases, in particular when large amounts of ETH have been sent to unspendable addresses or if the Solidity compiler is found to have a serious bug that puts 5 - 10M ETH at risk.
• Concerns about moral hazard are overblown.
• There is now a much higher burden on high-level language developers. There are not enough resources to keep projects such as Serpent at a satisfactory level - as such it is up to individual developers to check their code.

Source:

>https://www.reddit.com/r/ethereum/comments/4uq37o/a_grab_bag_of_thoughts_on_etc_and_forks/

1) Three months ago I made a statement in an interview with Morgen Peck as follows:

I generally support just about every secession attempt that comes along,” he says. “If in the future there is that kind of a dispute in Ethereum, I’d definitely be quite happy to see Ethereum A go in one direction and Ethereum B go the other.
I do have principles, and this is a principle that I have so far held consistently. It would of course be grossly hypocritical for me to (correctly) decry bitcoin maximalism back in 2014, and then start shouting "one chain to rule them all! network effects!" the moment it becomes suitable to me. Rather, I believe, just as I had stated in my 2014 post on silos, that:
>"If there truly is one consensus mechanism that is best, why should we not have a large merger between the various projects, come up with the best kind of decentralized computer to push forward as a basis for the crypto-economy, and move forward together under one unified system? In some respects, this seems noble; “fragmentation” certainly has undesirable properties, and it is natural to see “working together” as a good thing. In reality, however, while more cooperation is certainly useful, and this blog post will later describe how and why, desires for extreme consolidation or winner-take-all are to a large degree exactly wrong – not only is fragmentation not all that bad, but rather it’s inevitable, and arguably the only way that this space can reasonably prosper.
I personally admittedly find ETC's social contract, community and raison d'être less exciting and satisfying and would not personally feel the same passion for it that I do for ETH, but this is simply my judgement, and the judgement of the very many members of the community that have voted or otherwise expressed assent to the fork. Anyone who feels sufficiently strongly in the other direction is welcome to focus on the ETC chain, and we will see if it remains viable."

2) But those were just my beliefs and intermediate values. How do we know that this "let a hundred flowers bloom" position is actually correct? We can actually discover a lot of facts from the current situation. First of all, though we can see that the price of ETH + ETC has been remarkably stable around $14.3 for the past 2.5 days, despite great volatility in each component. This is still early-stage, but suggests that the value of at least the cryptocurrency component of the ecosystem actually isn't a superlinear function that favors monopoly.

>"Second, we can see from several sources (including exchange order books, but also public pronouncements from Barry Silbert et al) that incoming interest into ETC is actually coming from the bitcoin side even more than it is from the ethereum side. And this is a core tenet of blockchain pluralism: by leaving open an option to join an alternate system if an individual so chooses, you can satisfy the varying needs of larger groups of people."

3) I may as well offer my own views on hard forking. I do not believe that using hard forks as a primary paradigm to resolve thefts or to deal with unethical applications is a long-term viable strategy. This time, we got very lucky that the stolen DAO ETH were conveniently stuck in a known address for 35 days. Next time around, the funds will likely be being sold on exchanges before the developers even know it, and the only solution will be a rollback - and Casper will make rollbacks infeasible due to its economic finality mechanism in any case.

3b) "Evil dapps" can constantly move their contracts around in ways that evade a necessarily slow-moving hard fork, so while we can annoy them, "softer" means of mitigating the harm of such applications must necessarily still be sought out.

3c) The blockchain itself is very far from the eventual vision of a hyper-scalable, efficient and secure world computer and will see several more iterations to move closer to that goal; if you wish you may view Casper as a completely independent blockchain that happens to have a 100% state-copying premine from ETH, and in fact this may even be the cleanest way to implement it in code. I personally was okay with a fork in light of this context, together with a philosophical belief that a principle does not need to have literally infinite weight in order to have value.

>"In the near to mid-term future, I expect that there will be many small applications rather than one big application, and so no single failure will be enough to greatly impact the ecosystem; hence it strikes me as quite unlikely that application rescue hard forks will become a regular thing (note that some disagree; Vlad would love to have hard forks for many more things, though I'll let him defend his own views :) )"

At this point, I am hypothetically open to two kinds of application rescue hard forks:

i) A fork in the very unlikely case that the Solidity compiler proves to have a serious bug that puts 5-10 million ETH in danger.
ii) There has been a medium amount of ether that has been sent to unspendable addresses because users were using buggy ethereum-js libraries that created the address from the public key incorrectly. I would be OK with a change, for example as part of metropolis, that adds a new transaction type that effectively makes the most common categories of such unspendable addresses spendable by their cryptographically provable rightful owners (but I would only be ok with this with broad consensus and even still it's dependent on technical feasibility and tradeoffs in code complexity).

In the future, I suspect that both possibilities will recede over time.

3d) In the short and medium term, we are still under conditions of high technical uncertainty. For example, Vlad and I continue to argue about whether or not a fixed currency supply can offer sufficient incentives through transaction fees alone to secure the network. If we had agreed, for example, to a "100 million ETH and never a single bit more" principle on day one, we would have dug ourselves into a rather deep hole if the research ends up showing that low inflation (or something more complex, like expected low deflation but the possibility of low inflation under conditions of low Casper participation) is the only safe way forward. Similarly, "it is possible to create a contract that lasts forever" is also something that is economically dangerous to commit to. Hence, principles on these kinds of matters may need to be settled only later.

4) Concerns about moral hazard are, in this case, IMO overblown; on the contrary, despite the fork, I have been extremely impressed by the sheer number of formal verification and other secure contract programming projects that have recently emerged in academia. Writing this from inside the middle of an Ethereum research workshop in Cornell, I am very optimistic that the number of bugs in code will decrease greatly over the next year.

4b) This does however mean that there is now a much larger burden on high-level language developers, and I personally do not have the time or ability to maintain Serpent at a level that I personally find satisfactory. I am personally continuing to use it as a language for experimenting with Casper simulations, but I welcome proposals from the community for how and if it can find a niche in other contexts.