Bitcoin's blockchain size

[brainactive]

Bitcoin's block chain size is currently around 300GB and increasing. How much of an issue is this in the future? If internet speeds and storage capacity increases at the same pace as Bitcoin's blockchain size, then this is probably not a big deal but what if the increase in the blockchain size outpaces it? What are the implications? Would less people be able to run nodes/mining and therefore threaten decentralisation? Are there any other threats that need to be considered?

[1714974585]

1714974585

[1714974585]

1714974585

[1714974585]

1714974585

[1714974585]

1714974585

[NeuroticFish]

Bitcoin's block chain size is currently around 300GB and increasing. How much of an issue is this in the future? If internet speeds and storage capacity increases at the same pace as Bitcoin's blockchain size, then this is probably not a big deal but what if the increase in the blockchain size outpaces it? What are the implications? Would less people be able to run nodes/mining and therefore threaten decentralisation? Are there any other threats that need to be considered?

This silliness keeps coming out now and then. If you are genuinely interested, why didn't you search a little on the forum?
As calculated here, it takes at least 5 years for each 1 TB in the blockchain. And 1 TB of HDD is cheap and gets cheaper by every year passing.
Then, you should know that a node needs to download big amount of data only at the first sync, until it's catching up. Afterward the stress on the internet connection is not that big. And internet, again, is evolving to larger bandwidth and cheaper.
So... do you see any real problem? Cause I don't.

[Upgrade00]

In addition to what NeuroticFish said above, one does not necessarily need to download the entire gigabyte of data to run a node, that's the reason pruned nodes exist;
Not everyone even now wishes to run a full node, or have the capacity too, they can instead run a pruned node  As a pruned node; you only store the most recent transactions history, based on your configuration. But they still contribute to the Network

[brainactive]

This silliness keeps coming out now and then. If you are genuinely interested, why didn't you search a little on the forum?
As calculated here, it takes at least 5 years for each 1 TB in the blockchain. And 1 TB of HDD is cheap and gets cheaper by every year passing.
Then, you should know that a node needs to download big amount of data only at the first sync, until it's catching up. Afterward the stress on the internet connection is not that big. And internet, again, is evolving to larger bandwidth and cheaper.
So... do you see any real problem? Cause I don't.

Sorry I didn't mean to come off ignorant. I also think there are no serious problems with the blockchain size but I just wasn't sure if (a) I was missing anything and (b) if there's any merit to having a smaller blockchain size.

This came about when I looked at what the Mina blockchain was doing. They use zk proofs to keep blockchain size fixed at 22kb but it obviously has a lot of trade-offs and can lead to problems if the full history needs to be accessed. And their archived full chain is currently stored on Google Cloud lol.  

[Wind_FURY]

Bitcoin's block chain size is currently around 300GB and increasing. How much of an issue is this in the future? If internet speeds and storage capacity increases at the same pace as Bitcoin's blockchain size, then this is probably not a big deal but what if the increase in the blockchain size outpaces it? What are the implications? Would less people be able to run nodes/mining and therefore threaten decentralisation? Are there any other threats that need to be considered?

This silliness keeps coming out now and then. If you are genuinely interested, why didn't you search a little on the forum?

As calculated here, it takes at least 5 years for each 1 TB in the blockchain. And 1 TB of HDD is cheap and gets cheaper by every year passing.

Then, you should know that a node needs to download big amount of data only at the first sync, until it's catching up. Afterward the stress on the internet connection is not that big. And internet, again, is evolving to larger bandwidth and cheaper.

So... do you see any real problem? Cause I don't.

The counter-argument to that is, not everyone has the same access to large bandwidth, or would care to upgrade their internet connection, or their hardware, just to run a node.

Bitcoin's block chain size is currently around 300GB and increasing. How much of an issue is this in the future?

If internet speeds and storage capacity increases at the same pace as Bitcoin's blockchain size, then this is probably not a big deal but what if the increase in the blockchain size outpaces it? What are the implications?

Would less people be able to run nodes/mining and therefore threaten decentralisation? Are there any other threats that need to be considered?

It's always better to overshoot the decentralization/security of the network, than undershoot. The Bitcoin blockchain should also be made as redundant as possible for new nodes.

[ranochigo]

This silliness keeps coming out now and then. If you are genuinely interested, why didn't you search a little on the forum?
As calculated here, it takes at least 5 years for each 1 TB in the blockchain. And 1 TB of HDD is cheap and gets cheaper by every year passing.
Then, you should know that a node needs to download big amount of data only at the first sync, until it's catching up. Afterward the stress on the internet connection is not that big. And internet, again, is evolving to larger bandwidth and cheaper.
So... do you see any real problem? Cause I don't.

