Could preferring blocks with more txs help solve the small blocksize issue?

[CIYAM]

In another thread it was mentioned that the main reason that mining pools prefer to mine blocks <250 KB is that by doing so they incur less chance of "losing the race" to solve the next block (correct me if I am wrong - this was my interpretation).

But what if the rules were changed so that given 2 possible solutions for the "next block" (new block 123456A or 123456B) that are close enough in time one should not prefer the first one seen but the one with the largest size (or the first only if the sizes are the same or the second is smaller).

Would this help us to get bigger blocks mined and keep the fees to an absolute minimum?

[niothor]

In another thread it was mentioned that the main reason that mining pools prefer to mine blocks <250 KB is that by doing so they incur less chance of "losing the race" to solve the next block (correct me if I am wrong - this was my interpretation).

But what if the rules were changed so that given 2 possible solutions for the "next block" (new block 123456A or 123456B) that are close enough in time one should not prefer the first one seen but the one with the largest size (or the first only if the sizes are the same or the second is smaller).

Would this help us to get bigger blocks mined and keep the fees to an absolute minimum?

Wouldn't that involve a counter , and a value of min_time between blocks in each a larger block can take over?
This could get messy.

[CIYAM]

Wouldn't that involve a counter , and a value of min_time between blocks in each a larger block can take over?
This could get messy.

I don't think it would require any major change (although it obviously would be a hard fork). Each block is already timestamped so the only change for deciding to prefer an alternate chain would be that the timestamp of the "better" block was within x seconds of the first one (assuming the normal timestamp range check is valid).

This concept could also help stop the >50% "death due to empty blocks" scenario (when a miner/pool has enough hash power to simply keep creating empty blocks and therefore prevent any tx from ever happening).

[niothor]

Yeah , but there will be a lot of debate over the size , and the time between.
Overall a good idea, and could be implemented also the other way around  so we might avoid things like this:

https://blockchain.info/block-index/439289/0000000000000007df4a3fd95cc35eec4071e6a9e4dfa3dd81f0273cf3c2ffcd

[Barek]

I don't get why this gets brought up again and again.

Including a TX in a block costs the miner. If the fee outweighs the cost, it is in the miner's interest to include it. Otherwise, it is not.

A strong point about Bitcoin is that it does not need regulation, yet people seem to want to regulate the miners.

[CIYAM]

I don't get why this gets brought up again and again.

I don't believe that this particular idea has been brought up before (if so please give me a link so I can look into previous replies).

Including a TX in a block costs the miner. If the fee outweighs the cost, it is in the miner's interest to include it. Otherwise, it is not.

A strong point about Bitcoin is that it does not need regulation, yet people seem to want to regulate the miners.

No-one would be forcing the miners to do anything - if they all decide it is not worth mining >X KB blocks then they simply won't and nothing will have changed.

This is not about changing the upper limit of the block size (currently 1MB) it is about trying to get more txs into blocks when they are only being ignored because of the "race" to discover the next block.

[Sukrim]

Well, then you only incentivize miners to fill their blocks with as small as possible transactions using their own coins (with 0 fees) up to MAX_BLOCK_SIZE. This way it might be even better to reject a transaction and include 2 of your own instead. Also MAX_BLOCK_SIZE would be then EVERY_BLOCK_SIZE...

Of course that won't happen overnight, still it gives this incentive.

[CIYAM]

In the case of 0 fee txs sure they could just add their own (am not trying to help out 0 fee txs) but why would you do that if you can include txs that are paying a small fee?

Currently people even paying the minimum fee are waiting hours for confirmation due to the backlog which is due to the fact that miners are not going anywhere near the 1 MB limit.

EDIT: I see the point about "gaming" this and at this stage I don't have a good idea about how to stop that (although maybe ignoring 0 fees txs could help).

[Sukrim]

In the case of 0 fee txs sure they could just add their own (am not trying to help out 0 fee txs) but why would you do that if you can include txs that are paying a small fee?

Currently people even paying the minimum fee are waiting hours for confirmation due to the backlog which is due to the fact that miners are not going anywhere near the 1 MB limit.

EDIT: I see the point about "gaming" this and at this stage I don't have a good idea about how to stop that (although maybe ignoring 0 fees txs could help).

You can include fees too, though then you risk loosing the fees if you get forked off by other miners. Blocks that are not full would just get stuffed with "padding transactions" to win in fork situations, and more complex transactions would need an even higher fee, as they decrease transaction density.

[CIYAM]

You can include fees too, though then you risk loosing the fees if you get forked off by other miners.

But surely that risk is going to limit the ability to game the idea then?

(i.e. shouldn't an "honest" miner end up doing better?)

[Sukrim]

Depends on how you define "small" fee - if there are no magic constants (like the current minimum fee) a "small" fee can very well mean 1 Satoshi.

I guess there could eb an equilibrium of course, still it might very easily be somewhere in the area of "include padding in blocks" or if you adjust it slightly it might switch to "leave blocks deliberately (partially) empty" mode.
I don't think that miners really need incentives to mine 1 MB blocks other than fees. Maybe some better tools on selecting transactions etc. and filling their blocks might be of more use so they can execute more complex strategies.