-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
XRPFees
: Fee setting and handling improvements
#4247
Conversation
fc53680
to
72f0af4
Compare
Does this also fix the fact that the server (in some places?) serializes |
I'm not sure. Can you point me to some places where you see it? |
(@mDuo13 whenever you have a chance - there's an open question above) |
|
Note that I ran this test using my |
0aa77cc
to
fa94a73
Compare
XRPFees
: Fee setting and handling improvements
@thejohnfreeman any last thoughts on this PR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we remove the section "Fee level" in src/ripple/app/misc/FeeEscalation.md
and amend the rest of the documentation?
@thejohnfreeman I don't think so. Fee levels are not the same as fee units. I removed fee units here. Fee levels are still there and necessary for the transaction queue to work fairly. I'm hoping that after this is merged, there will be less confusion about the whole thing. As for the rest of the documentation, I don't think "fee units" are really documented anywhere because the were a transparent implementation detail, but if there are, then yeah, that would need to be updated. |
* Clarify comments explaining the ttFEE transaction field validation.
src/ripple/app/tx/impl/Change.cpp
Outdated
// The ttFEE transaction format defines these fields as | ||
// optional, but once the XRPFees feature is enabled, they are | ||
// forbidden. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are the required ones, right? Not forbidden? The code returns malformed if they are missing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, woops. Got those backwards.
src/ripple/app/tx/impl/Change.cpp
Outdated
// The ttFEE transaction format defines these fields as | ||
// optional, but once the XRPFees feature is enabled, they are | ||
// required. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly, these are the forbidden ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, woops. Got those backwards.
* upstream/develop: `XRPFees`: Fee setting and handling improvements (XRPLF#4247)
* upstream/develop: `XRPFees`: Fee setting and handling improvements (XRPLF#4247)
* upstream/develop: `XRPFees`: Fee setting and handling improvements (XRPLF#4247)
* upstream/develop: `XRPFees`: Fee setting and handling improvements (XRPLF#4247)
…tpage * upstream/develop: (37 commits) Update documented pathfinding configuration defaults: (XRPLF#4409) Update dependency: grpc (XRPLF#4407) Introduce min/max observers for Number Optimize uint128_t division by 10 within Number.cpp Replace Number division algorithm Include rounding mode in XRPAmount to STAmount conversion. Remove undefined behavior * Taking the negative of a signed negative is UB, but taking the negative of an unsigned is not. Silence warnings Introduce rounding modes for Number: Use Number for IOUAmount and STAmount arithmetic Add tests Add implicit conversion from STAmount to Number Add clip Add conversions between Number, XRPAmount and int64_t AMM Add Number class and associated algorithms Revise CONTRIBUTING (XRPLF#4382) `XRPFees`: Fee setting and handling improvements (XRPLF#4247) Update BUILD.md (XRPLF#4383) Make NodeToShardRPC a manual test (XRPLF#4379) Update build instructions (XRPLF#4376) ...
* Introduces amendment `XRPFees` * Convert fee voting and protocol messages to use XRPAmounts * Includes Validations, Change transactions, the "Fees" ledger object, and subscription messages * Improve handling of 0 drop reference fee with TxQ. For use with networks that do not want to require fees * Note that fee escalation logic is still in place, which may cause the open ledger fee to rise if the network is busy. 0 drop transactions will still queue, and fee escalation can be effectively disabled by modifying the configuration on all nodes * Change default network reserves to match Mainnet * Name the new SFields *Drops (not *XRP) * Reserve SField IDs for Hooks * Clarify comments explaining the ttFEE transaction field validation
High Level Overview of Change
This branch resolves #3932. The concept of "fee units" has been (almost) completely removed. It remains in a few places to preserve backward compatibility. Additionally, a new amendment,
XRPFees
has been introduced which, if enabled by the validators, will convert all representations of fees in the code, ledger, and protocol that are still raw numbers intoXRPAmount
s.Additionally, it fixes an issue where a sidechain / test network is able to confirm a 0 drop base fee, but is unable to accept submissions of transactions with 0 drop fees. The transaction engine appears to be perfectly fine with such fees, but fee escalation logic had an unstated assumption that the base fee would never be 0. This fix works around that assumption while still enabling fee escalation to raise required fees when the network gets busy - it effectively treats the base fee as 1 drop for purposes of getting into the open ledger ONLY when fees are escalated. No amendment is required for this fix because it only affects transaction submission, not processing. I am reasonably sure this solution is complete, but I would encourage anybody dealing with the issue to test this branch to ensure I haven't missed any edge cases.
Type of Change