About block size limit and transactions fees

[topcoin360]

Hi guys,

I've noticed that the transactions fees went down since a couple of weeks which I think is a good thing (but maybe not for the miners ). I thought that it might be a good time to talk about the block size limit (just an open discussion about the different options that we have). Of course we could keep the block size limit to 1MB and try to increase the network's throughput by optimizing the codes which I don't think is the best option (I must apologize to the dev team but it seems like technological progress is outperforming your work ). So I thought about something and I'd like to see what you've got.

Just like we have a DAA to maintain the block time at 10 min, we could have a dynamic block size limit algorithm to maintain the transaction fee at 1%. So basically..

If the avg transaction fee is greater than 1% then the block size limit increases;
If the avg transaction fee is lower than 1% then the block size limit decreases;

To make our calculation we would assume that the total amount of the transaction fees remains constant and that the total amount being transferred is proportional to the block size limit (we could optimize the formula if needed). The adjustment would be done every 2,016 blocks.

I'm obviously just brainstorming here. Anything you don't like about this idea or any other suggestion?

[1714885814]

1714885814

[1714885814]

1714885814

[1714885814]

1714885814

[1714885814]

1714885814

[NeuroticFish]

to maintain the transaction fee at 1%. So basically..

Sorry, but I have bad news for you. Tx fee is not related to the amount of coins transacted. One can easily pay for 100 BTC transferred less than another for 0.001 BTC. The tx size in bytes is the one that matters and I find in nowhere in your equation.
"So basically"... all you wrote is completely off and worthless.

[Wind_FURY]

OP, but what mechanism would you propose to protect the network from the entities that would flood the mempool to increase the fees, and therefore, according to your proposal to maintain 1%, would increase the block size so much that many of the nodes that do not have the hardware and the bandwidth will not have the ability to keep up?

[topcoin360]

to maintain the transaction fee at 1%. So basically..

Sorry, but I have bad news for you. Tx fee is not related to the amount of coins transacted. One can easily pay for 100 BTC transferred less than another for 0.001 BTC. The tx size in bytes is the one that matters and I find in nowhere in your equation.
"So basically"... all you wrote is completely off and worthless.

May I ask are you in the dev team?

Firstly, yes it is. The fee that the sender is willing to pay depends on the amount he is transferring.
Secondly, the block size limit have a direct impact on transaction fees for obvious reasons.

So basically, what exactly is your argument?

[ranochigo]

Total fee that a transaction pays is dependent on the size, so it doesn't make sense to peg it to the avg TX fees. You would probably be looking to peg it to the fee rates, but that is assuming that it doesn't get manipulated by miners intentionally including smaller fee TXes or vice versa.

I don't think a dynamic block size really matters. It would be far more prudent to increase the current block size than have to add additional mechanisms to regulate the block size. We're talking about block limits, so if there isn't enough transactions to include, then there is no need for the blocks to at their limits.

[topcoin360]

OP, but what mechanism would you propose to protect the network from the entities that would flood the mempool to increase the fees, and therefore, according to your proposal to maintain 1%, would increase the block size so much that many of the nodes that do not have the hardware and the bandwidth will not have the ability to keep up?

I fail to see what would be the incentive to launch this kind of attack as the attacker can't generate more income or reverse a transaction by increasing the block size limit.

Total fee that a transaction pays is dependent on the size, so it doesn't make sense to peg it to the avg TX fees. You would probably be looking to peg it to the fee rates, but that is assuming that it doesn't get manipulated by miners intentionally including smaller fee TXes or vice versa.

I don't think a dynamic block size really matters. It would be far more prudent to increase the current block size than have to add additional mechanisms to regulate the block size. We're talking about block limits, so if there isn't enough transactions to include, then there is no need for the blocks to at their limits.

You need 51% of the network's hashrate to manipulate the block chain. A miner with 51% of the hashrate could already manipulate the transaction fees.

[ranochigo]

You need 51% of the network's hashrate to manipulate the block chain. A miner with 51% of the hashrate could already manipulate the transaction fees.

No miners would intentionally re-org blocks, that is quite stupid. With your proposals, certain miners can influence the size of the blocks for the next epoch for whatever reason they'd like. But the point of my post is more about why should we use a dynamic block size instead of a fixed block size increment? It doesn't necessarily bring any benefits either as using a larger sample size only serves to delay the block size change... It would be quite possible that the larger block size wouldn't be required after the block size changes.

[HeRetiK]

Firstly, yes it is. The fee that the sender is willing to pay depends on the amount he is transferring.
Secondly, the block size limit have a direct impact on transaction fees for obvious reasons.

The fee a sender is willing to pay may depend on the amount they are transferring, but that's irrelevant for the protocol. How low you can set your fee and still have your transaction be included within a reasonable time depends on how many inputs are being spent, not on how many coins. So if you received a lot of small transactions you'll pay a much higher fee for the same amount of coins than if you received just one large transaction.

