You have some fundamental misunderstanding of the system.
I advice you to watch this: https://www.youtube.com/watch?v=t3hJsFpPmXs and read this: https://bitcoin.org/bitcoin.pdf
Topic: Solution for the Big Size of the Blockchain. (Read 1219 times)
Yes, there are concerns about the size the blockchain can get. This is partially what the Bitcoin XT fork controversy is all about. I would suggest you read more threads posted on this board. This is the best place to learn about Bitcoin.
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).
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.
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.
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.
- a list of all addresses that contains bitcoins right after the last block included here, and the balance of each address.
The UTXO dataset is currently 1.11 GB (2.d.p), Your overblocks would be about 2000 times larger than the average Bitcoin block.
So, if that overblock contains the blocks 1 to 100, and in the block 101 is written that some address has sent you money, then you just have to look back to that overblock to see if that address had enaugh balance.
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?
It's all about mining. Transactions become trustable when they are mined into the blockchain, because each block have a cost of generating. I propose to add an overblockchain, that resume X amount of blocks drastically, since an overblock only includes:
Satoshi had a similar concern about the potential blockchain size. He also considered a system where some users could reasonably well trust a transaction not by verifying its entire history but just by checking that it's buried deeply enough in the blockchain. He described this in his 2008 whitepaper, section 8. It's only 14 lines of text and a diagram and it's not too technical. Check it out here.
Hello, my name is nathan and I hope I don't screw up with my first post
Transactions are being sent like dozens per second,
Transactions are being sent like dozens per second,
Nope, not even durring the last spam attack. The last peak TX according to blockchain.info1 was 214,487 tx in july. Thats 214,487/(60*60*24) 2.4 TX per second.
and miners have to work hard on creating blocks as a system for building a reliable and trustable unique blockchain that contains all verified transactions ever made since the very first one.
One problem about this system is that, in order to know the current balance of a particular address, we have to check the blockchain for all transactions it has received, and from what addresses. Then, we have to also check all transactions of all those addresses to check if they had enaugh balance, and you have to go like this all way back to where those particular bitcoins where generated by mining, so then you can verify the balance of that address. So, we have a big problem, that is getting bigger every second, way bigger, and definitely could be 1TB soon, that big.
One problem about this system is that, in order to know the current balance of a particular address, we have to check the blockchain for all transactions it has received, and from what addresses. Then, we have to also check all transactions of all those addresses to check if they had enaugh balance, and you have to go like this all way back to where those particular bitcoins where generated by mining, so then you can verify the balance of that address. So, we have a big problem, that is getting bigger every second, way bigger, and definitely could be 1TB soon, that big.
No, thats not how bitcoin works. You can work your way back for every currently existing unspend output, but you dont have to. Its enough if you check whether the TX is valid and keep and set of all known unspend outputs aka UTXO.
Also assuming we constantly have full blocks (1 MB every 10 minutes) and currently the blockchain is 50 GB in size (its not that big yet) we would need another 1000GB-50GB * 1000 * 10min = 9.5*10^6 minutes or 18 more years to reach 1 TB. I would not call that soon. Considering the instantly switch to XT and get 8 MB blocks now it would still take over 2 years (not considering further growth for simplicity).
There's people that doesn't really mind about this, they say webwallets are a good solution, but remember bitcoin is all about decentralization, remember mtgox.
Im not sure what your point is here, but decentralization is indeed what makes bitcoin or crypto currencies in general special.
So, I think I have a solution for this, but I don't know if it could be implemented or if it is not a good practice. So here it goes, this is my idea:
It's all about mining. Transactions become trustable when they are mined into the blockchain, because each block have a cost of generating. I propose to add an overblockchain, that resume X amount of blocks drastically, since an overblock only includes:
- the hash of the previous overblock (just like with normal blocks do with the previous block)
- the hashes of all blocks, one by one, from the first one to the last one this overblock includes (it has to include at least 100 more blocks than the last overblock)
- a list of all addresses that contains bitcoins right after the last block included here, and the balance of each address.
It's all about mining. Transactions become trustable when they are mined into the blockchain, because each block have a cost of generating. I propose to add an overblockchain, that resume X amount of blocks drastically, since an overblock only includes:
- the hash of the previous overblock (just like with normal blocks do with the previous block)
- the hashes of all blocks, one by one, from the first one to the last one this overblock includes (it has to include at least 100 more blocks than the last overblock)
- a list of all addresses that contains bitcoins right after the last block included here, and the balance of each address.
So in order to save data you want to add more data by storring the UTXO set every 100 blocks on the blockchain?
So, if that overblock contains the blocks 1 to 100, and in the block 101 is written that some address has sent you money, then you just have to look back to that overblock to see if that address had enaugh balance.
The mining of this overblocks is rewarded to the miner with bitcoins, just like blocks are, but from now on, blocks will only receive half of what they received (half of the -currently- 25BTC and half of the fees) the other half will be rewarded to the overblock miner.
The mining of this overblocks is rewarded to the miner with bitcoins, just like blocks are, but from now on, blocks will only receive half of what they received (half of the -currently- 25BTC and half of the fees) the other half will be rewarded to the overblock miner.
So an overblock would be awarded 100*25/2 = 1250 BTC?
And the difficulty of overblocks should be 100 times higher than the difficulty of the last block included, which means that every 100 blocks (that would ideally represent 16.45 hours, an overblock will be mined).
So, maybe when we have more than 100 overblocks, we can start dumping normal blocks, and keep only the ones included in the last 100 overblocks.
Of course you can set your wallet to keep everything, for example if you are a website and want it to be public or something, but it would really save space to people that don't want that much data.
So, start telling me the probably hundreds of problems this could lead us to, but please don't be mean, I am a nice guy when you get to know me
So, maybe when we have more than 100 overblocks, we can start dumping normal blocks, and keep only the ones included in the last 100 overblocks.
Of course you can set your wallet to keep everything, for example if you are a website and want it to be public or something, but it would really save space to people that don't want that much data.
So, start telling me the probably hundreds of problems this could lead us to, but please don't be mean, I am a nice guy when you get to know me
I hope you dont consider it mean to point at flaws in your reasoning. Your solutions sounds like something you though about a little without too much knowledge off how bitcoin actually works. Do not let that stop you from thinking further about possible solutions to scaling problems, but its probably best if you read more about bitcoin to understand better where a solution is needed.
Pruning2,3 is something that is actually implemented currently. Its just not working with a full node that acts as a wallet yet. Pruning is similar to what you suggest without the extra data. The client forgets about certain blocks and only keeps the data it needs.
1 https://blockchain.info/charts/n-transactions
2 https://www.reddit.com/r/Bitcoin/comments/33oz97
3 https://www.reddit.com/r/Bitcoin/comments/33qv3a/pruning_support_what_is_it_and_where_might_it/
Hello, my name is nathan and I hope I don't screw up with my first post
Transactions are being sent like dozens per second, and miners have to work hard on creating blocks as a system for building a reliable and trustable unique blockchain that contains all verified transactions ever made since the very first one.
One problem about this system is that, in order to know the current balance of a particular address, we have to check the blockchain for all transactions it has received, and from what addresses. Then, we have to also check all transactions of all those addresses to check if they had enaugh balance, and you have to go like this all way back to where those particular bitcoins where generated by mining, so then you can verify the balance of that address. So, we have a big problem, that is getting bigger every second, way bigger, and definitely could be 1TB soon, that big.
There's people that doesn't really mind about this, they say webwallets are a good solution, but remember bitcoin is all about decentralization, remember mtgox.
So, I think I have a solution for this, but I don't know if it could be implemented or if it is not a good practice. So here it goes, this is my idea:
It's all about mining. Transactions become trustable when they are mined into the blockchain, because each block have a cost of generating. I propose to add an overblockchain, that resume X amount of blocks drastically, since an overblock only includes:
- the hash of the previous overblock (just like with normal blocks do with the previous block)
- the hashes of all blocks, one by one, from the first one to the last one this overblock includes (it has to include at least 100 more blocks than the last overblock)
- a list of all addresses that contains bitcoins right after the last block included here, and the balance of each address.
So, if that overblock contains the blocks 1 to 100, and in the block 101 is written that some address has sent you money, then you just have to look back to that overblock to see if that address had enaugh balance.
The mining of this overblocks is rewarded to the miner with bitcoins, just like blocks are, but from now on, blocks will only receive half of what they received (half of the -currently- 25BTC and half of the fees) the other half will be rewarded to the overblock miner.
And the difficulty of overblocks should be 100 times higher than the difficulty of the last block included, which means that every 100 blocks (that would ideally represent 16.45 hours, an overblock will be mined).
So, maybe when we have more than 100 overblocks, we can start dumping normal blocks, and keep only the ones included in the last 100 overblocks.
Of course you can set your wallet to keep everything, for example if you are a website and want it to be public or something, but it would really save space to people that don't want that much data.
So, start telling me the probably hundreds of problems this could lead us to, but please don't be mean, I am a nice guy when you get to know me
Transactions are being sent like dozens per second, and miners have to work hard on creating blocks as a system for building a reliable and trustable unique blockchain that contains all verified transactions ever made since the very first one.
One problem about this system is that, in order to know the current balance of a particular address, we have to check the blockchain for all transactions it has received, and from what addresses. Then, we have to also check all transactions of all those addresses to check if they had enaugh balance, and you have to go like this all way back to where those particular bitcoins where generated by mining, so then you can verify the balance of that address. So, we have a big problem, that is getting bigger every second, way bigger, and definitely could be 1TB soon, that big.
There's people that doesn't really mind about this, they say webwallets are a good solution, but remember bitcoin is all about decentralization, remember mtgox.
So, I think I have a solution for this, but I don't know if it could be implemented or if it is not a good practice. So here it goes, this is my idea:
It's all about mining. Transactions become trustable when they are mined into the blockchain, because each block have a cost of generating. I propose to add an overblockchain, that resume X amount of blocks drastically, since an overblock only includes:
- the hash of the previous overblock (just like with normal blocks do with the previous block)
- the hashes of all blocks, one by one, from the first one to the last one this overblock includes (it has to include at least 100 more blocks than the last overblock)
- a list of all addresses that contains bitcoins right after the last block included here, and the balance of each address.
So, if that overblock contains the blocks 1 to 100, and in the block 101 is written that some address has sent you money, then you just have to look back to that overblock to see if that address had enaugh balance.
The mining of this overblocks is rewarded to the miner with bitcoins, just like blocks are, but from now on, blocks will only receive half of what they received (half of the -currently- 25BTC and half of the fees) the other half will be rewarded to the overblock miner.
And the difficulty of overblocks should be 100 times higher than the difficulty of the last block included, which means that every 100 blocks (that would ideally represent 16.45 hours, an overblock will be mined).
So, maybe when we have more than 100 overblocks, we can start dumping normal blocks, and keep only the ones included in the last 100 overblocks.
Of course you can set your wallet to keep everything, for example if you are a website and want it to be public or something, but it would really save space to people that don't want that much data.
So, start telling me the probably hundreds of problems this could lead us to, but please don't be mean, I am a nice guy when you get to know me
Jump to: