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

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.

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.

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.

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.

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.

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!

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.

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.


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.

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.

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.


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.

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.

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?

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?

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.

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?