I just want to say that I don't doubt your concerns, and share few of them myself, but I do think this is an idea worth exploring and I want to try to address some of your concerns (this will be long).

In general, a for profit company with a low to no stake in Bitcoin should not be trusted to make changes to the protocol that facilitate its profit making. Especially if it's gone out and hired core devs and comes at the expense of the competition.

It seems to me that there have been a few other people had came up with this idea independently. It seems like killerstorm idea was very similar and etotheipi had similar ideas. So I wouldn't say that it's all originating from Back (who seems to be an altogether well put-together individual who wants to extend benefits of cryptography, not just Bitcoin, to the general public). A lot of great ideas seemed to come out of the Ultimate Blockchain Compression thread... and those threads seemed to originate from a forward thinking group of people, not all of them core devs. The sidechain idea seems like a fairly good solution to some of those issues.

I would like to know who these core devs are supposedly supporting the whole concept besides gmax who has gone on record saying Bitcoin needs to be "fixed". I don't understand the secrecy as I've asked for those names several times. I for one don't think Bitcoin needs fixing.

I would like to know this, too. It seems as if Mike Hearn and jgarzik are less than enthusiastic about it, but I could be reading too much into their comments. Gavin seemed to think the idea was worth exploring, although the comment came from a tweet.

I think it's also important to point out the code changes will necessarily allow others to explore these concepts as well... the two-way peg that's really the "core" of this idea seems to be very discrete, if it's implemented, Back's company may be "Xerox'd" out of there own innovations. We don't even have a great idea of what they are planning on doing, but I would almost bet it's based on consulting. Also dev's shouldn't be kept from profit-making ventures based on the ideas they've implemented in Bitcoin. Gavin has a consulting gig with coinbase. jgarzik is with Bitpay. They should be paid well for what they are contributing. There has to be an interesection of pragmatics and theory.

I've always conceptualized Bitcoin as being a self contained financial system so I am concerned that it's fundamental value units will be allowed to leave its system destined for what will inevitably be a weaker sidechain from a security standpoint.

It really depends on how well thought out the security model is and for that we need the whitepaper and code. I agree this is a sticking point. I've always considered bitcoin as a global asset ledger. It's security model as absolute as it can be, but the owner of the coins can choose whatever they want to do with them within reason. And as long as the "security firewall" is reasonably simple and relies on tried-and-true crypto I see no problem with it being implemented. After all, P2SH was implemented.

Bitcoins are a fundamental value unit that was made for its network and only for that network in my opinion and now we want to let them move off that network potentially never to return. Satoshi never provisioned for this. That doesn't feel right to me.

Even if Satoshi didn't provision for this, it doesn't mean anything. Satoshi was not infallible. I have the original source sitting on my computer. I've looked through it. There were bad design decisions that can only been seen in retrospect (paying to IP addresses, original ideas on how to handle certain types of denial of service attacks, and so on). I really don't think his writing can adequately prove he would support this idea or not. But I'll link to something he wrote that seems to be at least tangentially related. https://bitcointalk.org/index.php?topic=195.msg1611#msg1611

The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

The script is actually a predicate. It's just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.

I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.

Emphasis mine. As we know, this idea got neutered in subsequent versions due to the large attack surface. To me, those ideas should be reintroduced as we can understand them. Those disable OPCODES for the most part would almost allow someone to implement a side-chain in a permissionless way anyhow.

My model for how Bitcoin should be is very similar to yours, btw. I just think the sidechain idea allows an awesome amount of extensibility while not bloating the "core" with those awesome ideas. Ethereum is a wonderful idea. I love the idea, I'll probably get some, but it seems to me the attack surface is going to be ginormous. I'd rather have Bitcoin be the "wheel-hub" rather than Ethereum. As it stands, Bitcoin's script/P2SH is too neutered to allow that to happen, but only just so.

Ok this post got long and I don't even think I got anywhere near addressing all the concerns, but to me this is an idea worth pursuing to the point where it can be implemented. There is a certain irony that lies beneath all of this: a stripped down altcoin with just the opcodes necessary to support "sidechains" would likely be a worthwhile pursuit.