Hello, and thank you very much for your answers!
Let's start by just saying that I still have a lot to learn.
I wrote this yesterday under the effects of several substances that I should not name without the presence of my lawyer.., and now that I read it again I realize two things:
The first one, is that all this can be simplified as just treating every 100th block as an overblock (probably a better name now would be reference block), so there is no need to create a second blockchain.
The second point: I never talked about storing all UTXOs, that would be pointless, I was talking about storing addresses and their balance, and as far as I know, that would be way a lot smaller than all UTXOs.
Still, as you said, we are trying to solve a Size problem by increasing the size, I know, but the point of all this is that, at some point, we won't need all the blocks that were before the reference block number X, and we can start dumping those blocks (even the reference blocks) and only keep headers.
If someone sends bitcoins to you, you can validate those bitcoins two ways: normal way by going back through the blockchain until arriving to the mining of those bitcoins (yes, I know you do this by using tx inputs and outputs, but you need to get to the point were those bitcoins were mining if you want to fully validate them, or at least go deep enaugh). With my idea, you should only go back through the blockchain until you arrive to the first reference block that verifies that the given address had enough balance.
In order to know the balance of an address we have to check for all bitcoins that address has received, and substract to that the bitcoins it has sent. By having reference points (a file that says this address has this balance), we don't need to check the transactions behind that reference point (reference block).
Also assuming we constantly have full blocks (1 MB every 10 minutes) [ ... ]
That Mb per 10 minutes cap will have to be changed eventually if the bitcoin usage grows, or else the transaction fees would start growing and the probabilities that a transaction never gets confirmed will be higher.
What happens if a person with a 10 BTC balance tries to send you 8 BTC and, at about the same time, send someone else 7 BTC?
I don't know at what point my idea interferes with the double spending protection, but I guess, what would happen is just that we would have to wait for the next mined block to see which one of those transactions has been included, thus confirmed.
There is a problem with this idea. There might be more problems but this is the only one I thought of so far. (Correct me if I am wrong here) When you want to spend bitcoins, in the transaction data that you will have to broadcast you must specify the tx inputs. If those inputs were received far in the past, they might be in a block that you have dumped, and then you don't have that tx inputs ids. You know that the address has the balance, because you can tell it by checking the latest reference block and transactions done after that, but you need the tx input to spend it. I would say that this can be solved by adding a simple rule to the bitcoin network: a transaction must specify tx inputs, but can also specify the ID of a reference block that specifies that the address has enaugh balance. Again if you try to double spend this way, the network would reject the invalid transaction.
I would love to hear real problems about this idea, but so far everything you have posted are not real problems. Maybe a reference block every 100 blocks is too often and the data reduction would be insignificant, we maybe we have to change it to 1,000, but the idea is the same. Don't get me wrong here, I know there must be lots of problems, but finding problems and finding solutions is all fun
I think that this idea could work well and solve the big size problem, except for the fact that I am very sure there is a better way of doing it. But the only way to get to it is by thinking!
And remember this is all about having fun, we are not bitcoin developers and they won't look for ideas on this forum. I just have fun thinking of this things, but always in a healthy way.