Of course we could keep the block size limit to 1MB [...]

Block size limit has been effectively 2-4MB since SegWit's activation in 2017.

--

The problem with dynamic block size limits is that in the end it's pretty much like having no block size at all.

Reducing blocksize limits in times of low demand will do nothing but artificially increase mining fees without saving any storage space -- the blocks would have been half empty anyways.

Increasing blocksize limits in times of high demand, based on the amount of fees paid relative to the amount being sent, would not only inflate the blocksize to whatever upper bound you'd define for the dynamic blocksize range -- which would in practice end up us the blocksize limit anyway -- you'd actually even penalize efficient transactions over inefficient ones (e.g. transactions consisting of a lot of small inputs like faucet rewards and thus take up a lot more blockspace). That is, you'd have a system that would incentivize detrimental behaviour which is rarely a good idea for something that is supposed to be self-regulating.

Also note that due to the use of change addresses it's not even possible to reliably determine the amount that is being sent. If I spend USD 10,- worth of Bitcoin with USD 90,-worth of Bitcoin going back to a change address, your proposed system would have to base the fee on the total of USD 100,- being moved.

[BlackHatCoiner]

If the avg transaction fee is greater than 1% then the block size limit increases;
If the avg transaction fee is lower than 1% then the block size limit decreases;

Please be more explanatory; 1% of what? Of the transacted amount? Of the block size? In this case, 0.065 BTC? There are lots of factors involved when you have to make such change, especially if we include Segwit and other ways to reduce your transaction's size. I think that this way, the miners will prefer some transactions despite on the fee they're paying.

I have to agree with ranochigo for the block size.

[vjudeu]

to maintain the transaction fee at 1%

That's far more expensive than today! Even in LN there are nodes where you can pay 0.1% or where you can pay one satoshi per transaction. Someone having 1 BTC in a single UTXO will pay 0.01 BTC in your proposal, but transaction size could be less than 1 kB, that means over 1000 satoshis per byte!

Edit: more than that: in your proposal that would mean everyone will have a huge incentive to use as many UTXO's as possible! Even worse: transactions for outputs containing less than 100 satoshis would be free! So, someone having 1 BTC could pay 0.01 BTC once to split that into 99 satoshi outputs and then create as many free transactions as he want, bloating blockchain size all the time!

[pooya87]

So basically, what exactly is your argument?

Bitcoin fees are designed to work based on transaction size and not the amount. This can not change without changing everything else about bitcoin too (eg. change UTXO based to account base). Without making these fundamental changes you'd introduce easy attack vectors. For example I can create a single 4 MB weight transaction that has a small value and pays a small fee in order to fill a single block and continue that for every block.

[HeRetiK]

Even worse: transactions for outputs containing less than 100 satoshis would be free! So, someone having 1 BTC could pay 0.01 BTC once to split that into 99 satoshi outputs and then create as many free transactions as he want, bloating blockchain size all the time!

To be fair, this loop hole would be mitigated by the current dust limit of 546 satoshis. However I'm not entirely sure whether the dust limit is wallet dependent or actually part of the protocol consensus?

Great catch though! Without a dust limit, given this fee system one would be able to DDoS Bitcoin for free.

[vjudeu]

However I'm not entirely sure whether the dust limit is wallet dependent or actually part of the protocol consensus?

It's only checked at mempool level. If you are a miner, you can send single satoshis. More than that: you can send zero satoshis, you can have a lot of inputs and outputs transferring from zero to zero satoshis and it will be valid if included in a block, but rejected if sent to other miners (unless they change their configuration to accept free transactions).

Dust limit is not consensus rule, it is only artificially set as default to one satoshi per byte for mempools, any miner can turn that off.

[Wind_FURY]

OP, but what mechanism would you propose to protect the network from the entities that would flood the mempool to increase the fees, and therefore, according to your proposal to maintain 1%, would increase the block size so much that many of the nodes that do not have the hardware and the bandwidth will not have the ability to keep up?

I fail to see what would be the incentive to launch this kind of attack as the attacker can't generate more income or reverse a transaction by increasing the block size limit.

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.

[topcoin360]

The fee a sender is willing to pay may depend on the amount they are transferring, but that's irrelevant for the protocol. How low you can set your fee and still have your transaction be included within a reasonable time depends on how many inputs are being spent, not on how many coins. So if you received a lot of small transactions you'll pay a much higher fee for the same amount of coins than if you received just one large transaction.

Absolutely but the idea is to keep the fee at 1% on average, the percentage could vary from one transaction to another one.

Block size limit has been effectively 2-4MB since SegWit's activation in 2017.

--

The problem with dynamic block size limits is that in the end it's pretty much like having no block size at all.

