Topic: About block size limit and transactions fees - page 2. (Read 1088 times)

Large block takes a longer time to validate, so an excessively large block can be a resource exhaustion for underpowered nodes which are incapable of validating them fast enough. Either that, or to prevent blocks being excessively large and making storage excessively expensive, at least at that point in time. That isn't really considered DOS, or at least I don't think it is.

Block caps limits the number of transactions that can be included in the blocks every 10 minutes. A DOS would be a scenario where people start to spam "useless" transactions to prevent others from getting their transactions into the blocks, without spending more in fees. It has been done before, during the whole segwit ordeal. Whether an attack like this would be viable at this day and age depends on the motives and how much they are willing to spend.

Isn't DDoS made in the mempool only? Essentially, an attacker broadcasts dust transactions to occupy the space and prevent from other transactions to be mined. I suppose that it doesn't matter if the block size is 1MB or 1GB, because the analogy of the median fee and the total fees the attacker has to pay remain the same.

It is surely not a “hack”. Maybe “attacking” suits more properly.

Generally a hacking is when someone explores a system weakness. For example, the person who found the problematic functions from Poly's source code and decided to get advantage of it is a hacker.

Why would I be worried about network congestion when the miners can increase the block size “based on demand”. What you should be worried about is the centralizing nature of your proposal, and how a cartel of miners can exploit the system by faking demand. Like what gmaxwell mentioned, Calvin Ayre has been faking demand in BSV. Haha.


“Hack” would not be the term I would use.

This is wrong.
Miners AND nodes are both securing the network. Miners by providing hashrate and securing the network against 51% attacks and nodes by enforcing the consensus rules and keeping Bitcoin decentralized.

When speaking of number of nodes, block size, etc. saying things like "less" is ambiguous. The real question is "by how much?".
For example when discussing block size increase it should be clarified whether we are talking about a small increase (eg. 1 to 2 MB) or a bigger increase (eg. 1 to 100 MB), there is a big difference between these two. Same with number of nodes. If you could find historical data of nodes or a chart showing the count you could see that we have had big drops and slow rises in the past. For instance back when block started becoming full and again when there was a spam attack where mempool grow to huge sizes the number of nodes decline. But when the price started rising and bitcoin adoption grew the number of nodes went back up again.

So lets put "less people running a full node" into perspective. If now that we have 50k nodes it dropped to 20k, things will still be fine but if it dropped to 1k with only a dozen listening nodes then the network will be in some trouble that will only get worse with time.

Also the thing about block size is that it doesn't matter how much you increase it, in the end it won't be enough. So the trick is to increase it in a way that it minimize the inevitable damage but not so much that it disrupts everything.

If you're worried about a congestion attack with a higher limit then you should also be worried about a DDoS attack with a lower limit. Idk what the exact limit should be, but I know that it should be updated more than once every 10 years.  

I didn't expect this thread to turn into a capitalism vs. communism debate (those who believe in free market and those who believe that everyone should run a full node ). The only thing I can tell you is the customers will always go to whoever can give them what they want.

Since we're talking about the possibility of a new consensus rule and not a vector of attack, I think we should discuss the technical details and see if it works in the first place. I've seen a potential flaw in the model I proposed, although it is very unlikely to happen, in theory the excess supply could exceed the actual limit which means the block size limit in the next epoch would be below 0. We can easily fix that problem by introducing a minimum of 1MB which is the current maximum value (that would be our starting point).

Open for discussion!

"an attack vector, that would possibly disrupt the network"- isn't that "hacking the system"?  

The miner can increase its income due to the fact that users will pay a large commission for the transaction. This can be achieved by reducing the block. Or by setting a high commission for the right to be included in the block. And the miners ALREADY have such an opportunity. Miners can set any commission they want. To do this, they do not need to "fake demand".

A couple of years ago, a delusional idea was popular that miners fill blocks with their transactions (fake  demand) in order to artificially increase the mempool and thus earn more commissions. Miners ALREADY have such an opportunity - "to fake demand".  

Delusional ideas die very hard.

Hack the system? No, that’s not the reason. I’m talking about incentives. If you give the miners the power to decide how large the blocks should be “based on demand”, then you’re giving them an incentive to fake that demand for them to earn more in fees. Especially when most of the coins are mined out.

Miners can do this right now. The main mining pools can strategically exclude others from their exclusive "subnet" by simply broadcasting a new block only among themselves, and transmitting it to the general network with some delay. If it was profitable. Judging by the fact that this is not being done, the miners do not have any benefit from this. Or they do not want to do this for the sake of a minimal and risky increase in income. Any activity of this kind is a loss of Bitcoin's reputation, which will eventually lead to much greater losses.

