Automated blocksize increases

[franky1]

which would jeopardize decentralization.

hard drives are a non issue,
1mb legacy=52gb a year growth. cheap hard drives are terrabytes meaning 20 years of legacy or 5 years of LN gateway
people usually upgrade their computer very 2-5 years anyway, especially businesses(economic nodes) that get tax breaks for doing just that

as for decentralisation. the codebase is centralised to core control. what they say goes. all thats different is the distribution of blockdata. decentralisation vs distribution are different concepts.
again stifling bitcoin utility to promote a separate network of users using a compressed neutrino node for LN is not helping a bitcoin node count
it actually makes merchants less required to want to be full nodes by using LN
increasing transaction counts allows more bitcoin utility which increases merchants desire to want to doubl check and validate such
ergo the more merchants accepting real bitcoin helps bitcoin node counts. more merchants accepting LN msats doesnt hlp bitcoin node counts

but you are right, all these debates have been circled around time and time again because the ultimate answer is that devs want to deburden the bitcoin network to promote commercial networks like LN

[franky1]

we are no longer in the pre millenia of IDE based hard drives. these days the new tech is as standard

but here is a easier concept for allowing progressive growth
a node has a 'speed test' algo built in that gives the node a score. this score is used to establish good connectivity, EG high score nodes get to connect to multiple nodes near centre of relay network and low score nodes are at the edges.

this score is also used as a network tally. when high majority reach certain level then it shows that nodes can cope with more

it also helps the novice average joe that only has limited bandwidth due to living in moms basement from crying about bandwidth drain in 2 days because they foolishly think they are helping by setting their node to connect to 100 instead of just 3-8

yep thats right. users can have a better experience by reducing how many nodes they connect to at once because it concentrates the bandwidth

oh and another funny point
core decided to no longer support XP and vista.. so guess what by default core shouldnt then play games trying to convince people bitcoin should run on older tech that was around in xp/vista days

[Nadziratel]

Comeee onnnn! We shouldn't talk about any news forks. We are watching old ones which they are completely useless. Let go this fork shits also.


There is one big problem we should solve ASAP. It is energy consumption. It is not sustainable now. And I guess we need more developed mining device would be fine.

I do agree with you here. I have honestly had enough of these forks which are basically splitting our crypto communities instead of uniting them thanks to different perspectives.

Also, Bitman just released new miners which is good progress and they focused on improving energy efficiency which is epic indeed.

Yeah, another fork will just cause another market collapse as the public thinks this industry is a joke. Bitcoin Gold, Bitcoin Rabbit, Bitcoin Diamond, Bitcoin Buttcheeks, etc., etc. There is already a flavor for everyone.

I'm not talking about creating an altcoin with a fork. I'm talking about upgrading bitcoin with a fork, as plenty of other coins do but bitcoin has yet to do, at least not since the very early days.

I see that. But I think you don't want to understand we are talking about a big data size already now. As you see in this chart, blockchain data size reach over 200GB. So all computer keep 200GB data in blockchain network already. If we increase the data size x2-x4, then we will reach to 1 tb in a few months. So I think we have no choice about data size.

[franky1]

hard drives are a non issue,
--snip--

Storage capacity is still an issue, even though it's minor compared to :
1. RAM speed & capacity.
2. Internet bandwidth & latency, which affect transaction / block propagation time. Even worse if user use VPN/Tor.
3. CPU usage.
4. Storage speed. HDD will be useless if Bitcoin blockchain growth as fast as Ethereum.
And if we consider initial sync/start up full nodes, storage capacity (which related to blockchain size) will be major issue.
People need to wait days - weeks for initial sync and few minutes to start up their full nodes. I need to wait 1-3 minutes to run Bitcoin Core from my old HDD.

as for decentralisation. the codebase is centralised to core control. what they say goes. all thats different is the distribution of blockdata. decentralisation vs distribution are different concepts.

I specifically meant decentralization in terms of total full nodes & costs of running full nodes.

but you are right, all these debates have been circled around time and time again because the ultimate answer is that devs want to deburden the bitcoin network to promote commercial networks like LN

I disagree, there are many effort for on-chain scaling by reduce transaction size (rather than increase blocksize) such as Schnorr, MAST and Taproot.
Even though only developer and tech savvy who know about those.

