Adjustable Blocksize Cap: Why not?

[PrimeNumber7]

Your suggestion effectively allows the miners to decide the blocksize. It would be trivial and cost-free for the miners to either send many transactions to themselves with an arbitrary transaction fee, or to include fewer transactions than is economically logical. 

Actually, there is the cost of opportunity because miners don't get paid mining their own transactions. Also, I don't see why a miner would purposely raise his own storage cost...

A miner does not get paid to confirm his own transactions, but he also does not pay anything to confirm his own transaction. If the maximum block size is based on the last x number of blocks, including additional transactions will increase the maximum block size in the future. There is some opportunity cost, in the form of the greater chance that a block will be orphaned when it includes an additional transaction.

It doesn't make any sense. When the demand for block space exceeds the supply you'd rather mine high paying real transactions than your own no paying fake transactions.

The miners could make blocks look full with their own fake transactions that appear to pay high transaction fees, and leave only a small number of actually paying transactions outstanding. This would make it appear the market transaction fee rate is higher than it actually is.

The additional storage cost of including a transaction is close to zero.

Does that mean there is no miracle solution to spams?

Correct. A miner with a small percentage of total mining capacity could potentially broadcast valid spam transactions, and end up with more mining revenue after accounting for the transaction fees from the spam transactions.

If something like this BIP were to be implemented, I would suggest the automatic growth be limited to 10 years, and after 5 years, a new hard fork can be implemented (if there is consensus) to extend the growth indefinitely.

I agree, 5-10 years seems more reasonable than 40+ years. But what do you think about the growth percentage? Is 17.7% is just right or feels too big considering Bitcoin community is conservative?

It is an arbitrary figure, and I haven't studied the data supporting it. I would prefer that the rate be too high than too low. If the rate is too high, a soft fork can be implemented to reduce the rate, but if it is too low, a hard fork would be required. It is much easier, almost trivial, to implement a soft fork, while a hard fork is at least an order of magnitude more difficult.

[1714792254]

1714792254

[1714792254]

1714792254

[Farul]

And with an x3 lower average fee which you successfully managed to omit from the equation.

isn't it because ETH tx is much smaller(roughly 1/3 bitcoin tx)? the Fee/byte is still roughly the same

With 10MB blocks, costs of running a node would increase exponentially.

https://bitcoin.stackexchange.com/questions/43675/why-do-bigger-blocks-make-it-more-expensive-to-run-a-full-node

signature validation (which is currently still the majority of the CPU cost) scales linearly with the number of hashes. Signature hash computation scales O(num_transactions * avg_transaction_size^2). Database lookups/updates scale O(inputs) and O(outputs), and each will get slower over time as the UTXO set grows.

[Wind_FURY]

With 10MB blocks, costs of running a node would increase exponentially.

Unfortunately, this is simply not true. Another statement without proof.

I’ll stop you there. Full node hardware, and bandwidth requirements plus costs won’t increase as the block size increase? Then explain Ethereum. It’s simply a common-sense statement. The proof is all there, plain for you to see.

[pooya87]

And with an x3 lower average fee which you successfully managed to omit from the equation.

isn't it because ETH tx is much smaller(roughly 1/3 bitcoin tx)? the Fee/byte is still roughly the same

It's about 1.29x higher in ETH! Although fees are computed differently in ethereum but working with raw bytes and amount paid we have

____________________	ETH	BTC
Average tx size in kBytes	0.230	0.707
Average tx fee	0.005500000	0.00042000
fee/byte	0.000023910	0.00000059
fee/byte in USD	$0.029	$0.022
Ratio	1.29

[aliashraf]

Decentralization is hard to gain and easy to lose, I'm afraid..
And achieving Byzantine fault tolerance quality is much easier than actual decentralization.

In the case of Bitcoin, to achieve just Byzantine security, three nodes responsible for block production and validation would be enough, I suppose.

But would it really have anything to do with decentralization?
Of course not....

Good.

Do not forget that mining pools are not a threat to Bitoin's decentralization just because miners can unsubscribe at any time and start running full nodes on their own.
If the owner of a large mining pool does anything harmful to Bitcoin, it will instantly lose miners and market position and its potential to harm ends.

No. Unfortunately such a switch for miners neither by going solo (because of the variance) nor even by joining honest pools (at least fast enough, and again because of the variance) is practical.

Bitcoin's mining industry is still far from the theoretical limits of its development.

Now there are tens of thousands of full nodes dealing only with validation, in the future such a number of full nodes may turn out to be necessary for the free operation of fully developed mining.

YES! It'd be so better if you haven't made the comment before this one, what a waste.


P.S.
I was following Greg's sent merits, just like a normal stalker   noticing that he has merited this post. Now, I'm confused:
Which part of the post deserves big Maxwell's appreciation?

It'll be a total surprise, actually the second in the last couple of weeks, if it turns out to be the right part, Because @gmaxwell has not been there for a LONG time, though, it isn't too late, and he is making moves, IMHO.

[Wind_FURY]

With 10MB blocks, costs of running a node would increase exponentially.

Missed your post, but can you show source about exponential growth? What i know is only about quadratic growth verification time for certain signature, but SegWit already fix it.

Source : https://bitcoincore.org/en/2016/01/26/segwit-benefits/#linear-scaling-of-sighash-operations

Sorry, I’m wrong. Growth will not be exponential, BUT a one time block size increase to 10MB, and with current Bitcoin on-chain usage keeping those blocks full, would make each node process 10 times the data, and make it “feel” exponential. I want to see Bitcoin Cash’s blocks full, everyday, for a whole year.

[ABCbits]

BUT a one time block size increase to 10MB, and with current Bitcoin on-chain usage keeping those blocks full, would make each node process 10 times the data, and make it look exponential.

People call it linear growth or O(n)

[GGUL]

Sorry, I’m wrong. Growth will not be exponential, BUT a one time block size increase to 10MB, and with current Bitcoin on-chain usage keeping those blocks full, would make each node process 10 times the data, and make it “feel” exponential.

“feel” exponential - this is something new in cost estimation.

My computer, bought 5 years ago, processes a new block in less than 1 second. a 10mb block will process less than 10 seconds. And blocks appear once every 10 minutes. The only expense is disk space. At 10MB block - 0.5 TB per year. 2tb. hard disk ~$ 60 and this is for 4 years. The cost per year is $ 15, per month ~ $ 1.2. And now that I make a modest 12 transactions a year, look at the size of the average fee, and estimate how much I have costs due to 1MB. block.

You understand that it is your "concern" for the user that only brings them extra costs.

Even if we take the more expensive option, together hdd ssd. 2tb ssd - ~ $ 240. Divide by 48 months - $ 5 per month. The fee for one transaction per month is about the same level, and I will not pay this fee. That is, I will be at the same level in terms of costs. But in return, I get a 10-fold increase in the Bitcoin system. (10x! , Karl).

I want to see Bitcoin Cash’s blocks full, everyday, for a whole year.

You are more careful with your desires. If the Bitcoin Cache develops to the point that users will make 2.5 million transactions a day, and bitcoin will remain at its 350 thousand, then I do not think that this is a a good outcome for Bitcoin..

[DooMAD]

I want to see Bitcoin Cash’s blocks full, everyday, for a whole year.

You are more careful with your desires. If the Bitcoin Cache develops to the point that users will make 2.5 million transactions a day, and bitcoin will remain at its 350 thousand, then I do not think that this is a a good outcome for Bitcoin..

That's not the only metric people use to measure the overall success of the network, though.  If, for example, BCH's nodecount dropped to single digits, I wouldn't care how many millions of transactions it could process per day.

Just that increases should be moderate, not excessive.  

I understand your moderate position.
I just can't figure out how moderate growth is better than natural growth. After all, your moderate growth implies an artificial restriction of growth. Questions appear. What for? We tell users: some of your transactions are unworthy to get into the blockchain. What do we gain by throwing out some part of the transactions? My answers to these questions are: nothing. Only slowing down the development of Bitcoin.

If you can find a way to distinguish at protocol level between "natural growth" and "malicious growth", then let's hear it.  I get the part where encouraging a fee market is something many users are not fond of, but I see the sense behind it.  If something is valuable but there is very little cost to use it, people will simply abuse it.  That's just the nature of things.

As an analogy, I work in a call centre dealing with insurance.  I basically listen to people every day moaning about there being an administration fee to make changes to their car insurance policy.  None of them seem to grasp the fact that if there wasn't a fee, more people would call in more frequently to make superfluous changes.  Instead of paying the cost of adding a driver to a car insurance policy for the remainder of the policy term, you know some tightwads would be calling every other week to add a driver and then calling back a few days later to remove them again.  Then they'd tell their friends to do it because it would save them money and suddenly everyone is doing it.  People would take the piss if given the opportunity.  So if we didn't hire more staff, more customers would be stuck on hold for longer trying to get through to speak to someone.  The service would deteriorate and people would complain when they have something important or urgent to do and they can't even get through to us because the lines are jammed with skinflints.