Hmm. I recall certain pools don't have direct connections to each other and were resorting to running zombies on each other in the past. I find the current stale rates fairly reasonable and mining pools don't necessarily have to resort to those tactics to improve their propagation. If we were to reach the state whereby blocks takes 50 seconds to propagate, then is it possible for the major mining pools to strategically exclude others from their exclusive "subnet"?

I don't think anyone has ever claimed that. On the contrary, we have proven that full validation is sufficiently fast that the benefits of SPV mining is slim to none. The problem of SPV mining is that it is two fold; the incident caused a longer than usual block re-org and the damage could've definitely extended beyond the users.

You want to say that if all miners establish the highest possible exchange rate among themselves, this makes the system "more centralized". Judging by the number of orphan blocks, the miners have achieved this goal. That is, at the moment, the miners are as "centralized" as possible in terms of the exchange between them. It is simply impossible to make it "more centralized" already.

(p/s/ reasoning in terms of "increasing / decreasing centralization/decentralization" is meaningless until you determine what these indicators are:" level of decentralization / level of centralization". And how these levels are measured.)

Some miner will not want to, cannot speed up the exchange with other miners as much as possible and will lose his income because of this. And another miner can. So these are the problems of the miner. We do not solve the problems of miners in terms of the price of electricity, equipment, taxes. Why should we solve the problems of the miner in terms of its exchange rate over the network?
As far as I know, there has been one failure with spv mining over the past 5 years. And besides the loss of a part of the miners ' income, there were no other losses. Yes, spv mining has risks for the miner. And the miner himself decides whether to use it or not. And if you claim that it is impossible to increase the block in order not to encourage miners to use spv mining, then this is one of the most ridiculous arguments against increasing the block.
IIt is interesting that now, when it is almost free to save a full node, less than 1% of users save it. Why we set such a goal: so that most users can have a full node. If most people don't need it. To achieve this goal, we almost stopped the development and expansion of the bitcoin system 4 years ago. As for me, this is too expensive and pointless a sacrifice.

Maybe it makes sense to look at reality and change our goals. For example, so that the number of nodes is not less than a certain number, which is enough to ensure the security of the system.

Correct. Keep in mind that doing so would make the current mining scene more centralized, whereby miners that are not interconnected with the majority of the miners are more likely to experience more orphans, due to the lack of a direct connection.
I would prefer miners to validate the blocks first. SPV mining is not a behavior that I think we should encourage, we've had a mishap with SPV mining in the past so probably not such a good idea given that current validation speeds are sufficiently fast.

I don't think those sizes are particularly unrealistic to achieve in the future. If you don't need the majority of the network to be able to run their own nodes and that mining to be centralized with a few entities, then it should probably be fine.

1. It is worth noting that the speed of distribution of blocks in general on the network does not play a special role for mining. The main thing is what is the speed of distribution of blocks within the subnet that covers miners. If the speed inside the subnet was at the level of 1 second, we would have ~1.6% of orphan blocks. But there are much fewer orphan blocks at the moment. Somewhere on the forum, a figure of 0.0024% was given (I can't vouch for the accuracy). This means that the speed is now much less than 1 sec.

2. When using a technology such as spv mining, the block size ceases to affect the number of orphan blocks. Miners start mining the next block almost immediately after the block appears. However, this increases the number of empty blocks. But I think this is quite a reasonable compromise: reducing the number of orphan blocks at the expense of some increase in empty blocks. Moreover, an empty block, which sometimes appears a few seconds after a non-empty block, does not cause any inconvenience to users.

From all this, we can conclude that, for example, 10-20 MB. blocks do not pose any threat to the security of the network in terms of orphan blocks.
As far as I understand, you do not want to allow miners to increase the block, because they will have the opportunity to hack the system. Very strange reasoning. After all, miners ALREADY have a 100% chance to hack the system. If, of course, they have such a collective desire. For example, they can start mining empty blocks. Or make a 51% attack. That's all, the system is broken.

It looks like this: a person has a full warehouse of weapons. And you : we can't give him a loaded gun. He will have the opportunity to kill someone.

The security of the bitcoin system is 99.99% dependent on the miners. And if you give them the opportunity to change the block size, nothing will change. Similarly, the security will be 99.99% dependent on the miners.

A block size increase “based on demand”, and leaving it to the miners to decide how large the blocks should be “based on demand” is a very dangerous proposition, topcoin360. It will open an attack vector, that would possibly disrupt the network.

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.

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.


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.

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?

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.

As you mentioned earlier..


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.   

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

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

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.