Topic: Bitcoin's blockchain size - page 2. (Read 582 times)

I never said anyone was voting by running a node.  I was offering an analogy.

At least here in the U.S. there are a lot of people that are apathetic about making an effort to go to the polls and vote in elections.  One of the more frequent excuses is that their vote doesn't matter (since it's just one out of thousands, hundreds of thousands, or even millions of votes, depending on the election).  However, if everyone were to have that attitude, then nobody would vote, and then a single vote would suddenly have a LOT of power.  The only way democracy works is if people participate.  You limit the power of any single individual by participating along with the multitudes so that, not only your vote but, EVERY vote is limited in power.

The post I was responding to was suggesting that there was no benefit to running a node since there were already other nodes on the network to provide a copy of the blockchain.  In otherwords, he was coming off as a bit apathetic about making an effort to participate in the network.  I simply pointed out the parallels of that attitude to the common attitude of citizens that don't bother participating in elections. Then I pointed out the parallels of the repercussions, in that if EVERYONE had that attitude, then there wouldn't be a network. If there were only a few nodes, then those nodes suddenly have a LOT of power.

There is a certain level of personal responsibility and duty that come with choosing to participate in any system that can only exist through the voluntary efforts of the members of that system.  To choose to do NOTHING to support such a system you choose to use is quite selfish, self-centered, greedy, and anti-social.

You are forgetting that by running a node, you are enforcing, or "voting" in this terminology, on the consensus rules, the chain tip, etc.

True there's no danger threshold like mining has, but if a significant percentage of nodes are "voting" on a different chain tip or different rules then that's a sign of a big consensus problem.

It doesn't sound like this to me. The users vote with their computational power, not by running node(s). Someone could achieve having the majority of the nodes and act maliciously very easily, but the system would be unaffected from such attack. The so-called “Sybil attack” works if your vote matters, which means that you need to mine along with having lots of nodes.

There are some ways it benefits the network, but 'til there. You aren't voting for anything if you run your own node.

Except in 2015 low end / middle spec PCs were coming with 256GB drives. So although it was a smaller percentage of it, it was still a large percentage.

You really seem to be running around this forum looking for ways to prove BTC is not viable. No idea why.

If you don't like it, don't use it.

-Dave
 

Arguably a bigger issue than the blockchain size is the intensity that Bitcoin Core, wallet software, and other programs that make use of it, use the CPU.

I stopped the bitcoind node running on my web server some time ago, despite having ample capacity to run one, because sometimes, I would test such supporting programs but they instantly stun the CPU at startup - not memory or disk, as I have excess amounts of those - which freeze SSH connections and force me to reboot from my web interface (unacceptable for the website running on it).

It mainly has to do with the multithreaded nature of such programs and how they spawn as many threads as they want. If they're going to do that then they should be making more use of sleep() calls and yield the CPU.

I have not encountered stalls running bitcoind or bitcoin-qt by itself, not even during IBD.

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.

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.

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.

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.


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

You're right and I apologize for that.



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?



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".

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.

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.
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.

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.

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/

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?



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?

Quite bad from my personal experience.

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.

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.

That's correct indeed.



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.



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.

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.

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.



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.



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'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...

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.