Sometimes discouraging volume is the wiser course of action.


//EDIT:

That's not the only metric people use to measure the overall success of the network, though.  If, for example, BCH's nodecount dropped to single digits, I wouldn't care how many millions of transactions it could process per day.

A blockchain of 10mb. blocks, in which 2.5 million transactions are made every day, will hold less than 10 users? This is so implausible that there is nothing to comment on.

My belief was that I was engaging with someone who understood the distinction between the number of nodes and the number of people transacting.  Someone who knew what SPV was.  Perhaps I was mistaken? 

[amishmanish]

The transaction fees will eventually be the only source of income for the miners so we need a system that will force the user to "tip the miner" but which will also allow more block space for peak periods. A 10MB limit seems reasonable, the max yearly storage space that could be required would be approximately 0.5TB. A 0.1MB min gives enough space for most transactions.

The scarce space is the "commodity" being sold in the fee market. If you increase and decrease the supply depending on your price, I doubt there will be any customers who will want to buy your product for long. Can you think of a commodity that acts this way except the commodities that have middlemen traders hoarding capacity? Are those the best examples of the kind of market we want a bitcoin fee-market to be?

This solution seems to fail on the simplest of economic model. Someone accustomed to actual financial modelling can comment better on this.

In addition, this also opens up a situation where people will be waiting and speculating on the transaction fees.

2. How many previous block should be considered to calculate average transaction fee?
One.

Isn't verification of target size limit a thing while producing blocks. How do you calculate the average transaction fee for the current block when you haven't decided the block size and hence the topmost transactions to keep in it? Or do you propose to just calculate all the fees in all the transactions in mempool?

The logic is there. I think that an immediate adjustment to the change in price would be the best...

So I assume that you haven't seen or attempted an implementation of this sort on a test net etc. That would be the best way to go i suppose.

[GGUL]

I want to see Bitcoin Cash’s blocks full, everyday, for a whole year.

You are more careful with your desires. If the Bitcoin Cache develops to the point that users will make 2.5 million transactions a day, and bitcoin will remain at its 350 thousand, then I do not think that this is a a good outcome for Bitcoin..

That's not the only metric people use to measure the overall success of the network, though.  If, for example, BCH's nodecount dropped to single digits, I wouldn't care how many millions of transactions it could process per day.

A blockchain of 10mb. blocks, in which 2.5 million transactions are made every day, will hold less than 10 users? This is so implausible that there is nothing to comment on.

If you can find a way to distinguish at protocol level between "natural growth" and "malicious growth", then let's hear it.  I get the part where encouraging a fee market is something many users are not fond of, but I see the sense behind it.  If something is valuable but there is very little cost to use it, people will simply abuse it.  That's just the nature of things.

"malicious growth" - As far as I understand, this is filling the blockchain with transactions with zero or very small fee.

There is a very simple and elegant way to solve this problem. You need to enter a minimum fee amount. Transactions with a fee of less than will be invalid. The problem is solved, and solved well. Because it will only affect those who make "malicious" transactions.

The way this is solved now, through the block size limit , is a terrible solution. I do not know if it is possible to come up with a worse solution than this. It does not solve the problem when the block is not complete - "malicious " transactions hit the block. When the blocks are full and there are queues, many good transactions are thrown out along with the "malicious " ones. For example, right now, when the average transaction is $ 10, many transactions with fees of several dollars do not fall into the blocks. Good customers who want to get into the nearest block should play the game "guess the right fee".

If you look at the analogy with your work. For you, the cost of service does not depend on the number of customers at the moment. And the cost of service does not change every second.

[topcoin360]

At least the number isn't entirely arbitrary picked.

2. How many previous block should be considered to calculate average transaction fee?
One.
3. How often should block limit changed?
On every block.

The number you chose have some obvious problem, have you considered the possibility of
1. Miner mine 2 blocks at once, where the 2nd block usually are empty.
2. Analysis which shows certain days allows you move Bitcoin quickly with lower fees. See https://bitcointalk.org/index.php?topic=5250569.0.
3. Messing with various transaction fee estimation algorithm, which leads user pays too much or waiting too long.