ram speed and capacity is a non issue. right up until the point core added more wishy washy code that makes nodes have to convert blockchains into more than just one dataset.
think about it. it used to be just full data and UTXO, but now nodes have to re-org data to send out stripped/filtered(nonsegwit), prunned, headers only, neutrino, blooms and other datasets, which is what actually causes more ram wastage. going back to basics of just 2 datasets can save ram usage.

internet bandwidth easily solved as already explained. if your crying that your on a monthly limit. then pay more and upgrade. cant pay more. then reduce the node connectivity count down. there is no need to connect to 100 nodes then cry that YOUR internet is being used up.. connect to 10 nodes and realise your internet lasts 10x longer

cpu usage. again no longer in the XP/vista days of single core 2ghz. we are in the quad core era.. even devs admit they dont support xp/vista. so no point using decade old hardware and cry about it

schnorr is about reducing bloat of what would be LN factory transactions. and not really beneficial if i was wanting to pay real btc on the bitcoin network to a single recipient.
taproot is just about making NEW bloated smart contracts use less bytes, but doesnt help current default tx formats increase tx count.
its like having a strip club of anorexics for years.. then introducing plus size ladies and then introducing corsets to try hiding the plus size ladies flab. how about just stick with bitcoin being the digital cash network instead of a bloated smart contract network that needs to hide things

as for the initial sync. that can be solved easily.
people dont care that it takes weeks to download the blockchain. what they care about is that core coded their implementation to be useless untii the initial sync is complete. thus forcing people to wait and watch.
solutions can be that a node grabs a UTXO set initially to atleast get a, lets call it 'non independantly verified balance' so that users can atleast get on and start making transactions.. and then the full blockchain that does the double check becomes a background issue that people just leave to run without any twiddling thumbs needed

as for the cost of running a full node... that has got me laughing. again the math of 3000tx a block to match the blockreward would be $20 a tx.
if fools think that $20 a tx is acceptable fee war.. then dont complain about a $40 a month internet bill(just 2 tx comparatively)

[franky1]

I see that. But I think you don't want to understand we are talking about a big data size already now. As you see in this chart, blockchain data size reach over 200GB. So all computer keep 200GB data in blockchain network already. If we increase the data size x2-x4, then we will reach to 1 tb in a few months. So I think we have no choice about data size.

over 200gb is 10 years of accumilation.. not months of accumilation.
even if people made the most perfectly bloated segwit multsigs to utilise the full 4mb weight. thats still 200gb A YEAR
at the moment its 1.2mb average so lets call it 2.4mb at 2x (120gb a year)
at the moment its 1.2mb average so lets call it 4.8mb at 4x (240gb a year)
meaning at 2-4x it would be 1tb in 3.5-7 years.. not months

[thecodebear]

I said and repeat again, bitcoin wasn't consideted for high demand, but it got it and with problems (regulations, huge tx fees last year and etc).
Currently it's not a problem, demand/supply and lighting network (or even without it) keeps fast transaction with low fees. If you want bitcoin analogue with increased blockchain size, you can move on Bitcoin Cash.
That's all, I think problem is solved.

So your argument is that because we are in the slow period of the market and it isn't a problem right now we can just pretend the problem is solved? That's pretty awful. How about when we aren't in the slow part of the market again and the blockchain is way more busy, which we all know is coming as soon as the market starts to heat up again.

You haven't resolved a problem by saying "oh we decided not to resolve it but you can use some altcoin instead." Some altcoin, whether it is BCH or any other coin, is not bitcoin. That just means it isn't resolved yet.

[thecodebear]

There is one big problem we should solve ASAP. It is energy consumption. It is not sustainable now. And I guess we need more developed mining device would be fine.

I certainly agree with you. I really don't get the sense of talking about fork and debating about this issue over and over again when there is really better and more important stuff that we should focus on. There are still lots of changes that might happen so thinking of blocksize increase for the coming years is quite too early.
[/quote]


How is it too early? It's already a problem! As soon as the price goes up and people start flooding back into bitcoin scaling is again going to be THE MAJOR limiting factor with bitcoin.

