Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MinRelayFee algorithm revist #9328

Closed
rebroad opened this issue Dec 12, 2016 · 3 comments
Closed

MinRelayFee algorithm revist #9328

rebroad opened this issue Dec 12, 2016 · 3 comments

Comments

@rebroad
Copy link
Contributor

rebroad commented Dec 12, 2016

Currently, when looking at the historical MinRelayFee over time, it's usual pattern is to suddenly jump high when the Memory Usage reaches 100% to then slowly decrease until the same happens again. This causes wildly fluctuating MinRelayFees.

Intuitively I feel that the maths could be improved such that the MinRelayFee goes up prior to reaching 100% utilization such that an equilibrium can be reached where the memory utilization rarely reaches 100% and the MinRelayFee stays fairly constant (save for influences by market dynamics). For this to be possible the algorithm needs to change to at least allow it to increase in situations other than reaching 100% utilization.

@paveljanik
Copy link
Contributor

Please change the subject to "Predict the future".

@rebroad
Copy link
Contributor Author

rebroad commented Dec 12, 2016

@paveljanik I appreciate the levity :) I think the future does not need to be predictable for what I am suggesting but perhaps I am not being clear in what I am proposing. I am proposing that the algorithm tries to avoid sudden jumps, so for this to happen it needs to be something akin to the physics of two magnets opposing each other - i.e. when it gets nearer to being full the MinFeeFilter goes up at a rate such that it is unlikely to become full.

There may need to be some mathematical differentiation to achieve this where the speed at which 100% is being reached if used to decelerate it enough to stop it being reached. Inertial dampening I think might be the term for it. What we currently have is oscillation. Oscillation equals inefficiency. Same as traffic on the highway stopping and starting, the oscillations which can last for hours from their initial impetus, causing everyone to get to their destination slower than if the traffic was going along smoothly at the permitted speed.

I'm not saying the current algorithm is poor/bad/broken, but I am wondering if it can be more static than it currently is and therefore allow the memory used to be more static and therefore fluctuations in the TX throughput in the network to be reduced.

If I am missing something here, please let me know.

@maflcko
Copy link
Member

maflcko commented Oct 7, 2017

Can you explain the technical advantages of such approach?

@maflcko maflcko closed this as completed Apr 27, 2020
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants