About block size limit and transactions fees

[Wind_FURY]

That still doesn’t mean that it couldn’t happen. For Bitcoin, currently being a network with over a $trillion in market capitalization, the developers should NEVER risk and give any way for bad actors to exploit and disrupt the system. The network should be FULL PROOF as possible.

Absolutely, we would have to run a series of test to see if it works and if it is safe. If you have a better idea then you're welcome to share it, we are here to talk.

Haha. I am the stupid one in the forum, I will never have better ideas to force out of my mind. But I believe I’m smart enough to know that everything that we thought are “good ideas”, they are actually not after 10 years of the Core Developers’ research and work on the protocol. If you are a developer, make a BIP, give all the technical details.

[1714650463]

1714650463

[1714650463]

1714650463

[1714650463]

1714650463

[1714650463]

1714650463

[topcoin360]

--snip--
If the block size limit is lowered, the cost per transaction increases. There is the potential that transaction fees in total will increase more than the block size limit will decrease. So lowering the limit would increase total transaction fee revenue.[...]

In this case the network's hashrate will increase and it will be harder to maintain the attack. If the avg fee goes above 1% then the block size limit will increase in the next epoch.

If there were a situation in which bitcoin must have a dynamic block size limit, it would be superior to have the block size limit based on a sat/vByte basis. If the cost to include 200 bytes in a block becomes too high, the block size limit will increase, and if the cost to include 200 bytes in a block is too low, the maximum block size will decrease.

The problem with this proposal is that we don't know the real value of the fee, if the price of btc is high then the fee will be too expensive, if the price of btc is low then the price per vByte will be too low, we can determine a percentage but we can't determine btc's price.

Haha. I am the stupid one in the forum, I will never have better ideas to force out of my mind. But I believe I’m smart enough to know that everything that we thought are “good ideas”, they are actually not after 10 years of the Core Developers’ research and work on the protocol. If you are a developer, make a BIP, give all the technical details.

Didn't say any of that, I'm just observing that many of those ideas are not being pursued (or maybe it's just the lack of action since 2017). Writing a BIP is something I might consider...

[Wind_FURY]

Haha. I am the stupid one in the forum, I will never have better ideas to force out of my mind. But I believe I’m smart enough to know that everything that we thought are “good ideas”, they are actually not after 10 years of the Core Developers’ research and work on the protocol. If you are a developer, make a BIP, give all the technical details.

Didn't say any of that,

That I’m the stupid one? I said it, and I don’t mind if I am. Believe me. Haha.

I'm just observing that many of those ideas are not being pursued (or maybe it's just the lack of action since 2017). Writing a BIP is something I might consider...

I believe you should do a thorough research of the counter-arguments in why those ideas are “not being pursued” first, before assuming that they were feasible ideas but ignored ideas.

Plus how would you define scaling. I’m curious.

[PrimeNumber7]

--snip--
If the block size limit is lowered, the cost per transaction increases. There is the potential that transaction fees in total will increase more than the block size limit will decrease. So lowering the limit would increase total transaction fee revenue.[...]

In this case the network's hashrate will increase and it will be harder to maintain the attack. If the avg fee goes above 1% then the block size limit will increase in the next epoch.

There is nothing in this scenario that would cause the network hashrate to increase on its own. You are describing this as an attack, however it is something that would benefit all miners. As such, there is little reason why all miners would not participate via a cartel (something similar to how OPEC works for the oil markets).

If there were a situation in which bitcoin must have a dynamic block size limit, it would be superior to have the block size limit based on a sat/vByte basis. If the cost to include 200 bytes in a block becomes too high, the block size limit will increase, and if the cost to include 200 bytes in a block is too low, the maximum block size will decrease.

The problem with this proposal is that we don't know the real value of the fee, if the price of btc is high then the fee will be too expensive, if the price of btc is low then the price per vByte will be too low, we can determine a percentage but we can't determine btc's price.

The price of transaction always has been, and always will be measured in terms of BTC. If the price of BTC is too high, the market will respond accordingly.

I would also point out that your 1% transaction fee target is very high, even by traditional banking system standards. The cost of sending a wire transfer is at most $15 or $25 (if not waived), but it would be very unusual for someone to send a $2500 wire transfer. It is far more common for someone to send a six-figure wire transfer. It might cost $0.20 to write a check, but it would be very unusual to write a check for $20.

[topcoin360]

I'm just observing that many of those ideas are not being pursued (or maybe it's just the lack of action since 2017). Writing a BIP is something I might consider...

