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

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.

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

Hmm, okay I understand your argument on this.
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'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 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...

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

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'm still not convinced, what is your vision?


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

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.

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?

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


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.


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


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

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


Don't forget to follow the procedure on BIP 1 and see BIP 10x (since it's mainly about block size).

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

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.

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


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.

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.

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.

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

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.

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

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?  


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.

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!

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.

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
Well, I don't want to pay 1% for my transaction, by looking at the last N blocks you should know why.

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


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.


I meant the transacted amount of all the transactions combined.


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.


We can discuss about this as well...


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.