Topic: Effects of Forcing Miners to Fill Full Blocks (Read 256 times)

This idea of the op  is somewhat covered in my sticky thread.

https://bitcointalksearch.org/topic/why-all-miners-need-to-mine-on-a-pool-that-pays-them-the-tx-fees-2634505

If forced to fill 4mb with 0.00000001 minimum transaction big pools could follow the ideas in my thread above.  The would flood the blocks with the mini fee thus clogging the network for other people that need to do a transaction.

So if a 4mb block has 15000 227 sized transactions  it would cost a big pool

0.03405 btc or under 340.50 dollars.

it would fill 3.4mb of the block's 4mb  and that small spot would  cost high fees to move coins.

So  say ant pool wins 20% of the blocks  yeah they spend 340 dollars with bs filler transactions.

and the rest of us need to spend big coins to move coins.  so if they win 1 of every 5 blocks  all 5 blocks will have big ass fees.  and they only had to 340 x 144 = 48960 to flood the blocks. with 0.00000001 sat based transactions.  or 0.00000227 a transaction

this is why segwit and lightning are needed to prevent super pools from flooding blocks .


remember they will code there pool to accept every ant miner block first priority .

So the idea simply will not work. As ant miner can stop it.

Segwit and lightning  network came about to combat this exploit.

Here is a more informative chart with mempool data that includes the fee rate transactions are paying that are waiting to get confirmed. 

Sometimes there are a lot of transactions waiting but they are paying a very low fee rate. Pools may choose to ignore transactions that pay too low because there is a cost to including additional transactions, such as the risk the block will get orphaned. Most of the block reward comes from the block subsidy rather than transaction fees, so  pools will not want to include many very low paying fees.

Being connected to more peers will not speed up the time it takes to receive a block. All else being equal, being connected to one more peer will slow down the time it takes to receive a block because your internet connection has a fixed capacity. Being connected to more peers will also take up more resources on your computer.

The miners are actually pretty incentivised to fill blocks. Most of the empty blocks that you see are generated in when the miner starts removing transaction that were already included in the block from their mempool. This creates a time delay with the verification of the block itself and other overheads. To better utilise the time gap, miners usually just mine an empty block so they do not have to care about the transactions that has to be included in the block.

The propagation of the block isn't that big of a problem anymore. The time delay for a smaller block compared to the bigger block is much lower right now.

that has not been happening that often and there are times that mempool is completely empty when a new block is found. for example when block X is found and it includes all the transactions in mempool in it then block X+1 is found right away (with 1-2 seconds), that block has no other choice but to be empty.
if any additional rule were to be enforced the miner who found block X+1 is screwed!

by the way block size limit stopped being 1 MB more than 2 years ago and it has been at 4 MB weight.

What is exactly the point of forcing miners to fill blocks in the first place? If you add a new rule that says that blocks are only valid if they are full up to some threshold, but a miner for some strange reason doesn't want to mine that much transactions, then they would just create transactions between their own wallets. As you can see, it solves absolutely nothing, just puts a mildly annoying obstacle for miners.

I like the concept discussed in the OP but I also feel like some of the responses are (perhaps on purpose) focusing on semantics.

I think that OP's intent was never to imply that blocks should always reach the 1MB limit even if that would require filling them with trash...

I think that OP is simply asking something along the lines of what would be the effects of forcing miners to include pending transactions in their blocks?

What is the most reasonable explanation to me is that blocks should be filled with as many PENDING transactions as possible. Keep in mind that network propagation through nodes is already serving the purpose of checking transaction validity. If a transaction remains in mempools, it should be valid.

And correct me if I'm wrong, but I think that currently there's a bit of a disconnect between user intents, and miner interests.
Miners need fast propagation of their blocks to avoid orphans. They're after profit and efficiency.
Miners would also have it int their interest to focus on high-fee transactions. The so called fee-market already has it that higher fee transactions are confirmed faster. For example: https://bitcoinfees.earn.com/

