Skip to content

rippled Version 0.50.0
Compare
Choose a tag to compare
@mDuo13 mDuo13 released this 27 Jan 18:15
· 1798 commits to develop since this release
0.50.0
7799957
This commit was signed with the committer’s verified signature.
nbougalis Nik Bougalis
GPG key ID: E7B15890CAFBFDED
Learn about vigilant mode.

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)
Assets 2