Increasing the on-chain capacity will result in an exponential increase in the block size over a given period of time. Going by the general usage of it's user, it is very likely that as the database size gets bigger, we'll see fewer users running full nodes. Reason being, no one wants to synchronize for hours or days to use Bitcoin, adding another hour of synchronization every time they open their client.

The problem isn't really about how expensive the storage is. Yes, it is getting cheaper but no one would realistically get a new HDD every now and then solely for Bitcoin when there is a far more convenient alternative available. I can see it being a problem if bootstrap synchronization is still the modus operandi in the future and thus discouraging the general userbase to be running Bitcoin nodes.

It is possible for certain compression to be used on block data or transaction size. Problem being that there is also a certain degree of tradeoff for your CPU as well.

[NeuroticFish]

I also think there are no serious problems with the blockchain size

That's good. And I would have loved to see you start with that. There are plenty of people on this forum trying to spread FUD on various topics, including this one, and one of the methods seems to be by asking "innocent questions" like this.

but I just wasn't sure if (a) I was missing anything and (b) if there's any merit to having a smaller blockchain size.

Smaller blockchain would mean less information is stored and from what I know all the information there is important, or some sort of compression for storage and transfer. But compression would bring no real benefit (HDD is cheap, remember?) and it would mean a need for more computational power here and there (while some run nodes on Raspberry Pi today) and would mean identical data size to be transferred after the initial sync ends.

This came about when I looked at what the Mina blockchain was doing. They use zk proofs to keep blockchain size fixed at 22kb but it obviously has a lot of trade-offs and can lead to problems if the full history needs to be accessed. And their archived full chain is currently stored on Google Cloud lol.  

I am not familiar with Mina, but the Google cloud part doesn't look much reassuring  


It's as simple: underlying hardware is advancing, getting bigger and cheaper, hence if this is not a big problem now, it should also not be in the future.

It is possible for certain compression to be used on block data or transaction size. Problem being that there is also a certain degree of tradeoff for your CPU as well.

It's interesting that we both thought on compression. But I don't think that it can make that much of a difference...
And yes, I agree that the size can scare the users. But on the other hand those who need 1h for sync at each start don't matter that much for decentralization, right? The users we need would keep their nodes running closer to 24/7...

[ranochigo]

It's interesting that we both thought on compression. But I don't think that it can make that much of a difference...
And yes, I agree that the size can scare the users. But on the other hand those who need 1h for sync at each start don't matter that much for decentralization, right? The users we need would keep their nodes running closer to 24/7...

It will but whether it is worth it for the additional strain on CPU is a whole other question.

Actually every little bit helps. I personally don't think Bitcoin benefits substantially from having nodes within datacenters because that creates some centralization within the network as the node operators don't really have any control over it. I run a node within a datacenter because I have other uses for the server as well and I'm using the node for analytics. I would prefer for a network that comprises of regular users running nodes (albeit sporadically) than to have them distributed around the DCs.

Realistically, most users don't want to spend so much just for running a node. Bootstrapping on Raspberry Pi takes a week or so, and assuming the HDD doesn't crash. That is about how much most users would spend to run a node. It is terribly slow but there really isn't a choice.

On-chain capacity probably will have to be increased some point in the future. So it will become an issue sooner or later, provided that we don't do anything about it. Moore's law is more or less done for in the near future anyways.

[NeuroticFish]

I personally don't think Bitcoin benefits substantially from having nodes within datacenters because that creates some centralization within the network as the node operators don't really have any control over it.

That's correct indeed.

Bootstrapping on Raspberry Pi takes a week or so, and assuming the HDD doesn't crash. That is about how much most users would spend to run a node. It is terribly slow but there really isn't a choice.

Imho it's a one-time operation and you basically just leave it running. I know that people don't have enough patience though. I don't know how good or bad Pi performs as node though.

On-chain capacity probably will have to be increased some point in the future. So it will become an issue sooner or later, provided that we don't do anything about it. Moore's law is more or less done for in the near future anyways.

This is the part where I can tell "please don't count on that". Since off-chain can bring the heavy load, I think that it's normal for on-chain remain restricted (may need a better word here, I am thinking at block size only, no other restriction) and expensive. If we don't do that we may end up with miners leaving when the block rewards get too small.

[vjudeu]

How much of an issue is this in the future?

Not that much as you may think. Transaction joining is now possible with Pedersen Commitments (not in Bitcoin, but I guess it will be implemented sooner or later). Maybe joining shares will be possible in the future, if so, then everything could be compressed just to one huge block with enormous Proof of Work. But even transaction joining alone could compress a lot of transactions and you could for example receive compressed transactions from the last two weeks, that should speed up verification.

[ranochigo]

Imho it's a one-time operation and you basically just leave it running. I know that people don't have enough patience though. I don't know how good or bad it performs as node though.

