Just found a simple equation to balance supply and demand that could be easily introduced in btc source code:
next block size limit = previous block size limit + (total fee in the last period / avg fee in the previous period - space used in the last period) / block occupancy rate for the last period
Your equation does nothing to address the
issue I brought up previously. Miners can and do receive transaction fees in ways that are not attached to the transaction. For example, viaBTC offers a paid transaction accelerator
service for people who have attached too low of fees to their transaction. They charge a fortune for this service, so it is not widely used, but if pools have incentives to show transactions having lower fees than is actually the case, you can guarantee more pools would offer this service, and the cost would be very low.
As you said it is not a common practice, therefore it shoudn't have a significant impact on the result of the equation.
It is not a common practice now, but this is primarily because miners have no reason to engage in this practice currently, other than to help the less technically inclined get their low-fee transactions confirmed. If engaging in this practice would lead to potentially higher total fees, I can guarantee miners will make this practice much more common, or potentially will not even consider transactions that don't have their fees paid this way.
What I describe is an
edge case, and for something like bitcoin, it will need to be considered. You should really always consider edge cases, and corner cases (a situation in which multiple edge cases are combined into one) in production code, however with something with bitcoin, where there is literally billions of dollars potentially available if problems can be exploited, it is especially important to address, even perceived unlikely, or unusual scenarios.