Skip to content

Commit

Permalink
Fix whitespace diff
Browse files Browse the repository at this point in the history
  • Loading branch information
@Frassle
Frassle committed Jun 10, 2021
1 parent 4314406 commit 89e86b7
Showing 1 changed file with 18 additions and 18 deletions.
36 changes: 18 additions & 18 deletions RELEASENOTES.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@

This document contains the release notes for `rippled`, the reference server implementation of the XRP Ledger protocol. To learn more about how to build, run or update a `rippled` server, visit https://xrpl.org/install-rippled.html


Have new ideas? Need help with setting up your node? Come visit us [here](https://github.com/ripple/rippled/issues/new/choose)

# Change log
Expand All @@ -22,7 +22,7 @@ Version 1.7.2 supersedes version 1.7.1 and adds fixes for more issues that were

This release introduces a new amendment to the XRP Ledger protocol: `fixRmSmallIncreasedQOffers`. This amendments 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.
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

Expand All @@ -34,13 +34,13 @@ If you operate an XRP Ledger validator, please learn more about this amendment s
- **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 binary was requested [(7311629)](https://github.com/ripple/rippled/pull/3843/commits/73116297aa94c4acbfc74c2593d1aa2323b4cc52).
- **Updates to Windows builds:** When building on Windows, use vcpkg 2021 by default and add compatibility with MSVC 2019 [(36fe196)](https://github.com/ripple/rippled/pull/3843/commits/36fe1966c3cd37f668693b5d9910fab59c3f8b1f), [(30fd458)](https://github.com/ripple/rippled/pull/3843/commits/30fd45890b1d3d5f372a2091d1397b1e8e29d2ca).

## Version 1.7.0
## Version 1.7.0

Ripple has released version 1.7.0 of `rippled`, the reference server implementation of the XRP Ledger protocol.
This release [significantly improves memory usage](https://blog.ripplex.io/how-ripples-c-team-cut-rippleds-memory-footprint-down-to-size/), introduces a protocol amendment to allow out-of-order transaction execution with Tickets, and brings several other features and improvements.
Ripple has released version 1.7.0 of `rippled`, the reference server implementation of the XRP Ledger protocol.
This release [significantly improves memory usage](https://blog.ripplex.io/how-ripples-c-team-cut-rippleds-memory-footprint-down-to-size/), 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 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

Expand All @@ -54,7 +54,7 @@ Loading mirror speeds from cached hostfile
* epel: mirrors.syringanetworks.net
* extras: ftp.osuosl.org
* updates: mirrors.vcea.wsu.edu
ripple-nightly/signature | 650 B 00:00:00
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 <techops+rippled@ripple.com>"
Expand All @@ -81,7 +81,7 @@ sudo apt -y install rippled
- **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.
- **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](https://xrpl.org/xrp-ledger-toml.html) 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.
- **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](https://xrpl.org/feature.html). 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](https://xrpl.org/feature.html) 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:
Expand All @@ -101,7 +101,7 @@ Going forward, use the [feature method](https://xrpl.org/feature.html) to view a
- **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 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.
Expand All @@ -114,7 +114,7 @@ Going forward, use the [feature method](https://xrpl.org/feature.html) to view a

## Version 1.6.0

This release introduces several new features including changes to the XRP Ledger's consensus mechanism to make it even more robust in
This 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
Expand Down Expand Up @@ -154,11 +154,11 @@ The `rippled` 1.5.0 release introduces several improvements and new features, in

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.
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`](https://github.com/ripple/rippled/commit/ec137044a014530263cd3309d81643a5a3c1fdab)
- Native [gRPC API](https://grpc.io/) support. Currently, this API provides a subset of the full `rippled` [API](https://xrpl.org/rippled-api.html). You can enable the gRPC API on your server with a new configuration stanza. [`7d867b806`](https://github.com/ripple/rippled/commit/7d867b806d70fc41fb45e3e61b719397033b272c)
Expand All @@ -183,11 +183,11 @@ At this time, the developers recommend running with sharding disabled, pending t
## Version 1.4.0

The `rippled` 1.4.0 release introduces several improvements and new features, including support for deleting accounts, improved peer slot management, improved CI integration and package building and support for [C++17](https://en.wikipedia.org/wiki/C%2B%2B17) and [Boost 1.71](https://www.boost.org/users/history/version_1_71_0.html). Finally, this release removes the code for the `SHAMapV2` amendment which failed to gain majority support and has been obsoleted by other improvements.

**New and Updated Features**
- The `DeletableAccounts` amendment which, if enabled, will make it possible for users to delete unused or unneeded accounts, recovering the account's reserve.
- Support for improved management of peer slots and the ability to add and removed reserved connections without requiring a restart of the server.
- Tracking and reporting of cumulative and instantaneous peer bandwidth usage.
- 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](https://xrpl.org/subscribe.html).
- Reporting consensus phase changes in the `server` stream [subscription](https://xrpl.org/subscribe.html).
Expand Down Expand Up @@ -311,12 +311,12 @@ consensus.
- 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)
- Improve ledger_entry command’s inconsistent behavior (63e167b)

**Bug Fixes**

- Accept redirects from validator list sites (7fe1d4b)
- Implement missing string conversions for JSON (c0e9418)
- 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)

Expand Down Expand Up @@ -363,7 +363,7 @@ Ripple recommends that all server operators upgrade to XRP Ledger version 1.1.0

**New and Updated Features**

- Add `DepositPreAuth` ledger type and transaction (#2513)
- 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)
Expand Down

0 comments on commit 89e86b7

Please sign in to comment.