rippled

The rippled 0.90.0 release introduces several features and enhancements that improve the reliability, scalability and security of the XRP Ledger.

Highlights of this release include:

• The DepositAuth amendment, which lets an account strictly reject any incoming money from transactions sent by other accounts.
• The Checks amendment, which allows users to create deferred payments that can be cancelled or cashed by their intended recipients.
• History Sharding, which allows rippled servers to distribute historical ledger data if they agree to dedicate storage for segments of ledger history.
• New Preferred Ledger by Branch semantics which improve the logic that allow a server to decide which ledger it should base future ledgers on when there are multiple candidates.

New and Updated Features

• Add support for Deposit Authorization account root flag (#2239)
• Implement history shards (#2258)
• Preferred ledger by branch (#2300)
• Redesign Consensus Simulation Framework (#2209)
• Tune for higher transaction processing (#2294)
• Optimize queries for account_tx to work around SQLite query planner (#2312)
• Allow Journal to be copied/moved (#2292)
• Cleanly report invalid [server] settings (#2305)
• Improve log scrubbing (#2358)
• Update rippled-example.cfg (#2307)
• Force json commands to be objects (#2319)
• Fix cmake clang build for sanitizers (#2325)
• Allow account_objects RPC to filter by “check” (#2356)
• Limit nesting of json commands (#2326)
• Unit test that sign_for returns a correct hash (#2333)
• Update Visual Studio build instructions (#2355)
• Force boost static linking for MacOS builds (#2334)
• Update MacOS build instructions (#2342)
• Add dev docs generation to Jenkins (#2343)
• Poll if process is still alive in Test.py (#2290)
• Remove unused beast::currentTimeMillis() (#2345)

Bug Fixes

• Improve error message on mistyped command (#2283)
• Add missing includes (#2368)
• Link boost statically only when requested (#2291)
• Unit test logging fixes (#2293)
• Fix Jenkins pipeline for branches (#2289)
• Avoid AppVeyor stack overflow (#2344)
• Reduce noise in log (#2352)

The rippled 0.80.1 release provides several enhancements in support of published validator lists and corrects several bugs.

New and Updated Features

• Allow including validator manifests in published list (#2278)
• Add validator list RPC commands (#2242)
• Support SNI when querying published list sites and use Windows system root certificates (#2275)
• Grow TxQ expected size quickly, shrink slowly (#2235)

Bug Fixes

• Make consensus quorum unreachable if validator list expires (#2240)
• Properly use ledger hash to break ties when determing working ledger for consensus (#2257)
• Explictly use std::deque for missing node handler in SHAMap code (#2252)
• Verify validator token manifest matches private key (#2268)

Version 0.80.2

The rippled 0.80.2 release introduces changes that improve the scalability of the XRP Ledger.

New and Updated Features

This release has no new features.

Bug Fixes

• Do not dispatch a transaction received from a peer for processing if it has already been dispatched within the past ten seconds.
• Increase the number of transaction handlers that can be in flight in the job queue and decrease the relative cost for peers to share transaction and ledger data.
• Make better use of resources by adjusting the number of threads we initialize, by reverting commit #68b8ffd.

The rippled 0.80.1 release provides several enhancements in support of published validator lists and corrects several bugs.

New and Updated Features

• Allow including validator manifests in published list (#2278)
• Add validator list RPC commands (#2242)
• Support SNI when querying published list sites and use Windows system root certificates (#2275)
• Grow TxQ expected size quickly, shrink slowly (#2235)

Bug Fixes

• Make consensus quorum unreachable if validator list expires (#2240)
• Properly use ledger hash to break ties when determing working ledger for consensus (#2257)
• Explictly use std::deque for missing node handler in SHAMap code (#2252)
• Verify validator token manifest matches private key (#2268)

The rippled 0.70.2 release corrects an emergent behavior which causes large numbers of transactions to get stuck in different nodes' open ledgers without being passed on to validators, resulting in a spike in the open ledger fee on those nodes.

New and Updated Features

This release has no new features.

Bug Fixes

• Recent fee rises and TxQ issues (#2215)

The rippled 0.70.1 release corrects a technical flaw in the newly refactored consensus code that could cause a node to get stuck in consensus due to stale votes from a
peer, and allows compiling rippled under the 1.1.x releases of OpenSSL.

New and Updated Features

This release has no new features.

Bug Fixes

• Allow compiling against OpenSSL 1.1.0 (#2151)
• Log invariant check messages at "fatal" level (2154)
• Fix the consensus code to update all disputed transactions after a node changes a position (2156)

The rippled 0.70.0 release introduces several enhancements that improve the reliability, scalability and security of the network.

Highlights of this release include:

• The FlowCross amendment, which streamlines offer crossing and autobridging logic by leveraging the new “Flow” payment engine.
• The EnforceInvariants amendment, which can safeguard the integrity of the XRP Ledger by introducing code that executes after every transaction and ensures that the execution did not violate key protocol rules.
• fix1373, which addresses an issue that would cause payments with certain path specifications to not be properly parsed.

New and Updated Features

• Implement and test invariant checks for transactions (#2054)
• TxQ: Functionality to dump all queued transactions (#2020)
• Consensus refactor for simulation/cleanup (#2040)
• Payment flow code should support offer crossing (#1884)
• make Config init extensible via lambda (#1993)
• Improve Consensus Documentation (#2064)
• Refactor Dependencies & Unit Test Consensus (#1941)
• feature RPC test (#1988)
• Add unit Tests for handlers/TxHistory.cpp (#2062)
• Add unit tests for handlers/AccountCurrenciesHandler.cpp (#2085)
• Add unit test for handlers/Peers.cpp (#2060)
• Improve logging for Transaction affects no accounts warning (#2043)
• Increase logging in PeerImpl fail (#2043)
• Allow filtering of ledger objects by type in RPC (#2066)

Bug Fixes

• Fix displayed warning when generating brain wallets (#2121)
• Cmake build does not append '+DEBUG' to the version info for non-unity builds
• Crossing tiny offers can misbehave on RCL
• asfRequireAuth flag not always obeyed (#2092)
• Strand creating is incorrectly accepting invalid paths
• JobQueue occasionally crashes on shutdown (#2025)
• Improve pseudo-transaction handling (#2104)

The rippled 0.60.3 release helps to increase the stability of the network under heavy load.

New and Updated Features

This release has no new features.

Bug Fixes

Server overlay improvements (#2110)

The rippled 0.60.2 release further strengthens handling of cases associated with a previously patched exploit, in which NoRipple flags were being bypassed by using offers.

New and Updated Features

This release has no new features.

Bug Fixes

Prevent the ability to bypass the NoRipple flag using offers (#7cd4d78)

The rippled 0.80.0 release introduces several enhancements that improve the reliability, scalability and security of the XRP Ledger.

Highlights of this release include:

• The SortedDirectories amendment, which allows the entries stored within a page to be sorted, and corrects a technical flaw that could, in some edge cases, prevent an empty intermediate page from being deleted.
• Changes to the UNL and quorum rules
  • Use a fixed size UNL if the total listed validators are below threshold
  • Ensure a quorum of 0 cannot be configured
  • Set a quorum to provide Byzantine fault tolerance until a threshold of total validators is exceeded, at which time the quorum is 80%

New and Updated Features

• Improve directory insertion and deletion (#2165)
• Move consensus thread safety logic from the generic implementation in Consensus into the RCL adapted version RCLConsensus (#2106)
• Refactor Validations class into a generic version that can be adapted (#2084)
• Make minimum quorum Byzantine fault tolerant (#2093)
• Make amendment blocked state thread-safe and simplify a constructor (#2207)
• Use ledger hash to break ties (#2169)
• Refactor RangeSet (#2113)

Bug Fixes

• Fix an issue where setAmendmentBlocked is only called when processing the EnableAmendment transaction for the amendment (#2137)
• Track escrow in recipient's owner directory (#2212)

The rippled team has released rippled version 0.60.1, which corrects a technical flaw that resulted from using 32-bit space identifiers instead of the protocol-defined 16-bit values for Escrow and Payment Channel ledger entries. rippled version 0.60.1 also fixes a problem where the WebSocket timeout timer would not be canceled when certain errors occurred during subscription streams. Ripple requires upgrading to rippled version 0.60.1 immediately.

Bug Fixes

Fix a flaw that resulted from using 32-bit space identifiers instead of the protocol-defined 16-bit values (#2071)

Fix a problem where the WebSocket timeout timer would not be cancelled when certain errors occurred during subscription streams (#2067)

Escrow
rippled 0.60.0 release includes Escrow, (previously called SusPay), which introduces a new ledger node type and several new transaction types to the Ripple network. Escrow permits users to cryptographically escrow XRP on RCL with an expiration date using a crypto-condition called preimage-sha-256, commonly referred to as a hashlock. An XRP Escrow transaction on RCL can be used together with Interledger, to allow a payment to be routed without having to trust third-party intermediaries. We believe this will open a range of possibilities and use cases for XRP, particularly when sending high value, low volume payments cross-border.

Payment Channels
The amendment for Payment Channels was originally introduced in version 0.33.0, but is now ready for Payment Channels to be enabled on the production Ripple Consensus Ledger. XRP Payment Channels are intended for high volume, low value payments. They provide a method for scalable, intermittent, off-ledger settlement flowing in a single direction. For bidirectional payment channels, an XRP Payment Channel can be used in each direction. The recipient can claim any unpaid balance at any time before the channel closes. The owner can top off the channel as needed and must wait out a delay to close the channel to give the recipient a chance to supply any claims. The total amount paid increases monotonically as newer claims are issued.

Dynamic UNL Lite
At the core of RCL is the consensus process. Through the consensus process, validating nodes agree on a specific subset of the candidate transactions to be considered for the next ledger. Consensus is an iterative process in which nodes relay proposals, or sets of candidate transactions. Nodes communicate and update proposals until a supermajority of peers agree on the same set of candidate transactions.

During consensus, each node evaluates proposals from a specific set of peers, called chosen validators. Chosen validators represent a subset of the network which, when taken collectively, is “trusted” not to collude in an attempt to defraud the node evaluating the proposals. This definition of “trust” does not require that each individual chosen validator is trusted. Rather, validators are chosen based on the expectation they will not collude in a coordinated effort to falsify data relayed to the network.

The rippled 0.60.0 release introduces new Dynamic UNL configuration options, which allow rippled to update its set of trusted validators without reconfiguring and restarting. Instead of specifying a static list of trusted validators in the config or validators file, you can configure a trusted publisher key and a URI where the publisher serves signed lists of validators. rippled will regularly query the configured URIs for the latest recommended list of validators from the trusted publishers. Configuring the validation quorum is no longer required, as rippled will automatically update its quorum based on its current trusted validator set.

Dynamic UNL Lite is a progressive step towards fully automated dynamic UNLs, to which each client of the Ripple network determines its UNL through policies, rather than trusting a pre-provided list of validators.

fix1368 Amendment
rippled 0.60.0 also introduces the fix1368 Amendment to fix a minor bug in transaction processing that causes some payments to fail when they should be valid. Specifically, during payment processing, some payment steps that are expected to produce a certain amount of currency may produce a microscopically different amount, due to a loss of precision related to floating-point number representation. When this occurs, those payments fail because they cannot deliver the exact amount intended. The fix1368 amendment corrects transaction processing so payments can no longer fail in this manner.
These features underline Ripple’s continued support to improving RCL by making it more stable, distributed and scalable for settlement of global payments.

Upcoming Features

We do not have an update on the previously announced changes to the hash tree structure that rippled uses to represent a ledger, called SHAMapV2. At the time of activation, this amendment will require brief scheduled allowable unavailability while the changes to the hash tree structure are computed by the network. We will keep the community updated as we progress towards this date (TBA).

You can update to the new version on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please compile the new version from source.

0.60.0 Change Log

• Add Escrow support (#2039)](https://github.com/ripple/rippled/pull/2039)
• Dynamize trusted validator list and quorum (#1842)
• Simplify fee handling during transaction submission (#1992)
• Publish server stream when fee changes (#2016)
• Replace manifest with validator token (#1975)
• Add validator key revocations (#2019)
• Add SecretKey comparison operator (#2004)
• Reduce LEDGER_MIN_CONSENSUS (#2013)
• Update libsecp256k1 and Beast B30 (#1983)
• Make Config extensible via lambda (#1993)
• WebSocket permessage-deflate integration (#1995)
• Do not close socket on a foreign thread (#2014)
• Update build scripts to support latest boost and ubuntu distros (#1997)
• Handle protoc targets in scons ninja build (#2022)
• Specify syntax version for ripple.proto file (#2007)
• Eliminate protocol header dependency (#1962)
• Use gnu gold or clang lld linkers if available (#2031)
• Add tests for lookupLedger (#1989)
• Add unit test for get_counts RPC method (#2011)
• Add test for transaction_entry request (#2017)
• Unit tests of RPC sign (#2010)
• Add failure only unit test reporter (#2018)

Bug Fixes

• Enforce rippling constraints during payments (#2049)
• Fix limiting step re-execute bug (#1936)
• Make wss work the same as wss2 (#2033)
• Check for malformed public key on payment channel (#2027)
• Config test uses unique directories for each test (#1984)
• Send a websocket ping before timing out in server (#2035)

The rippled 0.50.0 release includes TickSize, which allows gateways to set a "tick size" for assets they issue to to help promote faster price discovery and deeper liquidity, as well as reduce transaction spam and ledger churn on RCL. Ripple expects TickSize to be enabled via an Amendment called TickSize on Tuesday, 2017-02-21. This feature underlines Ripple’s continued support to improving RCL and making it even better suited for settlement of global payments.

You can update to the new version on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please compile the new version from source.

New and Updated Features

Problem & Solution

Currently, offers on RCL can differ by as little as one part in a quadrillion. This means that there is essentially no value to placing an offer early, as an offer placed later at a microscopically better price gets priority over it. The TickSize Amendment solves this problem by introducing a minimum tick size that a price must move for an offer to be considered to be at a better price. The tick size is controlled by the issuers of the assets involved.

When you place a buy offer, the amount of currency you will buy is respected. When you place a sell offer, the amount of currency you will sell is respected. If a tick size is in force, the other side of the offer will be rounded (in your favor) such that the ratio is rounded to the tick size before the offer is placed on the books.

TickSize does not affect the size of an offer. A trader can still trade microscopic amounts of an asset. It just affects the prices (ratio of in to out) at which offers can be placed on the books. For asset pairs with XRP, the tick size imposed, if any, is the tick size of the issuer of the non-XRP asset. For asset pairs without XRP, the tick size imposed, if any, is the smaller of the two issuer's configured tick sizes.

The tick size is imposed by rounding the offer quality down to the nearest tick and recomputing the non-critical side of the offer. For a buy, the amount offered is rounded down. For a sell, the amount charged is rounded up.

Effects of TickSize Change

This change lets issuers quantize the exchange rates of offers to use a specified number of significant digits. Gateways must enable a TickSize on their account for this feature to benefit them. A single AccountSet transaction may set a "TickSize" parameter. Legal values are 0 and 3-15 inclusive. Zero removes the setting. 3-15 allow that many decimal digits of precision in the pricing of offers for assets issued by this account. It will still be possible to place an offer to buy or sell any amount of an asset and the offer will still keep that amount as exactly as it does now. If an offer involves two assets that each have a tick size, the smaller number of significant figures (larger ticks) controls.

Benefits of TickSize Change

The primary expected benefits of the TickSize amendment is the reduction of bots fighting over the tip of the order book, which means:

• Quicker price discovery
• Traders can't be outbid by a microscopic amount
• More offers left on the books
• A reduction in offer creation and cancellation spam

We also expect larger tick sizes to benefit market makers in the following ways:

• They increase the delta between the fair market value and the trade price, ultimately reducing spreads
• They prevent market makers from consuming each other's offers due to slight changes in perceived fair market value, which promotes liquidity
• They promote faster price discovery since traders have to adjust their prices in financially distinct increments
• They reduce transaction spam by reducing fighting over the tip of the order book and reducing the need to change offers due to slight price changes
• They reduce ledger churn and metadata sizes by reducing the number of indexes each order book must have
• They allow the order book as presented to traders to better reflect the actual book since these presentations are inevitably aggregated into ticks

Hardened TLS configuration

This release updates the default TLS configuration for rippled. The new release supports only 2048-bit DH parameters and defines a new default set of modern ciphers to use, removing support for ciphers and hash functions that are no longer considered secure.

Server administrators who wish to have different settings can configure custom global and per-port cipher suites in the configuration file using the ssl_ciphers directive.

0.50.0 Change Log

• Remove websocketpp support (#1910)
• Increase OpenSSL requirements & harden default TLS cipher suites (#1913)
• Move test support sources out of ripple directory (#1916)
• Enhance ledger header RPC commands (#1918)
• Add support for tick sizes (#1922)
• Port discrepancy-test.coffee to c++ (#1930)
• Remove redundant call to clearNeedNetworkLedger (#1931)
• Port freeze-test.coffee to C++ unit test. (#1934)
• Fix CMake docs target to work if BOOST_ROOT is not set (#1937)
• Improve setup for account_tx paging test (#1942)
• Eliminate npm tests (#1943)
• Port uniport js test to cpp (#1944)
• Enable amendments in genesis ledger (#1944)
• Trim ledger data in Discrepancy_test (#1948)
• Add "current_ledger" field to "fee" result (#1949)
• Cleanup unit test support code (#1953)
• Add ledger save / load tests (#1955)
• Remove unused websocket files (#1957)
• Update RPC handler role/usage (#1966)

Bug Fixes

• Validator's manifest not forwarded beyond directly connected peers (#1919)

Ripple has released rippled version 0.33.0-hf1, which fixes a JSON parsing issue in all rippled servers. Ripple recommends upgrading to 0.33.0-hf1 only if server operators are experiencing a jsonInvalid error response to client requests.

There are no new or updated features in the 0.33.0-hf1 release.

Bug Fixes

• Fix a JSON parsing issue that can fail to parse valid JSON requests when the data received by the server is broken up into more than one contiguous buffer. (#1863)

The rippled team has released version 0.40.1, which increases SQLite database limits in all rippled full-history servers. Ripple recommends upgrading to 0.40.1 only if server operators are running rippled servers with full-history of the ledger.

There are no new or updated features in the 0.40.1 release.

Bug Fixes

• Increase SQLite database limits to prevent full-history servers from crashing when restarting. (#1961)

The rippled 0.40.0 release includes Suspended Payments, a new transaction type on the Ripple network that functions similar to an escrow service, which permits users to lock XRP until a cryptographic condition is met or it expires. Ripple expects Suspended Payments to be enabled via an Amendment named “SusPay” on Tuesday, 2017-01-17 a later date.

You can update to the new version on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please compile the new version from source.

New and Updated Features

Previously, Ripple announced the introduction of Payment Channels during the release of rippled version 0.33.0, which permit scalable, off-ledger checkpoints of high volume, low value payments flowing in a single direction. This was the first step in a multi-phase effort to make RCL more scalable and to support Interledger Protocol (ILP). Ripple expects Payment Channels to be enabled via an Amendment called PayChan on a future date to be determined.

In the second phase towards making RCL more scalable and compatible with ILP, Ripple is introducing Suspended Payments, a new transaction type on the Ripple network that functions similar to an escrow service, which permits users to cryptographically escrow XRP on RCL with an expiration date. Ripple expects Suspended Payments to be enabled via an Amendment named “SusPay” on Tuesday, 2017-01-17 a later date.

A Suspended Payment can be created, which deducts the funds from the sending account. It can then be either fulfilled or canceled. It can only be fulfilled if the fulfillment transaction makes it into a ledger with a CloseTime lower than the expiry date of the transaction. It can be canceled with a transaction that makes it into a ledger with a CloseTime greater than the expiry date of the transaction.

In the third phase towards making RCL more scalable and compatible with ILP, Ripple plans to introduce additional library support for crypto-conditions, which are distributable event descriptions written in a standard format that describe how to recognize a fulfillment message without saying exactly what the fulfillment is. Fulfillments are cryptographically verifiable messages that prove an event occurred. If you transmit a fulfillment, then everyone who has the condition can agree that the condition has been met. Fulfillment requires the submission of a signature that matches the condition (message hash and public key). This format supports multiple algorithms, including different hash functions and cryptographic signing schemes. Crypto-conditions can be nested in multiple levels, with each level possibly having multiple signatures.

Lastly, we do not have an update on the previously announced changes to the hash tree structure that rippled uses to represent a ledger, called SHAMapV2. This will require brief scheduled allowable downtime while the changes to the hash tree structure are propagated by the network. We will keep the community updated as we progress towards this date (TBA).

• Consensus refactor (#1874)

Bug Fixes

• Correct an issue in payment flow code that did not remove an unfunded offer (#1860)
• Sign validator manifests with both ephemeral and master keys (#1865)
• Correctly parse multi-buffer JSON messages (#1862)

The rippled 0.33.0 release includes an improved version of the payment code, which we expect to be activated via Amendment on Wednesday, 2016-10-20 with the name Flow. We are also introducing XRP Payment Channels, a new structure in the ledger designed to support Interledger Protocol trust lines as balances get substantial, which we expect to be activated via Amendment on a future date (TBA) with the name PayChan. Lastly, we will be introducing changes to the hash tree structure that rippled uses to represent a ledger, which we expect to be available via Amendment on a future date (TBA) with the name SHAMapV2.

You can update to the new version on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please compile the new version from source.

New and Updated Features

A fixed version of the new payment processing engine, which we initially announced on Friday, 2016-07-29, is expected to be available via Amendment on Wednesday, 2016-10-20 with the name Flow. The new payments code adds no new features, but improves efficiency and robustness in payment handling.

The Flow code may occasionally produce slightly different results than the old payment processing engine due to the effects of floating point rounding.

We will be introducing changes to the hash tree structure that rippled uses to represent a ledger, which we expect to be activated via Amendment on a future date (TBA) with the name SHAMapV2. The new structure is more compact and efficient than the previous version. This affects how ledger hashes are calculated, but has no other user-facing consequences. The activation of the SHAMapV2 amendment will require brief scheduled allowable downtime, while the changes to the hash tree structure are propagated by the network. We will keep the community updated as we progress towards this date (TBA).

In an effort to make RCL more scalable and to support Interledger Protocol (ILP) trust lines as balances get more substantial, we’re introducing XRP Payment Channels, a new structure in the ledger, which we expect to be available via Amendment on a future date (TBA) with the name PayChan.

XRP Payment Channels permit scalable, intermittent, off-ledger settlement of ILP trust lines for high volume payments flowing in a single direction. For bidirectional channels, an XRP Payment Channel can be used in each direction. The recipient can claim any unpaid balance at any time. The owner can top off the channel as needed. The owner must wait out a delay to close the channel to give the recipient a chance to supply any claims. The total amount paid increases monotonically as newer claims are issued.

The initial concept behind payment channels was discussed as early as 2011 and the first implementation was done by Mike Hearn in bitcoinj. Recent work being done by Lightning Network has showcased examples of the many use cases for payment channels. The introduction of XRP Payment Channels allows for a more efficient integration between RCL and ILP to further support enterprise use cases for high volume payments.

Added getInfoRippled.sh support script to gather health check for rippled servers [RIPD-1284]

The account_info command can now return information about queued transactions - [RIPD-1205]

Automatically-provided sequence numbers now consider the transaction queue - [RIPD-1206]

The server_info and server_state commands now include the queue-related escalated fee factor in the load_factor field of the response - [RIPD-1207]

A transaction with a high transaction cost can now cause transactions from the same sender queued in front of it to get into the open ledger if the transaction costs are high enough on average across all such transactions. - [RIPD-1246]

Reorganization: Move LoadFeeTrack to app/tx and clean up functions - [RIPD-956]

Reorganization: unit test source files - [RIPD-1132]

Reorganization: NuDB stand-alone repository - [RIPD-1163]

Reorganization: Add BEAST_EXPECT to Beast - [RIPD-1243]

Reorganization: Beast 64-bit CMake/Bjam target on Windows - [RIPD-1262]

Bug Fixes

PaymentSandbox::balanceHook can return the wrong issuer, which could cause the transfer fee to be incorrectly by-passed in rare circumstances. [RIPD-1274, #1827]

Prevent concurrent write operations in websockets [#1806]

Add HTTP status page for new websocket implementation [#1855]

The rippled 0.32.1 release includes an improved version of the payment code, which we expect to be available via Amendment on Wednesday, 2016-08-24 with the name FlowV2, and a completely new implementation of the WebSocket protocol for serving clients.

You can update to the new version on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please compile the new version from source.

New and Updated Features

An improved version of the payment processing engine with the name “FlowV2”. The new payments code adds no new features, but improves efficiency and robustness in payment handling. (Update: During the voting process, a critical bug was found in FlowV2, and trusted validators vetoed the amendment. The amendment will be replaced in the next version of rippled.)

The FlowV2 code may occasionally produce slightly different results than the old payment processing engine due to the effects of floating point rounding.

Beast WebSocket

A completely new implementation of the WebSocket protocol for serving clients is available as a configurable option for rippled administrators. To enable this new implementation, change the “protocol” field in rippled.cfg from “ws” to “ws2” (or from “wss” to “wss2” for Secure WebSockets), as illustrated in this example:

[port_ws_public]
port = 5006
ip = 0.0.0.0
protocol = wss2

The new implementation paves the way for increased reliability and future performance when submitting commands over WebSocket. The behavior and syntax of commands should be identical to the previous implementation. Please report any issues to [email protected]. A future version of rippled will remove the old WebSocket implementation, and use only the new one.

Bug fixes

• Fix a non-exploitable, intermittent crash in some client pathfinding requests (RIPD-1219)
• Fix a non-exploitable crash caused by a race condition in the HTTP server. (RIPD-1251)
• Fix bug that could cause a previously fee queued transaction to not be relayed after being in the open ledger for an extended time without being included in a validated ledger. Fix bug that would allow an account to have more than the allowed limit of transactions in the fee queue. Fix bug that could crash debug builds in rare cases when replacing a dropped transaction. (RIPD-1200)
• Remove incompatible OS X switches in Test.py (RIPD-1250)
• Autofilling a transaction fee (sign / submit) with the experimental x-queue-okay parameter will use the user’s maximum fee if the open ledger fee is higher, improving queue position, and giving the tx more chance to succeed. (RIPD-1194)

The rippled 0.32.1 release includes an improved version of the payment code, which we expect to be available via Amendment on Wednesday, 2016-08-24 with the name FlowV2, and a completely new implementation of the WebSocket protocol for serving clients.

You can update to the new version on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please compile the new version from source.

New and Updated Features

An improved version of the payment processing engine, which we expect to be available via Amendment on Wednesday, 2016-08-24 with the name “FlowV2”. The new payments code adds no new features, but improves efficiency and robustness in payment handling.

The FlowV2 code may occasionally produce slightly different results than the old payment processing engine due to the effects of floating point rounding. Once FlowV2 is enabled on the network then old servers without the FlowV2 amendment will lose sync more frequently because of these differences.

Beast WebSocket

A completely new implementation of the WebSocket protocol for serving clients is available as a configurable option for rippled administrators. To enable this new implementation, change the “protocol” field in rippled.cfg from “ws” to “ws2” (or from “wss” to “wss2” for Secure WebSockets), as illustrated in this example:

[port_ws_public]
port = 5006
ip = 0.0.0.0
protocol = wss2

The new implementation paves the way for increased reliability and future performance when submitting commands over WebSocket. The behavior and syntax of commands should be identical to the previous implementation. Please report any issues to [email protected]. A future version of rippled will remove the old WebSocket implementation, and use only the new one.

Bug fixes

Fix a non-exploitable, intermittent crash in some client pathfinding requests (RIPD-1219)

Fix a non-exploitable crash caused by a race condition in the HTTP server. (RIPD-1251)

Fix bug that could cause a previously fee queued transaction to not be relayed after being in the open ledger for an extended time without being included in a validated ledger. Fix bug that would allow an account to have more than the allowed limit of transactions in the fee queue. Fix bug that could crash debug builds in rare cases when replacing a dropped transaction. (RIPD-1200)

Remove incompatible OS X switches in Test.py (RIPD-1250)

Autofilling a transaction fee (sign / submit) with the experimental x-queue-okay parameter will use the user’s maximum fee if the open ledger fee is higher, improving queue position, and giving the tx more chance to succeed. (RIPD-1194)

The rippled 0.32.0 release improves transaction queue which now supports batching and can hold up to 10 transactions per account, allowing users to queue multiple transactions for processing when the network load is high. Additionally, the server_info and server_state commands now include information on transaction cost multipliers and the fee command is available to unprivileged users. We advise rippled operators to upgrade immediately.

You can update to the new version on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please compile the new version from source.

New and Updated Features

• Allow multiple transactions per account in transaction queue (RIPD-1048). This also introduces a new transaction engine code, telCAN_NOT_QUEUE.
• Charge pathfinding consumers per source currency (RIPD-1019): The IP address used to perform pathfinding operations is now charged an additional resource increment for each source currency in the path set.
• New implementation of payment processing engine. This implementation is not yet enabled by default.
• Include amendments in validations subscription
• Add C++17 compatibility
• New WebSocket server implementation with Beast.WebSocket library. The new library offers a stable, high-performance websocket server implementation. To take advantage of this implementation, change websocket protocol under rippled.cfg from wss and ws to wss2 and ws2 under [port_wss_admin] and [port_ws_public] stanzas:

     [port_wss_admin]
     port = 51237
     ip = 127.0.0.1
     admin = 127.0.0.1
     protocol = wss2

     [port_ws_public]
     port = 51233
     ip = 0.0.0.0
     protocol = wss2, ws2

• The fee command is now public (RIPD-1113)
• The fee command checks open ledger rules (RIPD-1183)
• Log when number of available file descriptors is insufficient (RIPD-1125)
• Publish all validation fields for signature verification
• Get quorum and trusted master validator keys from validators.txt
• Standalone mode uses temp DB files by default (RIPD-1129): If a [database_path] is configured, it will always be used, and tables will be upgraded on startup.
• Include config manifest in server_info admin response (RIPD-1172)

Bug fixes

• Fix history acquire check (RIPD-1112)
• Correctly handle connections that fail security checks (RIPD-1114)
• Fix secured Websocket closing
• Reject invalid MessageKey in SetAccount handler (RIPD-308, RIPD-990)
• Fix advisory delete effect on history acquisition (RIPD-1112)
• Improve websocket send performance (RIPD-1158)
• Fix XRP bridge payment bug (RIPD-1141)
• Improve error reporting for wallet_propose command. Also include a warning if the key used may be an insecure, low-entropy key. (RIPD-1110)

Deprecated features

• Remove obsolete sendGetPeers support (RIPD-164)
• Remove obsolete internal command (RIPD-888)