Quite bad from my personal experience.

This is the part where I can tell "please don't count on that". Since off-chain can bring the heavy load, I think that it's normal for on-chain remain restricted (may need a better word here, I am thinking at block size only, no other restriction) and expensive. If we don't do that we may end up with miners leaving when the block rewards get too small.

You can introduce some form of scarcity, but only up to a point. Afterwhich, the benefits start to taper off and you're better off increasing the block size to increase both the capacity of the network as well as to help the miners increase their income. Being on ~4vMB blocks for the near future is absolutely not okay and it should not be an option at all. You do need on-chain transactions for second-layer solution. It is impossible to support them without having on-chain transactions, for opening/closing channels for example.

[NeuroticFish]

and you're better off increasing the block size to increase both the capacity of the network as well as to help the miners increase their income.

We are still far from the point (although it's years, not decades), but.. let's see what the hardware brings too in that time, OK?

Being on ~4vMB blocks for the near future is absolutely not okay and it should not be an option at all. You do need on-chain transactions for second-layer solution. It is impossible to support them without having on-chain transactions, for opening/closing channels for example.

Indeed, second layer channels do need on-chain operations. I knew that. But we don't know yet how big will be the need to open and close channels. Well thought channels will not need closing because they'll keep carrying transactions in both directions. Am I missing something there?

[brainactive]

That's good. And I would have loved to see you start with that. There are plenty of people on this forum trying to spread FUD on various topics, including this one, and one of the methods seems to be by asking "innocent questions" like this.

I don't feel the need to preface every question with a reinforcing statement for Bitcoin. The best way to prevent FUD is to provide logical counter-arguments to questions you think is FUD, rather than silence people for asking questions which critique Bitcoin's status quo.

It's as simple: underlying hardware is advancing, getting bigger and cheaper, hence if this is not a big problem now, it should also not be in the future.

Agree that hardware is advancing and getting bigger. So is the size of the blockchain. The question then becomes the relative rate of increase. The graph in the link below shows the increase in the size of the blockchain over the last decade.

In 2015, it was around 40GB. It is now over 300GB. My computer has a hard drive with 500GB. While I would've been happy to download the block in 2015, it is now too big for me. Yes, I could easily fork out another $100 to buy a new hard drive but this is something I wouldn't have needed a few years ago.

https://www.statista.com/statistics/647523/worldwide-bitcoin-blockchain-size/

[ranochigo]

We are still far from the point (although it's years, not decades), but.. let's see what the hardware brings too in that time, OK?

Well, we've experienced quite a few bouts of elevated fees nowadays and probably is discouraging adoption as well. Not as far as you think.

Indeed, second layer channels do need on-chain operations. I knew that. But we don't know yet how big will be the need to open and close channels. Well thought channels will not need closing because they'll keep carrying transactions in both directions. Am I missing something there?

Not really. LN is more suitable for microtransactions due to the liquidity of the channels and you will at some point require on-chain transactions. It's simply impossible for us to function solely on LN, or at least without a fairly huge dependency on it. LN is really not the panacea to the problems that we're facing right now. Yes, it will help to alleviate the issue but it really doesn't do that much. If we want any significant adoption, then a block size increase is the most straightforward method.

There are a few threads, off the top of my head that I've discussed about LN and the need for on-chain transactions as well. I think that would be a better starting point.

[BlackHatCoiner]

Would less people be able to run nodes/mining and therefore threaten decentralisation?

There must be a misunderstanding from your side. Running a node compared to mining is a different procedure. The system's decentralization is maintained due to the increase and the distribution of the hashrate. Whether we had ten or a million nodes, but the hashrate and its distribution remained the same, it'd not have any difference.

If you run a node, but do not vote for the security of the network, then you're just doing it for your own good. Thus, you may not even need a full node, but rather a pruned one, which comes cheaper.

[NeuroticFish]

that's your interpretation

You're right and I apologize for that.

It's as simple: underlying hardware is advancing, getting bigger and cheaper, hence if this is not a big problem now, it should also not be in the future.

Agree that hardware is advancing and getting bigger. So is the size of the blockchain. The question then becomes the relative rate of increase. The graph in the link below shows the increase in the size of the blockchain over the last decade.

In 2015, it was around 40GB. It is now over 300GB. My computer has a hard drive with 500GB. While I would've been happy to download the block in 2015, it is now too big for me. Yes, I could easily fork out another $100 to buy a new hard drive but this is something I would've have needed to do a few years ago.

https://www.statista.com/statistics/647523/worldwide-bitcoin-blockchain-size/

Indeed. The thing is that with the current code there's a maximum size that can be added to the blockchain. The 1 TB / 5 years was not reached yet, else we would be some 2.2 TB now. And although 2.2 TB may look a bit big for a download or as space locked on your HDD, is not that expensive or difficult to download, right?

It's simply impossible for us to function solely on LN, or at least without a fairly huge dependency on it. LN is really not the panacea to the problems that we're facing right now.

I expect that the not-so-great current use of LN and the fact that many make only smaller short lived channels may make current calculations not the much correct. (but yeah, I know that I may be wrong)
That's why I said "well thought channels". And increased on-chain fees will make people think twice if they make their own LN channels for each 1 or 10 small transactions or use one on-chain tx and move some funds into a service's wallet, using LN from there. I know that this hurts decentralization big, but this is how I see LN work. If we don't like this, then indeed we need other solutions, including bigger blocks, bigger chain size, better handling of that size...
But for now the only problem I see is that LN is under-used and still labeled as "beta".

[Wind_FURY]

In 2015, it was around 40GB. It is now over 300GB. My computer has a hard drive with 500GB. While I would've been happy to download the block in 2015, it is now too big for me. Yes, I could easily fork out another $100 to buy a new hard drive but this is something I wouldn't have needed a few years ago.

Fair point, but there are 2 alternative if you insist to run full node
1. Use pruned node. Bitcoin Core still download and verify whole blockchain, but only keep few thousand last block.

But it wouldn’t be that beneficial to the network. The blockchain must be made as redundant as possible for the new generation of Bitcoiners. If you have the hardware, store the whole blockchain.

2. Trust third party which prepare pruned snapshot such as https://github.com/ez-org/eznode.

There are another alternative such as UTXO commitment, but so far there's no interest to implement it on Bitcoin.

ALL users should rather run a pruned node, and validate everything themselves.

[BlackHatCoiner]

But it wouldn’t be that beneficial to the network. The blockchain must be made as redundant as possible for the new generation of Bitcoiners. If you have the hardware, store the whole blockchain.

And how does a full node (which isn't mining) benefit the network? The only way I can think of is if every other node goes offline and someone wants to download the whole chain.

[DannyHamilton]

And how does a full node (which isn't mining) benefit the network?

This is a bit like asking if a single vote matters in an election where there are thousands (or millions) of voters.  It can seem a bit like that one vote isn't really going to matter much at all, however if EVERY participant thought that way, then nobody would vote and that single vote would be ALL that matters.  As such, it's in the interest of the entire system for everyone to act as if their small contribution really does matter (because it's only when they do so that they can make sure that no single participant has excessive control).

Here are a few ways that a non-mining node benefits the network:
1. It enforces all consensus rules on all transactions and blocks that it receives and forwards.
2. It provides a source of pieces of the blockchain for new nodes which wish to join the network.
3. It provides a list of well-behaved nodes for other nodes to connect to.
4. It increases interconnectivity, reducing the risk that the network becomes fractured.

Can bitcoin accomplish these things if YOU don't run a node?  Probably.  But, if too many people feel that way, then any or all of these begin to break down. Simply to exist, bitcoin NEEDS some threshold number of participants to perform these actions.  As additional nodes are added above that threshold, it improves the durability of Bitcoin and reduces the power that any other participant has.

If you feel you are benefitting from the very existence of bitcoin, then you may want to consider doing your part to ensure its continued existence.  You get to decide what "doing your part" means. This is a voluntary system and nobody is forcing you to participate in any particular manner.  It's only your own sense of responsibility and community that can motivate you.  If running a node feels too expensive to justify for the amount of benefit you're receiving from bitcoin's existence, then there are other ways you can contribute to the community. Some great ways to give back are:

1. Encourage others to use bitcoin when they are going to pay you for some reason.
2. Encourage others to accept bitcoin when you need to pay them for some reason.
3. Learn more about how bitcoin works, and what its benefits are.
4. Participate in discussions (both online and in your daily life) about bitcoin and educate others about how bitcoin works and what its benefits are.
5. Run a pruned node
6. Learn to program, and write code or test cases for Bitcoin Core.
7. Support those politicians that are not hostile to the concept of Bitcoin.

[ranochigo]

But it wouldn’t be that beneficial to the network. The blockchain must be made as redundant as possible for the new generation of Bitcoiners. If you have the hardware, store the whole blockchain.

Archival nodes are needed for bootstrapping and that is about it, pruned nodes can do everything except to serve those pruned block data. It is only important, in the event that we're hitting a point where we are at the risk of losing those data completely. So, IMO the requirement for that can be quite overblown, especially given that we're not in shortage of those.

I do believe that the importance of archival nodes is overblown to a huge extent, where we have no shortage of those for now and in the near future. If anything, we should be exploring ways to either preserve the history, or employ some scheme to truncate the size.