I discussed this idea with some other core developers (on IRC) and they generally seem to agree that it can be done.

It may be equivalent to an idea called "blockchain extensions" but when I looked it up on bitcointalk.org I didn't see exactly the same proposal I am making.

One person suggested I should replace the address to chain function with a protocol addition that allows one to specify the target chain. Yes, this can also be done without changing the key properties.

One person said that the main problem is that I am not saying anything specific, and I should address the sidechain problems written about in the sidechains paper. Well, actually, there is one quite specific thing I am saying, in case you didn't notice: With this system, the network can achieve effectively 5^{n-1} MB blocks with each participant only storing n MB blocks. So for example, you can have effectively a block size of 625 MB (= 5^4) with each participant only storing 3 MB blocks; or 3.125 GB blocks with each participant only storing 4 MB blocks. For these calculations, I am assuming that only two separate sibling chains are involved in a transaction, so there is a duplication effect that divides in two the effective size of a given level of blocks (that's why it's 5 instead of 10 as would be without duplication). If you want to involve multiple sibling chains in one transaction, you can effectively achieve this by performing multiple transactions involving 2 of the multiple chains. Yes, the fees would be higher since you have more transactions to make, but it is reasonable to expect more fees for more complicated transactions, and I don't think it will result in people clustering on one chain (people who do these kinds of transactions would probably track multiple chain paths). As for the problems with sidechains, I think they would be eliminated due to the child-parent dependence I specified. I also propose the following additional rule: In case of conflict between parent and child chains (due to reorganizations), the child chain must choose the consensus of the parent chain. Also, for transferring from child to parent, the miners on the parent have the final say, but to make it more clear, they can use the relative difference of difficulty between their chain and the child chain to decide how many blocks deep a transaction in the child chain has to be to be accepted in the parent chain.

Gavin was the only one who disapproved of this, but I am not sure if he actually read the whole thing that I wrote. He said something along the line of "the outputs will span the subchains" and when I asked for an explanation he just said that I need to learn more about things. I stated to him my willingness to learn, but have yet to get a response from him.

Mike: You should also keep in mind the big picture when it comes to decentralization. If the hard drives (or tapes) can only be produced by a small number of large companies like Western Digital or Seagate, then you can't really count those for a decentralized system. A truly decentralized system would have the devices needed to participate in (and verify) the system be easily created by a regular user of the system without relying on a central power. So for example, the hard drives needed to store the bitcoin transaction records should be able to be produced at a regular person's home on a 3D printer starting from just the raw materials. I don't know how close we are to this ideal, but just pointing out that it needs to be considered. This is also a reason why I like that Bitcoin uses the simple SHA sum for mining instead of a more complicated function such as scrypt. It makes it easier for small scale entities to understand and to produce the ASIC miners. Also, in addition to the centralization of storage device manufacturing, one should also consider what would happen if everyone wanted to have a 5 TB drive at home. What would happen to the price of hard drives? Keep in mind also that the human population is likely increasing, so there are less real resources per person... Yes maybe in the future we can solve these problems, but we still haven't, so let's not assume they are solved. Also, you mentioned sharing the costs of a hard drive with other people. Do you mean trusting that others did not compromise the hard drives? If you want you can do so, but not every participant should be forced to trust others, a point I think I made already. And finally, this is all a discussion on the costs of running a Bitcoin node. Bitcoin is not all that people will use hard drives and computers for; we need to leave room for other things.

So Mike, I have a question for you. Are you supporting a block size increase partly due to philosophical reasons (i.e. you believe that regular people shouldn't have such strong freedom as I want) or do you just not care so much about the long term future and you just want to get your Bitcoin related projects up and running with minimal complications? Or is it a combination of both things? You should disclose this to the people following your words because they trust you as an experienced professional with a good reputation, and it would be dishonest to not disclose this to them. (same goes for Gavin)

Overall, I think this system is the only system that I heard of that can scale decentralization without a block size increase. Lightning by itself, for example, requires a block size increase that depends on how many such Lightning contracts are being made, so relies on people changing the protocol, which is obviously less secure and robust than a fixed protocol. But I am not ruling out any other possibilities, so other things should also be considered. But eventually, we may have to decide how to scale without knowing for sure whether the chosen scaling method is the ultimate scaling method. And I think this is a good candidate for that, and also, can be reversed later on without changing the original protocol before the softfork. Actually, we can just make nodes advertise whether they support the soft fork or not, and if a better scaling protocol comes along, those nodes can switch to advertise the better one. So it is quite a harmless soft fork to make, in my opinion.