Ok, we must not forget that there is some electricity cost for mining blocks, mining an empty block is not profitable. An adjustable blocksize cap algorithm would reduce the limit of the block when the demand for space is low which would maintain some level of competition for block space but the algorithm would increase the limit in periods where the demand is high which would improve the network's reliability while reducing the transaction fees. The client software would have to be updated.

I think that an immediate adjustment to the change in price would be the best...

You can't include external data without oracle or someone who you must trust.

I wasn't thinking about importing the data from external sources. We can easily compute the avg transaction fee of the last block:

total amount of all the transactions inputs - total amount of all the transactions outputs
                                                      nb of transactions

@amishmanish, I think this post may have addressed your concerns as well...                                                

[pooya87]

There is a very simple and elegant way to solve this problem. You need to enter a minimum fee amount.

It is a very lazy solution that only causes more problems than it solves.
For starters what would the minimum fee value be? Lets say the coin is worth $0.01 you hardcode the minimum to be 0.01X (X is the coin). Now price goes up to $10 and the minimum fee of that coin is suddenly 10 times more at $0.1, then it goes up to $100 and fee reaches $1 and so on.
Your solution simply added mandated hard forks each time there is a big price rise to reduce the minimum fee.

[amishmanish]

Ok, we must not forget that there is some electricity cost for mining blocks, mining an empty block is not profitable.

The question is not really about empty blocks. All miners don't work on the same set of transactions from the mempool. It can happen that some  miner arrives at the next acceptable hash immediately, rather than 10 mins after the current block.

total amount of all the transactions inputs - total amount of all the transactions outputs
                                                      nb of transactions

@amishmanish, I think this post may have addressed your concerns as well...                                                

If you are just calculating from the mempool then it becomes unrelated to the actual set of transactions you want to affect price-wise. This continuous variation also puts another set of calculations, consensus requirement and propagation delays for the miners to calculate, especially if you talk about adjusting size in every block. I don't think this is feasible.

Some kind of DAO based variation over periods of high fees maybe a different thing but that opens up to politics and is entirely not suited to Bitcoin's mathematical purity. That is why I have been asking if you have seen an actual implementation or you plan to think this over and then come up with calculations.

I think you should move this topic to "Bitcoin Discussion" already.

[tromp]

Your solution simply added mandated hard forks each time there is a big price rise to reduce the minimum fee.

Not necessarily. You can have a minimum fee scaling factor in a configuration file.
After all, this is not a consensus parameter. So after the price has gone up by an order of magnitude
for a long enough period, you could agree to have as many nodes as possible to update this scaling factor
to be 10 times smaller. Over time, more and more nodes will adopt this new value, and allow
the mempool acceptance and relay of transactions with 10x smaller fees.

[Wind_FURY]

Sorry, I’m wrong. Growth will not be exponential, BUT a one time block size increase to 10MB, and with current Bitcoin on-chain usage keeping those blocks full, would make each node process 10 times the data, and make it “feel” exponential.

“feel” exponential - this is something new in cost estimation.

My computer, bought 5 years ago, processes a new block in less than 1 second. a 10mb block will process less than 10 seconds. And blocks appear once every 10 minutes. The only expense is disk space. At 10MB block - 0.5 TB per year. 2tb. hard disk ~$ 60 and this is for 4 years. The cost per year is $ 15, per month ~ $ 1.2. And now that I make a modest 12 transactions a year, look at the size of the average fee, and estimate how much I have costs due to 1MB. block.

You understand that it is your "concern" for the user that only brings them extra costs.

Even if we take the more expensive option, together hdd ssd. 2tb ssd - ~ $ 240. Divide by 48 months - $ 5 per month. The fee for one transaction per month is about the same level, and I will not pay this fee. That is, I will be at the same level in terms of costs. But in return, I get a 10-fold increase in the Bitcoin system. (10x! , Karl).

Your computer is not other people’s computers. Plus the real problem is also bandwidth, and latency remember? The Initial Blockchain Download has become more and more difficult.

You want real scaling, a solution like this, if successful, is real scaling, https://medium.com/mit-media-lab-digital-currency-initiative/utreexo-demonstration-release-a0d87506fd70

I want to see Bitcoin Cash’s blocks full, everyday, for a whole year.

You are more careful with your desires. If the Bitcoin Cache develops to the point that users will make 2.5 million transactions a day, and bitcoin will remain at its 350 thousand, then I do not think that this is a a good outcome for Bitcoin..

