rippled
rippled copied to clipboard
XRPLF
Implement fee scaling based on the size of the memos
A revision of #3007 to scale the fees for transactions with many memos which is csauing a spamming problem. It may be better to just change the coe to change by the size of the transaction instead which works for other expensive things too likea lot of paths.
I would like to see some sort of Flag, or something that gets added to the response above and beyond simply bumping the fee. How does a legitimate dev know they may have tripped up on this?
There needs to be at least something say hey, you'r causing the fee's to rise.
I would like to see some sort of Flag, or something that gets added to the response above and beyond simply bumping the fee. How does a legitimate dev know they may have tripped up on this?
There needs to be at least something say hey, you'r causing the fee's to rise.
I'm not quite sure I follow? The fee change here isn't dynamic based on load: that is, it increases the amount of the fee purely based on the size of the memo, so a developer would simply check if the corresponding amendment is activated and, if so, calculate the fee using the algorithm implemented in this pull requests.
I'm not quite sure I follow? The fee change here isn't dynamic based on load: that is, it increases the amount of the fee purely based on the size of the memo, so a developer would simply check if the corresponding amendment is activated and, if so, calculate the fee using the algorithm implemented in this pull requests.
Apologies, I took for granted that there was a point at which it kicked in (exceeds limit). Fee is just dynamic end of story 👍🏻
I'm not certain this requires an amendment? It would make coordination/communication easier, but in the end transactions with higher fees are still valid to every node that doesn't run this code and if enough validators run this code, transactions with lower fees than required by the code would just get rejected.
I'm not certain this requires an amendment? It would make coordination/communication easier, but in the end transactions with higher fees are still valid to every node that doesn't run this code and if enough validators run this code, transactions with lower fees than required by the code would just get rejected.
As implemented, it does: it changes the code that calculates the minimum fee.
A non-amendment based implementation is possible, where servers could require higher local fees, but would accept transactions with lower fees if the network reached consensus about including such a transaction.
Personally, I'm fine with the amendment-based approach, because it makes it easier for everyone to calculate the minimum required fee, although it's hardly an "easy" thing to do, especially when faced with queue congestion/levels.
@a-noni-mousse can you resolve the merge conflicts?
Otherwise, this PR may be closed due to inactivity. You can always open a new PR in the future, of course.
@a-noni-mousse if merge conflicts are not resolved, this PR will be closed. But don't lose heart - you can always re-open it or open a new PR with the changes in the future :)
Closing due to inactivity. Feel free to open a new PR with this change (rebased on the head of develop).