Reducing blocksize limits in times of low demand will do nothing but artificially increase mining fees without saving any storage space -- the blocks would have been half empty anyways.

Increasing blocksize limits in times of high demand, based on the amount of fees paid relative to the amount being sent, would not only inflate the blocksize to whatever upper bound you'd define for the dynamic blocksize range -- which would in practice end up us the blocksize limit anyway -- you'd actually even penalize efficient transactions over inefficient ones (e.g. transactions consisting of a lot of small inputs like faucet rewards and thus take up a lot more blockspace). That is, you'd have a system that would incentivize detrimental behaviour which is rarely a good idea for something that is supposed to be self-regulating.

Also note that due to the use of change addresses it's not even possible to reliably determine the amount that is being sent. If I spend USD 10,- worth of Bitcoin with USD 90,-worth of Bitcoin going back to a change address, your proposed system would have to base the fee on the total of USD 100,- being moved.

As you mentioned, there is a min fee that the sender has to pay to have his transaction included in a block. That min fee is determined by supply and demand, with an inelastic supply like we have right now there is no way to control that fee which is IMO problematic.

--snip--

Please be more explanatory; 1% of what? Of the transacted amount? Of the block size? In this case, 0.065 BTC?

I meant the transacted amount of all the transactions combined.

to maintain the transaction fee at 1%

That's far more expensive than today! Even in LN there are nodes where you can pay 0.1% or where you can pay one satoshi per transaction. Someone having 1 BTC in a single UTXO will pay 0.01 BTC in your proposal, but transaction size could be less than 1 kB, that means over 1000 satoshis per byte!

Edit: more than that: in your proposal that would mean everyone will have a huge incentive to use as many UTXO's as possible! Even worse: transactions for outputs containing less than 100 satoshis would be free! So, someone having 1 BTC could pay 0.01 BTC once to split that into 99 satoshi outputs and then create as many free transactions as he want, bloating blockchain size all the time!

You probably misunderstood what I said, the goal is to keep the avg fee to 1%, the block size limit is adjusted every 2,016 blocks to meet that target. I'm not proposing to force the user to pay a 1% transaction fee, I'm not even proposing to change the fee structure.

The idea of dynamic block size already proposer and rejected few years ago. But if community willing to accept dynamic block size (with specific upper/lower limit), i prefer something like BIP 104 or 106 which configure block size limit based on past block size.

We can discuss about this as well...

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.

[garlonicon]

You probably misunderstood what I said, the goal is to keep the avg fee to 1%

There is a way to check if that's cheaper than today or not. You can get total fees in a block by looking at coinbase transaction. You can add all outputs to know how many coins are transferred. And then, you can calculate 1% of all moving amount in that block and compare that to the current fees. So, what can you see?

Also note that changing fees is possible without any fork or things like that, all you need is just some solo miner or pool with a different rules. You can simply run some node, invoke "getblocktemplate" and get some data in that way without mining anything, just by using your CPU, then you will know how it looks like when compared with the current system.

Also notice that if your proposal makes things cheaper for users, then miners have no incentive to use that and lower their profits. But if your proposal is more expensive than today, then miners of course could switch to that, but users will reject your nodes and use currently existing ones or just switch to LN and avoid your on-chain fees (or they simply won't create many channels with you if you want to force that inside LN). Either way, you need some arguments to convince someone who will be at a loss why the currently existing system should be changed to bring your proposal into reality.

Edit: even better, you can just look at blockchair and see that without any coding or running your own nodes, they have such data: https://blockchair.com/bitcoin/blocks?#f=id,output_total,fee,fee_usd,reward

Code:

+-------------+-------------------+-----------+-------------+
| blockNumber | transferredAmount | totalFees | yourFees    |
+-------------+-------------------+-----------+-------------+
| 694,347     |   600.72 BTC      | 0.02 BTC  |  6.0072 BTC |
| 694,346     | 5,152.17 BTC      | 0.11 BTC  | 51.5217 BTC |
| 694,345     | 7,152.26 BTC      | 0.16 BTC  | 71.5226 BTC |
| 694,344     |   950.63 BTC      | 0.05 BTC  |  9.5063 BTC |
| 694,343     |   485.70 BTC      | 0.00 BTC  |  4.8570 BTC |
+-------------+-------------------+-----------+-------------+

Well, I don't want to pay 1% for my transaction, by looking at the last N blocks you should know why.

[hosseinimr93]

I'm not proposing to force the user to pay a 1% transaction fee,

vjudeu is right.
You are trying to keep the average transaction fee at 1% of the average transacted amount. With this proposal, people will have to pay 1% of the transacted amount on average to be able to compete with other people and get confirmation.

Let's say you have succeeded to keep the transaction fee at 1% of the average transacted amount.
In the next block, there are 100 transactions. Each of them is 200 bytes and transacts 1 BTC. Note that it will be impossible to get confirmation if I pay less than 0.01 BTC as transaction fee.

And what if I have a UTXO of 1 BTC and I want to send 0.001 BTC to someone and the remainder to my change address?
I will have to pay 0.01 BTC for sending 0.001 BTC.

[DannyHamilton]

The protocol already allows solo-miners (and mining pools) to choose to ignore transactions with small value and only include high value transactions in their blocks. This is fine when there are enough high-value transactions to fill a block (which provides an incentive for all users to increase their fees or to not create their transaction).  However, when there are not enough high-value transactions to fill a block, the solo-miner (or mining pool) needs to decide... Is it better to just create a smaller block and ignore the low-value transactions? Or is it better to include those low value transactions in the block to increase revenue?

Ignoring the low-value transactions will cause the average transaction fee per byte to increase a bit on future transactions since there will be an increase in total transactions waiting to be confirmed.  However, it reduces your total revenue on that particular block and gives your competitors (other solo miners and pools) the opportunity to increase their revenue faster than you since they can pick up those fees you left out.

Including those low-value transactions increases your total revenue on that specific block, and reduces the opportunity for your competitors to increase their revenue, for the same reasons. However, it reduces the average transaction fee per byte on future transactions, since there are less transactions waiting to be confirmed.

These competing incentives are self-regulating and drive the fee to be whatever the market will support.  There isn't a lot of opportunity for any single solo-miner or mining pool to manipulate this without suffering losses from the attempt.

Now, instead of allowing a miner (or pool) to create a smaller block of their own when they want to, if wee were to FORCE the block size limit to be smaller... Then it opens up a big opportunity for manipulation.  Large scale solar miners (or worse yet, mining pools) could include a single VERY small transaction in every block that they create which pays to themselves the ENTIRE bitcoin balance that they have control over and include 0 fee.  This very tiny (in terms of bytes) huge value transaction with no fee at all will skew the "average fee" for the block so that it falls significantly below 1%.  This would force the protocol to shrink the block size for ALL miners in the future (not just the miner that creates the block).  As such, the malicious miner performing this attack doesn't lose as much revenue overall (since the other blocks won't be able to pick up as many of the remaining transactions) AND it punishes those miners (and pools) that are NOT participating in the attack, since their revenue is now limited.  Furthermore, since the total size of the block is reduced, it is even easier for the attacker to reduce the size even more.  His single high-value transaction is now a greater percentage of the total value transacted in the block.  Therefore he can repeat his attack over and over until he forces EVERY transaction to pay a fee of nearly 1% of all the bitcoin he has control over!

[topcoin360]

--snip--

Also notice that if your proposal makes things cheaper for users, then miners have no incentive to use that and lower their profits. But if your proposal is more expensive than today, then miners of course could switch to that, but users will reject your nodes and use currently existing ones or just switch to LN and avoid your on-chain fees (or they simply won't create many channels with you if you want to force that inside LN). Either way, you need some arguments to convince someone who will be at a loss why the currently existing system should be changed to bring your proposal into reality.

Absoluletly, I think 1% is affordable for most people (and cheaper than most other options like Visa). If you make large transactions then your avg fee will be less than 1% but if you make small transactions then your avg fee will be more than 1% which is not unfair considering the space you're using. Maybe collectively we'd be paying a little more or a little less, after all miners need to get paid to secure the network right?  

--snip--

Ignoring the low-value transactions will cause the average transaction fee per byte to increase a bit on future transactions since there will be an increase in total transactions waiting to be confirmed.  However, it reduces your total revenue on that particular block and gives your competitors (other solo miners and pools) the opportunity to increase their revenue faster than you since they can pick up those fees you left out.

As I responded to Wind_FURY, I don't see what would be the incentive for a miner to play with the block size limit (assuming they have enough hashrate to do that);

If they increase the limit then the transaction fees will go down.
If they decrease the limit then the transaction fees will go up but they can validate fewer transactions.

In any case, they are not guaranteed a higher income and their competitors can still validate the next block, the avg transaction fee should sooner or later reach 1% no matter what is the volume of transactions on the network.

[PrimeNumber7]

As I responded to Wind_FURY, I don't see what would be the incentive for a miner to play with the block size limit (assuming they have enough hashrate to do that);

If they increase the limit then the transaction fees will go down.
If they decrease the limit then the transaction fees will go up but they can validate fewer transactions.

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.

As Danny explained, a miner can send a large (in terms of value) transaction to himself with zero transaction fee, effectively lowering the average transaction fee for that block at a very low cost.

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. This would make the mechanism for changing the block size to be consistent with how transactions are priced today. It would also make the manipulation as described by Danny less effective, although said manipulation would still be possible, as a miner could fill 30% of his block with zero-fee transactions to himself (or with transactions whose on-chain fee is zero, one party to the transaction has paid the miner via some off-chain means).