However, users transacting BTC have it in their interest to have lower fees and faster transaction times.

What OP proposes, could be a potential answer to coercing miners in serving user interests more thoroughly.

---

The answer to this hypothetical of course could be better answered by developers/pool admins etc.

My hypothesis would be that on times of low demand, such measure would allow for zero fee transactions to go through.
The potential effects on demand are a mystery.

Median block size for now shows there's still space in blocks to cover for current transaction volumes. BUT, let's say that the change proposed in OP was to be implemented, then all miners would have to include all those transactions in their blocks even without fee. BTC isn't too close, but also not THAT far from reaching capacity of its blocks. With zero fee transactions, surely demand to transact in BTC would increase.
And then, who's to have a say on which transactions are prioritized? It might have to be hard-coded as some sort of rule set. But then, the power to decide the rules about transaction verification would lie in the hands of developers. Taking away the freedom of miners to confirm transactions based on own standards ends up being a political issues with conflicting interests at play.

And keep in mind that I'm not even discussing how such a hardcoded measure might be enforced to miners. For example, what do you do if a miner doesn't follow the central rules for which transactions to prioritize for verification? Should they be thrown out of the network? From a technical perspective, one could argue that miners have larger bargaining power in this debate. They could choose to support such measure or everyone would risk a chain split.

TL;DR:
The question in the OP is thoughtful, but (at least to me), the debate on why such measure should be implemented or not ends up being political. Maybe it's just better to leave the fee-market in place in order to avoid having to deal with such issues.

Exactly, correct incentives is much more efficient than forcing anything.

Miners already have an incentive to put the most transactions as possible in a block, to receive more fees.
Why would a miner reject to receive more transaction fees and mine an empty block?

But still they would have to create transactions for that because they can't insert garbage bits in transactions. Even if they do so by using OP_RETURN opcode, those are not spendable transactions. So they are anyway doing something fruitful to system (Creating more transactions).

Mempool data at https://www.blockchain.com/en/charts/mempool-size?timespan=24h says, sometimes waiting transactions size even reaches upto 14MBs during day time. Provided every node has their own mempool, I think this data only depicts the transactions that are in mempool of connected peers. And on the other hand there is so much concern about increasing blocksize in community, that shows there are enough transactions waiting in the mempool every time a new block is created. And this "forced" thing might lead miners to be connected to more peers for receiving mempool transactions, in turn increase in block syncing speed as well. What do you say?

I think it isd a bad idea. If implemented, miners would just create big wasteful messages to fill the block.

Pretty much this. The network can't know in a reliable and tamper-proof way whether there's "enough" transactions floating around.

Additionally enforcing a mininum block size would just artificially slow down the network when there's not much going on (ie. due to miners waiting for enough transactions to fill their mempool before building a block) while doing nothing to increase transaction throughput when blocks are full.

Also note that as block subsidy gets reduced over time, transaction fees gain in importance. Currently the block subsidy still surpasses the profit made by fees, but once fees are the main income there's literally no profit to be made from creating empty blocks.

Exactly, it's self-regulating.
If I had a couple of ASIC's, and i could chose between mining with a pool that filled the blocks (whenever they could) or a pool that mined only empty blocks, i'd chose the first one... Even from a purely economical standpoint: a pool with full blocks collects more fees, so theoretically it should make more profits (if the pool divides the fees amongst their miners offcourse)

"forced" doesn't seem like a good word.  What if there isn't 1MB worth of transactions to put in a block?  The community more/less tries to hold pools responsible that don't make an effort to fill blocks when they are able as it is.  Any outstanding backlog in the mempool would certainly put more pressure on pools to fill blocks.

I was wondering if Miners are forced to fill full blocks or almost full block (according current block limit of 1MB) in bitcoin network (assuming that they all are honest enough to do so), what will be its effect on bitcoin network and transaction throughput? Which aspects I am missing on, that this change would be affecting? Even if miners are honest enough to do so, will it affect their profit? (In case of segwit, we can assume we are running older nodes.) Any comments will be helpful..