You are discussing two issues that IMHO it's already resolved in my proposal or a followup:
Efficient tree update: The update functions only recalculates the hashes affected by the changes of each block. Those changes can be reversed, as long as the block is valid (i.e. there's no double spends), therefore it will be easy to roll-back in case of getting orphaned blocks.
Where to save the roots: In my proposal I explain how to roll it out in the coinbase of the existing chain, but nullifying the risk of a chain split by rejecting blocks with invalid root only when there are more than 55% of valid roots in a specific time span.
For extra security (and this is what isn't originally in my proposal), the root should be accompanied by a hash of the previous+current valid roots, effectively making a secure blockchain from day one. But after it's deployed widely, it will be unnecessary, as we'll know miners will reject blocks with invalid roots. Miners won't reject blocks without roots. Blocks with valid root but without this blockchain-ish hash won't be rejected either (so we can drop this hash when it's not longer necessary).
In this way, creating a separate chain is just a temporal fix for something that will be in the main chain some day.
DiThi,
I see this from a different angle.
(1) The tree-part of my proposal should be seen as an extension of yours. I'm sure my idea was inspired from reading yours a long time ago. The difference being that extra complexity is added to the tree structure to accommodate the most common use-case: requesting address balances. My tree structure guarantees that you can not only get any TxOut, but you can get
all TxOuts for a given address/script and have no doubts that it's correct.
I believe this is a worthy trade-off, comared to your tree structure, as it removes a channel of uncertainty for the operator, and removes a channel for shenanigans from those who wish to deceive you. And in the end, it's not actually that much more complicated. It's simply more-tailored for the way that users need to access the network.
(2) As echoed by others, I believe that a hard-forking blockchain change is going to only happen in the event of a crisis. To do so requires more than democracy -- it will seriously impact the entire network in a detrimental way. There are users who are still using version 0.3.X bitcoin clients not because they want to, but because it works, and they don't follow the forums or Bitcoin news or anything of the sort. And the hard fork exposes them to all sorts of malicious behavior by others who would exploit their ignorance of current events and manipulate the abandoned chain that they are stuck on.
To maintain confidence in the system, a hard fork is going to need more than democracy -- it's going to need super-majority, probably 80-90% ... and gaining that level of consensus is pretty much impossible for new ideas that are not well-understood --
unless the idea has been in the wild, and in use for many months/years and is already used by 80%+ people.
The idea of using a second blockchain is actually a way of creating a "staging area" for such ideas on the main network (like galambo said) without actually risking exposing that network to any of the unforeseen issues that could arise. It can be used to add such functionality to the network without actually changing the network.
In this way, the meta-chain can grow and develop as people start using it and understanding it. People start building infrastructure on
the availability of the information in that chain. Once it has become ubiquitous enough and time-tested as a pillar of a part of the network, then you have 80%+ agreement amongst users without even having to ask for it. At this point, a hard-fork is entirely feasible -- or at least orders of magnitude less disruptive.
You're right, it's not the only way, but I think it's about as good as it's going to get.