Version 1.8.4

This is the 1.8.4 release of rippled, the reference implementation of the XRP Ledger protocol.

This release corrects a technical flaw introduced with 1.8.3 that may result in failures if the newly-introduced 'fast loading' is enabled. The release also adjusts default parameters used to configure the pathfinding engine to reduce resource usage.

Bug Fixes

• Adjust mutex scope in walkMapParallel: This commit corrects a technical flaw introduced with commit 7c12f0135897361398917ad2c8cda888249d42ae that would result in undefined behavior if the server operator configured their server to use the 'fast loading' mechanism introduced with 1.8.3.

• Adjust pathfinding configuration defaults: This commit adjusts the default configuration of the pathfinding engine, to account for the size of the XRP Ledger mainnet. Unless explicitly overriden, the changes mean that pathfinding operations will return fewer, shallower paths than previous releases.

Version 1.8.3

This is the 1.8.3 release of rippled, the reference implementation of the XRP Ledger protocol.

This release implements changes that improve the syncing performance of peers on the network, adds countermeasures to several routines involving LZ4 to defend against CVE-2021-3520, corrects a minor technical flaw that would result in the server not using a cache for nodestore operations, and adjusts tunable values to optimize disk I/O.

Summary of Issues

Recently, servers in the XRP Ledger network have been taking an increasingly long time to sync back to the network after restartiningg. This is one of several releases which will be made to improve on this issue.

Bug Fixes

• Parallel ledger loader & I/O performance improvements: This commit makes several changes that, together, should decrease the time needed for a server to sync to the network. To make full use of this change, rippled needs to be using storage with high IOPS and operators need to explicitly enable this behavior by adding the following to their config file, under the [node_db] stanza:

  [node_db]
  ...
  fast_load=1

Note that when 'fast loading' is enabled the server will not open RPC and WebSocket interfaces until after the initial load is completed. Because of this, it may appear unresponsive or down.

• Detect CVE-2021-3520 when decompressing using LZ4: This commit adds code to detect LZ4 payloads that may result in out-of-bounds memory accesses.

• Provide sensible default values for nodestore cache:: The nodestore includes a built-in cache to reduce the disk I/O load but, by default, this cache was not initialized unless it was explicitly configured by the server operator. This commit introduces sensible defaults based on the server's configured node size.

• Adjust the number of concurrent ledger data jobs: Processing a large amount of data at once can effectively bottleneck a server's I/O subsystem. This commits helps optimize I/O performance by controlling how many jobs can concurrently process ledger data.

• Two small SHAMapSync improvements: This commit makes minor changes to optimize the way memory is used and control the amount of background I/O performed when attempting to fetch missing SHAMap nodes.

Version 1.8.2

Ripple has released version 1.8.2 of rippled, the reference server implementation of the XRP Ledger protocol. This release addresses the full transaction queues and elevated transaction fees issue observed on the XRP ledger, and also provides some optimizations and small fixes to improve the server's performance overall.

Summary of Issues

Recently, servers in the XRP Ledger network have had full transaction queues and transactions paying low fees have mostly not been able to be confirmed through the queue. After investigation, it was discovered that a large influx of transactions to the network caused it to raise the transaction costs to be proposed in the next ledger block, and defer transactions paying lower costs to later ledgers. The first part worked as designed, but deferred transactions were not being confirmed as the ledger had capacity to process them.

The root cause was that there were very many low-cost transactions that different servers in the network received in a different order due to incidental differences in timing or network topology, which caused validators to propose different sets of low-cost transactions from the queue. Since none of these transactions had support from a majority of validators, they were removed from the proposed transaction set. Normally, any transactions removed from a proposed transaction set are supposed to be retried in the next ledger, but servers attempted to put these deferred transactions into their transaction queues first, which had filled up. As a result, the deferred transactions were discarded, and the network was only able to confirm transactions that paid high costs.

Bug Fixes

• Address elevated transaction fees: This change addresses the full queue problems in two ways. First, it puts deferred transactions directly into the open ledger, rather than transaction queue. This reverts a subset of the changes from ximinez@62127d7. A transaction that is in the open ledger but doesn't get validated should stay in the open ledger so that it can be proposed again right away. Second, it changes the order in which transactions are pulled from the transaction queue to increase the overlap in servers' initial transaction consensus proposals. Like the old rules, transactions paying higher fee levels are selected first. Unlike the old rules, transactions paying the same fee level are ordered by transaction ID / hash ascending. (Previously, transactions paying the same fee level were unsorted, resulting in each server having a different order.)