And energy consumption is not a problem at all. Bitcoin uses proof of work. That is never going to change, it'd be way to disruptive to the mining community to change that. A mining change would be one thousand times harder to do than a blocksize increase so between these two things talking about blocksize is the one to focus on. Energy consumption is only a problem in the media. A lot of the energy comes from cheap renewables, very possibly over half the energy is from renewables, a recent non-scientific study concluded that about 75% is from renewables. Energy consumption is entirely a non-issue. Transaction throughput, which will grind the blockchain to a halt for most people as soon as bitcoin becomes popular again, is the only major problem we should be dealing with right now. Everything else is secondary, except energy consumption, which isn't a problem at all.

[thecodebear]

We really have ideas and suggestions which are beyond the capacity of Bitcoin. Sometimes, it's exceeding beyond its real role. As for me the supply and demand has no problem and automated increase isn't really what we need but rather adoption, transaction development and the problem with energy regulatory.

Adoption won't happen if it costs $100 to do a bitcoin transaction. I don't know what you mean by transaction development. And I don't know what you mean by energy regulatory, but if you mean energy consumption that isn't a problem either. I agree we need adoption, and you can't have adoption unless there is space for transactions, and there won't be as soon as bitcoin gets even just a little bit more popular again.

[thecodebear]

Comeee onnnn! We shouldn't talk about any news forks. We are watching old ones which they are completely useless. Let go this fork shits also.


There is one big problem we should solve ASAP. It is energy consumption. It is not sustainable now. And I guess we need more developed mining device would be fine.

I do agree with you here. I have honestly had enough of these forks which are basically splitting our crypto communities instead of uniting them thanks to different perspectives.

Also, Bitman just released new miners which is good progress and they focused on improving energy efficiency which is epic indeed.

Yeah, another fork will just cause another market collapse as the public thinks this industry is a joke. Bitcoin Gold, Bitcoin Rabbit, Bitcoin Diamond, Bitcoin Buttcheeks, etc., etc. There is already a flavor for everyone.

I'm not talking about creating an altcoin with a fork. I'm talking about upgrading bitcoin with a fork, as plenty of other coins do but bitcoin has yet to do, at least not since the very early days.

I see that. But I think you don't want to understand we are talking about a big data size already now. As you see in this chart, blockchain data size reach over 200GB. So all computer keep 200GB data in blockchain network already. If we increase the data size x2-x4, then we will reach to 1 tb in a few months. So I think we have no choice about data size.

200GB is NOT a big size. It's quite small. It may take a while to download the blockchain the first time, but actually storing that is cheap because 200gb is tiny for a storage these days. A full 100% segwit block would be 4MB right (I think I'm right about that). In a year that would take up 200GB. Addoing 200GB of storage a year for a bitcoin miner is nothing compared to the cost of actually running a miner, and full node operators are usually hobbyists so they're into this stuff and probably wouldn't be scared away from having to buy some more cheap storage. If you say 5x the blocksize right now, that would clear out any immediate or near-future problem with transaction capacity (probably for the next few years) and it'd still only require an extra TB storage to be added each year if every block were full. That's not too bad. And storage is only going to get cheaper in the future, which is why gradually increasing the blocksize on a regular interval makes sense from this perspective becomes you make the blockchain gain data at a faster rate every few years as storage gets cheaper. Downloading the full blockchain the first time might suck, but storing the blockchain would not be much of an issue.

[DooMAD]

That's where my idea of automated blocksize increases comes in. I don't know if this has been talked about, but I've never seen mention of it.

I used to push for an automated, algorithmic increase, but it never found any real support.  It just seems as though the majority of people who run full nodes don't like the uncertainty of it.  In a way, it's understandable they'd rather know what the resource costs are going to be before they agree to bear them.  

It's all well and good everyone piling in with their views about what would be best and how it should be done, but it all means nothing if no one runs the code.  It's not going to change unless it's an idea that lots of people can get behind and support.

[thecodebear]

This topic already discussed many times, to the point where people insult each other, going off-topic, sharing FUD or all of them.
There are even few proposal which pass BIP (check BIP 101 - 109), the only BIP that i could agree is BIP 103 which based on technology growth, not some random arbitrary number.

I'm in favor of incremental block size limit growth, but i disagree with your idea since all i could see is arbitrary number, not following technology growth which would jeopardize decentralization.

