RequireFullyCanonicalSig, fixQualityUpperBound, and FlowCross are Now Available
As previously announced, the RequireFullyCanonicalSig amendment became enabled on the XRP Ledger on 2020-07-03. Additionally, the fixQualityUpperBound amendment became enabled on 2020-07-09 and the FlowCross amendment became enabled on 2020-08-04.
With these amendments enabled, version 1.5.0 is the minimum server version to remain synced to the XRP Ledger.
If you operate a
rippledserver, you should upgrade to version 1.5.0 (or higher) immediately.
For instructions on upgrading
rippledon supported platforms, see Install
Note: As of 2020-08-04, version 1.6.0 is in the release candidate process, so the full 1.6.0 release is expected in the near future.
If you use a custom or very old (pre-2014) tool for signing XRP Ledger transactions using secp256k1, check that your tool produces fully canonical signatures. All valid Ed25519 signatures are fully canonical. If your tool produces secp256k1 signatures that are not fully canonical (see Alternate secp256k1 signatures for details), you must update your tool to continue sending XRP Ledger transactions.
If you trade in the XRP Ledger's decentralized exchange, the FlowCross amendment requires no further action at this time. There may be some differences in rounding when executing OfferCreate transactions compared to before the amendment, but the overall functionality of the decentralized exchange is unchanged and the actual currency value of any differences is expected to be very, very small.
Impact of Not Upgrading
If you operate a
rippled server on a version older than 1.5.0, then your server is now amendment blocked, meaning that your server:
- Cannot determine the validity of a ledger
- Cannot submit or process transactions
- Does not participate in the consensus process
- Does not vote on future amendments
- Could rely on potentially invalid data
Changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid in any case. This protects against transaction malleability on all transactions, instead of just transactions with the tfFullyCanonicalSig flag enabled.
Without this amendment, a transaction is malleable if it uses a secp256k1 signature and does not have tfFullyCanonicalSig enabled. Most signing utilities enable tfFullyCanonicalSig by default, but there are exceptions.
With this amendment, no single-signed transactions are malleable. (Multi-signed transactions may still be malleable if signers provide more signatures than are necessary.) All transactions must use the fully canonical form of the signature, regardless of the tfFullyCanonicalSig flag. Signing utilities that do not create fully canonical signatures are not supported. All of Ripple's signing utilities have been providing fully-canonical signatures exclusively since at least 2014.
For more information, see
rippled issue #3042.
Fixes a bug in unused code for estimating the ratio of input to output of individual steps in cross-currency payments.
Although this has no impact on current transaction processing, it corrects a flaw in the flow cross engine. The fixQualityUpperBound was considered a prerequisite for the FlowCross amendment to be activated safely.
Originally introduced in
rippled v0.70.0, back in 2017, the Flow amendment streamlines the offer crossing logic in the XRP Ledger's decentralized exchange. With FlowCross, OfferCreate transactions use the logic for Payment transactions, originally introduced by the Flow amendment. This has subtle differences in how offers are processed:
- Rounding is slightly different in some cases.
- Due to differences in rounding, some combinations of offers may be ranked higher or lower than by the old logic, and taken preferentially.
- The new logic may delete more or fewer offers than the old logic. (This includes cases caused by differences in rounding and offers that were incorrectly removed as unfunded by the old logic.)
Learn, ask questions, and discuss
To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the ripple-server Google Group.
Related documentation is available in the XRP Ledger Dev Portal, including detailed example API calls and web tools for API testing.