Dynamic max blocksize dependent on fees

[stdset]

I don't know was it already discussed or not, I didn't find it.
If we want to make max blocksize dynamic, why wouldn't we make it dependent on fees payed per block.
It seems natural to require average fee per byte to grow with block growth, if we make this dependence linear, it would look like:

f/S = a + b(S - S0)

Where
f - total transactions fee payed per considered block,
S - size of the block,
S0 - unconditionally allowed size, i.e. miners are allowed to form blocks of any size lesser than S0 filled with transactions paying no fees at all,
a, b - some constants.
In the formula it's assumed that S >= S0, the opposite case is trivial.

We could also write this equation another way:

(f - f0)/(S - S0) = k*S*f0/S0

Here f0 - minimum total fee that transactions must pay to form a block of size exactly S0, k - is a constant.
Explicit formula for total fee, expressed from the second equation:

f = f0(1 + k*S*(S/S0 - 1))

f is obviously quadratic on S, what means we are still protected from spam transactions.

Your thoughts?

[stdset]

The network sees these high fees and makes the blocks bigger and bigger.

Size of a block doesn't depend on sizes of other blocks.

Edit: But I agree, that with this design miners can make blocks arbitrarily large by including very high fee transactions without posting those transactions to the network. I.e. a miner includes say a 100 BTC fee transaction and stuffs the block with lots of very low fee transactions. I think this issue can be mitigated though. For instance we can set a limit on ratio of highest and lowest per byte fee transactions included in a block.

[DannyHamilton]

The network sees these high fees and makes the blocks bigger and bigger.

Size of a block doesn't depend on sizes of other blocks.

I'll take a closer look at the formulas you posted.  I may have misunderstood what you were suggesting.  In the meantime, I've removed my (possibly misleading) response.

[CounterEntropy]

I don't know was it already discussed or not, I didn't find it.

Dynamic max blocksize dependent on fees has been suggested before in BIP 106. But, your formula to adjust block size seems to be different.

[stdset]

Dynamic max blocksize dependent on fees has been suggested before in BIP 106.

Thanks for the link, it's a lot of interesting read. I see that similar ideas were discussed more than a year ago.

[stdset]

Edit: But I agree, that with this design miners can make blocks arbitrarily large by including very high fee transactions without posting those transactions to the network. I.e. a miner includes say a 100 BTC fee transaction and stuffs the block with lots of very low fee transactions. I think this issue can be mitigated though. For instance we can set a limit on ratio of highest and lowest per byte fee transactions included in a block.

A more elegant solution is to put say a half of fees that exceed f0 to a fee pool, much like Meni Rosenfeld proposed. If the pool isn't empty, each new block can claim some part of those funds.

[CounterEntropy]

Dynamic max blocksize dependent on fees has been suggested before in BIP 106.

Thanks for the link, it's a lot of interesting read. I see that similar ideas were discussed more than a year ago.

Relevant thread in case u r interested - https://bitcointalk.org/index.php?topic=1154536.0

[stdset]

Relevant thread in case u r interested - https://bitcointalk.org/index.php?topic=1154536.0

I already started reading it.
BIP 106 provides a way of slow max blocksize change, reflecting slow processes of adoption change, while my concern is how to cope with sudden significant increase in tx influx.
I believe both approaches could work in conjunction. In terms of the OP, BIP 106 could slowly change S0, while there could be another algorithm, similar to what is proposed in the OP, which could quickly, without any delay, increase max blocksize when necessary. Maybe even the term "max blocksize" becomes misleading with this approach. Blocks become elastic, like Meni Rosenfeld explains. There is an "unstrained" blocksize which can be regulated according to BIP 106, but we can "stretch" blocks, temporarily "inflate" them, when necessary.

[DooMAD]

While I've always been a fan of BIP106, I'm starting to appreciate the merits of "proposal 2" a bit more now.  Making it dependent on fees would definitely add an additional layer of security.

Relevant thread in case u r interested - https://bitcointalk.org/index.php?topic=1154536.0

I already started reading it.
BIP 106 provides a way of slow max blocksize change, reflecting slow processes of adoption change, while my concern is how to cope with sudden significant increase in tx influx.
I believe both approaches could work in conjunction. In terms of the OP, BIP 106 could slowly change S0, while there could be another algorithm, similar to what is proposed in the OP, which could quickly, without any delay, increase max blocksize when necessary. Maybe even the term "max blocksize" becomes misleading with this approach. Blocks become elastic, like Meni Rosenfeld explains. There is an "unstrained" blocksize which can be regulated according to BIP 106, but we can "stretch" blocks, temporarily "inflate" them, when necessary.

The "sudden significant increase in tx influx" part is a tricky one, since there's no real way to discern between an attack on the network and an increase in legitimate usage.  It's better if blocksize adjustments aren't too large in one go, as if someone did find a way to game the system, smaller adjustments would make the attack more costly to sustain and would give developers more time to detect and correct the problem before the attacker did too much damage.

[stdset]

While I've always been a fan of BIP106, I'm starting to appreciate the merits of "proposal 2" a bit more now.  Making it dependent on fees would definitely add an additional layer of security.

Relevant thread in case u r interested - https://bitcointalk.org/index.php?topic=1154536.0

I already started reading it.
BIP 106 provides a way of slow max blocksize change, reflecting slow processes of adoption change, while my concern is how to cope with sudden significant increase in tx influx.
I believe both approaches could work in conjunction. In terms of the OP, BIP 106 could slowly change S0, while there could be another algorithm, similar to what is proposed in the OP, which could quickly, without any delay, increase max blocksize when necessary. Maybe even the term "max blocksize" becomes misleading with this approach. Blocks become elastic, like Meni Rosenfeld explains. There is an "unstrained" blocksize which can be regulated according to BIP 106, but we can "stretch" blocks, temporarily "inflate" them, when necessary.

The "sudden significant increase in tx influx" part is a tricky one, since there's no real way to discern between an attack on the network and an increase in legitimate usage.  It's better if blocksize adjustments aren't too large in one go, as if someone did find a way to game the system, smaller adjustments would make the attack more costly to sustain and would give developers more time to detect and correct the problem before the attacker did too much damage.

It's conceived that blockspace exceeding S0 can only be 'bought', it's never free. Space purchases in any two different blocks are completely independent. I.e. if users bought additional space equivalent to S0 in block N, that doesn't affect block N+1. N+1 still has S0 free space, any additional space must be payed for. The more space users buy, in any given block, the more expensive it becomes. That doesn't affect other blocks.

It's also important to realize, that under optimistic scenario, if Bitcoin adoption continues to grow, and hopefully Bitcoin economy becomes comparable in size to present USD or EUR economies, fees must remain low (i.e. total fees in a block must be much smaller than block subsidy) for years and maybe even decades from now, because of mining energy consumption.