• Add ignore_default option to account_lines API: This flag, if present, suppresses the output of incoming trust lines in the default state. This is primarily motivated by observing that users often have many unwanted incoming trust lines in a default state, which are not useful in the vast majority of cases. Being able to suppress those when doing account_lines saves bandwidth and resources. (#3980)

• Make I/O and prefetch worker threads configurable: This commit adds the ability to specify io_workers and prefetch_workers in the config file which can be used to specify the number of threads for processing raw inbound and outbound IO and configure the number of threads for performing node store prefetching. (#3994)

• Enforce account RPC limits by objects traversed: This changes the way the account_objects API method counts and limits the number of objects it returns. Instead of limiting results by the number of objects found, it counts by the number of objects traversed. Additionally, the default and maximum limits for non-admin connections have been decreased. This reduces the amount of work that one API call can do so that public API servers can share load more effectively. (#4032)

• Fix a crash on shutdown: The NuDB backend class could throw an error in its destructor, resulting in a crash while the server was shutting down gracefully. This crash was harmless but resulted in false alarms and noise when tracking down other possible crashes. (#4017)

• Improve reporting of job queue in admin server_info: The server_info command, when run with admin permissions, provides information about jobs in the server's job queue. This commit provides more descriptive names and more granular categories for many jobs that were previously all identified as "clientCommand". (#4031)

• Improve full & compressed inner node deserialization: Remove a redundant copy operation from low-level SHAMap deserialization. (#4004)

• Reporting mode: only forward to P2P nodes that are synced: Previously, reporting mode servers forwarded to any of their configured P2P nodes at random. This commit improves the selection so that it only chooses from P2P nodes that are fully synced with the network. (#4028)

• Improve handling of HTTP X-Forwarded-For and Forwarded headers: Fixes the way the server handles IPv6 addresses in these HTTP headers. (#4009, #4030)

• Other minor improvements to logging and Reporting Mode.

Version 1.8.0

Ripple has released version 1.8.0 of rippled, the reference server implementation of the XRP Ledger protocol. This release brings several features and improvements.

New and Improved Features

• Improve History Sharding: Shards of ledger history are now assembled in a deterministic way so that any server can make a binary-identical shard for a given range of ledgers. This makes it possible to retrieve a shard from multiple sources in parallel, then verify its integrity by comparing checksums with peers' checksums for the same shard. Additionally, there's a new admin RPC command to import ledger history from the shard store, and the crawl_shards command has been expanded with more info. (#2688, #3726, #3875)
• New CheckCashMakesTrustLine Amendment: If enabled, this amendment will change the CheckCash transaction type so that cashing a check for an issued token automatically creates a trust line to hold the token, similar to how purchasing a token in the decentralized exchange creates a trust line to hold the token. This change provides a way for issuers to send tokens to a user before that user has set up a trust line, but without forcing anyone to hold tokens they don't want. (#3823)
• Automatically determine the node size: The server now selects an appropriate [node_size] configuration value by default if it is not explicitly specified. This parameter tunes various settings to the specs of the hardware that the server is running on, especially the amount of RAM and the number of CPU threads available in the system. Previously the server always chose the smallest value by default.
• Improve transaction relaying logic: Previously, the server relayed every transaction to all its peers (except the one that it received the transaction from). To reduce redundant messages, the server now relays transactions to a subset of peers using a randomized algorithm. Peers can determine whether there are transactions they have not seen and can request them from a peer that has them. It is expected that this feature will further reduce the bandwidth needed to operate a server.
• Improve the Byzantine validator detector: This expands the detection capabilities of the Byzantine validation detector. Previously, the server only monitored validators on its own UNL. Now, the server monitors for Byzantine behavior in all validations it sees.
• Experimental tx stream with history for sidechains: Adds an experimental subscription stream for sidechain federators to track messages on the main chain in canonical order. This stream is expected to change or be replaced in future versions as work on sidechains matures.
• Support Debian 11 Bullseye: This is the first release that is compatible with Debian Linux version 11.x, "Bullseye." The .deb packages now use absolute paths only, for compatibility with Bullseye's stricter package requirements. (#3909)
• Improve Cache Performance: The server uses a new storage structure for several in-memory caches for greatly improved overall performance. The process of purging old data from these caches, called "sweeping", was time-consuming and blocked other important activities necessary for maintaining ledger state and participating in consensus. The new structure divides the caches into smaller partitions that can be swept in parallel.
• Amendment default votes: Introduces variable default votes per amendment. Previously the server always voted "yes" on any new amendment unless an admin explicitly configured a voting preference for that amendment. Now the server's default vote can be "yes" or "no" in the source code. This should allow a safer, more gradual roll-out of new amendments, as new releases can be configured to understand a new amendment but not vote for it by default. (#3877)
• More fields in the validations stream: The validations subscription stream in the API now reports additional fields that were added to validation messages by the HardenedValidations amendment. These fields make it easier to detect misconfigurations such as multiple servers sharing a validation key pair. (#3865)
• Reporting mode supports validations and manifests streams: In the API it is now possible to connect to these streams when connected to a servers running in reporting. Previously, attempting to subscribe to these streams on a reporting server failed with the error reportingUnsupported. (#3905)

Bug Fixes

• Clarify the safety of NetClock::time_point arithmetic: * NetClock::rep is uint32_t and can be error-prone when used with subtraction. * Fixes #3656
• Fix out-of-bounds reserve, and some minor optimizations
• Fix nested locks in ValidatorSite
• Fix clang warnings about copies vs references
• Fix reporting mode build issue
• Fix potential deadlock in Validator sites
• Use libsecp256k1 instead of OpenSSL for key derivation: The deterministic key derivation code was still using calls to OpenSSL. This replaces the OpenSSL-based routines with new libsecp256k1-based implementations
• Improve NodeStore to ShardStore imports: This runs the import process in a background thread while preventing online_delete from removing ledgers pending import
• Simplify SHAMapItem construction: The existing class offered several constructors which were mostly unnecessary. This eliminates all existing constructors and introduces a single new one, taking a Slice. The internal buffer is switched from std::vector to Buffer to save a minimum of 8 bytes (plus the buffer slack that is inherent in std::vector) per SHAMapItem instance.
• Redesign stoppable objects: Stoppable is no longer an abstract base class, but a pattern, modeled after the well-understood std::thread. The immediate benefits are less code, less synchronization, less runtime work, and (subjectively) more readable code. The end goal is to adhere to RAII in our object design, and this is one necessary step on that path.

Version 1.7.3

This is the 1.7.3 release of rippled, the reference implementation of the XRP Ledger protocol. This release addresses an OOB memory read identified by Guido Vranken, as well as an unrelated issue identified by the Ripple C++ team that could result in incorrect use of SLEs. Additionally, this version also introduces the NegativeUNL amendment, which corresponds to the feature which was introduced with the 1.6.0 release.

Action Required

If you operate an XRP Ledger server, then you should upgrade to version 1.7.3 at your earliest convenience to mitigate the issues addressed in this hotfix. If a sufficient majority of servers on the network upgrade, the NegativeUNL amendment may gain a majority, at which point a two week activation countdown will begin. If the NegativeUNL amendment activates, servers running versions of rippled prior to 1.7.3 will become amendment blocked.

Bug Fixes

Improve SLE usage in check cashing: Fixes a situation which could result in the incorrect use of SLEs.
Address OOB in base58 decoder: Corrects a technical flaw that could allow an out-of-bounds memory read in the Base58 decoder.
Add NegativeUNL as a supported amendment: Introduces an amendment for the Negative UNL feature introduced in rippled 1.6.0.

This the 1.7.2 release of rippled, the reference server implementation of the XRP Ledger protocol. This release protects against the security issue CVE-2021-3499 affecting OpenSSL, adds an amendment to fix an issue with small offers not being properly removed from order books in some cases, and includes various other minor fixes. Version 1.7.2 supersedes version 1.7.1 and adds fixes for more issues that were discovered during the release cycle.

Action Required

This release introduces a new amendment to the XRP Ledger protocol: fixRmSmallIncreasedQOffers. This amendment is now open for voting according to the XRP Ledger's amendment process, which enables protocol changes following two weeks of >80% support from trusted validators. If you operate an XRP Ledger server, then you should upgrade to version 1.7.2 within two weeks, to ensure service continuity. The exact time that protocol changes take effect depends on the voting decisions of the decentralized network. If you operate an XRP Ledger validator, please learn more about this amendment so you can make informed decisions about how your validator votes. If you take no action, your validator begins voting in favor of any new amendments as soon as it has been upgraded.

Bug Fixes

fixRmSmallIncreasedQOffers Amendment: This amendment fixes an issue where certain small offers can be left at the tip of an order book without being consumed or removed when appropriate and causes some payments and Offers to fail when they should have succeeded (#3827).
Adjust OpenSSL defaults and mitigate CVE-2021-3499: Prior to this fix, servers compiled against a vulnerable version of OpenSSL could have a crash triggered by a malicious network connection. This fix disables renegotiation support in OpenSSL so that the rippled server is not vulnerable to this bug regardless of the OpenSSL version used to compile the server. This also removes support for deprecated TLS versions 1.0 and 1.1 and ciphers that are not part of TLS 1.2 (#79e69da).
Support HTTP health check-in reporting mode: Enables the Health Check special method when running the server in the new Reporting Mode introduced in 1.7.0 (9c8cadd).
Maintain compatibility for forwarded RPC responses: Fixes a case in API responses from servers in Reporting Mode, where requests that were forwarded to a P2P-mode server would have the result field nested inside another result field (8579eb0).
Add load_factor in reporting mode: Adds a load_factor value to the server info method response when running the server in Reporting Mode so that the response is compatible with the format returned by servers in P2P mode (the default) (430802c).
Properly encode metadata from tx RPC command: Fixes a problem where transaction metadata in the tx API method response would be in JSON format even when the binary was requested (7311629).
Updates to Windows builds: When building on Windows, use vcpkg 2021 by default and add compatibility with MSVC 2019 (36fe196), (30fd458).

Ripple has released version 1.7.0 of rippled, the reference server implementation of the XRP Ledger protocol. This release significantly improves memory usage, introduces a protocol amendment to allow out-of-order transaction execution with Tickets, and brings several other features and improvements.

Upgrading (SPECIAL ACTION REQUIRED)
If you use the precompiled binaries of rippled that Ripple publishes for supported platforms, please note that Ripple has renewed the GPG key used to sign these packages. If you are upgrading from a previous install, you must download and trust the renewed key. Automatic upgrades will not work until you have re-trusted the key.

Red Hat Enterprise Linux / CentOS

(These instructions have been updated.) First, re-add the repository to get the updated key.

cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo 
[ripple-stable]
name=XRP Ledger Packages
enabled=1
gpgcheck=0
repo_gpgcheck=1
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
REPOFILE

Then perform a manual upgrade. When prompted, confirm that the key's fingerprint matches the following example, then press y to accept the updated key:

$ sudo yum install rippled
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.web-ster.com
* epel: mirrors.syringanetworks.net
* extras: ftp.osuosl.org
* updates: mirrors.vcea.wsu.edu
ripple-nightly/signature 
|  650 B  00:00:00    
Retrieving key from https://repos.ripple.com/repos/rippled-rpm/nightly/repodata/repomd.xml.key
Importing GPG key 0xCCAFD9A2:
Userid     : "TechOps Team at Ripple <[email protected]>"
Fingerprint: c001 0ec2 05b3 5a33 10dc 90de 395f 97ff ccaf d9a2
From       : https://repos.ripple.com/repos/rippled-rpm/nightly/repodata/repomd.xml.key
Is this ok [y/N]: y

Ubuntu / Debian
Download and trust the updated public key, then perform a manual upgrade as follows:

wget -q -O - "https://repos.ripple.com/repos/api/gpg/key/public" | \
    sudo apt-key add -
sudo apt -y update
sudo apt -y install rippled

New and Improved Features

• Rework deferred node logic and async fetch behavior: This change significantly improves ledger sync and fetch times while reducing memory consumption. (https://blog.ripplex.io/how-ripples-c-team-cut-rippleds-memory-footprint-down-to-size/)
• New Ticket feature: Tickets are a mechanism to prepare and send certain transactions outside of the normal sequence order. This version reworks and completes the implementation for Tickets after more than 6 years of development. This feature is now open for voting as the newly-introduced TicketBatch amendment, which replaces the previously-proposed Tickets amendment. The specification for this change can be found at: xrp-community/standards-drafts#16
• Add Reporting Mode: The server can be compiled to operate in a new mode that serves API requests for validated ledger data without connecting directly to the peer-to-peer network. (The server needs a gRPC connection to another server that is on the peer-to-peer network.) Reporting Mode servers can share access to ledger data via Apache Cassandra and PostgreSQL to more efficiently serve API requests while peer-to-peer servers specialize in broadcasting and processing transactions. (#3609)
• Optimize relaying of validation and proposal messages: Servers typically receive multiple copies of any given message from directly connected peers; in particular, consensus proposal and validation messages are often relayed with extremely high redundancy. For servers with several peers, this can cause redundant work. This commit introduces experimental code that attempts to optimize the relaying of proposals and validations by allowing servers to instruct their peers to "squelch" delivery of selected proposals and validations. This change is considered experimental at this time and is disabled by default because the functioning of the consensus network depends on messages propagating with high reliability through the constantly-changing peer-to-peer network. Server operators who wish to test the optimized code can enable it in their server config file.
• Report server domain to other servers: Server operators now have the option to configure a domain name to be associated with their servers. The value is communicated to other servers and is also reported via the server_info API. The value is meant for third-party applications and tools to group servers together. For example, a tool that visualizes the network's topology can show how many servers are operated by different stakeholders. An operator can claim any domain, so tools should use the xrp-ledger.toml file to confirm that the domain also claims ownership of the servers.
• Improve handling of peers that aren't synced: When evaluating the fitness and usefulness of an outbound peer, the code would incorrectly calculate the amount of time that the peer spent in a non-useful state. This release fixes the calculation and makes the timeout values configurable by server operators. Two new options are introduced in the 'overlay' stanza of the config file.
• Persist API-configured voting settings: Previously, the amendments that a server would vote in support of or against could be configured both via the configuration file and via the "feature" API method. Changes made in the configuration file were only loaded at server startup; changes made via the command line take effect immediately but were not persisted across restarts. Starting with this release, changes made via the API are saved to the wallet.db database file so that they persist even if the server is restarted. Amendment voting in the config file is deprecated. The first time the server starts with v1.7.0 or higher, it reads any amendment voting settings in the config file and saves the settings to the database; on later restarts the server prints a warning message and ignores the [amendments] and [veto_amendments] stanzas of the config file. Going forward, use the feature method to view and configure amendment votes. If you want to use the config file to configure amendment votes, add a line to the [rpc_startup] stanza such as the following: [rpc_startup] { "command": "feature", "feature": "FlowSortStrands", "vetoed": true }
• Support UNLs with future effective dates: Updates the format for the recommended validator list file format, allowing publishers to pre-publish the next recommended UNL while the current one is still valid. The server is still backwards compatible with the previous format, but the new format removes some uncertainty during the transition from one list to the next. Also, starting with this release, the server locks down and reports an error if it has no valid validator list. You can clear the error by loading a validator list from a file or by configuring a different UNL and restarting; the error also goes away on its own if the server is able to obtain a trusted validator list from the network (for example, after an network outage resolves itself).
• Improve manifest relaying: Servers now propagate change messages for validators' ephemeral public keys ("manifests") on a best-effort basis, to make manifests more available throughout the peer-to-peer network. Previously, the server would only relay manifests from validators it trusts locally, which made it difficult to detect and track validators that are not broadly trusted.
• Implement ledger forward replay feature: The server can now sync up to the network by "playing forward" transactions from a previously saved ledger until it catches up to the network. Compared with the default behavior of fetching the latest state and working backwards, forward replay can save time and bandwidth by reconstructing previous ledgers' state data rather than downloading the pre-calculated results from the network. As an added bonus, forward replay confirms that the rest of the network followed the same transaction processing rules as the local server when processing the intervening ledgers. This feature is considered experimental this time and can be enabled with an option in the config file.
• Make the transaction job queue limit adjustable: The server uses a job queue to manage tasks, with limits on how many jobs of a particular type can be queued. The previously hard-coded limit associated with transactions is now configurable. Server operators can increase the number of transactions their server is able to queue, which may be useful if your server has a large memory capacity or you expect an influx of transactions. (https://github.com/ripple/rippled/issues/3556)
• Add public_key to the Validator List method response: The Validator List method can be used to request a recommended validator list from a rippled instance. The response now includes the public key of the requested list. (https://github.com/ripple/rippled/issues/3392)
• Server operators can now configure maximum inbound and outbound peers separately: The new peers_in_max and peers_out_max config options allow server operators to independently control the maximum number of inbound and outbound peers the server allows. [70c4ecc]
• Improvements to shard downloading: Previously the download_shard command could only load shards over HTTPS. Compressed shards can now also be downloaded over plain HTTP. The server fully checks the data for integrity and consistency, so the encryption is not strictly necessary. When initiating multiple shard downloads, the server now returns an error if there is not enough space to store all the shards currently being downloaded.
• The manifest command is now public: The manifest API method returns public information about a given validator. The required permissions have been changed so it is now part of the public API.

Bug Fixes

• Implement sticky DNS resolution for validator list retrieval: When attempting to load a validator list from a configured site, attempt to reuse the last IP that was successfully used if that IP is still present in the DNS response. (https://github.com/ripple/rippled/issues/3494).
• Improve handling of RPC ledger_index argument: You can now provide the ledger_index as a numeric string. This allows you to copy and use the numeric string ledger_index value returned by certain RPC commands. Previously you could only send native JSON numbers or shortcut strings such as "validated" in the ledger_index field. (https://github.com/ripple/rippled/issues/3533)
• Fix improper promotion of bool on return [6968da1]
• Fix ledger sequence on copynode [ef53197]
• Fix parsing of node public keys in manifest CLI: The previous code attempts to validate the provided node public key using a function that assumes that the encoded public key is for an account. This causes the parsing to fail. This commit fixes #3317 (https://github.com/ripple/rippled/issues/3317) by letting the caller specify the type of the public key being checked.
• Fix idle peer timer: Fixes a bug where a function to remove idle peers was called every second instead of every 4 seconds. #3754 (https://github.com/ripple/rippled/issues/3754)
• Add database counters: Fix bug where DatabaseRotateImp::getBackend and ::sync utilized the writable backend without a lock. ::getBackend was replaced with ::getCounters.
• Improve online_delete configuration and DB tuning [6e9051e]
• Improve handling of burst writes in NuDB database ( https://github.com/ripple/rippled/pull/3662 )
• Fix excessive logging after disabling history shards. Previously if you configured the server with a shard store, then disabled it, the server output excessive warning messages about the shard limit being exceeded.
• Fixed some issues with negotiating link compression. ( https://github.com/ripple/rippled/pull/3705 )
• Fixed a potential thread deadlock with history sharding. ( https://github.com/ripple/rippled/pull/3683 )
• Various fixes to typos and comments, refactoring, and build system improvements

This rippled 1.6.0 release introduces several new features including changes to the XRP Ledger's consensus mechanism to make it even more robust in adverse conditions, as well as numerous bug fixes and optimizations.

New and Improved Features

• Initial implementation of Negative UNL functionality: This change can improve the liveness of the network during periods of network instability, by allowing servers to track which validators are temporarily offline and to adjust quorum calculations to match. This change requires an amendment, but the amendment is not in the 1.6.0 release. Ripple expects to run extensive public testing for Negative UNL functionality on the Devnet in the coming weeks. If public testing satisfies all requirements across security, reliability, stability, and performance, then the amendment could be included in a version 2.0 release. [#3380]
• Validation Hardening: This change allows servers to detect accidental misconfiguration of validators, as well as potentially Byzantine behavior by malicious validators. Servers can now log a message to notify operators if they detect a single validator issuing validations for multiple, incompatible ledger versions, or validations from multiple servers sharing a key. As part of this update, validators report the version of rippled they are using, as well as the hash of the last ledger they consider to be fully validated, in validation messages. [#3291] Amendment: Required
• Software Upgrade Monitoring & Notification: After the HardenedValidations amendment is enabled and the validators begin reporting the versions of rippled they are running, a server can check how many of the validators on its UNL run a newer version of the software than itself. If more than 60% of a server's validators are running a newer version, the server writes a message to notify the operator to consider upgrading their software. [#3447]
• Link Compression: Beginning with 1.6.0, server operators can enable support for compressing peer-to-peer messages. This can save bandwidth at a cost of higher CPU usage. This support is disabled by default and should prove useful for servers with a large number of peers. [#3287]
• Unconditionalize Amendments that were enabled in 2017: This change removes legacy code which the network has not used since 2017. This change limits the ability to replay ledgers that rely on the pre-2017 behavior. [#3292]
• New Health Check Method: Perform a simple HTTP request to get a summary of the health of the server: Healthy, Warning, or Critical. [#3365]
• Start work on API version 2. Version 2 of the API will be part of a future release. The first breaking change will be to consolidate several closely related error messages that can occur when the server is not synced into a single "notSynced" error message. [#3269]
• Improved shard concurrency: Improvements to the shard engine have helped reduce the lock scope on all public functions, increasing the concurrency of the code. [#3251]
• Default Port: In the config file, the [ips_fixed] and [ips] stanzas now use the IANA-assigned port for the XRP Ledger protocol (2459) when no port is specified. The connect API method also uses the same port by default. [#2861].
• Improve proposal and validation relaying. The peer-to-peer protocol always relays trusted proposals and validations (as part of the consensus process), but only relays untrusted proposals and validations in certain circumstances. This update adds configuration options so server operators can fine-tune how their server handles untrusted proposals and validations, and changes the default behavior to prioritize untrusted validations higher than untrusted proposals. [#3391]
• Various Build and CI Improvements including updates to RocksDB 6.7.3 [#3356], NuDB 2.0.3 [#3437], adjusting CMake settings so that rippled can be built as a submodule [#3449], and adding Travis CI settings for Ubuntu Bionic Beaver [#3319].
• Better documentation in the config file for online deletion and database tuning. [#3429]

Bug Fixes

• Fix the 14 day timer to enable amendment to start at the correct quorum size [#3396]
  Improve online delete backend lock which addresses a possibility in the online delete process where one or more backend shared pointer references may become invalid during rotation. [#3342]
• Address an issue that can occur during the loading of validator tokens, where a deliberately malformed token could cause the server to crash during startup. [#3326]
• Add delivered amount to GetAccountTransactionHistory. The delivered_amount field was not being populated when calling GetAccountTransactionHistory. In contrast, the delivered_amount field was being populated when calling GetTransaction. This change populates delivered_amount in the response to GetAccountTransactionHistory, and adds a unit test to make sure the results delivered by GetTransaction and GetAccountTransactionHistory match each other. [#3370]
• Fix build issues for GCC 10 [#3393]
• Fix historical ledger acquisition - this fixes an issue where historical ledgers were acquired only since the last online deletion interval instead of the configured value to allow deletion.[#3369]
• Fix build issue with Docker #3416]
• Add Shard family. The App Family utilizes a single shared Tree Node and Full Below cache for all history shards. This can create a problem when acquiring a shard that shares an account state node that was recently cached from another shard operation. The new Shard Family class solves this issue by managing separate Tree Node and Full Below caches for each shard. #3448]
• Amendment table clean up which fixes a calculation issue with majority. #3428]
• Add the ledger_cleaner command to rippled command line help [#3305]
  Various typo and comments fixes.

The rippled 1.5.0 release introduces several improvements and new features, including support for gRPC API, API versioning, UNL propagation via the peer network, new RPC methods validator_info and manifest, augmented submit method, improved tx method response, improved command line parsing, improved handshake protocol, improved package building and various other minor bug fixes and improvements.

This release also introduces two new amendments: fixQualityUpperBound and RequireFullyCanonicalSig.

Several improvements to the sharding system are currently being evaluated for inclusion into the upcoming 1.6 release of rippled. These changes are incompatible with shards generated by previous versions of the code.
Additionally, an issue with the existing sharding engine can result in a server running versions 1.4 or 1.5 of the software to experience a deadlock and automatically restart when running with the sharding feature enabled.
At this time, the developers recommend running with sharding disabled, pending the improvements scheduled to be introduced with 1.6. For more information on how to disable sharding, please visit https://xrpl.org/configure-history-sharding.html

New and Updated Features

• The RequireFullyCanonicalSig amendment which changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid. 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. ec137044a
• Native gRPC API support. Currently, this API provides a subset of the full rippled API. You can enable the gRPC API on your server with a new configuration stanza. 7d867b806
• API Versioning which allows for future breaking change of RPC methods to co-exist with existing versions. 2aa11fa41
• Nodes now receive and broadcast UNLs over the peer network under various conditions. 2c71802e3
• Augmented submit method to include additional details on the status of the command. 79e9085dd
• Improved tx method response with additional details on ledgers searched. 47501b7f9
• New validator_info method which returns information pertaining to the current validator's keys, manifest sequence, and domain. 3578acaf0
• New manifest method which looks up manifest information for the specified key (either master or ephemeral). 3578acaf0
• Introduce handshake protocol for compression negotiation (compression is not implemented at this point) and other minor improvements. f6916bfd4
• Remove various old conditionals introduced by amendments. (51ed7db00, 6e4945c56)
• Add getRippledInfo info gathering script to rippled Linux packages. acf4b7889

Bug Fixes and Improvements

• The fixQualityUpperBound amendment which fixes a bug in unused code for estimating the ratio of input to output of individual steps in cross-currency payments. 9d3626fec
• tx method now properly fetches all historical tx if they are incorporated into a validated ledger under rules that applied at the time. 11cf27e00
• Fix to how fail_hard flag is handled with the submit method - transactions that are submitted with the fail_hard flag that result in any TER code besides tesSUCCESS is neither queued nor held. cd9732b47
• Remove unused Beast code. 172ead822
• Lag ratchet code fix to use proper ephemeral public keys instead of the long-term master public keys.6529d3e6f

Ripple has released version 1.4.0 of rippled, the reference implementation of the core XRP Ledger protocol. To learn more about how to build and run a rippled server, see Manage the rippled Server.

New and Updated Features

• The DeletableAccounts amendment which, if enabled, allow users to delete their XRP Ledger accounts and recover some of their base reserve.

• Support for improved management of peer slots and the ability to add and remove reserved connections without requiring a restart of the server.

• Tracking and reporting of cumulative and instantaneous peer bandwidth usage.

• Preliminary support for post-processing historical shards after downloading to index their contents.

• Reporting the master public key alongside the ephemeral public key in the validation stream subscriptions.

• Reporting consensus phase changes in the server stream subscription.

Bug Fixes

• The fixPayChanRecipientOwnerDir Amendment which corrects a minor technical flaw that would cause a payment channel to not appear in the recipient's owner directory, which made it unnecessarily difficult for users to enumerate all their payment channels.

• The fixCheckThreading Amendment which corrects a minor technical flaw that caused checks to not be properly threaded against the account of the check's recipient.

• Respect the ssl_verify configuration option in the SSLHTTPDownloader and HTTPClient classes.

• Properly update the server_state when a server detects a disagreement between itself and the network.

• Allow Ed25519 keys to be used with the channel_authorize command.

Ripple has released version 1.3.1 of rippled, the reference implementation of the core XRP Ledger protocol. To learn more about how to build and run a rippled server, see Manage the Rippled Server.

This release supersedes version 1.3.0. Version 1.3.1 addresses deadlock conditions reported by some users late in the release cycle for 1.3.0.

Installing or Updating rippled

The installation instructions on supported platforms have changed for rippled 1.3.x.

• For all new installs, see Install rippled.
• On Red Hat Enterprise Linux 7 or CentOS 7, if you have automatic updates enabled, the updates should work successfully. For more information or for manual update instructions, see the Migration Instructions for RHEL 7 / CentOS.
• On Ubuntu Linux (16.04, 18.04, or newer), native (APT) packages are now available. If you already have rippled installed using the previous method (installing RPMs with Alien), see Migration Instructions for Ubuntu Linux for steps to migrate to the new, native packages. Additionally, it is now possible to enable automatic updates on Ubuntu.
• Debian 9 Stretch is now a supported operating system. See Installation on Ubuntu or Debian Linux for instructions.
• For other platforms, please compile from source.
  • Step-by-step instructions for compiling rippled are also available for macOS and Ubuntu.

Summary of Changes

The rippled 1.3.1 release introduces several new features and overall improvements to the codebase, including the fixMasterKeyAsRegularKey amendment, code to adjust the timing of the consensus process and support for decentralized validator domain verification. The release also includes miscellaneous improvements including in the transaction censorship detection code, transaction validation code, manifest parsing code, config file parsing code, log file rotation code, and in the build, continuous integration, testing and package building pipelines.

New and Updated Features

• The fixMasterKeyAsRegularKey amendment which, if enabled, will correct a technical flaw that allowed setting an account's regular key to the account's master key.
• Code that allows validators to adjust the timing of the consensus process in near-real-time to account for connection delays.
• Support for decentralized validator domain verification by adding support for a "domain" field in manifests.

Bug Fixes

• Improve ledger trie ancestry tracking to reduce unnecessary error messages.
• More efficient detection of dry paths in the payment engine. Although not a transaction-breaking change, this should reduces spurious error messages in the log files.
• Improved handling of deadlock conditions.

Version 1.2.4

The rippled 1.2.4 release improves the way that shard crawl requests are routed and the robustness of configured validator list retrieval by imposing a 20 second timeout.

New and Updated Features

This release has no new features.

Bug Fixes

• Use public keys when routing shard crawl requests (2e26377)
• Enforce a 20s timeout when making validator list requests (RIPD-1737) (dd99bf4)

Version 1.2.3

The rippled 1.2.3 release corrects a technical flaw which in some circumstances can cause a null pointer dereference that can crash the server.

New and Updated Features

This release has no new features.

Bug Fixes

• Fix a technical flaw which in some circumstances can cause a null pointer dereference that can crash the server. (b347afcc5b4c5228a425508d96e99b85cac7a1d7)

Version 1.2.2

The rippled 1.2.2 release corrects a technical flaw in the fee escalation engine which could cause some fee metrics to be calculated incorrectly. In some circumstances this can potentially cause the server to crash.

New and Updated Features

This release has no new features.

Bug Fixes

• Fix a technical flaw in the fee escalation engine which could cause some fee metrics to be calculated incorrectly (4c06b3f86)

Version 1.2.1

The rippled 1.2.1 release introduces several fixes including a change in the
information reported via the enhanced crawl functionality introduced in the
1.2.0 release, a fix for a potential race condition when processing a status
change message for a peer, and for a technical flaw that could cause a server
to not properly detect that it had lost all its peers.

The release also adds the delivered_amount field to more responses to simplify
the handling of payment or check cashing transactions.

New and Updated Features

This release has no new features.

Bug Fixes

• Fix a race condition during TMStatusChange handling (c8249981)
• Properly transition state to disconnected (9d027394)
• Display validator status only in response to admin requests (2d6a518a)
• Add the delivered_amount to more RPC commands (f2756914)

The rippled 1.2.0 release introduces the MultisignReserve Amendment, which
reduces the reserve requirement associated with signer lists. This release also
includes incremental improvements to the code that handles offers. Furthermore,
rippled now also has the ability to automatically detect transaction
censorship attempts and issue warnings of increasing severity for transactions
that should have been included in a closed ledger after several rounds of
consensus.

New and Updated Features

• Reduce the account reserve for a Multisign SignerList (6572fc8)
• Improve transaction error condition handling (4104778)
• Allow servers to automatically detect transaction censorship attempts (945493d)
• Load validator list from file (c1a0244)
• Add RPC command shard crawl (17e0d09)
• Add RPC Call unit tests (eeb9d92)
• Grow the open ledger expected transactions quickly (7295cf9)
• Avoid dispatching multiple fetch pack threads (4dcb3c9)
• Remove unused function in AutoSocket.h (8dd8433)
• Update TxQ developer docs (e14f913)
• Add user defined literals for megabytes and kilobytes (cd1c5a3)
• Make the FeeEscalation Amendment permanent (58f786c)
• Remove undocumented experimental options from RPC sign (a96cb8f)
• Improve RPC error message for fee command (af1697c)
• Improve ledger_entry command’s inconsistent behavior (63e167b)

Bug Fixes

• Accept redirects from validator list sites (7fe1d4b)
• Implement missing string conversions for JSON (c0e9418)
• Eliminate potential undefined behavior (c71eb45)
• Add safe_cast to sure no overflow in casts between enums and integral types (a7e4541)

The rippled 1.1.2 release introduces a fix for an issue that could have
prevented cluster peers from successfully bypassing connection limits when
connecting to other servers on the same cluster. Additionally, it improves
logic used to determine what the preferred ledger is during suboptimal
network conditions.

New and Updated Features

This release has no new features.

Bug Fixes

• Properly bypass connection limits for cluster peers (#2795, #2796)
• Improve preferred ledger calculation (#2784)

Version 1.1.1

New and Updated Features

• Enhance status reporting when using the server_info and validators commands (#2734)
• Accept redirects from validator list sites: (#2715)

Bug Fixes

• Properly handle expired validator lists when validating (#2734)

The rippled 1.1.0 release release includes the DepositPreAuth amendment, which combined with the previously released DepositAuth amendment, allows users to pre-authorize incoming transactions to accounts, by whitelisting sender addresses. The 1.1.0 release also includes incremental improvements to several previously released features (fix1515 amendment), deprecates support for the sign and sign_for commands from the rippled API and improves invariant checking for enhanced security.

Ripple recommends that all server operators upgrade to XRP Ledger version 1.1.0 by Thursday, 2018-09-27, to ensure service continuity.

New and Updated Features

• Add DepositPreAuth ledger type and transaction (#2513)
• Increase fault tolerance and raise validation quorum to 80%, which fixes issue 2604 (#2613)
• Support ipv6 for peer and RPC comms (#2321)
• Refactor ledger replay logic (#2477)
• Improve Invariant Checking (#2532)
• Expand SQLite potential storage capacity (#2650)
• Replace UptimeTimer with UptimeClock (#2532)
• Don’t read Amount field if it is not present (#2566)
• Remove Transactor:: mFeeDue member variable (#2586)
• Remove conditional check for using Boost.Process (#2586)
• Improve charge handling in NoRippleCheckLimits test (#2629)
• Migrate more code into the chrono type system (#2629)
• Supply ConsensusTimer with milliseconds for finer precision (#2629)
• Refactor / modernize Cmake (#2629)
• Add delimiter when appending to cmake_cxx_flags (#2650)
• Remove using namespace declarations at namespace scope in headers (#2650)

Bug Fixes

• Deprecate the ‘sign’ and ‘sign_for’ APIs (#2657)
• Use liquidity from strands that consume too many offers, which will be enabled on fix1515 Amendment (#2546)
• Fix a corner case when decoding base64 (#2605)
• Trim space in Endpoint::from_string (#2593)
• Correctly suppress sent messages (#2564)
• Detect when a unit test child process crashes (#2415)
• Handle WebSocket construction exceptions (#2629)
• Improve JSON exception handling (#2605)
• Add missing virtual destructors (#2532)

The rippled 1.0.0 release includes incremental improvements to several previously released features.

New and Updated Features

• The history sharding functionality has been improved. Instances can now use the shard store to satisfy ledger requests.
• Change permessage-deflate and compress defaults (RIPD-506)
• Update validations on UNL change (RIPD-1566)

Bug Fixes

• Add check, escrow, and pay_chan to ledger_entry (RIPD-1600)
• Clarify Escrow semantics (RIPD-1571)

The rippled 0.90.1 release includes fixes for issues reported by external security researchers. These issues, when exploited, could cause a rippled instance to restart or, in some circumstances, stop executing. While these issues can result in a denial of service attack, none affect the integrity of the XRP Ledger and no user funds, including XRP, are at risk.

New and Updated Features

This release has no new features.

Bug Fixes

• Address issues identified by external review:
  • Verify serialized public keys more strictly before using them
    (RIPD-1617, RIPD-1619, RIPD-1621)
  • Eliminate a potential out-of-bounds memory access in the base58
    encoding/decoding logic (RIPD-1618)
  • Avoid invoking undefined behavior in memcpy (RIPD-1616)
  • Limit STVar recursion during deserialization (RIPD-1603)
• Use lock when creating a peer shard rangeset