ripple-rippled-0.60.0

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)

    Downloads

    Source code (tar.gz)
    Source code (zip)

Ripple Version 0.50.0

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)