ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-27 23:25:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

Migrate dev-blog to Redocly (#2346)

Browse Source 
* Step 1 to migrate the blog - Add blog pages from the dev-blog repo

* Add blog-specific sidebar (& update contents)

* Add new dev reflections blog post from 01-23-2024

* Blog migration: fix markdoc errors and broken links

* Remove community pages from the sidebar

---------

Co-authored-by: mDuo13 <mduo13@gmail.com>
This commit is contained in:
Amarantha Kulkarni
2024-01-24 12:32:55 -08:00
committed by mDuo13
parent 33cd1f54a5
commit b4489f8649
269 changed files with 13832 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
content/blog/2017/data-api-load-balancing-test.md Normal file
View File

@@ -0,0 +1,23 @@
# Load Testing Data API
The Ripple Data team will be running load balancing tests on Ripple Data API starting Wednesday, 2017-01-18, at 2pm PST, which will last approximately 15 minutes. The Ripple Data API is an open and free resource that provides access to information about changes in the Ripple Consensus Ledger, including transaction history and processed analytical data.
## Action Recommended
**If you operate software or services that rely on the Ripple Data API, then we recommend that you alert end users with the relevant information provided in this post.**
## Impact of Tests
If you operate software or services that rely on the Ripple Data API, then you may experience a brief outage and / or inconsistent data, including transaction history and processed analytical data, for a period of approximately 15 mins.
For more information regarding the Ripple Data API, please see [Ripple Data API Documentation](https://ripple.com/build/data-api-v2/).
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: support@ripple.com
* [XRP Chat](http://www.xrpchat.com/)

43
content/blog/2017/decent-strategy-update.md Normal file
View File

@@ -0,0 +1,43 @@
# Decentralization Strategy Update
As Ripple progresses towards further decentralizing the XRP Ledger, we want to make server operators and members of the XRP Ledger community aware of a few upcoming changes to help ensure the reliability and stability of the network as it transitions to a distributed architecture with fully decentralized validators.
## Background
The XRP Ledger (formerly called the Ripple Consensus Ledger) was created in 2012, as a trust-based alternative to the proof-of-work consensus mechanism originated by Bitcoin. So far, most of that trust has relied upon validators owned and controlled by Ripple, the company leading development of the XRP Ledger.
Ripple chose deliberately to be the most trusted validator operator in the network during the initial stages of development of the XRP Ledger. This decision involved trade-offs to prioritize security and scalability ahead of decentralization.
Since inception, the XRP Ledger has closed over 33 million ledgers, processed over 600 million transactions amounting to more than $15 billion in transaction volume, with no major issues or network forks.
At present, the XRP Ledger can natively scale to 1,500 transactions per second. With Payment Channels, XRP can theoretically scale to tens of thousands of transactions per second—throughput levels comparable to VISA.
With the security, stability, and throughput of the XRP Ledger thoroughly proven, Ripple feels that now is the time for a crucial next step in decentralization, while continuing to improve all aspects of the XRP Ledger software.
## Strategy
To meet the growing needs of customers, and further increase resiliency and stability of the XRP Ledger, Ripple is in a great position to fully execute on its [decentralization strategy](https://ripple.com/insights/how-we-are-further-decentralizing-the-ripple-consensus-ledger-rcl-to-bolster-robustness-for-enterprise-use/), which has been an ongoing process since 2012.
Phase one includes the diversification of validators by identity, location, hardware and software, in an effort to further mitigate the risk of a single point of failure. At the time of the announcement, 25 validator nodes were running with 5 trusted validators owned and managed by Ripple. Currently, [over 70 validator nodes](https://xrpcharts.ripple.com/#/validators) are running globally. During this phase Ripple will be adding 16 more trusted validators, in preparation for phase two.
During the second phase, for every two of the most reliable, reputable, stable, secure and attested validators added to the recommended list of trusted nodes, one validator node currently controlled by Ripple will be removed, until no entity operates a majority of recommended trusted nodes on the XRP Ledger.
The validator operators on this recommended list of trusted nodes believe in the long term vision of XRP and want to participate in the consensus process, which involves voting on proposed amendments, modifying fees and validating transactions.
## Changes
Before Ripple can progress to phase two, a few changes have to be made to ensure a safe transition.
With the 0.80.0 release, Ripple will transition its recommended validator list to a new hosted site. This involves a change in the default `rippled` configuration file. The `[validators]` field with its static list of trusted validators will be replaced with `[validator_list_keys]` and `[validator_list_sites]` fields containing the key Ripple will use to sign its newly recommended validator list as well as the URLs where the dynamic list can be found.
These changes will allow new validators to be safely added to the recommended validator list for phase two without requiring every `rippled` operator to manually update their configuration with each new addition.
It is important to note that, for operators who already use the recommended validator list, no further trust in Ripple is required during phase 1, despite the significant increase of validators under Ripple’s operational control. The validator list currently recommended by Ripple contains 5 validators operated by Ripple, and at the end of phase 1, the list will contain 16 such validators.
During phases 1 and 2, Ripple strongly recommends that operators use only the default Ripple-provided validator list. Consistent with this recommendation, the next scheduled release of `rippled`, version 0.81.0, will ship with a default configuration file using that list by default.
During phase 2, Ripple will begin decommissioning one validator under its operational control for every two third-party validators that demonstrate a strong reputation for stability, security and reliability. Ripple will also be working with other entities to establish independent providers of validator lists.
## Conclusion
Ripple remains committed to decentralizing the XRP Ledger and divesting itself of operational control. This multi-phase approach does that, but is intentionally conservative and has been devised with a single goal in mind: to ensure the reliability and stability of the network during the transition period to a fully decentralized and distributed architecture.

38
content/blog/2017/escrow-paychan-fix1368-reminder.md Normal file
View File

@@ -0,0 +1,38 @@
# Escrow, PayChan, and fix1368 Will Be Available in 3 Days
A majority of `rippled` validators voted to enable the [Escrow](https://ripple.com/build/amendments/#escrow), [PayChan](https://ripple.com/build/amendments/#paychan), and [fix1368](https://ripple.com/build/amendments/#fix1368) Amendments, which are scheduled to become enabled on the network on Thursday, 2017-03-30.
* **Escrow** (previously called SusPay), designed for low volume, high value transactions, permits users to cryptographically escrow XRP on RCL with an expiration date using a [hashlock crypto-condition](https://interledgerjs.github.io/five-bells-condition/jsdoc/).
* **PayChan**, designed for high volume, low value transactions, flowing in a single direction. The scalability of these transactions is not limited by the Ripple Consensus ledger, and they do not incur the risks typically associated with delayed settlement.
* **fix1368** fixes a minor bug in transaction processing that causes some payments to fail when they should be valid.
## Action Required
**If you operate a `rippled` server**, then you should upgrade to version 0.60.0 by Thursday, 2017-03-30, for service continuity.
## Impact of Not Upgrading
If you operate a `rippled` server but don’t upgrade to version 0.60.0 by Thursday, 2017-03-30, when **Escrow, PayChan & fix1368** are expected to be activated via Amendment, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server:
* Cannot determine the validity of a ledger
* Cannot submit or process transactions
* Does not participate in the consensus process
* Does not vote on future amendments
* Could rely on potentially invalid data
If the **Escrow, PayChan & fix1368** amendments do not get approved, then your server will not become amendment blocked and should continue to operate.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: <support@ripple.com>
* [XRP Chat](http://www.xrpchat.com/)

25
content/blog/2017/explanation-of-ripples-xrp-escrow.md Normal file
View File

@@ -0,0 +1,25 @@
# An Explanation of Ripple’s XRP Escrow
To provide additional predictability to the XRP supply, Ripple has locked 55 billion XRP (55% of the total possible supply) into a series of escrows. These escrows are on the ledger itself and the ledger mechanics, enforced by consensus, control the release of the XRP.
The escrow consists of independent on ledger escrows that release a total of one billion XRP each month over the next 55 months. This provides an upper limit on the amount of new XRP that can be brought into circulation. The amount of XRP actually released into circulation will likely be much less than this. Any additional XRP leftover each month will be placed into a new escrow to release in the first month in which no escrow currently releases.
During the process of moving Ripple’s XRP into escrow, we also changed our account security model. The XRP Ledger supports a native multisign scheme and Ripple secured the accounts the escrows release into using this scheme.
The multisignature scheme has numerous advantages over the schemes other ledgers use. For example, the signers or quorum can be changed without changing the receiving address. Individual signers can rotate their own credentials without disturbing the funds on the ledger.
## Ledger Mechanics
The XRP Ledger’s escrow system is designed to handle two use cases. The one that gives it its name is its ability to lock funds on the ledger subject to release to one of two accounts depending on whether a particular condition occurs by a particular time. This supports Interledger transactions or cross-ledger atomic swaps.
The escrow system consists of three types of transactions and one type of ledger entry. Escrows are created with an “EscrowCreate” transaction. This creates the “Escrow” ledger entry. An escrow can then be either cancelled or finished with an “EscrowCancel” or an “EscrowFinish” transaction.
If an escrow is successfully finished, it delivers the XRP held to its destination account. If the escrow is cancelled, it delivers the XRP back to the source account. A ledger can have a date before which it cannot be cancelled, a date before which it cannot be finished, and a condition which must be satisfied to permit it to be finished.
An escrow as a time lock several different ways, but the simplest one is to create an escrow that cannot be cancelled, cannot be finished before a particular date, and requires no additional condition to finish. For simplicity, the destination account can be set to be identical to the source account.
On the ledger, an “Escrow” entry has a source account, a destination account, and an XRP amount. It is considered owned by the account that created it and increases the required XRP reserve for that account until it is completed or cancelled. Escrow entries can optionally have a cryptocondition that must be satisfied to finish the escrow, a date before which it cannot be cancelled, and a date before which it cannot be completed.
Escrows can also have source and destination tags. Source and destination tags on the XRP Ledger provide a uniform and reliable way to support hosted accounts where an agent (such as an exchange) performs a transaction on behalf of its customer. The destination tag informs the recipient of which customer to credit. The source tag permits a payment to be refunded and the refund to be credited to the proper customer. This permits exchanges (or hosted wallet providers) to perform and receive escrowed payments on behalf of their customers.
While the escrow is currently being used to provide more predictability to the XRP supply, Ripple expects that escrow will increasingly be used for higher-value, on-ledger and cross-ledger atomic payments using the Interledger Protocol. The XRP Ledger also provides payment channels for lower-value, off-ledger payments and micropayments.

11
content/blog/2017/high-scalability-xrp-ledger.md Normal file
View File

@@ -0,0 +1,11 @@
# The Most (Demonstrably) Scalable Blockchain
Blockchain technology is set to fundamentally transform the way the world moves value, but to do so, it must first meet a number of challenges.
In previous posts on this blog, we have highlighted our engineering practices and how they help us built robust and secure software—an important consideration for these new systems.
The ability to handle volume is equally important, and today, we are sharing some more details about that aspect of our process. In [a feature article about the XRP Ledger on High Scalability](http://highscalability.com/blog/2017/10/2/ripple-the-most-demonstrably-scalable-blockchain.html)—the premiere news source about scalable, high performance Internet applications—we are proud to talk about our development and benchmarking practices and to discuss the data-driven changes we made to increase transaction throughput by a factor of 10 since we began performance testing.
The XRP Ledger has been designed from the ground up with scalability in mind and the underlying architecture has only been improved over time. As our data shows, the XRP Ledger is now capable of sustaining a throughput of **1,500 transactions per second** on commodity hardware.
We hope that this will be the first article in a series highlighting our continued efforts to scale the performance of the XRP Ledger to meet not only the demands of the present, but of the future as we help the Internet of Value take shape.

26
content/blog/2017/invariant-checking.md Normal file
View File

@@ -0,0 +1,26 @@
# Protecting the Ledger: Invariant Checking
_By Nik Bougalis, Engineering Manager_
At Ripple, we have been developing next-generation financial infrastructure with an eye towards making value move as fast and as efficiently as information does today.
But we are also keenly aware of the need for value to also move securely and reliably, so we place heavy emphasis on writing solid, secure and robust code. Our singular focus on code quality is the reason that the Ripple network experienced no service outages through 2016 or, so far, in 2017.
With the release of rippled 0.70.0, and as part of our long-standing and enduring commitment to a reliable and error-free XRP Ledger, we are going further than before. We are adding code that runs automatically and in real time after each transaction completes, and examines the changes it made for correctness before the results are committed to the ledger.
This is the idea behind the [recently activated](https://xrpcharts.ripple.com/#/transactions/17593B03F7D3283966F3C0ACAF4984F26E9D884C9A202097DAED0523908E76C6) [EnforceInvariants amendment](https://ripple.com/build/amendments/#enforceinvariants), which will make it possible to verify that key properties of the system are not violated. The new checks—which we believe will never trigger—help protect the integrity of the XRP Ledger from bugs yet to be discovered, or even created.
What’s more, the process is transparent and public: problematic transactions are marked with a **tecINVARIANT_FAILED** result code and are included in the ledger. This broad exposure, coupled with Ripple’s powerful ability to step through the execution of past transactions, makes it possible to quickly identify and fix any logic flaws in the code.
One key property of the invariant checking functions is that they are simple: each check only does one thing and is easy to read and understand. This means that it is trivial to verify the correctness of the implementation by inspection—an important consideration in any security critical code.
Our existing software development and quality assurance process places heavy emphasis on correctness and security. Over the past five years, we've honed this process to cover the entire software development lifecycle. Some of the systems we've put in place include:
- Extensive unit tests, with tests as a requirement to merge any new code
- Regular use of tools to objectively assess the quality of the codebase
- A rigorous and public review process by Ripple’s world-class team of developers and third-party contributors
- Regular security audits by subject matter experts from the crypto, fintech and C++ communities.
The new invariant checking sits atop and enhances our existing process by extending real-time protection to the XRP Ledger to help ensure its long-term health and security.
As we continue to improve the XRP Ledger by adding new features and by further improving performance, we will also work to refine our process to help ensure that the financial infrastructure of the future will not only be fast, but also robust and secure.

17
content/blog/2017/response-to-china-cert-report.md Normal file
View File

@@ -0,0 +1,17 @@
# Response to China CERT Report
As a leader in open-source, distributed financial technology, Ripple recognizes the importance of security researchers and we always encourage responsible disclosure of potential security vulnerabilities via our [bug bounty program](https://ripple.com/bug-bounty/). Ripple also employs regular external security audits and, as a matter of practice, the maintainers of the Ripple Consensus Ledger (RCL) technology (`rippled`) routinely use static and dynamic analysis tools on the C++ codebase (most recently version 0.50.0-b1).
The results of the last internal static analyzer run determined that the defect rate of rippled was below the threshold that is typical for open source projects. To date, there have been no critical vulnerabilities discovered through static and dynamic analysis of the rippled C++ codebase, and the issues that have been found have been false-positives. In addition to using automated scanning tools, manual reviews of the code by multiple engineers have failed to identify a single vulnerability and the minor issues that have been discovered have long been fixed.
Further, a recent independent security audit conducted by the NCC Group, a global security risk mitigation firm, revealed no serious security vulnerabilities, and found rippled “to be well-written and designed” before adding that it was clear that Ripple “has taken time to carefully consider the implementation.”
In a recent [blockchain security report](http://if.cert.org.cn/res/web_file/bug_analyze_report.pdf) _(dead link)_, China CERT claimed that software related to Ripple’s open-sourced, distributed ledger technology has “230 high-risk security vulnerabilities.” Unfortunately, since the researchers behind the report did not demonstrate responsible disclosure by contacting Ripple prior to publication, we do not know what testing methodology or techniques were used nor which code repositories were tested. As a result, we were forced to investigate the claims being made after the fact, with no guidance from the security researchers and very little context.
From what we can determine, the methodology appears to have been strictly limited to automated analysis tools run over a mixture of both security critical code and code that has no security implications whatsoever. The quantitative results were determined by the number of possible vulnerabilities identified by the tool and the possible severity of actual vulnerabilities in that class. (<i>for example, any code that might have a buffer overflow would be identified as high risk, because if there actually is a buffer overflow issue and the code is actually security relevant, that could cause a significant compromise</i>).
Automated analysis tools typically have extremely high false positive rates of about 99%. When projects that already use this same methodology are tested in this way, the false positive rate nears 100% since all actual vulnerabilities that could be found in this way already have been found.
Again, Ripple recognizes the importance of security researchers, and we take any reports of security vulnerabilities very seriously. At this time, we do not feel confident in the accuracy of the CERT report. Furthermore, based on the way in which the report was published, we question the legitimacy of the reporting body. We are confident in our processes and our codebase, and expressly state that this report identifies no actionable items and our review, in response to it, found none either.
We will continue to promptly and vigorously investigate all reports of security vulnerabilities, and urge anyone who thinks they have identified such a vulnerability to responsibly disclose it to us via our [bug bounty program](https://ripple.com/bug-bounty/).

15
content/blog/2017/ripple-consensus-ledger-can-sustain-1000-transactions-per-second.md Normal file
View File

@@ -0,0 +1,15 @@
# Ripple Consensus Ledger Can Sustain 1000 Transactions per Second
2016 was an [important year for Ripple](https://ripple.com/insights/ripple-2016-year-review/). Banks were added to our [growing network](http://www.ibtimes.co.uk/seven-banks-kick-off-ripples-blockchain-network-including-santander-ubs-unicredit-90-more-1566894), we completed a successful [Series B investment round](https://ripple.com/insights/ripple-raises-55-million-in-series-b-funding/) and formed the [Global Payments Steering Group](https://ripple.com/insights/announcing-ripples-global-payments-steering-group/). Underlying all those milestones was the Ripple Consensus Ledger (RCL), which runs 24 hours a day, 7 days a week and recently celebrated its 4th birthday on February 17, 2017. In 2016 alone, RCL closed over 8 million ledgers, processing more than 225 million transactions and handling more than $1 Billion dollars in payment volume throughout the year.
Today, for the first time, Ripple is proud to publicly announce that in recent internal benchmark testing, across 16 geographically distributed validators, the RCL is able to sustain nearly 1000 transactions per second.
For even higher throughput transactions, we recently introduced [XRP payment channels](https://developers.ripple.com/blog/2016/rippled-0.33.0.html), which allow for zero-latency XRP payments. Although payment channels achieve practically infinite scalability by decoupling payment from settlement, they do so without incurring the risk typically associated with delayed settlement.
Throughout 2016, the network received upgrades that seamlessly enabled new functionality and significantly improved performance. Fast ledger close times have been the hallmark of RCL since its inception and those were further improved last year. Ledgers now close, on average, every 3.5 seconds - a full 20% faster than they did a year ago.
The new [fee escalation code ](https://ripple.com/build/transaction-cost/)was introduced to constantly monitor network load and adjust (in near real-time) the cost of executing transactions, which makes it more difficult to overload the network and further helps to ensure the long-term health and stability of RCL.
Stability, however, goes beyond improving performance and adding new features. At Ripple we place heavy emphasis on writing code that is secure, solid and robust. This singular focus on code quality has helped the Ripple network achieve availability and reliability well beyond industry standards with no outages.
With 2017 now well under way, we remain hard at work, focused on adding exciting new features to the RCL and further improving the performance, stability and quality of the [rippled](https://github.com/ripple/rippled) open source codebase. Most importantly, we remain more committed than ever to the simple goal of making XRP the world’s reserve digital currency.

44
content/blog/2017/rippled-0.40.1.md Normal file
View File

@@ -0,0 +1,44 @@
# rippled version 0.40.1
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.
## Action Recommended
**If you operate a `rippled` server and have full-history of the ledger, then you should upgrade to 0.40.1 immediately.**
## Impact of Not Upgrading
If you operate a `rippled` server and have full-history of the ledger, but don’t upgrade to version 0.40.1, then your server may crash when restarted.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The md5sum for the rpm is: e876816f4ddb38bec28d158083020fa9
The md5sum for the source rpm is: 3ed1569bd0dbba5ff1d1ef1abfca7ed7
For other platforms, please [compile version 0.40.1 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
$ git log -1 upstream/master
commit e91aacc9a3d2f332a93981270c3812e26189226e
Author: Nik Bougalis <nikb@bougalis.net>
Date: Thu Jan 5 09:38:28 2017 -0800
Set version to 0.40.1
## Bug Fixes
Increase SQLite database limits to prevent full-history servers from crashing when restarting. [(#1961)](https://github.com/ripple/rippled/commit/610e51a162a6ef06accf8733b3b35b492963a78b)
## Network Update
The Ripple operations team has deployed version 0.40.1 to all full-history `rippled` servers under its operational control.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: <support@ripple.com>
* [XRP Chat](http://www.xrpchat.com/)

138
content/blog/2017/rippled-0.50.0.md Normal file
View File

@@ -0,0 +1,138 @@
# rippled version 0.50.0
Ripple has released `rippled` version 0.50.0, which introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger (RCL). Ripple recommends that all server operators upgrade to version 0.50.0 by Tuesday, 2017-02-21, for service continuity.
Highlights of this release include:
* **TickSize**, which allows gateways to set a "tick size" for assets they issue 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 named “TickSize”](https://ripple.com/build/amendments/#ticksize) on Tuesday, 2017-02-21. See below for details.
## Action Required
**1. If you operate a `rippled` server, then you should upgrade to version 0.50.0 by Tuesday, 2017-02-21, for service continuity.**
**2. If you are a gateway issuer, then please review forthcoming documentation for the TickSize amendment to determine what tick size is appropriate for your issuing asset.**
**3. If you are a market maker and have algorithmic trading bots, then please review forthcoming documentation for the TickSize amendment to update your trading system to check the tick size for a given issuer.**
**4. If you have backend software which constructs and submits transactions related to the issuing of assets on the Ripple network, then please review forthcoming documentation for the TickSize amendment to adapt it for correct usage.**
## Impact of Not Upgrading
If you operate a `rippled` server but don’t upgrade to version 0.50.0 by Tuesday, 2017-02-21, when **TickSize** is expected to be activated via Amendment, then your server will become amendment blocked, meaning that your server:
* Cannot determine the validity of a ledger
* Cannot submit or process transactions
* Does not participate in the consensus process
* Does not vote on future amendments
* Could rely on potentially invalid data
If the **TickSize** amendment is vetoed or does not pass, then your server will not become amendment blocked and should continue to operate.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The md5sum for the rpm is: 82eb29f7e464e44eb24e3c891a021041
The md5sum for the source rpm is: 7bf25c86f018daf82c5d5f8ab621153a
For other platforms, please [compile version 0.50.0 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
commit 77999579b535373872d8cce7ddc8b12cdcc39d84
Author: Nik Bougalis <nikb@bougalis.net>
Date: Thu Jan 26 13:26:03 2017 -0800
Set version to 0.50.0
## Network Update
The Ripple operations team plans to deploy version 0.50.0 to all `rippled` servers under its operational control, including private clusters, starting at 11:00 AM PDT on Friday, 2017-01-27. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: support@ripple.com
* [XRP Chat](http://www.xrpchat.com/)
## Full Release Notes
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](https://ripple.com/build/rippled-setup/#updating-rippled) on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds).
**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)](https://github.com/ripple/rippled/pull/1910)
* Increase OpenSSL requirements & harden default TLS cipher suites [(#1913)](https://github.com/ripple/rippled/pull/1913)
* Move test support sources out of ripple directory [(#1916)](https://github.com/ripple/rippled/pull/1916)
* Enhance ledger header RPC commands [(#1918)](https://github.com/ripple/rippled/pull/1918)
* Add support for tick sizes [(#1922)](https://github.com/ripple/rippled/pull/1922)
* Port discrepancy-test.coffee to c++ [(#1930)](https://github.com/ripple/rippled/pull/1930)
* Remove redundant call to clearNeedNetworkLedger [(#1931)](https://github.com/ripple/rippled/pull/1931)
* Port freeze-test.coffee to C++ unit test. [(#1934)](https://github.com/ripple/rippled/pull/1934)
* Fix CMake docs target to work if BOOST_ROOT is not set [(#1937)](https://github.com/ripple/rippled/pull/1937)
* Improve setup for account_tx paging test [(#1942)](https://github.com/ripple/rippled/pull/1942)
* Eliminate npm tests [(#1943)](https://github.com/ripple/rippled/pull/1943)
* Port uniport js test to cpp [(#1944)](https://github.com/ripple/rippled/pull/1944)
* Enable amendments in genesis ledger [(#1944)](https://github.com/ripple/rippled/pull/1944)
* Trim ledger data in Discrepancy_test [(#1948)](https://github.com/ripple/rippled/pull/1948)
* Add "current_ledger" field to "fee" result [(#1949)](https://github.com/ripple/rippled/pull/1949)
* Cleanup unit test support code [(#1953)](https://github.com/ripple/rippled/pull/1953)
* Add ledger save / load tests [(#1955)](https://github.com/ripple/rippled/pull/1955)
* Remove unused websocket files [(#1957)](https://github.com/ripple/rippled/pull/1957)
* Update RPC handler role/usage [(#1966)](https://github.com/ripple/rippled/pull/1966)
**Bug Fixes**
* Validator's manifest not forwarded beyond directly connected peers [(#1919)](https://github.com/ripple/rippled/pull/1919)
## Upcoming Features
We expect the [previously](https://developers.ripple.com/blog/2016/rippled-0.40.0.html) announced Suspended Payments feature, which introduces new transaction types to the Ripple protocol that will permit users to cryptographically escrow XRP on RCL, to be enabled via the [“SusPay”](https://ripple.com/build/amendments/#suspay) Amendment on Tuesday, 2017-02-21.
Also, we expect support for [crypto-conditions](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02), which are signature-like structures that can be used with suspended payments to support ILP integration, to be included in the next `rippled` release scheduled for March.
Lastly, we do not have an update on the [previously announced](https://developers.ripple.com/blog/2016/rippled-0.33.0.html) changes to the hash tree structure that `rippled` uses to represent a ledger, called [SHAMapV2](https://ripple.com/build/amendments/#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).

47
content/blog/2017/rippled-0.50.2.md Normal file
View File

@@ -0,0 +1,47 @@
# rippled version 0.50.2
The `rippled` team has released 0.50.2, which adjusts the default TLS cipher list and corrects a flaw that would not allow an SSL handshake to properly complete if the port was configured using the wss keyword. Ripple recommends upgrading to 0.50.2 only if server operators are running `rippled` servers that accept client connections over TLS. There are no new or updated features in the 0.50.2 release.
## Action Recommended
**If you operate a `rippled` server and accept secure client connections, then you should upgrade to 0.50.2 immediately.**
## Impact of Not Upgrading
If you operate a `rippled` server and accept secure client connections, but don’t upgrade to version 0.50.2, then your server may be unable to negotiate SSL connections.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The md5sum for the rpm is: 05cf675685158aabfc3ff6af7b1549d8
The md5sum for the source rpm is: 0a8c93d67e1c27726ee57693177e7745
For other platforms, please [compile version 0.50.2 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
```
commit d8a5f5b0946e2a155a1af8455512488a5f758955
Author: Nik Bougalis <nikb@bougalis.net>
Date: Mon Jan 30 15:45:35 2017 -0800
Set version to 0.50.2
```
## Bug Fixes
Adjust the default cipher list and correct a flaw that would not allow an SSL handshake to properly complete if the port was configured using the wss keyword. [(#1985)](https://github.com/ripple/rippled/pull/1985/commits/708fc6cd6f3c75d08fa409f6815ed915854438a5)
## Network Update
The Ripple operations team has deployed a configuration-based fix to all client-facing `rippled` servers under its operational control and will not be updating to 0.50.2 at this time.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: support@ripple.com
* [XRP Chat](http://www.xrpchat.com/)

59
content/blog/2017/rippled-0.50.3.md Normal file
View File

@@ -0,0 +1,59 @@
# rippled version 0.50.3
The `rippled` team has released version 0.50.3, which patches a reported exploit that would allow a combination of trust lines and order books in a payment path to bypass the blocking effect of the `NoRipple` flag. Ripple recommends that all `rippled` server operators immediately upgrade to version 0.50.3, which contains a patch that fixes the exploit. There are no new or updated features in the 0.50.3 release.
Ripple will be following up with a postmortem, explaining the exploit, the timeline of events and the actions taken in more detail at a later date.
## Action Recommended
**If you operate a `rippled` server**, then you should upgrade to version 0.50.3 immediately.
**If you operate a gateway**, then you should:
1. Make sure your issuing account has not set the `NoRipple` flag on any trust lines
2. Your issuing account should have a zero limit on all trust lines
3. Make sure the `DefaultRipple` flag is set on your issuing account
4. Upgrade to `rippled` version 0.50.3 immediately
**If you are an individual user**, then you should have the `NoRipple` flag enabled by default and set the trust line limit to zero on gateways that you do not trust.
**If you are an individual user, and you do not have the `NoRipple` flag enabled**, and you discover a negative balance owed to an unknown account, then you should freeze that individual trust line.
## Impact of Not Upgrading
If you operate a `rippled` server, but don’t upgrade to `rippled` version 0.50.3, then your server may lose sync with Ripple operated validators more frequently.
If you operate a `rippled` validating server, but don’t upgrade to `rippled` version 0.50.3, which includes a patch for the reported exploit, then your server will validate some transactions in a payment path that bypass the blocking effect of the `NoRipple` flag.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The sha256 for the rpm is: 2ee3e7e2912b5df9e3f8f88c5f6adfa60afbb37ef08afe50f6147795c5c2abaf
The sha256 for the source rpm is: ada6f9ae8b8136569d28f03a43fef0f828e2c69857c81f230d17cf9f832cce0f
For other platforms, please [compile version 0.50.3 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
commit 82de944b30afef7fb6220424b62a79156e93b321
Author: Nik Bougalis <nikb@bougalis.net>
Date: Mon Mar 13 15:49:21 2017 -0700
Set version to 0.50.3
## Bug Fixes
Patch a reported exploit that would allow a combination of trust lines and order books in a payment path to bypass the blocking effect of the `NoRipple` flag [(#2050)](https://github.com/ripple/rippled/pull/2050/commits/0b187a6a4eb503c91efca997aae32c4c9b45f115)
## Network Update
Ripple engineers have deployed the fix to all `rippled` validating servers under Ripple’s operational control and will not be updating client-facing `rippled` servers to 0.50.3 at this time. _(Editor's note: an earlier version of this post incorrectly stated that the fix was configuration-based. The fix was to update Ripple's validating servers to 0.50.3.)_
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: <support@ripple.com>
* [XRP Chat](http://www.xrpchat.com/)

124
content/blog/2017/rippled-0.60.0.md Normal file
View File

@@ -0,0 +1,124 @@
# rippled Version 0.60.0
Ripple has released `rippled` version 0.60.0, which introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger (RCL), including [Interledger Protocol](https://interledger.org/overview.html) compatibility for ledger interoperability. Ripple recommends that all server operators upgrade to version 0.60.0 by Thursday, 2017-03-30, for service continuity.
Highlights of this release include:
* **Escrow** (previously called SusPay), which permits users to cryptographically escrow XRP on RCL with an expiration date using a [hashlock crypto-condition](https://interledgerjs.github.io/five-bells-condition/jsdoc/).
* **[Dynamic UNL Lite](https://github.com/ripple/rippled/pull/1842)**, which allows `rippled` to automatically adjust which validators it trusts based on recommended lists from trusted publishers.
Ripple expects Escrow, the [previously announced **Payment Channels**](https://developers.ripple.com/blog/2016/rippled-0.33.0.html), and the new [**fix1368** amendment](#fix1368-amendment) to be enabled via Amendments called [Escrow](https://ripple.com/build/amendments/#escrow), [PayChan](https://ripple.com/build/amendments/#paychan), and `fix1368`, respectively, on Thursday, 2017-03-30.
## Action Required
**If you operate a `rippled` server**, then you should upgrade to version 0.60.0 by Thursday, 2017-03-30, for service continuity.
## Impact of Not Upgrading
If you operate a `rippled` server but don’t upgrade to version 0.60.0 by Thursday, 2017-03-30, when Escrow and PayChan are expected to be activated via Amendment, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server:
* Cannot determine the validity of a ledger
* Cannot submit or process transactions
* Does not participate in the consensus process
* Does not vote on future amendments
* Could rely on potentially invalid data
If the **Escrow** and **PayChan** amendments do not get approved, then your server will not become amendment blocked and should continue to operate.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The sha256 for the rpm is: 4d2acb2a40e2d18ba1737098efdca54caa823a403ce9562c83e2dd2c9e959588
The sha256 for the source rpm is: 3437a0202e762801869f31bf798417ebdb3717e16c4381dc0e9b02fe75d23024
For other platforms, please [compile version 0.60.0 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
commit 0df1b09a731ba0feaa5d60046e1c7dd415f5f7ed
Author: Nik Bougalis <nikb@bougalis.net>
Date: Thu Mar 16 13:33:29 2017 -0700
Set version to 0.60.0
## Network Update
The Ripple operations team plans to deploy version 0.60.0 to all `rippled` servers under its operational control, including private clusters, starting at 7:00 PM PST on Thursday, 2017-03-16. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: <support@ripple.com>
* [XRP Chat](http://www.xrpchat.com/)
## Full Release Notes
### Escrow
The rippled version 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](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02) called [preimage-sha-256](https://interledgerjs.github.io/five-bells-condition/jsdoc/#create-a-preimage-sha-256-condition-hashlock), 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](https://ripple.com/build/amendments/#paychan) 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](https://ripple.com/build/ripple-ledger-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` version 0.60.0 release introduces new [Dynamic UNL](https://github.com/ripple/rippled/pull/1842) 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
Version 0.60.0 also introduces the [fix1368 Amendment](https://github.com/ripple/rippled/pull/1936) 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](https://developers.ripple.com/blog/2016/rippled-0.33.0.html) changes to the hash tree structure that `rippled` uses to represent a ledger, called [SHAMapV2](https://ripple.com/build/amendments/#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](https://ripple.com/build/rippled-setup/#updating-rippled) on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds).
## 0.60.0 Change Log
* Add Escrow support [(#2039)](https://github.com/ripple/rippled/pull/2039/commits/cfde591ac9deb683b9d1be8f8d4c7a14d9598507)
* Dynamize trusted validator list and quorum [(#1842)](https://github.com/ripple/rippled/pull/1842)
* Simplify fee handling during transaction submission [(#1992)](https://github.com/ripple/rippled/commit/8345475bc37a4d6bddf1e47dc06f22ef9396bbd8)
* Publish server stream when fee changes [(#2016)](https://github.com/ripple/rippled/pull/2016)
* Replace manifest with validator token [(#1975)](https://github.com/ripple/rippled/pull/1975)
* Add validator key revocations [(#2019)](https://github.com/ripple/rippled/pull/2019)
* Add SecretKey comparison operator [(#2004)](https://github.com/ripple/rippled/pull/2004/commits/a00e684bf2a088bb432b9f7c4c859ee98c730817)
* Reduce LEDGER_MIN_CONSENSUS [(#2013)](https://github.com/ripple/rippled/pull/2013)
* Update libsecp256k1 and Beast B30 [(#1983)](https://github.com/ripple/rippled/pull/1983)
* Make Config extensible via lambda [(#1993)](https://github.com/ripple/rippled/pull/1993)
* WebSocket permessage-deflate integration [(#1995)](https://github.com/ripple/rippled/pull/1995)
* Do not close socket on a foreign thread [(#2014)](https://github.com/ripple/rippled/pull/2014)
* Update build scripts to support latest boost and ubuntu distros [(#1997)](https://github.com/ripple/rippled/pull/1997)
* Handle protoc targets in scons ninja build [(#2022)](https://github.com/ripple/rippled/pull/2022)
* Specify syntax version for ripple.proto file [(#2007)](https://github.com/ripple/rippled/pull/2007)
* Eliminate protocol header dependency [(#1962)](https://github.com/ripple/rippled/pull/1962)
* Use gnu gold or clang lld linkers if available [(#2031)](https://github.com/ripple/rippled/pull/2031)
* Add tests for lookupLedger [(#1989)](https://github.com/ripple/rippled/pull/1989)
* Add unit test for get_counts RPC method [(#2011)](https://github.com/ripple/rippled/pull/2011)
* Add test for transaction_entry request [(#2017)](https://github.com/ripple/rippled/pull/2017)
* Unit tests of RPC "sign" [(#2010)](https://github.com/ripple/rippled/pull/2010)
* Add failure only unit test reporter [(#2018)](https://github.com/ripple/rippled/pull/2018)
## Bug Fixes
* Enforce rippling constraints during payments [(#2049)](https://github.com/ripple/rippled/pull/2049)
* Fix limiting step re-execute bug [(#1936)](https://github.com/ripple/rippled/pull/1936)
* Make "wss" work the same as "wss2" [(#2033)](https://github.com/ripple/rippled/pull/2033)
* Check for malformed public key on payment channel [(#2027)](https://github.com/ripple/rippled/pull/2027)
* Config test uses unique directories for each test [(#1984)](https://github.com/ripple/rippled/pull/1984)
* Send a websocket ping before timing out in server [(#2035)](https://github.com/ripple/rippled/pull/2035)

51
content/blog/2017/rippled-0.60.1.md Normal file
View File

@@ -0,0 +1,51 @@
# rippled version 0.60.1
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 cancelled when certain errors occurred during subscription streams. **Ripple strongly recommends upgrading to `rippled` version 0.60.1 immediately.**
Ripple expects the [`Escrow`](https://ripple.com/build/amendments/#escrow) and [`PayChan`](https://ripple.com/build/amendments/#paychan) amendments to be enabled via [amendment vote](https://developers.ripple.com/blog/2017/escrow-paychan-fix1368-reminder.html) around 11:26 PM PDT on Thursday, 2017-03-30. There are no new features in the 0.60.1 release.
## Action Required
**If you operate a `rippled` server, then you must upgrade to 0.60.1 immediately.**
## Impact of Not Upgrading
* If you operate a `rippled` server, but do not upgrade to `rippled` version 0.60.1, then your `rippled` server will lose sync when processing Payment Channel or Escrow transactions. The `Escrow` and `PayChan` amendments are expected to be enabled via amendment vote around 11:26 PM PDT on Thursday, 2017-03-30.
* If you operate a `rippled` server, but do not upgrade to version 0.60.1, then client websocket connections to your `rippled` server may continue to disconnect during subscription streams.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The sha256 for the RPM is: 6714050e9d1d232e8250be434fe6a61c44f78e41adc3c2b5f49df490ee5312ef
The sha256 for the source RPM is: 5bba13e93fed160a3405315e4128e891b2bc1e439ee5f7b429294003c618f0e1
For other platforms, please [compile version 0.60.1 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
commit 0d4fe469c6b0ba47645b53930e74248ff789fe75
Author: seelabs <scott.determan@yahoo.com>
Date: Wed Mar 29 15:41:43 2017 -0400
Set version to 0.60.1
## Bug Fixes
Fix a flaw that resulted from using 32-bit space identifiers instead of the protocol-defined 16-bit values [(#2071)](https://github.com/ripple/rippled/pull/2071)
Fix a problem where the WebSocket timeout timer would not be cancelled when certain errors occurred during subscription streams [(#2067)](https://github.com/ripple/rippled/pull/2067)
## Network Update
The Ripple technical operations team plans to deploy `rippled` version 0.60.1 to all `rippled` servers under its operational control, including private clusters, starting at 11:00 AM PDT on Thursday, 2017-03-30. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: support@ripple.com
* [XRP Chat](http://www.xrpchat.com/)

42
content/blog/2017/rippled-0.60.2-2-rpm.md Normal file
View File

@@ -0,0 +1,42 @@
# rippled RPM version 0.60.2-2
Ripple has released a new `rippled` 0.60.2-2 RPM that contains an update to the [validator-keys](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#validator-keys) key generation and management tool. The latest version of validator-keys allows validator operators to [sign data with their validator key](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#signing).
There are no changes to `rippled` with this version.
## Action Required
**If you operate a `rippled` validator server that was set up using validator-keys and would like to sign data with your validator key**, then you should update to the `rippled` 0.60.2-2 RPM.
## Impact of Not Upgrading
**If you operate a `rippled` validator server but you don’t update to the `rippled` 0.60.2-2 RPM**, then your `rippled` instance will continue to operate normally.
**If you operate a `rippled` validator server that was set up using validator-keys but don’t update to the `rippled` 0.60.2-2 RPM**, then you will be unable to sign data using your validator key.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The sha256 for the RPM is: 74e2541c1c6c06bd34d102229890bb11811701d73d99e4cfb4882d430131c067
The sha256 for the source RPM is: aab7f247b5cf9d3a20d4720aef2c51532bb83ee91fafe584e4fdfac77171537b
For other platforms, please [compile version 0.60.2-2 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
commit 7cd4d7889779e6418270c8af89386194efbef24b
Author: seelabs <scott.determan@yahoo.com>
Date: Thu Mar 30 14:25:41 2017 -0400
Set version to 0.60.2
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: support@ripple.com
* [XRP Chat](http://www.xrpchat.com/)

56
content/blog/2017/rippled-0.60.2.md Normal file
View File

@@ -0,0 +1,56 @@
# rippled version 0.60.2
The `rippled` team has released `rippled` version 0.60.2, which further strengthens handling of cases associated with a [previously patched exploit](https://developers.ripple.com/blog/2017/rippled-0.50.3.html), in which `NoRipple` flags were being bypassed by using offers. Ripple requires upgrading to `rippled` version 0.60.2 immediately. There are no new features in the 0.60.2 release. **Note**: This does not affect XRP transactions.
Ripple will be following up with a postmortem, explaining the previosuly patched exploit, the timeline of events and the actions taken in more detail at a later date.
## Action Required
**If you operate a rippled server**, then you must upgrade to 0.60.2 immediately.
**If you are an individual user**, then you should have the `NoRipple` flag enabled by default and set the trust line limit to zero on gateways that you do not trust.
**If you are an individual user**, and you do not have the `NoRipple` flag enabled, and you discover a negative balance owed to an unknown account, then you should [freeze](https://ripple.com/build/freeze/#individual-freeze) that individual trust line.
## Impact of Not Upgrading
**If you operate a rippled server**, but do not upgrade to `rippled` version 0.60.2, then your server may lose sync with Ripple operated validators more frequently.
**If you operate a rippled validating server**, but do not upgrade to `rippled` version 0.60.2, which prevents `NoRipple` flags from being bypassed by using offers, then your server will validate some transactions in a payment path that bypass the blocking effect of the `NoRipple` flag using offers.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The sha256 for the RPM is: 3dc7412bda8986188164f0ff70ff80c351b17521e6943a876d5d3268fa07289d
The sha256 for the source RPM is: f189ba1a8ae2201da47008ff50d027dcf719c7001c9b350b6759db279cbb48c8
For other platforms, please [compile version 0.60.2 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
commit 7cd4d7889779e6418270c8af89386194efbef24b
Author: seelabs <scott.determan@yahoo.com>
Date: Thu Mar 30 14:25:41 2017 -0400
Set version to 0.60.2
## Bug Fixes
Prevent the ability to bypass `NoRipple` flags using offers [(#7cd4d78)](https://github.com/ripple/rippled/commit/4ff40d4954dfaa237c8b708c2126cb39566776da)
## Network Update
The Ripple technical operations team plans to deploy `rippled` version 0.60.2 to all `rippled` servers under its operational control, including private clusters, starting at 2:00 PM PDT on Thursday, 2017-03-30. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: support@ripple.com
* [XRP Chat](http://www.xrpchat.com/)

46
content/blog/2017/rippled-0.60.3.md Normal file
View File

@@ -0,0 +1,46 @@
# rippled version 0.60.3
The `rippled` team has released `rippled` version 0.60.3, which helps to increase the stability of the overlay network under increased load. Ripple recommends server operators upgrade to `rippled` version 0.60.3 immediately. There are no new features in the 0.60.3 release.
## Action Recommended
**If you operate a rippled server and are experiencing connection instability or your server has difficulty maintaining sync with the Ripple network during periods of increased load**, then you should upgrade to `rippled` version 0.60.3 immediately.
## Impact of Not Upgrading
**If you operate a rippled server**, but don’t upgrade to `rippled` version 0.60.3, then your server may experience dropped connections to other servers more frequently.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The sha256 for the RPM is: 3e9c8b421ea0ae6da7ae65524be60408f32ef2bd0bcfea1e1c9fb54eec5fc809
The sha256 for the source RPM is: 9848185e35a21ef41fcea334f8ad224c49e243f64b38dd9311ab898b97ab6c0a
For other platforms, please [compile version 0.60.3 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
commit 208028a1420cc187a6b5b9e97846e8cafd54f39f
Author: Nik Bougalis <nikb@bougalis.net>
Date: Tue May 9 13:37:49 2017 -0700
Set version to 0.60.3
## Change Log
Server overlay improvements [(#2110)](https://github.com/ripple/rippled/pull/2110)
## Network Update
The Ripple technical operations team plans to deploy `rippled` version 0.60.3 to all `rippled` servers under its operational control, including private clusters and hubs, starting at 4:00 PM PDT on Thursday, 2017-05-11. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: support@ripple.com
* [XRP Chat](http://www.xrpchat.com/)

121
content/blog/2017/rippled-0.70.0.md Normal file
View File

@@ -0,0 +1,121 @@
# rippled Version 0.70.0
Ripple has released `rippled` version 0.70.0, which introduces several enhancements that improve the reliability, scalability and security of the Ripple Consensus Ledger. Ripple recommends that all `rippled` server operators upgrade to version 0.70.0 by Thursday, 2017-06-29, for service continuity.
Highlights of this release include:
* The [**FlowCross** Amendment](https://ripple.com/build/amendments/#flowcross), which streamlines offer crossing and autobrigding logic by leveraging the new “Flow” payment engine in `rippled`.
* The [**EnforceInvariants** Amendment](https://ripple.com/build/amendments/#enforceinvariants), which safeguards the integrity of RCL by introducing code that executes after every transaction and ensures that the execution did not violate key protocol rules.
* [**fix1373**](https://ripple.com/build/amendments/#fix1373), which addresses an issue that would cause payments with certain path specifications to not be properly parsed.
Ripple expects the **EnforceInvariants** and **fix1373** Amendments to be enabled on Thursday, 2017-06-29. The **FlowCross** Amendment will be enabled on a future date (TBA).
## Operational Note
The algorithm that determines how many threads `rippled` uses has been changed with this release. The new logic creates more threads, allowing the server to better leverage multi-core processing units. As a result of the increase in thread count, operators may find that their `rippled` instances may now utilize more memory than in the past.
## Action Required
**If you operate a `rippled` server**, then you should upgrade to version 0.70.0 by Thursday, 2017-06-29, for service continuity.
## Impact of Not Upgrading
If you operate a `rippled` server but do not upgrade to version 0.70.0 by Thursday, 2017-06-29, when **EnforceInvariants** and **fix1373** are expected to be activated via Amendment, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server:
* Cannot determine the validity of a ledger
* Cannot submit or process transactions
* Does not participate in the consensus process
* Does not vote on future amendments
* Could rely on potentially invalid data
If the **EnforceInvariants** and **fix1373** Amendments do not get approved, then your server will not become amendment blocked and should continue to operate.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The sha256 for the rpm is: 5a617bce531f39c044de535b6bda2a59371829dfc1079b67876b68c9a9748834
The sha256 for the source rpm is: c51212ae374f69ddc10f967409a750834f06195cb384b2af04e4fa0c3fb81a24
For other platforms, please [compile version 0.70.0 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
commit 7b0d48281049c3fec7fafcb7ce5cea045367ae1f
Author: Nik Bougalis <nikb@bougalis.net>
Date: Thu Jun 15 07:34:17 2017 -0700
Set version to 0.70.0
## Network Update
The Ripple operations team plans to deploy version 0.70.0 to all `rippled` servers under its operational control, including private clusters, starting at 2:00 PM PST on Thursday, 2017-06-15. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected.
At that time, `rippled` validators under Ripple’s operational control will begin voting for the **EnforceInvariants** and **fix1737** Amendments.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: <support@ripple.com>
* [XRP Chat](http://www.xrpchat.com/)
## Full Release Notes
### FlowCross
Currently, the offer crossing code in `rippled` is independent of the payment flow code in `rippled`. The introduction of the **FlowCross** Amendment ensures that the same logic that drives payments also drives offer crossing. This change streamlines the code base, improves test coverage and is expected to result in some marginal performance benefits in offer crossing. For more information, see [FlowCross](https://ripple.com/build/amendments/#flowcross).
### EnforceInvariants
The introduction of the **EnforceInvariants** Amendment supplements existing safeguards of RCL integrity. Once the amendment activates, the servers will execute specialized code to check key system invariants after the execution of each transaction. If a transaction fails any of the checks, it will be considered as invalid. For more information, see [EnforceInvariants](https://ripple.com/build/amendments/#enforceinvariants).
### fix1373 Amendment
Version 0.70.0 also introduces the fix1373 Amendment to fix a minor bug in pathfinding that causes strand creation to fail. Specifically, the issue was related to paths that contain path elements where all the path elements types are set (account, currency and issuer). The fix1373 Amendment corrects the issue that caused some strand creation to fail. For more information, see [fix1373](https://ripple.com/build/amendments/#fix1373).
These features underline Ripple’s continued support to improving RCL by making it more stable, secure and efficient for settlement of global payments.
## Upcoming Features
We do not have an update on the [previously announced](https://developers.ripple.com/blog/2016/rippled-0.33.0.html) changes to the hash tree structure that `rippled` uses to represent a ledger, called [SHAMapV2](https://ripple.com/build/amendments/#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](https://ripple.com/build/rippled-setup/#updating-rippled) on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds).
## 0.70.0 Change Log
* Implement and test invariant checks for transactions [(#2054)](https://github.com/ripple/rippled/pull/2054)
* TxQ: Functionality to dump all queued transactions [(#2020)](https://github.com/ripple/rippled/pull/2020)
* Consensus refactor for simulation/cleanup [(#2040)](https://github.com/ripple/rippled/pull/2040)
* Payment flow() code should support offer crossing [(#1884)](https://github.com/ripple/rippled/pull/1884)
* Make Config init extensible via lambda [(#1993)](https://github.com/ripple/rippled/pull/1993)
* Improve Consensus Documentation [(#2064)](https://github.com/ripple/rippled/pull/2064)
* Refactor Dependencies & Unit Test Consensus [(#1941)](https://github.com/ripple/rippled/pull/1941)
* Feature RPC test [(#1988)](https://github.com/ripple/rippled/pull/1988)
* Add unit Tests for handlers/TxHistory.cpp [(#2062)](https://github.com/ripple/rippled/pull/2062)
* Add unit tests for handlers/AccountCurrenciesHandler.cpp [(#2085)](https://github.com/ripple/rippled/pull/2085)
* Add unit test for handlers/Peers.cpp [(#2060)](https://github.com/ripple/rippled/pull/2060)
* Improve logging for Transaction affects no accounts warning [(#2043)](https://github.com/ripple/rippled/pull/2043)
* Increase logging in PeerImpl fail [(#2043)](https://github.com/ripple/rippled/pull/2043)
* Allow filtering of ledger objects by type in RPC [(#2066)](https://github.com/ripple/rippled/pull/2066)
* Cleanup, refactor, and improve GetMissingNodes [(#1979)](https://github.com/ripple/rippled/pull/1979)
* Add helper to modify Env configs [(#2003)](https://github.com/ripple/rippled/pull/2003)
* Add timer start param to Application [(#2024)](https://github.com/ripple/rippled/pull/2024)
* Improve log warnings [(#2043)](https://github.com/ripple/rippled/pull/2043)
* Prevent low likelihood Database job queue crash [(#2052)](https://github.com/ripple/rippled/pull/2052)
* Remove ledger and manifest Python tools [(#2057)](https://github.com/ripple/rippled/pull/2057)
## Bug Fixes
* Fix displayed warning when generating brain wallets [(#2121)](https://github.com/ripple/rippled/pull/2121)
* Cmake build does not append '+DEBUG' to the version info for non-unity builds [(#1264)](https://github.com/ripple/rippled/pull/1264)
* Crossing tiny offers can misbehave on RCL [(#1884)](https://github.com/ripple/rippled/pull/1884)
* asfRequireAuth flag not always obeyed [(#2092)](https://github.com/ripple/rippled/pull/2092)
* Strand creating is incorrectly accepting invalid paths (No ticket)
* JobQueue occasionally crashes on shutdown [(#2025)](https://github.com/ripple/rippled/pull/2025)
* Prevent consensus from relaying/retrying rejected pseudo-transactions [(#2104)](https://github.com/ripple/rippled/pull/2104)
* Improve pseudo-transaction handling [(#2104)](https://github.com/ripple/rippled/pull/2104)

56
content/blog/2017/rippled-0.70.1.md Normal file
View File

@@ -0,0 +1,56 @@
# rippled version 0.70.1
**UPDATE 7-12-2017:** This announcement now contains corrected SHA-256 values for the `RPM` and source `RPM`.
The `rippled` team has released `rippled` version 0.70.1, which corrects a technical flaw in the newly [refactored](https://github.com/ripple/rippled/commit/00c60d408a887d8a986db81afbb5ead121e8310c#diff-dab2766c14d0ef8e760dc5e353fa7b9dR1389) consensus code that could, in rare cases, cause a node to get stuck in consensus due to stale votes from a peer. **Ripple requires upgrading to `rippled` version 0.70.1 immediately.**
There are no new features in the 0.70.1 release.
## Action Required
**If you operate a `rippled` server, then you should upgrade to 0.70.1 immediately.**
## Impact of Not Upgrading
* If you operate a `rippled` validator server, but do not upgrade to `rippled` version 0.70.1, then your `rippled` validator server could experience increased loss of synchronization with the network.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The SHA-256 for the `RPM` is: `23c8ec08d1ca8c8ce6c0602617c7e41b7f2fd249a1417a79a286a3faa5be08eb`
The SHA-256 for the source `RPM` is: `3522546989024e783cfa933218a28ee878dcc3f334749e7456cb04a9cd07d8fc`
For other platforms, please [compile version 0.70.1 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
commit 3bfd9de6779994e5bbbba864791429e2f7360947
Author: Nik Bougalis <nikb@bougalis.net>
Date: Wed Jun 28 07:15:07 2017 -0700
Set version to 0.70.1
## 0.70.1 Change Log
* Allow compiling against OpenSSL 1.1.0, which allows compiling under the latest version of Fedora. [(#2151)](https://github.com/ripple/rippled/pull/2151)
## Bug Fixes
* Log invariant check messages at "fatal" level [(#2154)](https://github.com/ripple/rippled/pull/2154)
* Fix the consensus code to update all disputed transactions after a node changes a position [(#2156)](https://github.com/ripple/rippled/pull/2156)
## Network Update
The Ripple technical operations team deployed `rippled` version 0.70.1 to all `rippled` servers under its operational control, including private clusters, on Sunday, 2017-07-09.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: support@ripple.com
* [XRP Chat](http://www.xrpchat.com/)

51
content/blog/2017/rippled-0.70.2.md Normal file
View File

@@ -0,0 +1,51 @@
# rippled version 0.70.2
The `rippled` team has released `rippled` version 0.70.2, which corrects an emergent behavior that resulted in high transaction costs and fewer transactions in validated ledgers over the past few days. The problematic behavior involved large numbers of transactions being stuck in different `rippled` instances' open ledgers without being consistently relayed to validators. The large number of "stuck" transactions filled the transaction queue and caused a dramatic increase in the open ledger cost.
There are no new features in the 0.70.2 release.
## Action Required
**If you operate a `rippled` server, then you should upgrade to 0.70.2 immediately.**
## Impact of Not Upgrading
If you operate a `rippled` server, but do not upgrade to `rippled` version 0.70.2, then your `rippled` server could see inconsistent transaction relaying as well as transactions getting stuck in the open ledger without being passed on to validators. In this case, your server may report very high transaction costs and brimming transaction queues.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The SHA-256 for the RPM is: b41f3d75bb0fcf67dcd3cd14fbf1a7029ce28442b6dcd19fff7df330c35ee3e7
The SHA-256 for the source RPM is: 8cae27e639ef57987238c7800127288857c6caa61d15342faf781749ce9ee7ff
For other platforms, please [compile version 0.70.2 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
```
commit cd2d52acdcb4c58cbb5ca3f9a025a826c65f99aa
Author: Edward Hennis <ed@ripple.com>
Date: Tue Sep 19 14:26:06 2017 -0400
Set version to 0.70.2
```
## 0.70.2 Change Log
## Bug Fixes
* Recover old open ledger transactions to the queue [(#2231)](https://github.com/ripple/rippled/pull/2231)
## Network Update
The Ripple operations team plans to deploy version 0.70.2 to all `rippled` servers under its operational control, including private clusters, starting at 4:00 PM PT on Thursday, 2017-09-21. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: <support@ripple.com>
* [XRP Chat](http://www.xrpchat.com/)

97
content/blog/2017/rippled-0.80.0.md Normal file
View File

@@ -0,0 +1,97 @@
# rippled Version 0.80.0
Ripple has released `rippled` version 0.80.0, which introduces several enhancements that improve the reliability, scalability and security of the XRP Ledger. Ripple recommends that all `rippled` server operators upgrade to version 0.80.0 by Tuesday, 2017-11-07, for service continuity.
Highlights of this release include:
* The **SortedDirectories** amendment sorts the entries in [`DirectoryNode` ledger objects](https://ripple.com/build/ledger-format/#directorynode). It also corrects a technical flaw that could, in some edge cases, prevent an empty intermediate page from being deleted.
Ripple expects the **SortedDirectories** amendment to be enabled on Tuesday, 2017-11-07.
## Action Required
**If you operate a `rippled` server**, then you should upgrade to version 0.80.0 by Tuesday, 2017-11-07, for service continuity.
## Impact of Not Upgrading
If you operate a `rippled` server but do not upgrade to version 0.80.0 by Tuesday, 2017-11-07, when the **SortedDirectories** Amendment is expected to be activated, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server:
* Cannot determine the validity of a ledger
* Cannot submit or process transactions
* Does not participate in the consensus process
* Does not vote on future amendments
* Could rely on potentially invalid data
If the **SortedDirectories** amendment does not get approved, then your `rippled` server will not become amendment blocked and should continue to operate.
## Action Recommended
**If you operate a `rippled` server that uses RocksDB as its data store**, then we recommend removing the RocksDB `file_size_mb` parameter from your `rippled.cfg` config file.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The sha256 for the rpm is: 0f67e8fdc9c555921534b6944ca418df007cee0705ab9e2fc5423963848b2935
The sha256 for the source rpm is: 9c6f5074e1ec3ce6ced27c0da243bb7ed19a32a8bedf2d68809ec37845f42c1b
For other platforms, please [compile version 0.80.0 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
```
commit cafe18c59279e7de447f25a0e00d0562d6441c7a
Author: Nik Bougalis <nikb@bougalis.net>
Date: Thu Oct 19 14:37:27 2017 -0700
Set version to 0.80.0
```
## Network Update
The Ripple operations team plans to deploy version 0.80.0 to all `rippled` servers under its operational control, including private clusters, starting at 2:00 PM PST on Tuesday, 2017-10-24. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected.
At that time, `rippled` validators under Ripple’s operational control will begin voting for the **SortedDirectories** amendment.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: <support@ripple.com>
* [XRP Chat](http://www.xrpchat.com/)
## Full Release Notes
### SortedDirectories
The **SortedDirectories** amendment addresses two distinct issues: First, it corrects a technical flaw that could, in some edge cases, prevent an empty intermediate page from being deleted. Second, it sorts directory entries within a page (other than order book page entries, which remain strictly FIFO). This makes insert operations deterministic, instead of pseudo-random and reliant on temporal ordering. Lastly, it removes the ability to perform a "soft delete" where the page number of the item to delete need not be known if the item is in the first 20 pages, and enforces a maximum limit to the number of pages that a directory can span.
## Upcoming Features
The [previously announced](https://developers.ripple.com/blog/2017/rippled-0.70.0.html) FlowCross Amendment will be enabled on a future date (TBA).
We do not have an update on the [previously announced](https://developers.ripple.com/blog/2016/rippled-0.33.0.html) changes to the hash tree structure that `rippled` uses to represent a ledger, called [SHAMapV2](https://ripple.com/build/amendments/#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](https://ripple.com/build/rippled-setup/#updating-rippled) on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds).
## 0.80.0 Change Log
* Improve directory insertion and deletion [(#2165)](https://github.com/ripple/rippled/pull/2165)
* Move consensus thread safety logic from the generic implementation in Consensus into the RCL adapted version RCLConsensus [(#2106)](https://github.com/ripple/rippled/pull/2106)
* Refactor Validations class into a generic version that can be adapted [(#2084)](https://github.com/ripple/rippled/pull/2084)
* Make minimum quorum Byzantine fault tolerant [(#2093)](https://github.com/ripple/rippled/pull/2093)
* Make amendment blocked state thread-safe and simplify a constructor [(#2027)](https://github.com/ripple/rippled/pull/2207/commits/be1f734845ac763ce51d61507c9ba6cf18fc3cfb)
* Use ledger hash to break ties [(#2169)](https://github.com/ripple/rippled/pull/2169)
* Refactor RangeSet [(#2113)](https://github.com/ripple/rippled/pull/2113)
* Improvements to validation quorum calculation
## Bug Fixes
* Check and modify amendment blocked status with each new ledger [(#2137)](https://github.com/ripple/rippled/pull/2137)
* Track escrow in recipient's owner directory [(#2212)](https://github.com/ripple/rippled/pull/2212)
* Ensure consensus close times generate identical ledgers [(#2221)](https://github.com/ripple/rippled/pull/2221)
* Recover open ledger transactions to the queue [(#2232)](https://github.com/ripple/rippled/pull/2232/commits/62127d725d801641bfaa61dee7d88c95e48820c5)

71
content/blog/2017/rippled-0.80.2.md Normal file
View File

@@ -0,0 +1,71 @@
# rippled Version 0.80.2
Ripple has released `rippled` version 0.80.2, which improves the transaction dispatch logic of `rippled`, allows for more transactions to be in flight at any one time and reduces the overall resource usage of `rippled`. The improved transaction dispatch logic ensures that a transaction is dispatched at most once every 10 seconds, even if it received from multiple peers during that interval.
The fix should also improve load accounting on peer links, reducing the number of extraneous server-server connection drops caused by redundant transaction dispatching.
Ripple strongly recommends upgrading to `rippled` version 0.80.2 immediately.
## Action Required
If you operate a `rippled` server, then you should upgrade to 0.80.2 immediately.
## Impact of Not Upgrading
* **If you operate a `rippled` server**, but do not upgrade to rippled version 0.80.2, then your `rippled` server will use more resources than necessary and may periodically drop transactions and fall out of sync with the network.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The SHA-256 for the RPM is: `a0f431a55a241770d7496b240e4d2c638f2cadd4126ee621c5ed980b8174223c`
The SHA-256 for the source RPM is: `d25bda2c384c67e48fe6c29250c07039d33c6ed5d280ad19fc246469213fe251`
For other platforms, please [compile version 0.80.2 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
```
commit d2fc4e3569d79d3cade78533f673f642a8d26845
Author: Nikolaos D. Bougalis <nikb@bougalis.net>
Date: Thu Dec 14 15:30:20 2017 -0800
Set version to 0.80.2
```
## Network Update
The Ripple technical operations team will deploy `rippled` version 0.80.2 to all production `rippled` servers under its operational control, on Friday, 12/15/2017.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: <support@ripple.com>
* [XRP Chat](http://www.xrpchat.com/)
## 0.80.2 Change Log
* Tune for higher transaction rate processing [(#2294)](https://github.com/ripple/rippled/pull/2294)
* Control transaction dispatch rate [(#2297)](https://github.com/ripple/rippled/pull/2297)
## 0.80.1 Change Log
The [previously-released `rippled` version 0.80.1](https://github.com/ripple/rippled/releases/tag/0.80.1) also included the following fixes and improvements:
**New and Updated Features**
- Allow including validator manifests in published list ([#2278](https://github.com/ripple/rippled/issues/2278))
- Add validator list RPC commands ([#2242](https://github.com/ripple/rippled/issues/2242))
- Support [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) when querying published list sites and use Windows system root certificates ([#2275](https://github.com/ripple/rippled/issues/2275))
- Grow TxQ expected size quickly, shrink slowly ([#2235](https://github.com/ripple/rippled/issues/2235))
**Bug Fixes**
- Make consensus quorum unreachable if validator list expires ([#2240](https://github.com/ripple/rippled/issues/2240))
- Properly use ledger hash to break ties when determing working ledger for consensus ([#2257](https://github.com/ripple/rippled/issues/2257))
- Explictly use std::deque for missing node handler in SHAMap code ([#2252](https://github.com/ripple/rippled/issues/2252))
- Verify validator token manifest matches private key ([#2268](https://github.com/ripple/rippled/issues/2268))

28
content/blog/2017/ticksize-3days.md Normal file
View File

@@ -0,0 +1,28 @@
# TickSize Will Be Available in 3 Days
This notice is for all validator operators, and may be useful for gateways that intend to use tick sizes.
A majority of trusted validators [voted to enable the TickSize amendment](https://developers.ripple.com/blog/2017/ticksize-voting.html), which is scheduled to become active on the protocol on Tuesday, 2017-02-21. The amendment changes the way RCL offers are ranked in order books, so that currency issuers can configure how many significant digits are taken into account when ranking offers by exchange rate.
For a detailed look into the TickSize feature, see the [original TickSize announcement](https://developers.ripple.com/blog/2017/ticksize-voting.html).
## Action Required
1. **If you operate a `rippled` server and accept secure client connections**, then you should upgrade to `rippled` version 0.50.2 immediately. If you operate a `rippled` server but do not accept secure client connections, then you should upgrade to version 0.50.0 by Tuesday, 2017-02-21, for service continuity.
2. **If you are a gateway issuer**, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to determine what tick size is appropriate for your issuing asset.
3. **If you are a market maker** and have algorithmic trading bots, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to update your trading system to check the tick size for a given issuer.
4. **If you have backend software**, which constructs and submits transactions related to the issuing of assets on the Ripple network, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to adapt it for correct usage.
## Learn More
For more information, see the following articles in the [Ripple Developer Portal](https://ripple.com/build/):
- [Offer Preference](https://ripple.com/build/transactions/#offer-preference) - How offers are ranked with and without TickSize.
- [AccountSet transaction](https://ripple.com/build/transactions/#accountset) - How to configure a TickSize.
To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: <https://groups.google.com/forum/#!forum/ripple-server>

28
content/blog/2017/ticksize-7days.md Normal file
View File

@@ -0,0 +1,28 @@
# TickSize Will Be Available in 7 Days
This notice is for all validator operators, and may be useful for gateways that intend to use tick sizes.
A majority of trusted validators [voted to enable the TickSize amendment](https://developers.ripple.com/blog/2017/ticksize-voting.html), which is scheduled to become active on the protocol on Tuesday, 2017-02-21. The amendment changes the way RCL offers are ranked in order books, so that currency issuers can configure how many significant digits are taken into account when ranking offers by exchange rate.
For a detailed look into the TickSize feature, see the [original TickSize announcement](https://developers.ripple.com/blog/2017/ticksize-voting.html).
## Action Required
1. **If you operate a `rippled` server and accept secure client connections**, then you should upgrade to `rippled` version 0.50.2 immediately. If you operate a `rippled` server but do not accept secure client connections, then you should upgrade to version 0.50.0 by Tuesday, 2017-02-21, for service continuity.
2. **If you are a gateway issuer**, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to determine what tick size is appropriate for your issuing asset.
3. **If you are a market maker** and have algorithmic trading bots, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to update your trading system to check the tick size for a given issuer.
4. **If you have backend software**, which constructs and submits transactions related to the issuing of assets on the Ripple network, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to adapt it for correct usage.
## Learn More
For more information, see the following articles in the [Ripple Developer Portal](https://ripple.com/build/):
- [Offer Preference](https://ripple.com/build/transactions/#offer-preference) - How offers are ranked with and without TickSize.
- [AccountSet transaction](https://ripple.com/build/transactions/#accountset) - How to configure a TickSize.
To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: <https://groups.google.com/forum/#!forum/ripple-server>

37
content/blog/2017/ticksize-available.md Normal file
View File

@@ -0,0 +1,37 @@
# TickSize is Now Available
As [predicted previously](https://developers.ripple.com/blog/2017/ticksize-3days.html), the TickSize amendment became available on the Ripple Consensus Ledger yesterday afternoon (PST) in ledger 27841793 ([2017-02-21T23:02:52Z](https://xrpcharts.ripple.com/#/transactions/A12430E470BE5C846759EAE3C442FF03374D5D73ECE5815CF4906894B769565E)).
The amendment changes the way RCL offers are ranked in order books, so that currency issuers can configure how many significant digits are taken into account when ranking offers by exchange rate.
## Action Required
1. **If you operate a `rippled` server and accept secure client connections**, then you should upgrade to version 0.50.2 immediately. If you operate a `rippled` server but do not accept secure client connections, then you should upgrade to version 0.50.0 or higher immediately.
2. **If you issue currency on the RCL**, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to determine what tick size is appropriate for your issuing asset. If you take no action, your issued currency can still be traded using the default tick size of 15 significant digits, but Ripple strongly recommends setting a tick size between four and eight digits to provide faster price discovery and to decrease churn in the RCL order books for your currency. Ripple also recommends publishing your tick size policy to users.
3. **If you trade on the RCL** and have algorithmic trading bots, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to update your trading system to check the tick size for a given issuer.
4. **If you have backend software** which constructs and submits transactions related to the issuing of assets on the Ripple Consensus Ledger, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to adapt your software for correct usage.
## Impact of Not Upgrading
If you operate a `rippled` server but don’t upgrade to version 0.50.0 or higher, immediately, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server:
* Cannot determine the validity of a ledger
* Cannot submit or process transactions
* Does not participate in the consensus process
* Does not vote on future amendments
## Learn More
For more information, see the following documentation:
- [TickSize Voting Announcement](https://developers.ripple.com/blog/2017/ticksize-voting.html) - Introduction to TickSize and recommendations for how to use it.
- [Offer Preference](https://ripple.com/build/transactions/#offer-preference) - How offers are ranked with and without TickSize.
- [AccountSet transaction](https://ripple.com/build/transactions/#accountset) - How to configure a TickSize.
To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: <https://groups.google.com/forum/#!forum/ripple-server>

114
content/blog/2017/ticksize-voting.md Normal file
View File

@@ -0,0 +1,114 @@
# TickSize Amendment Open for Voting
Previously [introduced](https://developers.ripple.com/blog/2017/rippled-0.50.0.html) in `rippled` version 0.50.0, the [TickSize amendment](https://ripple.com/build/amendments/#ticksize) to the Ripple Consensus Ledger is now open for voting. The amendment changes the way offers are ranked in the RCL's order books, so that currency issuers can configure how many significant digits are taken into account when ranking offers by exchange rate.
Ripple expects several benefits to result from adoption of the TickSize amendment, including faster price discovery and deeper liquidity, as well as a reduction in transaction spam and ledger churn on the RCL.
The introduction of TickSize demonstrates Ripple’s continued commitment to supporting the RCL as a unique distributed ledger technology for settlement of global payments.
## Action Required
1. **If you operate a `rippled` server and accept secure client connections**, then you should upgrade to 0.50.2 immediately. If you operate a rippled server, but do not accept secure client connections then you should upgrade to version 0.50.0 by Tuesday, 2017-02-21, for service continuity.
2. **If you run a gateway that issues currency on the RCL**, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to determine what tick size is appropriate for your issuing asset.
3. **If you trade on the RCL** and have algorithmic trading bots, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to update your trading system to check the tick size for a given issuer.
4. **If you have backend software**, which constructs and submits transactions related to the issuing of assets on the Ripple network, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to adapt it for correct usage.
## Impact of Not Upgrading
If you operate a `rippled` server but don’t upgrade to version 0.50.0 (or higher) by Tuesday, 2017-02-21, when **TickSize** is expected to be activated via Amendment, then your server will become amendment blocked, meaning that your server:
* Cannot determine the validity of a ledger
* Cannot submit or process transactions
* Does not participate in the consensus process
* Does not vote on future amendments
* Could rely on potentially invalid data
If the **TickSize** amendment is vetoed or does not pass, then your server will not become amendment blocked and should continue to operate.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: <support@ripple.com>
* [XRP Chat](http://www.xrpchat.com/)
## TickSize Amendment Overview
Ripple has added a new feature (called “TickSize”) to the Ripple Consensus Ledger (RCL). This feature is expected to significantly improve the performance of currency markets on RCL. Gateways (those who issue assets on the RCL) and currency traders will need to be aware of these changes as they may affect their operations.
Currently, the RCL tracks offers to trade one currency for another with fifteen digits of price precision. This high precision has been shown to cause some poor behavior in these currency markets resulting in transaction congestion and poor liquidity.
The tick size change permits the price granularity to be selectively reduced. Gateways must to enable this feature for their assets. Those who trade on RCL’s internal markets must be aware of the change in behavior.
### The problem TickSize addresses
The Ripple Consensus Ledger maintains internal order books between pairs of assets. These internal order books are used to permit cross-currency payments and to settle offers to trade assets against each other. Internally, the RCL tracks an offer’s price (that is, the rate at which the exchange takes place) with 15 digits of precision. Offers with a better price are consumed first, and offers at the same price are consumed in the order in which they were placed.
Because the precision is so high, an offer can be placed at a microscopically better price and that offer will get priority over all existing offers at a lower price. This means that there is effectively no seniority advantage to leaving an offer on the books or stacking offers near the current exchange rate.
A significant fraction of the RCL’s transactions are rapid sequences of the creation and deletion of offers. When a trader operating through a programmatic trading platform believes an existing price is too low, the trader places an offer at a higher price. But they will not make the price too high because that reduces their margin. Other traders react by topping their offer. This acts like an auction.
With RCL’s microscopic tick sizes, this acts like an auction in which you can top the existing bid by a microscopic amount. As you might expect, this results in a lot of bids. Worse, it also results in slow price discovery: while these trading bots are each topping the other by a microscopic amount, the order book price remains below the true price until the order placement stabilizes. In practice, order placement never stabilizes and the flux is constant.
### The TickSize solution
The TickSize feature permits assets issued on the RCL to configure their tick sizes. With a tick size of three, offer prices are tracked with three digits of precision. That would mean that a trader who wanted priority over an offer to charge 1.07 dollars per Euro would have to charge no more than 1.06 dollars per Euro or a trader who wanted priority over an offer to sell bitcoins at $915 each would have to charge $914 each or less.
This immediately makes price discovery much faster. Without the tick size, you might see a long string of offers with prices gradually going down from 1.08 to 1.07. And a payment processed at that time would get a rate worse than the fair rate.
The TickSize feature also protects the time priority of larger orders by securing their position at the front of what may become a large queue at a specific price point; this effectively prevents front running by microscopically better price improvements. When volatility of a market becomes low versus the tick size, the economic impact of this can be significant. To the same effect, enforcing a TickSize also gives traders a larger theoretical edge versus fair value of the same asset trading on other exchanges.
The most important long run impact of a fixed TickSize is to encourage traders to stack orders at several depths in the market in advance, with the hope of being filled when the market moves; this incentivizes traders to take inventory risk and therefore increases displayed liquidity in order books.
In addition, if there are very small changes in the fair exchange rate, as there always are, these won’t require restructuring of the order book. Until the price variance exceeds the price increment, there is no reason for an offer to change its price and removing an existing offer would mean losing its seniority, giving priority to others who placed their offers first.
### The mechanics of TickSize
The TickSize amendment adds an account property also called “TickSize”. An account can set its tick size by sending an “AccountSet” transaction with a “TickSize” property. The value of the “TickSize” property should be a decimal value between 3 and 10. To clear the tick size, set the “TickSize” to zero. The configured size applies to all assets issued by the account.
To determine an account’s configured tick size, you can use any method to get the account root (such as “account_info”). If the account has a configured tick size, there will be a “TickSize” attribute in the response.
XRP does not have a tick size. Until configured by their issuers, issued assets use the default effective tick size of 15. If an offer is placed between two assets that do not have a tick size, no tick size is enforced. If an offer is placed between two assets that have a tick size, the smaller tick size (fewer digits of precision) controls.
When an attempt to create an offer is made and there is a tick size, the tick size is enforced when the offer is placed into the order book. If the offer is a buy, the amount to buy is unchanged. If the offer is a sell, the amount to sell is unchanged. The tick size is enforced by adjusting the unlocked size of the offer in the offer placer’s favor towards the nearest tick size in the offer price.
RCL internally tracks an offer’s price as the ratio of the input currency amount to the output currency amount. The price is the ratio of the input to the output or how much currency must be paid to get one unit of currency out. Offers with lower prices from the point of view of the taker are consumed first. The rounding is performed on this price.
So, for example, if the offer at the tip of an order book were one to give 100 USD for 20 CNY, that would be internally tracked as having a price of 0.2 -- the 20 in divided by the 100 out. If the effective tick size for this order book was 4, this offer could be topped by an offer with a price of 0.1999 or less (the largest number less than 0.2 using four significant digits). So an offer to give 100.05 USD for 20 Yuan (or one to give 100 USD for 19.99 Yuan) would be needed to take the tip of the order book from the existing offer.
The tick size is expressed as the number of digits of precision kept in the price on the books. For example, if the tick size is four, the next tick after 102.3 is 102.4, the next tick after 1.023 is 1.024, and the next tick size after 10,230 is 10,240.
It is important to remember that it is the price (the ratio of input to output) that is rounded. Offers can still be placed for arbitrarily large or small amounts of currency and payments can still consume arbitrarily small pieces out of offers.
### TickSize for traders
Traders, particularly algorithmic traders, will need to be aware of how the tick size feature affects the behavior of currency markets on the RCL. We expect that gateways that opt to enable tick sizes on their assets will provide traders with reasonable notice, but traders will need to be on the lookout for those notices until the issuer of every asset they care about has published their intended policy.
Traders will want to adjust their strategies to leave their offers on the books if the pricing is off by less than the tick size. They will want to avoid trying to top another offer by less than the tick size as this will not put their order at the tip of the order book.
New strategies involving stacking offers near the current price should be possible. If the price moves in that direction, these offers will have a seniority advantage over newly-placed offers.
### TickSize for gateways
Gateways, those who issue assets on the RCL, will need to draft and publish a tick size policy. Even if a gateway opts not to set a tick size, they should still announce this intention and the amount of notice they plan to give should they ever decide to set a tick size. This will help eliminate uncertainty.
Ripple recommends that gateways set reasonable tick sizes in pretty much all cases. This will provide better price discovery for their assets as well as improving the RCL's performance for everyone by reducing transaction spam.
Tick sizes of between four and eight digits are reasonable. Four digits will provide rapid price discovery, but poor granularity. Seven digits will provide reasonable price discovery while preserving high granularity. If you do not select a tick size, you effectively have a tick size of 15. In almost all cases, five and six are reasonable, safe choices that should provide a good balance of granularity and rapid price discovery.
## Upcoming Features
The [previously announced](https://developers.ripple.com/blog/2016/rippled-0.40.0.html) Suspended Payments amendment, which introduces new transaction types to the Ripple protocol that will permit users to cryptographically escrow XRP on the RCL, will be re-introduced as an amendment simply called *Escrow*, in the next release scheduled for March.
Also, we expect additional support for [crypto-conditions](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02), which are signature-like structures that can be used with suspended payments to support ILP integration, to be included in the next rippled release scheduled for March.
Lastly, we do not have an update on the [previously announced](https://developers.ripple.com/blog/2016/rippled-0.33.0.html) changes to the hash tree structure that `rippled` uses to represent a ledger, called [SHAMapV2](https://ripple.com/build/amendments/#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).

36
content/blog/2017/trust-line-quality-sendmax.md Normal file
View File

@@ -0,0 +1,36 @@
# Gateway Bulletin: Setting Trust Line Quality with SendMax
## Summary
When you build an automated system to send payments into the Ripple Consensus Ledger (RCL) for your customers, you must make sure that it constructs payments carefully. Malicious actors are constantly trying to find flaws in a system implementation that pays them more money than it should.
Once such flaw was [revealed](https://forum.ripple.com/viewtopic.php?f=1&t=18210) _(dead link)_ recently, related to setting [trust line quality](https://web.archive.org/web/20150422102043/https://wiki.ripple.com/Trust_line_quality), which affects gateways that use a `SendMax` value greater than the amount they deliver. This setup could result in a destination account receiving slightly higher (typically less than 1% higher) than the expected amount from the gateway's account.
Note: This system implementation flaw does not affect XRP balances.
## Action Recommended
The [recommended setup](https://xrpl.org/become-an-xrp-ledger-gateway.html#sending-payments-to-customers) is to use either of the following rules:
* Setting the `SendMax` value equal to the Amount * (1 + transfer rate); or
* Setting the `SendMax` value as low as possible and only leaving space for slippage to buffer the transaction from failing
A malicious user can make trust line quality changes in the ledger between when you prepare a transaction and when it is validated in the ledger. To ensure that these changes cannot cause a transaction to cost you more than you expected, it is vital to set the `SendMax` no higher than the maximum amount you are willing to send.
To reduce the chance of sending a transaction that fails, add the following checks to any transaction that delivers issued currency on a trust line:
* Does the trust line exist?
* Is the trust line’s limit sufficient?
* Are optional incoming balances on this trust line valued at the appropriate ratio?
* Did the user freeze the trust line?
## Learn, Ask Questions, and Discuss
To experiment with the Ripple Consensus Ledger technology without using real money, try out the [Ripple Test Net](https://xrpl.org/xrp-testnet-faucet.html).
### Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* The Ripple Dev Blog: <https://developers.ripple.com/blog/>
* Ripple Technical Services: <support@ripple.com>
* XRP Chat: <http://www.xrpchat.com>