But it is always going to be an arbitrary number. Even BIP 103 just proposes slowly stepping up the blocksize by small amounts every 97 days, at a rate of 17.7% increase per year. That is arbitrary. OK yes it was based on the average growth rate over bitcoin for several years, but there is no reason to think bitcoin will continue to grow at the average rate of a few early years for future years and decades to come.

Anyway BIP 103 is is arguing for the same thing I am, an automated increase over decades to slowly expand the blocksize to at least try to keep up with growth and requiring only a single hard fork rather than multiple one-off hard forks to solve immediate capacity problems when they arrise (which from the scaling debate over the past few years we know having to do repeated hard forks just means it wouldn't happen).

Anyway, I wasn't proposing a specific increase, but a carefully thought out set of increases, the main difference being that in my model it is front loaded since the increases halve over time, but that is percentage based so it is still increasing by a significant amount for quite a while. Also front loading it is needed now because Bitcoin already smashed into the capacity wall in 2017, it's going to be much much worse in the next couple of years, so a bigger increase is needed now, and then as LN gets going in the years to come that should take up a lot of the new transaction growth.

I'd be fine with BIP 103 if you include in that hard fork an immediate blocksize increase of say like 4x so that the network doesn't grind to a halt in the next couple years on the next bitcoin boom (or at least it can take in a lot more before it grinds to a halt). I think an immediate 2x or 4x increase, combined with a BIP103-like solution would be perfectly fine. I think it should actually be less than 17%/year if we solve the near-term problem the network will have once the market heats up again by getting an initial 2x or 4x, but yeah I like BIP103.

The problem is, and as we have seen from most of the comments on this thread, people have somehow been lulled into thinking the problem was resolved by not doing anything. Not sure how its even possible to think that, but Bitcoin will desperately need a solution in the next couple of years before things start getting bad even when the market is down, or otherwise it will just severely restrict bitcoin growth and none of us want to see that.

BIP 103 is promoting the same idea I am, a single hard fork to gradually increase blocksize over the coming decades so that some action to resolve the problem has been taken and bitcoin is allowed to grow and we can stop the endless debate on when, if, and how a hard fork to increase block size which will no doubt arise every few years if a long term solution isn't put in place.

[thecodebear]

That's where my idea of automated blocksize increases comes in. I don't know if this has been talked about, but I've never seen mention of it.

I used to push for an automated, algorithmic increase, but it never found any real support.  It just seems as though the majority of people who run full nodes don't like the uncertainty of it.  In a way, it's understandable they'd rather know what the resource costs are going to be before they agree to bear them.  

It's all well and good everyone piling in with their views about what would be best and how it should be done, but it all means nothing if no one runs the code.  It's not going to change unless it's an idea that lots of people can get behind and support.

That doesn't make sense to me - I mean the part about people not knowing what the resource costs will be. Because with an automated increase they will always know exactly how much the blockchain will grow by and when. Unless you are saying they just always want the blockchain to be the same size with no increases. If so that's a losing argument because that means no growth for bitcoin in the long run.

Everyone reasonable can agree that we need blocksize increases in the near term and the long term. Having it done with a single hard fork and having it automated so there is no question about it, and everyone knows exactly how large the limit will be in the future, is the only thing that makes sense.

[pooya87]

that is not something that you could leave to an algorithm to automatically decide what the size should be. what if it was too much? what if it was too little? and not to mention that you can't just be abstract and say "algorithmic way", the implementation of such a thing can open up new ways of exploitation by the miners and we don't want that.
with that said i am all for a block size increase. i always say we need "scaling" not just block size increase but with all the scaling that we have received, it was obviously not enough and with the adoption increase there simply is not enough room in blocks to handle that. and if we want to see LN be used more we need to be able to handle all the extra transactions that LN adoption would bring to bitcoin.

[thecodebear]

that is not something that you could leave to an algorithm to automatically decide what the size should be. what if it was too much? what if it was too little? and not to mention that you can't just be abstract and say "algorithmic way", the implementation of such a thing can open up new ways of exploitation by the miners and we don't want that.
with that said i am all for a block size increase. i always say we need "scaling" not just block size increase but with all the scaling that we have received, it was obviously not enough and with the adoption increase there simply is not enough room in blocks to handle that. and if we want to see LN be used more we need to be able to handle all the extra transactions that LN adoption would bring to bitcoin.

Too much isn't a problem, if by that you mean it would be too empty. For most of Bitcoin's life the blocksize has been too much. Was never a problem. Most altcoins that claim high tx/sec have large almost entirely unused blocks, not a problem for them. The only problem for blocksize it too little and it makes the blockchain almost unusable, which is the problem that needs solving, and making sure blocks don't get so big (assuming they are full) that it forces more centralization. But also the reason my idea involves halving of the size increase each time is so that the size increase doesn't run amok and get way too large too fast. Right now we need a good size increase to handle whats gonna happen at the next market peak, likely bitcoin will need a 4x or 8x realistically to not grind to a halt during the next peak. Unfortunately I'm 100% sure there will be no scaling by then which means the tx fees and limited blocksize will likely end the bull market prematurely. Then in the future, as the compounding blocksize increases build upon themselves, we need smaller percentage increases, especially so that the blockchain doesn't become too big and risk centralization. If anything I think my proposal wouldn't be able to keep up with what is needed, but it would alleviate it a lot and the rest could be pushed mostly to the LN, and it would limit centralization from having too large blocks being filled and therefore fewer people can mine or run nodes.

Absolutely, both LN and blocksize increases are absolutely necessary for bitcoin to scale. It is sad that people tend to only think that one of those things is needed (2nd layer or onchain scaling) and they ignore how obviously the other one is needed as well.

The way I see it, LN opens up new possibilities, like everyday $5, $10, $50 transactions, or even microtransactions. These are things that aren't really done currently on bitcoin, as the blocks are currently mostly filled with people just moving money between wallets or exchanges. So the LN does nothing to solve the current problem, but it opens up bitcoin to handle many thousands of everyday transactions per second that aren't currently done. We still need a lot of onchain scaling in the years and decades to come to handle the types of transactions that make sense to do on-chain rather that in the LN. The current blocksize is grossly inadequate for what we should expect for that in the future.

[thecodebear]

That's where my idea of automated blocksize increases comes in. I don't know if this has been talked about, but I've never seen mention of it.

I used to push for an automated, algorithmic increase, but it never found any real support.  It just seems as though the majority of people who run full nodes don't like the uncertainty of it.  In a way, it's understandable they'd rather know what the resource costs are going to be before they agree to bear them.  

It's all well and good everyone piling in with their views about what would be best and how it should be done, but it all means nothing if no one runs the code.  It's not going to change unless it's an idea that lots of people can get behind and support.

That doesn't make sense to me - I mean the part about people not knowing what the resource costs will be. Because with an automated increase they will always know exactly how much the blockchain will grow by and when. Unless you are saying they just always want the blockchain to be the same size with no increases. If so that's a losing argument because that means no growth for bitcoin in the long run.

Everyone reasonable can agree that we need blocksize increases in the near term and the long term. Having it done with a single hard fork and having it automated so there is no question about it, and everyone knows exactly how large the limit will be in the future, is the only thing that makes sense.

Except for that fact the technology of hard drives and memory are an unknown at this point.

Aside from that obvious flaw, sure, your idea makes some sense, except for the obvious error, so what you propose is nonsense.

Take your anger out elsewhere please. Hard drives readily decrease in cost and increase in size. Storage is not remotely a problem. The storage for the bitcoin blockchain right now is super small compared to available storage technology. And what I'm suggesting doesn't come even close to pushing storage technology.

[thecodebear]

No, the BIP clearly says the number based on average growth rate of bandwidth the last years, which seems to be the bottleneck. Check https://github.com/bitcoin/bips/blob/master/bip-0103.mediawiki#rationale

Yes I mentioned that earlier, that it is based off growth for a few years. But like I said when I mentioned that, that doesn't mean that level of growth will continue for decades to come. It could be less it could be more. Plus LN could take up a lot of growth. So picking a yearly increase for decades into the future based off a few very early years of data is indeed rather arbitrary.

My other main problem with BIP103 is that compounding the percentages means it would start growing too much in a few decades, the growth might become unnecessarily large 30 years from now, but it is too small for right now. So it likely misses on both ends. We need much more than yearly 17% increases right now, and will likely need much less than 17% increases 30 years from now. That's why I think my halving idea makes more sense. We alleviate the near-term problem right away rather than waiting a bunch of years for the 17% increases to get large enough to resolve the problem, but the increases get smaller and smaller in the future so the blocks don't grow too large and don't outstrip network technology and risk centralization from propagation problems and whatnot.

BIP103 and my idea have the same general idea though, and I think it is the best concept for keeping bitcoin growing, but I prefer my idea over BIP103 because it is better in those two ways and solves the immediate (or near-term) problem, which BIP103 doesn't do.

[pooya87]

Too much isn't a problem, if by that you mean it would be too empty. For most of Bitcoin's life the blocksize has been too much. Was never a problem. Most altcoins that claim high tx/sec have large almost entirely unused blocks, not a problem for them.

too much is also a problem, it is not as serious as too little but still is. if the blocks were mostly empty then it becomes easier to spam the network with more junk and cause problems. remember that spam is not just increasing fees, it has different forms. for example one form is to increase the number of UTXOs and make it extremely hard for nodes to run since they would have to load up a much bigger UTXO database in memory and look things up.
you can't compare bitcoin with altcoins either. because there is no incentive to spam attack an altcoin but there are lots of incentives from all sides to spam bitcoin!

i agree with the rest.

The way I see it, LN opens up new possibilities, like everyday $5, $10, $50 transactions, or even microtransactions. These are things that aren't really done currently on bitcoin, as the blocks are currently mostly filled with people just moving money between wallets or exchanges. So the LN does nothing to solve the current problem,

actually one of the most important usages of LN is when people want to make lots of transactions like when they move their money between their wallets and exchanges. we only need one exchange to start an LN node and traders to move their transactions there to see a decreased number of on-chain transactions. there are a lot of other cases too, like gambling sites and mixers.

[franky1]

I don't see correlation between cost of running full nodes and tx fee, but cost of running a full node is more than internet bill. Don't forget initial hardware cost (if user buy an hardware mainly for run full nodes) and electricity price.

initial hardware cost
well if you dont have a modern PC then your not interested in computer stuff in the first place.
again if you think its ok to have people pay $1+ fee per tx. then worrying about having to spend $500 every 4 years is not an issue.

again for emphasis.
those that use computers already have computers. those that have computers are those interested in bitcoin. upgrading a computer is cheaper then buying a computer for first time.
 
those that have no clue about computers and never had a computer wont be the ones that NEED to be full node users as they have no technical reasoning to understand or need to be full nodes. if they run a business then buying a computer is not an issue due to certain business/tax allowances and buying a computer becomes a justified expense.

but to be hypocritical and say using bitcoin should be ok to be charged at XX fee a tx, but then cry about someone having to buy a pc.. is foolish

[franky1]

too much is also a problem, it is not as serious as too little but still is. if the blocks were mostly empty then it becomes easier to spam the network with more junk and cause problems. remember that spam is not just increasing fees, it has different forms. for example one form is to increase the number of UTXOs and make it extremely hard for nodes to run since they would have to load up a much bigger UTXO database in memory and look things up.
you can't compare bitcoin with altcoins either. because there is no incentive to spam attack an altcoin but there are lots of incentives from all sides to spam bitcoin!

LN CLTV locks increase UTXO's because the longer funds are locked as UTXO's and the more tx's getting locked. the more UTXO's there are stuck in ram not moving for weeks. which makes it a waste to even have them in ram.

as for spam attack bitcoin.
easy solution.. implement a fee priority.
instead of everyone bidding for top price. have a formulae where if your spending funds with less than X confirms you pay more then someone who has XXX confirms.

that way spammers that need to spend multiple times a day pay the price.. or use LN for its niche. and those that use bitcoin irregularly are not forced to use LN and not forced to pay the same price as a spammer.. win win for everyone

[Sithara007]

For how long we are going to increase the block size? There needs to be another alternative. It is widely claimed that Bitcoin is having around 100 million users. But I guess the number of active users stand at somewhere between 1 million and 10 million. So my question is what happens if Bitcoin becomes more popular and gets accepted by the vast majority of the world population? What will happen if the number of active users increase from 1 million to 1 billion? Are we comfortable with block sizes like 1GB or 2 GB? Is it possible to include such blocks in the blockchain?