I believe you should do a thorough research of the counter-arguments in why those ideas are “not being pursued” first, before assuming that they were feasible ideas but ignored ideas.

Plus how would you define scaling. I’m curious.

Scaling is increasing the currency's utility by allowing more people to make transactions or allowing people to make more transactions.

The equation I found may not be accurate but I'll explain my reasoning;

If we assume that the user base is not going to change much in the short term AND people's habits are not going to change much in the short term then;

a) the volume of transactions on the network is proportional to the block size limit.

b) the price people are willing to pay to make a transaction when the limit is reached stays the same.

I'd rather have 10 persons running a full node and sharing the cost then have thousands of people using some third party services to make their transactions. As of now, the size of the block chain is controlled by a limit on the block size and by the level of difficulty to mine a block, the value of the second paramater can change depending on the network's hashrate but the value of the first paramater can't change because of the risk of a consensus problem. The system we have now benefits to speculators but does not benefit to the real users of the currency, if bitcoin isn't used as a medium of exchange then sooner or later the price of the coin will drop down to zero (or it will fall drastically to it's true value).

Using percentage also flawed since block reward changed every 4 years.

In my view the inflation is a flat fee that is charged to the hodlers, it won't affect you if you don't hold your coins.

The price of transaction always has been, and always will be measured in terms of BTC. If the price of BTC is too high, the market will respond accordingly. [...]

If btc's price is high then everyone has more money to outbid each other so I believe that the transaction fees may also increase (on top of that people tend to make more transactions when the price is high)...

I would also point out that your 1% transaction fee target is very high, even by traditional banking system standards. The cost of sending a wire transfer is at most $15 or $25 (if not waived), but it would be very unusual for someone to send a $2500 wire transfer. It is far more common for someone to send a six-figure wire transfer. It might cost $0.20 to write a check, but it would be very unusual to write a check for $20.

For someone who wants to move funds around the world OUTSIDE the banking system I think 1% is a good price.

[ranochigo]

I'd rather have 10 persons running a full node and sharing the cost then have thousands of people using some third party services to make their transactions. As of now, the size of the block chain is controlled by a limit on the block size and by the level of difficulty to mine a block, the value of the second paramater can change depending on the network's hashrate but the value of the first paramater can't change because of the risk of a consensus problem. The system we have now benefits to speculators but does not benefit to the real users of the currency, if bitcoin isn't used as a medium of exchange then sooner or later the price of the coin will drop down to zero (or it will fall drastically to it's true value).

Unfortunately, that isn't what majority of the community wants. There is nothing wrong with increasing block size, but if you were to increase to that extent, then no one except a selected few can run a node because they are prohibitively expensive. Miners can only mine if they're fast enough, which would mean further centralization as they need to achieve the lowest latency possible to reduce orphans. Complete centralization of Bitcoin defeats the very purpose of it, and putting the control of it to a selected few only serves to discourage people from using it.

There is nothing wrong with increasing the block size to increase the on-chain capacity. However, if you want to achieve mass adoption and surpass that of the major banking systems, you can't do it without making it impossible for the average joe to run a node. There is no way this should ever happen, because we'll be at the mercy of whoever is running the few nodes.

I briefly read through the topic again. Are you still proposing a complicated dynamic block size as opposed to a simple and linear block size increase?

[dkbit98]

There is nothing wrong with increasing block size, but if you were to increase to that extent, then no one except a selected few can run a node because they are prohibitively expensive. Miners can only mine if they're fast enough, which would mean further centralization as they need to achieve the lowest latency possible to reduce orphans. Complete centralization of Bitcoin defeats the very purpose of it, and putting the control of it to a selected few only serves to discourage people from using it.

Great explanation by @ranochigo and confirmation of this words can be seen with forks that tried to make ''better'' bitcoin and instead created more centralized junk.
For example, 3 mining pools (ViaBTC, AntPool and one more) for Bcash are having over 75% of total hashrate, and situation is even worse for bsv scam with 2 mining pools controlling all hashrate, and they are constantly under 51% attacks.
We can at least thank all those forks that serve more as testing ground so we can see what effect it could have on Bitcoin and what we should avoid doing.
It's not impossible to imagine that block size will also change for Bitcoin in future, but it must be carefully implemented after doing deep investigation as a part of some bigger change, but result will be new forks and I think that people are a bit tired of forks.

[topcoin360]

Unfortunately, that isn't what majority of the community wants. There is nothing wrong with increasing block size, but if you were to increase to that extent, then no one except a selected few can run a node because they are prohibitively expensive. Miners can only mine if they're fast enough, which would mean further centralization as they need to achieve the lowest latency possible to reduce orphans. Complete centralization of Bitcoin defeats the very purpose of it, and putting the control of it to a selected few only serves to discourage people from using it.

My apologies, I think you missed the point I was trying to make and it's probably because I did a spelling mistake. Here is the correction..

I'd rather have 10 persons running a full node and sharing the cost than have thousands of people using some third party services to make their transactions.

So what I was trying to say is 10 persons sharing the same computer is more decentralized than thousands of people using the same server. I think the majority of the community would agree with that.

I briefly read through the topic again. Are you still proposing a complicated dynamic block size as opposed to a simple and linear block size increase?

I'm still not convinced, what is your vision?

so yes fee's will be cheaper per transaction.. but the total the pool gets will be more

I agree with you but I also think that the size of the block chain should automatically adjust to the need of its users.

[ranochigo]

So what I was trying to say is 10 persons sharing the same computer is more decentralized than thousands of people using the same server. I think the majority of the community would agree with that.

Correct.

I'm still not convinced, what is your vision?

I'm against a dynamic block size because it fails to take into account the possibility of the miners intentionally colluding and manipulating the fee market, by either introducing scarcity or otherwise intentionally gaming the block size. Problem with dynamic block size is that it is difficult to accurately provision higher block size for the correct period, due to time lag mainly as the sample size is way too huge.

I would rather just proposing a predictable block size increase, than to have a dynamic block size because it is honestly quite redundant. I don't expect Bitcoin to survive solely on on-chain transactions, that isn't feasible.

[topcoin360]

I'm against a dynamic block size because it fails to take into account the possibility of the miners intentionally colluding and manipulating the fee market, by either introducing scarcity or otherwise intentionally gaming the block size. Problem with dynamic block size is that it is difficult to accurately provision higher block size for the correct period, due to time lag mainly as the sample size is way too huge.

I'd like to remind you that any miner with a lot of hashrate can inflate the fees by choosing to not pick the transactions that pay a low fee. It is actually easier for a miner to do that with an inelasic supply, if the supply was elastic then inflating the fees would also increase the block size limit which would ultimately reduce the fees (it would then be pointless to inflate the fees in the first place).

I would rather just proposing a predictable block size increase, than to have a dynamic block size because it is honestly quite redundant. I don't expect Bitcoin to survive solely on on-chain transactions, that isn't feasible.

I see but what factor would you take into account to calculate the block size limit? I believe bitcoin can only survive with on chain scaling but that's another topic...

[ranochigo]

I'd like to remind you that any miner with a lot of hashrate can inflate the fees by choosing to not pick the transactions that pay a low fee. It is actually easier for a miner to do that with an inelasic supply, if the supply was elastic then inflating the fees would also increase the block size limit which would ultimately reduce the fees (it would then be pointless to inflate the fees in the first place).

Hmm, okay I understand your argument on this.

I see but what factor would you take into account to calculate the block size limit? I believe bitcoin can only survive with on chain scaling but that's another topic...

The ideal block size should be something that still ensures that the network is sufficiently secure. It makes no sense for us to implement a dynamic size, where the size gets inflated to unrealistic limits at times just to accommodate the extra transactions. It would be far better for us to determine the specific and appropriate block size from the on-start because there isn't any downsides to that. If the demand isn't enough, then the blocks would naturally be smaller.

[topcoin360]

The ideal block size should be something that still ensures that the network is sufficiently secure. It makes no sense for us to implement a dynamic size, where the size gets inflated to unrealistic limits at times just to accommodate the extra transactions. It would be far better for us to determine the specific and appropriate block size from the on-start because there isn't any downsides to that. If the demand isn't enough, then the blocks would naturally be smaller.

I get your point but as franky1 pointed out it may not be worth the hassle of running a full node if you do not make a lot of transactions, you may in this case use some third party services to verify your transactions. If you do make a lot of transactions then you could as well pay a lower fee on your transactions and spend more money on your storage/bandwith. I want to emphasize the fact that the cost for a full node can be shared between multiple persons, however the cost of a transaction can hardly be shared so transaction fees may have a bigger impact on centralization than the cost of running a full node.

That said, I just verified the avg transaction value on https://bitinfocharts.com/bitcoin/. It says it was approx. 71,125USD in the last 24h, the avg transaction fee was 2.44USD. For now I think your proposal makes more sense...

[PrimeNumber7]

There is no technical reason why miners need to receive transaction fees via transactions themselves. This is not very common, but pools could offer "account holders" to deposit coin, and have their account balance deducted whenever the pool confirms a customer's transaction. In this case, the pool would be confirming a lot of transactions that have zero fees attached, but the pool is actually receiving transaction fees via out-of-band transactions. Miners could even require transaction fees to be paid this way.

The above would make a dynamic block size based on transaction fees attached to transactions useless.

[ranochigo]

I get your point but as franky1 pointed out it may not be worth the hassle of running a full node if you do not make a lot of transactions, you may in this case use some third party services to verify your transactions. If you do make a lot of transactions then you could as well pay a lower fee on your transactions and spend more money on your storage/bandwith. I want to emphasize the fact that the cost for a full node can be shared between multiple persons, however the cost of a transaction can hardly be shared so transaction fees may have a bigger impact on centralization than the cost of running a full node.

That said, I just verified the avg transaction value on https://bitinfocharts.com/bitcoin/. It says it was approx. 71,125USD in the last 24h, the avg transaction fee was 2.44USD. For now I think your proposal makes more sense...

I'm far more concerned about the security of the network being impacted, instead of the issue surrounding the costs of a full nodes. In this day and age, most people simply wouldn't opt for a full node as their daily driver unless they're interested in Bitcoin. Most people wouldn't run a node, no matter how much money they can save simply because it is time consuming and not very rewarding.

The issue surrounding block size has really been discussed over and over again and I doubt we would reach a new conclusion by doing it again. Again, since this issue brings us to whether we scale on-chain or second layer, it doesn't make much sense to discuss it on this thread. I prefer the latter, 100MB blocks isn't really desirable for the near future.

[topcoin360]

I'm far more concerned about the security of the network being impacted, instead of the issue surrounding the costs of a full nodes. In this day and age, most people simply wouldn't opt for a full node as their daily driver unless they're interested in Bitcoin. Most people wouldn't run a node, no matter how much money they can save simply because it is time consuming and not very rewarding.

The miners are the ones securing the network and I think most of them can easily afford to buy more storage/bandwith. In this regard, less people running a full node isn't really a threat...

The issue surrounding block size has really been discussed over and over again and I doubt we would reach a new conclusion by doing it again. Again, since this issue brings us to whether we scale on-chain or second layer, it doesn't make much sense to discuss it on this thread. I prefer the latter, 100MB blocks isn't really desirable for the near future.

If the demand for block space increases more than the supply then eventually the transaction fees will become so high that only the rich could afford them. Here's the problem and one solution..

In theory, the sender does not have any incentive to pay more than the "min fee" if there's no excess demand as he doesn't have to compete against other people for block space. If there's an excess demand then the block size limit willl determine how many transactions will pay more than the min fee, therefore the block size limit and the avg transaction fee are inversely related. We can balance the supply and demand with this simple equation:

new block size limit = previous block size limit x current avg fee / previous avg fee

We know that the avg fee depends on the amount of transactions that are waiting to be confirmed AND the block size limit, the demand for block space shouldn't change much in the short term.

[ranochigo]

The miners are the ones securing the network and I think most of them can easily afford to buy more storage/bandwith. In this regard, less people running a full node isn't really a threat...

It would be still ideal for a significant portion of the users to have the capabilities to run a full node. Relying on someone else for validation isn't really a good idea, and yes, I did agree that the full node numbers would probably dwindle in the future.

new block size limit = previous block size limit x current avg fee / previous avg fee

We know that the avg fee depends on the amount of transactions that are waiting to be confirmed AND the block size limit, the demand for block space shouldn't change much in the short term.

Do you think we should cap the block size with your variable block size scheme? You do realize that an increase in block size or transactions per block will inevitably result in the blocks being propagated through the network slowly or a far slower validation. This makes it unsuitable for smaller miners to be mining and will have to be directly connected to at least half of the network to achieve a lower stale rate. There is a reason why the blocks were capped at 1MB, and that any scheme should strive for a reasonable block size that doesn't compromise the security of Bitcoin. An increase in the stale rates also results in a decrease in the perceived security, as there can be multiple conflicting blocks at the same height.

I don't disagree that we need a block size increase. What I'm thinking of is a sustainable block size increase that balances the tradeoffs to the benefits.

[topcoin360]

Do you think we should cap the block size with your variable block size scheme? You do realize that an increase in block size or transactions per block will inevitably result in the blocks being propagated through the network slowly or a far slower validation. This makes it unsuitable for smaller miners to be mining and will have to be directly connected to at least half of the network to achieve a lower stale rate. There is a reason why the blocks were capped at 1MB, and that any scheme should strive for a reasonable block size that doesn't compromise the security of Bitcoin. An increase in the stale rates also results in a decrease in the perceived security, as there can be multiple conflicting blocks at the same height.

I don't disagree that we need a block size increase. What I'm thinking of is a sustainable block size increase that balances the tradeoffs to the benefits.

As you mentioned earlier..

The issue surrounding block size has really been discussed over and over again and I doubt we would reach a new conclusion by doing it again.

Unless the block size limit is decided at the protocol level we will have to have this debate over and over again! By having a self-regulated system we wouldn't have that problem. So what is your solution?

I'll just bring some adjustments to mine;

new block size limit = previous block size limit + (current total fee - previous total fee)
                                                                                           current avg fee               

I know this calculation may not be very accurate but that's a starting point. I don't think we should forbid people from owning BTC because some miners aren't able to keep up with the demand.   

[ranochigo]

As you mentioned earlier..

The issue surrounding block size has really been discussed over and over again and I doubt we would reach a new conclusion by doing it again.

Unless the block size limit is decided at the protocol level we will have to have this debate over and over again! By having a self-regulated system we wouldn't have that problem. So what is your solution?

I'll just bring some adjustments to mine;

new block size limit = previous block size limit + (current total fee - previous total fee)
                                                                                           current avg fee              

I know this calculation may not be very accurate but that's a starting point. I don't think we should forbid people from owning BTC because some miners aren't able to keep up with the demand.  

I've highlighted the constraints of the network with a larger block size and why a block size that is excessively large isn't favorable for the network. I'm not concerned about your algorithm, I'm concerned about whether you think it is okay for the so called self-regulated system to regulate the block size such that it can potentially take up to minutes to propagate across the network.

Do you think the point of the block size we have today is to introduce scarcity into the block or is it ensure that the blocks are appropriately sized and thereby preventing any issues, pertaining to the security of the network or it's resources? Your self-regulated system is not going to work if it can have the potential to make the network excessively centralized or insecure. There is a very good reason why most of Bitcoin's derivatives don't have a dynamic or an unlimited block size (for which a dynamic block size without any hard cap can also be considered as an unlimited block size).

Edit: If you think that it is fine for a dynamic block size without any upperlimits, then I rest my case. I don't have anything to add on ontop of what I've mentioned and I'm not a huge proponent of increasing it to meet a level that could be compared to the TPS of a mass adoption.

[topcoin360]

I've highlighted the constraints of the network with a larger block size and why a block size that is excessively large isn't favorable for the network. I'm not concerned about your algorithm, I'm concerned about whether you think it is okay for the so called self-regulated system to regulate the block size such that it can potentially take up to minutes to propagate across the network.

I understand your point but if the limit is not high enough then many people won't even be able to spend their coins which is another problem.

Do you think the point of the block size we have today is to introduce scarcity into the block or is it ensure that the blocks are appropriately sized and thereby preventing any issues, pertaining to the security of the network or it's resources? Your self-regulated system is not going to work if it can have the potential to make the network excessively centralized or insecure. There is a very good reason why most of Bitcoin's derivatives don't have a dynamic or an unlimited block size (for which a dynamic block size without any hard cap can also be considered as an unlimited block size).

It is to protect the network and I think we must have a limit. I just think the free market should decide what that limit should be and the miners should adapt accordingly.

Edit: If you think that it is fine for a dynamic block size without any upperlimits, then I rest my case. I don't have anything to add on ontop of what I've mentioned and I'm not a huge proponent of increasing it to meet a level that could be compared to the TPS of a mass adoption.

I believe you prefer a block size increase based on technological progress and I favor a block size increase based on demand. I proposed a way to calculate the block size limit, so far you haven't. I'll briefly explain how my equation could balance supply and demand..

new limit = (current total fee - previous total fee) / current avg + previous size limit

We calulate the excess demand or excess supply relative to the previous period then we adjust the block size limit to meet a new equilibrium (assuming that the demand is constant).

Could you tell us how would you determine what the block size limit should be in the future?

[ranochigo]

Could you tell us how would you determine what the block size limit should be in the future?

Estimate the time it takes for blocks to be propagated through the majority of the network. Determine the block size that still takes a reasonable amount of time to propagate through the network and use that as the max block size.

Currently, the 4vMB blocks have a median propagation time of 6.5s (or less since the study was done a long time ago). If we can keep the expected stale rates to be <5%, then I consider it an acceptable compromise. Expected stale rate is a function of the time it takes for the block to propagate and the block intervals.