I completely do not understand your proposal it's enormously complex and relies on additional communication providing data which might or might not be available. But reading your ideas I have my own idea:
(Editi/Addition:Ok, now I understand your proposal better, I didn't know what a ledger is lol
I think our ideas are similiar, except my idea was to create a new protocol to exchange the ledger hashes, apperently your idea is to embed those into the block chains, so no new protocol would be necessary, However a drawback of your idea would be that only miners get to verify the ledger/balance sheet, an obvious flaw I think
It needs to be seperated so everybody can have a vote on it !
Then again, blocks are the way the network protocol and verification works, this could mean miners are now in control and decide what transactions are valid and which are not, those it seems bitcoin is coming down crashing and burning it's no longer p2p, it's no longer everybody in control, only the miners are now in control, probably a very dangerous situation
at least non-miners can still verify, but rejecting will be useless it seems, since they can never win).
How about this instead:
1. Instead of storing all transactions which ever occured, a point in historic time is chosen, where the software makes up the balances of all bitcoin addresses.
2. Bitcoin addresses which have turned into zero balances are thrown away.
3. Instead of storing the transactions, the balances are stored, which could cut back on data.
What kind of problems could this solution face and what could be the additional solutions:
1. Somebody could change it's own balance in it's own data, to give himself a million dollars.
This would then conflict with the datasets of others.
An idea could be to calculate a hash over all bit coin address balances.
This hash is then broadcasted throughout the system.
The number of confirmations is tracked.
If the majority agrees that the hash is indeed correct it is accepted into a "balance chain".
To make it a little bit more difficult to fake this balance chain, the hash could follow the principle of "difficulty", except since there is no rush, the difficulty could be set 100x times the current difficulty.
(Perhaps the difficult setting for the balance should match the number of "transaction/blocks collapses" * "current difficulty". In other words, blocks are calculated every 10 minutes, the balance block is calculated every 1000 blocks. So the difficulty for the balance chain is 1000x the block difficulty, which should keep both in sync).
Seems simply enough idea.
In principle there is probably no difference between "storing transactions" or "storing the sum of all those transactions" ?!?!?
Except that those transactions are "hashed into a block chain".
Well the same can be done with a "balance chain".
Perhaps it should also become a "racing balance chain" where the longest balance chain wins.
The difference is however: the balance chain is much harder to calculate.
Also the balance chain lags behind the transaction chain, by for example 1000 or 2000 blocks.
So the transaction chain gets a chance to stabilize, so the balance chain can work on stabilized transaction/block data.
