Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: Brandsen on May 07, 2016, 08:32:19 PM



Title: Fee dependent block size limit
Post by: Brandsen on May 07, 2016, 08:32:19 PM
A fee dependent block size limit to prevent spam and ensure that security is paid for:
 
What would you think about a new consensus rule that allowed miners to mine valid bigger blocks only if the total amount of fees collected in the blocks are greater than a certain threshold?

If a miner manages to construct a 1MB block where the total amount of fees collected is greater than X, then the new consensus rule would allow that miner to extend the size of this block up to 2MB.
If the total amount of fees in the 2MB block is greater than Y, then the miner is allowed to further extend the size of this block to 3MB, and so on...

The threshold defining X and Y can be made static for simplicity, or it could be made flexible according to some relevant parameters.

Any feedback is appreciated! Thank you!


Title: Re: Fee dependent block size limit
Post by: shorena on May 07, 2016, 08:43:38 PM
A fee dependent block size limit to prevent spam and ensure that security is paid for:
 
What would you think about a new consensus rule that allowed miners to mine valid bigger blocks only if the total amount of fees collected in the blocks are greater than a certain threshold?

If a miner manages to construct a 1MB block where the total amount of fees collected is greater than X, then the new consensus rule would allow that miner to extend the size of this block up to 2MB.
If the total amount of fees in the 2MB block is greater than Y, then the miner is allowed to further extend the size of this block to 3MB, and so on...

The threshold defining X and Y can be made static for simplicity, or it could be made flexible according to some relevant parameters.

Any feedback is appreciated! Thank you!

So mining a TX that pays a high fee e.g. slightly over 249 BTC any miner could create very large blocks? There is no risk as the miner must not broadcast the TX until the block is found. Adding additional TX for size is trivial. Is there an upper limit? If there is one, why do we need the fees to reach it?


Title: Re: Fee dependent block size limit
Post by: Brandsen on May 07, 2016, 09:01:55 PM
Yes I believe there should be a upper limit, but I lack the technical competence to have a relevant opinion on what that limit should be..
This idea just poped into my head and I just wanted to get it out there..

Thank you for the feedback!


Title: Re: Fee dependent block size limit
Post by: danda on May 07, 2016, 11:26:52 PM
How would the developers determine the "right" amount of fee per byte?

With bitcoin likely to increase significantly over value in time, a fixed fee per byte would tend to have the effect that it becomes more and more expensive in terms of real world value to create a large block.

not sure if this is a showstopper or not.  just pointing it out.


Title: Re: Fee dependent block size limit
Post by: Monnt on May 08, 2016, 04:56:36 AM
Maybe instead of a blocksize limit, there's a total fee limit? So maybe 5 BTC of fees max per block?

But maybe we should simply have a variable blocksize, based on how many MBS of transactions are pending in the mempool (above 1 sat per byte)


Title: Re: Fee dependent block size limit
Post by: Brandsen on May 08, 2016, 10:38:33 AM
A fee dependent block size limit to prevent spam and ensure that security is paid for:
 
What would you think about a new consensus rule that allowed miners to mine valid bigger blocks only if the total amount of fees collected in the blocks are greater than a certain threshold?

If a miner manages to construct a 1MB block where the total amount of fees collected is greater than X, then the new consensus rule would allow that miner to extend the size of this block up to 2MB.
If the total amount of fees in the 2MB block is greater than Y, then the miner is allowed to further extend the size of this block to 3MB, and so on...

The threshold defining X and Y can be made static for simplicity, or it could be made flexible according to some relevant parameters.

Any feedback is appreciated! Thank you!

So mining a TX that pays a high fee e.g. slightly over 249 BTC any miner could create very large blocks? There is no risk as the miner must not broadcast the TX until the block is found. Adding additional TX for size is trivial. Is there an upper limit? If there is one, why do we need the fees to reach it?


What do you think about instead using the median fee paid in the block.. If the the block is full and the median fee is above a certain threshold then the miner is allowed to extend the block size. Using the median instead of the average or the total would make it harder for the miner to "cheat" by sending high fee transactions, wouldn't it?


Title: Re: Fee dependent block size limit
Post by: Brandsen on May 08, 2016, 11:27:02 AM
How would the developers determine the "right" amount of fee per byte?

With bitcoin likely to increase significantly over value in time, a fixed fee per byte would tend to have the effect that it becomes more and more expensive in terms of real world value to create a large block.

not sure if this is a showstopper or not.  just pointing it out.


That is a good point!
I haven't checked the statistic to back this up, but I'm guessing that the dollar value of the median transaction within a block is fairly stable over time.. The median transaction within all blocks over the last 100 blocks could be used to find an average, lets call this the value "A".

Lets just say that the "right" amount of fee per bite is 1/10000 of A, lets call this the value "B"

Several people have rightly  pointed out to me that miners can just 'fake fees' by paying them to themselves...

I'm therefore thinking that instead a miner should be allowed to create a bigger block if the median fee per bite paid within that block is greater than B+20%

(NB: please do not give to much attention to the numbers I have used.. They are just for the sake of examples, and are most probably the wrong numbers)