Increasing transaction throughput, but centralizing the validators is not real scaling.

[pooya87]

Your solution simply added mandated hard forks each time there is a big price rise to reduce the minimum fee.

Not necessarily. You can have a minimum fee scaling factor in a configuration file.
After all, this is not a consensus parameter. So after the price has gone up by an order of magnitude
for a long enough period, you could agree to have as many nodes as possible to update this scaling factor
to be 10 times smaller. Over time, more and more nodes will adopt this new value, and allow
the mempool acceptance and relay of transactions with 10x smaller fees.

Click on the quote in my comment and read the full comment first. The user is talking about preventing miners from filling the blocks with cheap fee transactions. You cannot prevent that by anything that is not consensus rules such as a simple configuration that already exists called minrelaytxfee.

[amishmanish]

total amount of all the transactions inputs - total amount of all the transactions outputs
                                                      nb of transactions

@amishmanish, I think this post may have addressed your concerns as well...                                                

If you are just calculating from the mempool then it becomes unrelated to the actual set of transactions you want to affect price-wise. This continuous variation also puts another set of calculations, consensus requirement and propagation delays for the miners to calculate, especially if you talk about adjusting size in every block. I don't think this is feasible.
--snip--

In continuation of this, it just occurred to me that any attempt at dynamically calculating the "miner fees" based on mempool transactions will automatically open up the network to all sort of nuisance attacks.

Not sure if I am thinking this correctly but a malicious actor could simply spam the chain with hundreds and thousands of transactions with bare minimum fee. The transactions just stay there, never being picked due to the very low fees and screwing up your calculations. You end up making an elegantly sybil-resistance system welcoming to the most basic of sybil attacks and manipulation.

[Farul]

You can't include external data without oracle or someone who you must trust.

Maybe we can use Mining difficulty as a predicting tool for the price?
When bitcoin prices rise, mining profitability will rise, resulting in more people mining, and therefore increasing difficulty. we need to factor in mining hardware improvement though (Updated Moore's Law?)

Your computer is not other people’s computers. Plus the real problem is also bandwidth, and latency remember? The Initial Blockchain Download has become more and more difficult.

You want real scaling, a solution like this, if successful, is real scaling, https://medium.com/mit-media-lab-digital-currency-initiative/utreexo-demonstration-release-a0d87506fd70

is the validating process really significantly increase with that blocksize? i think if there will be any blocksize increase, it should be increased to the point where mini-computer like Raspberry Pi still can handle it.
and BTW, isn't that utreexo is just like a pruned node but with "compressed" UTXO?
I think, for now, there's no need for blocksize increase yet. the recent increase in bitcoin transaction fee are most likely because the significant price increase, and it maybe won't last forever, once the price fall significantly, the transaction fee will go down too(2017, mid-2019).  there needs some long-term transaction fee increase to make it worth it to increase the blocksize. Maybe when we start using bitcoin as a method of payment, not as speculative asset.

[GGUL]

There is a very simple and elegant way to solve this problem. You need to enter a minimum fee amount.

It is a very lazy solution that only causes more problems than it solves.
For starters what would the minimum fee value be? Lets say the coin is worth $0.01 you hardcode the minimum to be 0.01X (X is the coin). Now price goes up to $10 and the minimum fee of that coin is suddenly 10 times more at $0.1, then it goes up to $100 and fee reaches $1 and so on.
Your solution simply added mandated hard forks each time there is a big price rise to reduce the minimum fee.

You just haven't tried it yet. Everything is known by comparison.

Managing the fee through the block size:
If there are few transactions, the fee is sharply reduced, to cents. If there are a lot of transactions, the fee increases dramatically, up to $10. That is, it can change 100 times. And in a very short time - in a day, 2.
As I wrote above, this is a bad way, because it constantly causes inconvenience to bona fide users.

Minimum fee management:
The fee is set in satoshi and, let's say, changes every 2 weeks. What is a change algorithm is a topic for discussion. Now the price does not change dramatically by 10 times. The recent sharp increase is just a 2-fold increase in 2 weeks.(even in December 2017, the growth was 2-fold in 2 weeks.) It's not that bad. Instead of 10 cents - 20 cents, instead of $ 1 - $ 2 before changing the fee. - not terrible, against the background of the current $10.  
As for hard forks. Since this is adding restrictions, you can theoretically do with a soft fork. Possible, You may need one hard fork.