ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-26 14:45:50 +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

33
content/blog/2020/checks-enabled.md Normal file
View File

@@ -0,0 +1,33 @@
# The Checks Amendment is Now Enabled
[As previously announced](https://xrpl.org/blog/2020/checks-expected.html), the Checks amendment [became enabled on the XRP Ledger](https://xrpcharts.ripple.com/#/transactions/D88F2DCDFB10023F9F6CBA8DF34C18E321D655CAC8FDB962387A5DB1540242A6) on 2020-06-18.
<!-- BREAK -->
## Checks Summary
Introduces "Checks" to the XRP Ledger. Checks work similarly to personal paper checks. The sender signs a transaction to create a Check for a specific maximum amount and recipient. Later, the recipient can cash the Check to receive up to the specified amount. The actual movement of money only occurs when the Check is cashed, so cashing the Check may fail depending on the sender's current balance and the available liquidity. If cashing the Check fails, the Check object remains in the ledger so the recipient can try again later.
For more information, see [Checks](https://xrpl.org/checks.html).
## Action Recommended
No action is required at this time. The minimum XRP Ledger server version to remain synced to the network already has support for Checks.
The Checks amendment also enables a minor improvement to the XRP Ledger's [decentralized exchange](https://xrpl.org/decentralized-exchange.html): OfferCreate transactions that failed because their expiration time had already passed when the transaction executed are now assigned the [error code `tecEXPIRED`](https://xrpl.org/tec-codes.html). Previously, such offers were assigned the success code `tesSUCCESS` despite not being executed. Users of the API can use the new status code to more easily recognize when an offer was not executed because it had already expired.
If you are the developer for a library that reads and writes the XRP Ledger's binary format, make sure your library can read and write the new transaction and ledger types introduced by the Checks amendment. Ripple's reference libraries already support Checks, including [`ripple-binary-codec` (since v0.1.13)](https://github.com/ripple/ripple-binary-codec/) and [`ripple-lib` (since v0.19.0)](https://github.com/ripple/ripple-lib/).
If you have an XRP Ledger business, you may also want to read about [Checks](https://xrpl.org/checks.html) to see if your business model could benefit from using this feature.
## Learn, ask questions, and discuss
To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing.
Other resources:
* [XRPScan Amendments Dashboard](https://xrpscan.com/amendments)
* [Xpring Forum](https://forum.xpring.io/)
* [XRP Chat Forum](http://www.xrpchat.com/)

33
content/blog/2020/checks-expected.md Normal file
View File

@@ -0,0 +1,33 @@
# The Checks Amendment is Expected 2020-06-18
The Checks amendment to the XRP Ledger, introduced all the way back in [`rippled` v0.90.0](https://github.com/ripple/rippled/releases/tag/0.90.0), has [gained support from a majority of trusted validators](https://xrpcharts.ripple.com/#/transactions/F2CACEB0680626E8A4DE7EDA02DEC7438E1FB0D7C8736DD327074F85877E6D8E). Currently, it is expected to become enabled on 2020-06-18. As long as the Checks amendment continues to have the support of at least 80% of trusted validators continuously, it will become enabled on the scheduled date.
<!-- BREAK -->
## Checks Summary
Introduces "Checks" to the XRP Ledger. Checks work similarly to personal paper checks. The sender signs a transaction to create a Check for a specific maximum amount and recipient. Later, the recipient can cash the Check to receive up to the specified amount. The actual movement of money only occurs when the Check is cashed, so cashing the Check may fail depending on the sender's current balance and the available liquidity. If cashing the Check fails, the Check object remains in the ledger so the recipient can try again later.
For more information, see [Checks](https://xrpl.org/checks.html).
## Action Recommended
No action is required at this time. The minimum XRP Ledger server version to remain synced to the network already has support for Checks.
If you are the developer for a library that reads and writes the XRP Ledger's binary format, make sure your library can read and write the new transaction and ledger types introduced by the Checks amendment. Ripple's reference libraries already support Checks, including [`ripple-binary-codec` (since v0.1.13)](https://github.com/ripple/ripple-binary-codec/) and [`ripple-lib` (since v0.19.0)](https://github.com/ripple/ripple-lib/).
If you have an XRP Ledger business, you may also want to read about [Checks](https://xrpl.org/checks.html) to see if your business model could benefit from using this feature.
## Learn, ask questions, and discuss
To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing.
Other resources:
* [XRPScan Amendments Dashboard](https://xrpscan.com/amendments)
* [Xpring Forum](https://forum.xpring.io/)
* [XRP Chat Forum](http://www.xrpchat.com/)

38
content/blog/2020/deletableaccounts-enabled.md Normal file
View File

@@ -0,0 +1,38 @@
# DeletableAccounts is Now Enabled
As previously announced, the DeletableAccounts amendment [became enabled on the XRP Ledger](https://livenet.xrpl.org/transactions/47B90519D31E0CB376B5FEE5D9359FA65EEEB2289F1952F2A3EB71D623B945DE) on **2020-05-08**.
<!-- BREAK -->
## DeletableAccounts Summary
Prior to this amendment, every [account in the XRP Ledger](https://xrpl.org/accounts.html) was permanent. With this amendment, accounts can now be deleted at a cost of 5 XRP by sending a new AccountDelete transaction type. This amendment also changes the starting `Sequence` number for new accounts so that it matches the ledger index when they were created instead of starting at 1.
For more details on what to look out for or how to use deletable accounts, see [the previous primer](/blog/2020/get-ready-for-deletable-accounts).
## Adieu, Deleted Accounts
Within minutes of the amendment going live, some XRP Ledger users have already started reclaiming XRP by deleting their excess accounts. A few of the first accounts to be deleted include:
- [r4WQTd2Ck9tVS536U6EBNErBbrToUoVGh8](https://livenet.xrpl.org/transactions/CF61501174E29B3C7A63E65FFCEF4EA882BD22B449490AB453701DCA7EEAF0B3/detailed)
- [r93Fr5Cmf6KAho1GfF9mvNKV97tZsCFKcB](https://livenet.xrpl.org/transactions/2BCD5B4C9CB7DC65C4C620F2767104CF3F35F805B189A414C1E02479788B7FDA/detailed)
- [rpZ74gjYqVGmRQpXYXbsMXXQXJGJaWhgNu](https://livenet.xrpl.org/transactions/9E471809937837E1D7F6DB5542BECFFD2CE4D43E93D6169613333858CB865436/detailed)
We salute these early adopters for cleaning up extra cruft from the ledger.
## Action Recommended
**If you have software that uses the XRP Ledger,** you should be sure your code still works with the changes to make accounts deletable. See [Get Ready for Deletable Accounts](https://xrpl.org/blog/2020/get-ready-for-deletable-accounts.html) for details on starting sequence numbers, deleted accounts' transaction history, and more.
Additionally, **if you operate an XRP Ledger server,** then you should upgrade to **version 1.5.0** as soon as possible. Two amendments new to v1.5.0, `fixQualityUpperBound` and `RequireFullyCanonicalSig`, are currently **open for voting** and could gain supermajority support among trusted validators at any time. After that point, the amendments could become enabled in two weeks, causing any servers not running at least v1.5.0 to become amendment blocked.
## Learn, ask questions, and discuss
To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing.
Other resources:
* [The Xpring Forum](https://forum.xpring.io/)
* [XRP Chat Forum](http://www.xrpchat.com/)

74
content/blog/2020/deletableaccounts-expected.md Normal file
View File

@@ -0,0 +1,74 @@
# DeletableAccounts and Two Other Amendments Expected Soon
Three amendments to the XRP Ledger protocol currently hold support of a majority of trusted validators, and are expected to become enabled on the following dates (in UTC):
- [fixPayChanRecipientOwnerDir is expected](https://xrpcharts.ripple.com/#/transactions/2EBB6EC9C6A070EF665D482C2E725319DEB552D88B079227333A5BE452602C2A) on **2020-05-01**.
- [fixCheckThreading is expected](https://xrpcharts.ripple.com/#/transactions/413007375A2D1B213D477154375A6878AF58360E4190D339C8B43122CA366AA7) also on **2020-05-01**.
- [DeletableAccounts is expected](https://xrpcharts.ripple.com/#/transactions/592E5151BFAE5B544FF4213A4358D341EA6F394ECF738CBC740F555CEC5A6C70) on **2020-05-08**.
<!-- BREAK -->
As long as these amendments continue to have the support of at least 80% of trusted validators continuously, they will become enabled on the scheduled dates. All three amendments were introduced in [`rippled` v1.4.0](https://github.com/ripple/rippled/releases/tag/1.4.0).
## Action Required
- If you operate a `rippled` server, you must upgrade to version 1.4.0 or higher by **2020-05-01**, for service continuity. **Version 1.5.0** is _strongly recommended_.
- The DeletableAccounts amendment changes the starting [sequence numbers](https://xrpl.org/basic-data-types.html#account-sequence) for accounts. If you have automatic processes that send transactions from newly-funded accounts, please check that the change does not break critical processes.
## Note Regarding Payment Channels
The fixPayChanRecipientOwnerDir amendment previously [gained majority support in January.](https://xrpl.org/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-expected.html) However, several trusted validators withdrew support from the amendment because it would cause [breaking changes](https://xrpl.org/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-expected.html#action-required) to the [`account_channels` API method](https://xrpl.org/account_channels.html). Version 1.5.0 of `rippled` contains a fix that makes the `account_channels` API method continue to work without breaking changes. If you use `account_channels`, be sure to upgrade to `rippled` version 1.5.0 to avoid breaking changes to the API.
## Impact of Not Upgrading
If you operate a `rippled` server but don’t upgrade to version 1.4.0 or higher by 2020-05-01, when the fixPayChanRecipientOwnerDir and fixCheckThreading amendments are expected to become enabled, then your server will become [amendment blocked](https://xrpl.org/amendments.html#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 none of the amendments become enabled, then your server will not become amendment blocked and should continue to operate.
For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html).
## DeletableAccounts Summary
The DeletableAccounts amendment makes it possible to delete [XRP Ledger accounts](https://xrpl.org/accounts.html).
If you have accounts on the XRP Ledger, you may be able to reclaim some of the [XRP account reserve](https://xrpl.org/reserves.html) by deleting your accounts after this amendment becomes active. Deleting an account costs 5 XRP and sends the deleted account's remaining XRP to another address. You can send the remaining XRP to another account you own, or even deposit the remaining XRP at a hosted wallet such as an exchange. (When sending to a hosted wallet, be sure to include a [destination tag](https://xrpl.org/source-and-destination-tags.html) or use an [X-address](https://xrpaddress.info/).) Not all accounts can be deleted. For the complete list of requirements, see [Deletion of Accounts](https://xrpl.org/accounts.html#deletion-of-accounts) and the [XRP Community Standards Draft 7](https://github.com/xrp-community/standards-drafts/issues/8).
With this amendment, new accounts start with their `Sequence` numbers equal to the `Sequence` number matching the [index of the ledger](https://xrpl.org/basic-data-types.html#ledger-index) in which the account is created. This change protects accounts that have been deleted from having their old transactions executed again if the same address is later re-created.
Without this amendment, new accounts always start with their `Sequence` numbers at 1, and there is no way to remove accounts from the state data of the ledger.
## fixPayChanRecipientOwnerDir Summary
Changes the [PaymentChannelCreate transaction](https://xrpl.org/paymentchannelcreate.html) type so that it adds new [payment channels](https://xrpl.org/payment-channels.html) to the recipient's [owner directory](https://xrpl.org/directorynode.html). Without this amendment, new payment channels are added only to the sender's owner directory; with this amendment enabled, newly-created payment channels are added to both owner directories. Existing payment channels are unchanged.
This change prevents accounts from being deleted if they are the recipient for open payment channels, except for channels created before this amendment.
## fixCheckThreading Summary
This amendment fixes an aspect of the [Checks amendment](https://xrpl.org/known-amendments.html#checks) and has no effect until the Checks amendment is also enabled. However, enabling this amendment first ensures that all Checks have proper threading metadata from the start.
The fixCheckThreading amendment changes the way Checks transactions affect account metadata, so that Checks are properly added to the [account](https://xrpl.org/accounts.html) history of the receiving account. (Specifically, they update the `PreviousTxnID` and `PreviousTxnLedgerSeq` fields of the receiving account's [AccountRoot object](https://xrpl.org/accountroot.html), which can be used to trace the "thread" of transactions that affected the account and the objects it owns.)
Without this amendment, Checks transactions ([CheckCreate](https://xrpl.org/checkcreate.html), [CheckCash](https://xrpl.org/checkcash.html), and [CheckCancel](https://xrpl.org/checkcancel.html)) only update the account history of the sender. With this amendment, those transactions affect both the sending and receiving accounts.
## Learn, ask questions, and discuss
To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing.
Other resources:
* [The Xpring Forum](https://forum.xpring.io/)
* [XRP Chat Forum](http://www.xrpchat.com/)

27
content/blog/2020/developer-reflections-xrp-toolkit.md Normal file
View File

@@ -0,0 +1,27 @@
---
category: 2020
date: 2020-07-17
labels:
- Developer Reflections
---
# Developer Reflections: XRP Toolkit
[XRP Toolkit](https://www.xrptoolkit.com/), developed by [Towo Labs](https://towo.io), is a platform for managing crypto assets on the XRP Ledger, including a full-featured graphical user-interface (GUI) for the XRP Ledger's built-in decentralized exchange (DEX).
> ![Screenshot: trade tab](../img/xrp-toolkit/trade-tab.png)
XRP Toolkit is used by thousands of Xumm App and Ledger hardware wallet users to access advanced XRP Ledger features, such as limit orders, cross-currency payments, escrows, checks, and account settings.
> ![Screenshot: account tab](../img/xrp-toolkit/account-tab.png)
When a user connects their wallet to XRP Toolkit, they get the security benefits of their favorite non-custodial wallet, and the usability of a full-featured web interface.
> ![Screenshot: send tab](../img/xrp-toolkit/send-tab.png)
XRP Toolkit has been designed from the ground up with strong security standards, and only handles public data and public keys. XRP Toolkit uses ripple-lib and the JSON-RPC Websocket to access the XRP Ledger.
> ![Screenshot: escrow tab](../img/xrp-toolkit/escrow-tab.png)
All transaction signing has been offloaded to the supported wallets, which reduces the need to copy/paste sensitive key material, and allows XRP Toolkit to focus on offering users advanced XRP Ledger features.
If you're a developer that uses the [XRP Ledger](https://xrpl.org/), [Interledger](https://interledger.org/), [Xpring SDK](https://github.com/xpring-eng/xpring-sdk), [XRP API](https://github.com/xpring-eng/xrp-api), [ripple-lib](https://github.com/ripple/ripple-lib), [XRP CLI](https://github.com/xpring-eng/xrp-cli) or related open-source technologies in your products and apps, then fill out this form [[link](https://docs.google.com/forms/d/e/1FAIpQLSeQAWZFBanNeuYyTFoA2FzHXJzzduoQGSGxgeInzCL_WKJpdQ/viewform?usp=sf_link)] with details about your product or app, and join the community.

34
content/blog/2020/developer-reflections-xrplorer.md Normal file
View File

@@ -0,0 +1,34 @@
---
category: 2020
date: 2020-05-30
labels:
- Developer Reflections
---
# Developer Reflections: Xrplorer
This week on Developer Reflections, we're proud to highlight [Xrplorer](https://xrplorer.com), a powerful open analytics platform built on top of a graph database representation of the XRP Ledger.
Xrplorer was built by [Thomas Silkjaer](https://twitter.com/Silkjaer), a Danish data scientist, designer, and popular [Forbes Contributor](https://www.forbes.com/sites/thomassilkjaer/#4562826a7348), as a side-project on [Neo4j](https://neo4j.com/), to prove out the benefits of using a graph database over a traditional relational database management system (RDBMS), which is typically used to store XRP Ledger historical data.
<!-- BREAK -->
**Note:** The Xrplorer project as described in this post has been deprecated, as forensics and other data are being combined with related efforts within the XRP Ledger Foundation. _(Updated October 2022)_
A primary benefit of the graph database is that the ledgers are not stored in their original binary form or JSON representations, which makes it easier to do more complex relational queries, apply graph algorithms, run fraud detection algorithms and integrate XRP Ledger data with machine learning.
To that extent, Xrplorer has been widely used by the XRP Community as a watchdog platform to prevent, report and combat fraudulent activity on the XRP Ledger.
A forensic team was formed on [Twitter](https://twitter.com/xrpforensics) using Xrplorer and social media data to serve as a safety beacon for the XRP Community by reporting scammers and fake giveaways.
> ![Xrplorer tweet flagging a scam domain](../img/xrplorer/xrplorer-anti-scam-tweet.png)
[Xrplorer](https://twitter.com/xrplorer) has also been effective at identifying "[amendment blocked](https://xrpl.org/amendments.html#amendment-blocked)" servers and notifying their operators, who hadn't yet upgraded to the latest stable version of the XRP Ledger.
> ![Xrplorer tweet about finding amendment blocked services](../img/xrplorer/xrplorer-amendment-blocked-tweet.png)
The graph database structure has also enabled Silkjaer to [visualize XRP Ledger data in stunning ways](https://www.forbes.com/sites/thomassilkjaer/2019/05/13/visualization-the-xrp-ledger-expanding-over-time/#6508d5a446ea) , which have uniquely expressed his combined passion and talent for data and design.
> ![XRP Ledger visualization by Thomas Silkjaer](../img/xrplorer/xrpl-visualized-by-silkjaer.png)
> _XRP Ledger visualized by Thomas Silkjaer in [Forbes](https://www.forbes.com/sites/thomassilkjaer/2019/05/13/visualization-the-xrp-ledger-expanding-over-time/#52c7b3746ea7)._
If you're a developer that uses the [XRP Ledger](https://xrpl.org/), [Interledger](https://interledger.org/), [Xpring SDK](https://github.com/xpring-eng/xpring-sdk), [XRP API](https://github.com/xpring-eng/xrp-api), [ripple-lib](https://github.com/ripple/ripple-lib), [XRP CLI](https://github.com/xpring-eng/xrp-cli) or related open-source technologies in your products and apps, then fill out this form [[link](https://docs.google.com/forms/d/e/1FAIpQLSeQAWZFBanNeuYyTFoA2FzHXJzzduoQGSGxgeInzCL_WKJpdQ/viewform?usp=sf_link)] with details about your product or app, and join the community.

28
content/blog/2020/developer-reflections-xrpscan.md Normal file
View File

@@ -0,0 +1,28 @@
---
category: 2020
date: 2020-05-02
labels:
- Developer Reflections
targets: [devblog]
---
# Developer Reflections: XRPScan
This week on Developer Reflections, we’re proud to highlight [XRPScan](https://xrpscan.com/), one of the most popular blockchain explorers for XRP, used by over 50+ exchanges globally, including Coinbase, Bitfinex, Bitkub, and Bitpay, among others, to look up XRP Ledger account information and show Proof-of-Transaction to their users.
![Screenshot: account summary](/blog/img/dev-reflections-xrpscan-1.webp)
[XRPScan](https://twitter.com/xrpscan) is also used by a growing number of wallets, crypto tax software providers, market maker trading bots, and has seen over 180 million individual API calls in the last 30 days alone. XRPScan uses [xrpl.js](https://github.com/XRPLF/xrpl.js) _(Note: formerly ripple-lib)_ to surface transaction data across the XRP Ledger.
![Screenshot: transaction summary](/blog/img/dev-reflections-xrpscan-2.webp)
As one of the largest providers of XRP Ledger account identification services in the community, with over 550 verified exchange, payment, AML and compliance services integrated, XRPScan sees several thousand unique visitors per day.
![Screenshot: Amendments dashboard](/blog/img/dev-reflections-xrpscan-3.webp)
The Xpring team at Ripple even uses the XRPScan Amendments page internally to track the status of amendment activations among validators on the XRP Ledger network. We believe that XRPScan has built a powerful platform for visualizing actionable data across the XRP Ledger, using Xpring tools.
![Screenshot: DeleteableAccounts amendment status page](/blog/img/dev-reflections-xrpscan-4.webp)
XRPScan is the first app that we’re featuring in a new content series called Developer Reflections, which will highlight some of the work being done by the growing community of talented developers using the open-source protocols, tools and services that Xpring helps to build and maintain.
If you’re a developer that uses the [XRP Ledger](https://xrpl.org), [Interledger](https://interledger.org/), [xrpl.js](https://github.com/XRPLF/xrpl.js) or related open-source technologies in your products and apps, then [fill out this form](https://docs.google.com/forms/d/e/1FAIpQLSeQAWZFBanNeuYyTFoA2FzHXJzzduoQGSGxgeInzCL_WKJpdQ/viewform?usp=sf_link) with details about your product or app, and join the community. _(Editor's note: this post was updated to remove links to deprecated projects.)_

50
content/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-expected.md Normal file
View File

@@ -0,0 +1,50 @@
# Two Fix Amendments are Expected 2020-01-18
On 2020-01-03, the [fixCheckThreading](https://xrpcharts.ripple.com/#/transactions/71460CE2DB7594C25A649C042D18BC3C027910CF02C60EC7F1E77660C9CAE1D2) and [fixPayChanRecipientOwnerDir](https://xrpcharts.ripple.com/#/transactions/4F5C639512B14BC6986026A2871CBF348C6092B1D4BE2DE9EE64D0F04E1EA5F7) amendments to the XRP Ledger gained support from a majority of trusted validators. These amendments were introduced in [`rippled` v1.4.0](https://github.com/ripple/rippled/releases/tag/1.4.0). Currently, they are expected to become enabled on 2020-01-18. Each amendment that continues to have the support of at least 80% of trusted validators continuously will become enabled on the scheduled date.
## fixCheckThreading Summary
Changes the way Checks transactions affect account metadata, so that Checks are properly added to the [account](https://xrpl.org/accounts.html) history of the receiving account. (Specifically, they update the `PreviousTxnID` and `PreviousTxnLedgerSeq` fields of the receiving account's [AccountRoot object](https://xrpl.org/accountroot.html), which can be used to trace the "thread" of transactions that affected the account and the objects it owns.)
Without this amendment, Checks transactions ([CheckCreate](https://xrpl.org/checkcreate.html), [CheckCash](https://xrpl.org/checkcash.html), and [CheckCancel](https://xrpl.org/checkcancel.html)) only update the account history of the sender. With this amendment, those transactions affect both the sending and receiving accounts. This amendment has no direct effect unless the [Checks amendment](https://xrpl.org/known-amendments.html#checks) is also enabled.
By enabling this amendment in advance of the Checks amendment, the corrected behavior will apply to all Checks.
## fixPayChanRecipientOwnerDir Summary
Changes the [PaymentChannelCreate transaction](https://xrpl.org/paymentchannelcreate.html) type so that it adds new [payment channels](https://xrpl.org/payment-channels.html) to the recipient's [owner directory](https://xrpl.org/directorynode.html). Without this amendment, new payment channels are added only to the sender's owner directory; with this amendment enabled, newly-created payment channels are added to both owner directories. Existing payment channels are unchanged.
This change makes it easier to look up payment channels by their recipient and prevents accounts from being deleted if they are the recipient for open payment channels (except those channels created before this amendment).
## Action Required
- If you operate a `rippled` server, **you must upgrade to version 1.4.0 (or higher) by 2020-01-18, for service continuity.**
- If you use the XRP Ledger APIs to list payment channels, such as using the [account_channels](https://xrpl.org/account_channels.html) method, be aware that the fixPayChanRecipientOwnerDir amendment affects the results of this API. Specifically, the method will list newly-created channels for which the specified account is the recipient. Previously, this method only listed channels for which the account is the sender. (Existing payment channels for which the specified account is the recipient will continue not to appear in the results. Only new channels, created after the amendment becomes enabled, are affected.)
## Impact of Not Upgrading
If you operate a `rippled` server but don’t upgrade to version 1.4.0 (or higher) by 2020-01-18, when the fixCheckThreading and fixPayChanRecipientOwnerDir amendments are expected to become enabled, 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 neither amendment becomes enabled, then your server will not become amendment blocked and should continue to operate.
For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html).
## Learn, ask questions, and discuss
To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing.
Other resources:
* [The XRP Ledger Dev Blog](https://xrpl.org/blog/)
* Ripple Technical Services: <support@ripple.com>
* [XRP Chat Forum](http://www.xrpchat.com/)

37
content/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-lost-majority.md Normal file
View File

@@ -0,0 +1,37 @@
# fixCheckThreading and fixPayChanRecipientOwnerDir Amendments Lost Majority
On 2019-01-11, the fixCheckThreading and fixPayChanRecipientOwnerDir amendments lost the support of several validators, causing those amendments' support to fall below the 80% threshold for approval. (EnableAmendment LostMajority transactions: [fixCheckThreading](https://xrpcharts.ripple.com/#/transactions/3D10E846B1DA4BA07FA79BA1C13F802DD587F842F3810D997224C3693B120F51), [fixPayChanRecipientOwnerDir](https://xrpcharts.ripple.com/#/transactions/C848F96FDB815623753F27E8B5C83F4E38CFC8F50B28307142A6DFAC946EF070).) As a result, these amendments are no longer expected to become enabled on 2020-01-18, and their status depends on more validators to resume voting in favor of the amendments.
For more information on the Amendment process, see [Amendments](https://xrpl.org/amendments.html) in the XRP Ledger Dev Portal.
## Ripple's Statement
Ripple is one of several validators in the recommended list that are [currently voting](https://xrpscan.com/amendment/621A0B264970359869E3C0363A899909AAB7A887C8B73519E4ECF952D33258A8) against enabling the fixCheckThreading and fixPayChanRecipientOwnerDir amendments. Ripple's statement on the validator voting is as follows:
> We would like to see these amendments enabled before Deletable Accounts because they fix some edge cases that could be more confusing with Deletable Accounts. However, we have seen a slower than usual uptake of the new core XRP Ledger server version, with almost half the network still using version 1.3.1 instead of the newer 1.4.0. Additionally, [the announcement about these amendments getting a majority](https://xrpl.org/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-expected.html) was the first time it was reported that fixPayChanRecipientOwnerDir would result in a backwards-incompatible change in the behavior in the API for Payment Channels. Since neither amendment fixes an immediate bug, and enabling either one would [amendment block](https://xrpl.org/amendments.html#amendment-blocked) everyone who's still on v1.3.1, we decided to temporarily have our validators vote against the amendments with the hopes that it would give people more time to upgrade.
## Action Recommended
All XRP Ledger servers should continue to operate as normal for now. If any new amendment gains (or regains) a majority of 80% of validators, it must hold that majority for a continuous period of two weeks to become enabled. However, the following actions are strongly recommended to prepare for the likelihood of future amendments:
- If you operate a `rippled` server, please [upgrade](https://xrpl.org/install-rippled.html) to version 1.4.0.
**Caution:** Upgrading to v1.4.0 may take longer than usual because of SQL database cleanup the server performs the first time after upgrading. For more information, see [XRP Ledger version 1.4.0 Upgrade Advisory](https://xrpl.org/blog/2020/rippled-1.4.0-upgrade-advisory.html).
- If you use the XRP Ledger APIs to list payment channels, such as using the [account_channels](https://xrpl.org/account_channels.html) method, be aware that the fixPayChanRecipientOwnerDir amendment affects the results of this API. Specifically, the method will list newly-created channels for which the specified account is the recipient. Previously, this method only listed channels for which the account is the sender. (Existing payment channels for which the specified account is the recipient will continue not to appear in the results. Only new channels, created after the amendment becomes enabled, are affected.)
- If you use the XRP Ledger, you may want to read about [how Deletable Accounts work](https://xrpl.org/accounts.html#deletion-of-accounts) in case the changes affect your use of the XRP Ledger. The Deletable Accounts amendment is open for voting, so it may become available within a few weeks depending on how the network's trusted validators vote. (See also: the [Deletable Accounts Draft Specification](https://github.com/xrp-community/standards-drafts/issues/8).)
## Learn, ask questions, and discuss
To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing.
Other resources:
* [XRPScan Amendments Dashboard](https://xrpscan.com/amendments)
* This XRP Ledger Dev Blog
* Ripple Technical Services: <support@ripple.com>
* [XRP Chat Forum](http://www.xrpchat.com/)

77
content/blog/2020/get-ready-for-deletable-accounts.md Normal file
View File

@@ -0,0 +1,77 @@
# Get Ready for Deletable Accounts
The XRP Ledger is currently [expected to enable](https://xrpl.org/blog/2020/deletableaccounts-expected.html) the deletion of on-ledger accounts for the first time, through the [DeletableAccounts Amendment](https://xrpl.org/known-amendments.html#deletableaccounts), on **2020-05-08 (UTC)**. This amendment comes with changes to some fairly fundamental details of the XRP Ledger protocol. If you use the XRP Ledger for your business, this is a good time to do a last check to make sure you're ready.
Read on for some tips on:
- Deletable accounts in general
- Handling changes to account creation
- Dealing with accounts that could be deleted
- Getting XRP back by deleting your extra accounts
<!-- BREAK -->
## Deletable accounts in general
Prior to this amendment, every [account in the XRP Ledger](https://xrpl.org/accounts.html) was permanent. That's part of why there's a 20 XRP reserve to create new accounts; they take up space in the shared ledger.
After the amendment, any account that meets [the prerequisites](https://xrpl.org/accounts.html#deletion-of-accounts) can be deleted. Only the owner of an account can delete it, though, since you have to send a transaction from the account to be deleted. After an account has been deleted, it's completely gone from the current ledger. Its transaction history continues to exist in immutable historical ledger data, so [full-history servers](https://xrpl.org/ledger-history.html#full-history) won't forget about it. It will eventually be forgotten by servers that only keep recent ledger history; to those servers, an account that has been deleted is pretty much the same as an account that never existed.
After an account has been deleted, anyone can re-create it by sending at least 20 XRP to its address to fund the account, just like with any other valid XRP Ledger address. The newly created account is initialized like any other new account: settings from before it was deleted _do not_ carry over. Just like any other address, you don't get any special powers over the account for funding it; you need the cryptographic keys associated with the address to have control over the account.
## Handling changes to account creation
The DeletableAccounts amendment changes the way new accounts' [sequence numbers](https://xrpl.org/basic-data-types.html#account-sequence) work in the XRP Ledger: instead of starting at sequence number 1, the starting sequence number matches the current ledger index when the account was created. This change protects accounts from having their old transactions replayed if the account gets deleted and then re-created.
Sequence numbers otherwise work the same. There are no changes necessary if you are continuing to use an account that was already created before deletable accounts.
Sending transactions from newly-funded accounts is mostly the same as before; the main difference with deletable accounts is that you should check the account's starting sequence number when you confirm that the account has been funded, instead of assuming the starting sequence number is 1. If you let your signing software [auto-fill](https://xrpl.org/sign.html#auto-fillable-fields) the `Sequence` number, no changes are necessary.
In cases where you must explicitly specify the sequence number, you can look it up using the [account_info method](https://xrpl.org/account_info.html) first. For a detailed walkthrough of how to do this process with an airgapped machine, see [Offline Account Setup](https://xrpl.org/offline-account-setup.html).
## Dealing with accounts that could be deleted
One change that is likely to have a mild impact on many integrations with the XRP Ledger is simply the fact that accounts are no longer permanent. Even if you have looked up an account once to confirm that it exists now, deletable accounts mean the account may not still be there later when you try to interact with it again.
For example, if someone gives you the address of an account where they want you to send a payment, your transaction may fail if the account you're sending to has been deleted. In this case, your transaction may result in a code such as [`tecNO_DST` or `tecNO_DST_INSUF_XRP`](https://xrpl.org/tec-codes.html). (If you send at least 20 XRP, your transaction will successfully fund the account instead.) You should **not automatically re-send** payments that failed with these codes, because the second transaction is very likely to fail with the same error. In this case, you should check with the intended recipient for a different address that you should use instead. The typical way to handle these errors has not changed, but there are more circumstances where they can come up.
If you try to look up the [account_info](https://xrpl.org/account_info.html) of an account that does not exist in the ledger version you've queried, the server responds with the error code `actNotFound`. This could mean the account has been deleted, or it did not exist to begin with. If you want to know if an account has ever existed, you can use the [account_tx method](https://xrpl.org/account_tx.html) on a full-history server.
One of the prerequisites for deleting an account is that it must not be linked to any objects in the ledger. You don't need to worry about not being able to finish an [Escrow](https://xrpl.org/escrow.html), and the [issuer of a non-XRP currency](https://xrpl.org/issued-currencies-overview.html) won't go away as long as anyone holds a balance of that currency.
Payment Channels are a little more complicated because channels that have been grandfathered in from before the [fixPayChanRecipientOwnerDir amendment went live on 2020-05-01](https://xrpl.org/blog/2020/two-fixes-enabled.html) don't actually block their destinations from being deleted. (All new payment channels created since then do.) If the destination of a grandfathered payment channel has been deleted, the following options are possible:
- Someone can re-create the destination account by funding it with at least 20 XRP.
- The sender of the payment channel can request to close the channel, according to the normal restrictions.
- If the channel has an immutable expiration time or is already scheduled to close, you can wait for it to close and then remove the expired channel from the ledger as normal.
## Getting XRP back by deleting your extra accounts
If you have any accounts on the XRP Ledger that you're not using, you may have up to 20 XRP locked up for the [reserve requirements](https://xrpl.org/reserves.html) for each of those accounts. (It's possible for an account to have less than 20 XRP if you've destroyed XRP to pay [transaction costs](https://xrpl.org/transaction-cost.html).) If your account meets the prerequisites, you can get most of the reserved XRP back by deleting your unused accounts.
**The cost to delete an account is 5 XRP,** which is destroyed in the process of deleting the account. This cost protects the XRP Ledger from attacks where someone excessively creates accounts and then deletes them to get their XRP reserves back. If an account currently holds less than 5 XRP, it cannot be deleted.
To delete an account, it must have _no_ [trust lines](https://xrpl.org/trust-lines-and-issuing.html), [Escrows](https://xrpl.org/escrow.html), or [Payment Channels](https://xrpl.org/payment-channels.html) in the ledger linked to it. If your account currently has any of these ledger objects, you may be able to delete the account _after_ removing some objects:
- To remove a trust line, reset it to its default state. (0 limit, 0 balance, and no non-default settings.)
- To remove an Escrow, finish it (if the escrow is ready), or cancel it (if the escrow is expired). If it is a time-based escrow, you cannot remove it until its FinishAfter time has passed.
- To remove a PaymentChannel, close the channel. If the channel has unclaimed XRP, you may have to wait for the `SettleDelay` to expire after requesting to close the channel.
If your account meets the requirements to be deleted, send an [AccountDelete transaction](https://xrpl.org/accountdelete.html) from that account. The `Destination` address in the transaction receives the deleted account's remaining XRP (after subtracting the destroyed XRP). If you are withdrawing to an account at an exchange or hosted wallet, don't forget to include your `DestinationTag` at that exchange.
## Next steps
Stay tuned for updates on whether the DeletableAccounts amendment becomes enabled as expected, as well as the status of other amendments that are currently in voting such as the Checks amendment.
To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing.
Other resources:
* [The Xpring Forum](https://forum.xpring.io/)
* [XRP Chat Forum](http://www.xrpchat.com/)

70
content/blog/2020/moving-devnet-to-vl.md Normal file
View File

@@ -0,0 +1,70 @@
---
category: 2020
date: 2020-08-10
labels:
- Advisories
---
# Moving Devnet to a Validator List
Ripple plans to upgrade [the XRP Ledger Devnet](https://xrpl.org/parallel-networks.html) to use a recommended validator list like the ones used on the Testnet and Mainnet. Ripple also plans to reset the Devnet history and state at this time. If you operate a server on the XRP Ledger Devnet, or run software on the Devnet, you must upgrade your configuration to remain synced.
<!-- BREAK -->
## Background
Ripple runs the Devnet as a way to preview and test upcoming XRP Ledger features. Until now, the Devnet has used a short, hard-coded list of trusted validators that every server must use to remain synced. Configurations with a different set of trusted validators may not be fork-safe, so the entire network has to coordinate adding or removing trusted validators from the list.
Ripple plans to add more trusted validators to the Devnet before testing the upcoming [Negative UNL feature](https://www.xrpchat.com/topic/33072-suggestion-robustness-improvements/). A validator list site helps to coordinate adding more validators to servers' UNLs, and provides a test environment that more closely resembles the Testnet and Mainnet.
Balances in the Devnet have no real-world value. To enforce this and to keep the Devnet a free place to run tests, Ripple resets the ledger state and history of the Devnet periodically.
## Actions Required
Ripple plans to upgrade and reset its Devnet validators on Tuesday, 2020-08-11. After the upgrade, the way to [connect your server to the Devnet](https://xrpl.org/connect-your-rippled-to-the-xrp-test-net.html) will be to use a validator list site, as described below.
If you had any Devnet accounts, balances, or in-ledger settings, you must re-create those accounts and settings. Use the [Devnet Faucet](https://xrpl.org/xrp-testnet-faucet.html) to fund new addresses with a new supply of Devnet Test XRP.
### Configuration Changes
To connect to the Devnet after the update, complete the following steps:
1. Add the new validator list and key to your `validators.txt`.
[validator_list_sites]
https://vl.devnet.rippletest.net
[validator_list_keys]
EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12
The `validators.txt` file defines a server's trusted validator settings. The [recommended installation](https://xrpl.org/install-rippled.html) places this file at `/etc/opt/ripple/validators.txt` by default.
2. Remove or comment-out any other URLs in `[validator_list_sites]` and any other keys in `[validator_list_keys]`. If this server was previously connected to the devnet, **remove or comment out the `[validators]` stanza and any hard-coded validator public keys in that stanza**.
For example:
# # Old Hard-coded List of Devnet Validators
# [validators]
# n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
# n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
# n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
# n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
# n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
# n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
# n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS
3. After changing your config, **restart** the `rippled` service.
$ sudo systemctl restart rippled
## Next Steps
Stay tuned to the [XRP Ledger Dev Blog](https://xrpl.org/blog/) for the upcoming release of version 1.6.0 of the core XRP Ledger server (`rippled`) and details about the upcoming tests of the Negative UNL feature. To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
Other resources:
- [XRP Ledger Dev Portal](https://xrpl.org/)
* [The Xpring Forum](https://forum.xpring.io/)
* [XRP Chat Forum](http://www.xrpchat.com/)

46
content/blog/2020/requirefullycanonicalsig-expected.md Normal file
View File

@@ -0,0 +1,46 @@
# The RequireFullyCanonicalSig Amendment is Expected 2020-07-03
The RequireFullyCanonicalSig amendment to the XRP Ledger, introduced in [`rippled` v1.5.0](https://github.com/ripple/rippled/releases/tag/1.5.0), has [gained support from a majority of trusted validators](https://xrpcharts.ripple.com/#/transactions/4DF3E28D6920D917CE0A0A9E341BC5F792B3584E2DD5E679BD7679FE0875AEE6). Currently, it is expected to become enabled on 2020-07-03 (UTC). As long as the RequireFullyCanonicalSig amendment continues to have the support of at least 80% of trusted validators continuously, it will become enabled on the scheduled date.
<!-- BREAK -->
## RequireFullyCanonicalSig Summary
Changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid in any case. This protects against [transaction malleability](https://xrpl.org/transaction-malleability.html) on _all_ transactions, instead of just transactions with the [tfFullyCanonicalSig flag](https://xrpl.org/transaction-common-fields.html#global-flags) enabled.
Without this amendment, a transaction is malleable if it uses a secp256k1 signature and does not have tfFullyCanonicalSig enabled. Most signing utilities enable tfFullyCanonicalSig by default, but there are exceptions.
With this amendment, no single-signed transactions are malleable. ([Multi-signed transactions may still be malleable](https://xrpl.org/transaction-malleability.html#malleability-with-multi-signatures) if signers provide more signatures than are necessary.) All transactions must use the fully canonical form of the signature, regardless of the tfFullyCanonicalSig flag. Signing utilities that do not create fully canonical signatures are not supported. All of Ripple's signing utilities have been providing fully-canonical signatures exclusively since at least 2014.
## Action Required
- If you operate a `rippled` server, you must upgrade to version 1.5.0 (or higher) by 2020-07-03, for service continuity.
- If you use a custom or very old (pre-2014) tool for signing XRP Ledger transactions using secp256k1, check that your tool produces _fully canonical_ signatures. All valid Ed25519 signatures are fully canonical. If your tool produces secp256k1 signatures that are not fully canonical (see [Alternate secp256k1 signatures](https://xrpl.org/transaction-malleability.html#alternate-secp256k1-signatures) for details), you must update your tool to continue sending XRP Ledger transactions.
## Impact of Not Upgrading
If you operate a `rippled` server but don’t upgrade to version 1.5.0 (or higher) by 2020-07-03, when the RequireFullyCanonicalSig amendment is expected to become enabled, 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 RequireFullyCanonicalSig amendment does not become enabled, then your server will not become amendment blocked and should continue to operate.
For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html).
## Learn, ask questions, and discuss
To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing.
Other resources:
* [XRPScan Amendments Dashboard](https://xrpscan.com/amendments)
* [Xpring Forum](https://forum.xpring.io/)
* [XRP Chat Forum](http://www.xrpchat.com/)

69
content/blog/2020/requirefullycanonicalsig-fixqualityupperbound-flowcross-enabled.md Normal file
View File

@@ -0,0 +1,69 @@
# RequireFullyCanonicalSig, fixQualityUpperBound, and FlowCross are Now Available
[As previously announced](https://xrpl.org/blog/2020/requirefullycanonicalsig-expected.html), the **RequireFullyCanonicalSig** amendment [became enabled on the XRP Ledger](https://xrpcharts.ripple.com/#/transactions/94D8B158E948148B949CC3C35DD5DC4791D799E1FD5D3CE0E570160EDEF947D3) on 2020-07-03. Additionally, the **fixQualityUpperBound** amendment [became enabled](https://xrpcharts.ripple.com/#/transactions/5F8E9E9B175BB7B95F529BEFE3C84253E78DAF6076078EC450A480C861F6889E) on 2020-07-09 and the **FlowCross** amendment [became enabled](https://xrpcharts.ripple.com/#/transactions/44C4B040448D89B6C5A5DEC97C17FEDC2E590BA094BC7DB63B7FDC888B9ED78F) on 2020-08-04.
With these amendments enabled, **version 1.5.0 is the minimum** server version to remain synced to the XRP Ledger.
<!-- BREAK -->
## Action Required
- If you operate a `rippled` server, you should upgrade to version 1.5.0 (or higher) immediately.
For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html).
**Note:** As of 2020-08-04, [version 1.6.0 is in the release candidate process](https://github.com/ripple/rippled/commit/7b048b423e8ae08a54018a89231d050b9f562855), so the full 1.6.0 release is expected in the near future.
- If you use a custom or very old (pre-2014) tool for signing XRP Ledger transactions using secp256k1, check that your tool produces _fully canonical_ signatures. All valid Ed25519 signatures are fully canonical. If your tool produces secp256k1 signatures that are not fully canonical (see [Alternate secp256k1 signatures](https://xrpl.org/transaction-malleability.html#alternate-secp256k1-signatures) for details), you must update your tool to continue sending XRP Ledger transactions.
- If you trade in the XRP Ledger's decentralized exchange, the FlowCross amendment requires no further action at this time. There may be some differences in rounding when executing OfferCreate transactions compared to before the amendment, but the overall functionality of the decentralized exchange is unchanged and the actual currency value of any differences is expected to be very, very small.
## Impact of Not Upgrading
If you operate a `rippled` server on a version older than 1.5.0, then your server is now [amendment blocked](https://xrpl.org/amendments.html#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
## RequireFullyCanonicalSig Summary
Changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid in any case. This protects against [transaction malleability](https://xrpl.org/transaction-malleability.html) on _all_ transactions, instead of just transactions with the [tfFullyCanonicalSig flag](https://xrpl.org/transaction-common-fields.html#global-flags) enabled.
Without this amendment, a transaction is malleable if it uses a secp256k1 signature and does not have tfFullyCanonicalSig enabled. Most signing utilities enable tfFullyCanonicalSig by default, but there are exceptions.
With this amendment, no single-signed transactions are malleable. ([Multi-signed transactions may still be malleable](https://xrpl.org/transaction-malleability.html#malleability-with-multi-signatures) if signers provide more signatures than are necessary.) All transactions must use the fully canonical form of the signature, regardless of the tfFullyCanonicalSig flag. Signing utilities that do not create fully canonical signatures are not supported. All of Ripple's signing utilities have been providing fully-canonical signatures exclusively since at least 2014.
For more information, see [`rippled` issue #3042](https://github.com/ripple/rippled/issues/3042).
## fixQualityUpperBound Summary
Fixes a bug in unused code for estimating the ratio of input to output of individual steps in cross-currency payments.
Although this has no impact on current transaction processing, it [corrects a flaw in the flow cross engine](https://twitter.com/nbougalis/status/1273415169482223616). The fixQualityUpperBound was considered a prerequisite for the [FlowCross amendment](https://xrpl.org/known-amendments.html#flowcross) to be activated safely.
## FlowCross Summary
Originally [introduced in `rippled` v0.70.0, back in 2017](https://xrpl.org/blog/2017/rippled-0.70.0.html), the Flow amendment streamlines the offer crossing logic in the XRP Ledger's decentralized exchange. With FlowCross, [OfferCreate transactions](https://xrpl.org/offercreate.html) use the logic for Payment transactions, originally introduced by the [Flow](https://xrpl.org/known-amendments.html#flow) amendment. This has subtle differences in how offers are processed:
- Rounding is slightly different in some cases.
- Due to differences in rounding, some combinations of offers may be ranked higher or lower than by the old logic, and taken preferentially.
- The new logic may delete more or fewer offers than the old logic. (This includes cases caused by differences in rounding and offers that were incorrectly removed as unfunded by the old logic.)
## Learn, ask questions, and discuss
To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing.
Other resources:
* [XRPScan Amendments Dashboard](https://xrpscan.com/amendments)
* [Xpring Forum](https://forum.xpring.io/)
* [XRP Chat Forum](http://www.xrpchat.com/)

74
content/blog/2020/rippled-1.4.0-upgrade-advisory.md Normal file
View File

@@ -0,0 +1,74 @@
# XRP Ledger version 1.4.0 Upgrade Advisory
Version 1.4.0 of the XRP Ledger core server (`rippled`) contains a change that can cause upgrades to take much longer than usual.
When upgrading to version 1.4.0, `rippled` automatically reorganizes its SQL databases to remove some unused data. This happens during startup the first time the server runs after upgrading to 1.4.0. The SQL reorganization should complete within 10 to 20 minutes for most servers. For servers that have been running for longer than a few months, the operation may take significantly longer. During this time, your server will not be usable.
Plan accordingly for the time that this upgrade may take.
If you currently use a single `rippled` server, consider instead running two or more independent `rippled` servers to avoid downtime while one server is being upgraded. (Do not run more than one validator.)
## Database Reorganization Details
Previous releases stored data in a "Validations" table in the SQLite data store. This data is not needed, so `rippled` 1.4.0 drops (deletes) the Validations table, if it exists. Dropping the Validations table can take many, many hours, depending on how large the Validations table is. This varies based on the server's configuration and how long it has been collecting past history. During this time, the rippled server is unable to operate or serve requests.
If needed, a workaround is possible. However, we do not recommend this procedure if you are not familiar with sqlite3.
## Workaround
The following workaround can reduce `rippled`'s initial startup time after upgrading to version 1.4.0. It requires making changes to one of the SQL databases maintained by the server. Instead of deleting the unneeded data, this workaround renames the table. The old data continues to take up disk space on the server.
**WARNING:** We do not recommend this procedure to anyone not familiar with sqlite3.
1. Install the required tool: `sqlite3`. This is operating-system dependent.
On Ubuntu you can use the following commands:
sudo apt-get update
sudo apt-get install sqlite3
2. Stop your `rippled` instance.
This is operating-system dependent. On Linux, you can use the following commands:
sudo systemctl stop rippled.service
3. Read your configuration file and find the `[database_path]` stanza.
On Linux, the configuration file is usually located at `/opt/ripple/etc/rippled.cfg`.
The directory in the `[database_path]` stanza is where your server stores its SQL databases.
4. Change to a user that has permissions to read and write files in the SQL database directory you found in the previous step.
On Linux, you can use the `sudo -i` command.
5. Open the `ledger.db` file using the SQLite commandline:
sqlite3 ledger.db
6. Execute the following command (the trailing semicolon is required):
ALTER TABLE Validations RENAME TO OldValidations;
7. Execute the following command (the leading period is required):
.quit
8. You should now be able to start `rippled` without experiencing any delay.
sudo systemctl start rippled.service
For general instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html).
## Learn, ask questions, and discuss
To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing.
Other resources:
* [The XRP Ledger Dev Blog](https://xrpl.org/blog/)
* Ripple Technical Services: <support@ripple.com>
* [XRP Chat Forum](http://www.xrpchat.com/)

150
content/blog/2020/rippled-1.5.0.md Normal file
View File

@@ -0,0 +1,150 @@
# Introducing XRP Ledger version 1.5.0
**XRP Ledger (`rippled` server) version 1.5.0** has been released. The `rippled` 1.5.0 release introduces several improvements and new features, including support for gRPC API, API versioning, UNL propagation via the peer network, new RPC methods `validator_info` and `manifest`, augmented `submit` method, improved `tx` method, improved CLI parsing, improved protocol-level handshaking protocol, improved package building and various other minor bug fixes and improvements.
<!-- BREAK -->
## Action Required
This release introduces two new amendments: `fixQualityUpperBound` and `RequireFullyCanonicalSig`. These amendments are now **open for voting** according to the XRP Ledger's [amendment process](https://xrpl.org/amendments.html), which enables protocol changes following two weeks of >80% support from trusted validators.
**If you operate an XRP Ledger server,** then you should upgrade to version 1.5.0 by 2020-04-13, to ensure service continuity. The exact time that protocol changes take effect could be on that date or later, depending on the voting decisions of the decentralized network.
If you operate an XRP Ledger validator, please [learn more about these amendments](https://xrpl.org/known-amendments.html) so you can make informed decisions about if and when your validator should [support them](https://xrpl.org/amendments.html#configuring-amendment-voting). If you take no action, your validator begins voting in favor of the new amendments as soon as it has been upgraded.
### Impact of Not Upgrading
When one or both of the new amendments become enabled, any server on a version earlier than 1.5.0 will become [amendment blocked](https://xrpl.org/amendments.html#amendment-blocked), meaning that it:
* Cannot determine the validity of a ledger;
* Cannot submit or process transactions;
* Cannot participate in the consensus process;
* Cannot vote on future amendments; and
* Could rely on potentially invalid data.
If the amendments do not become enabled, then your XRP Ledger server will not become amendment blocked and should continue to operate.
### Upgrading
For instructions on updating XRP Ledger on supported platforms, see here:
- [Install `rippled`](https://xrpl.org/install-rippled.html)
The SHA-256 hashes for the official packages are as follows:
| Package | SHA-256 |
|:--------|:--------|
| [Red Hat RPM (x86-64)](https://repos.ripple.com/repos/rippled-rpm/stable/rippled-1.5.0-1.el7.x86_64.rpm) | `fe6b5ba0958fd4531a917af4ba58efecf51c951e534f06e025a684c2777aa7f8` |
| [Ubuntu DEB (x86-64)](https://repos.ripple.com/repos/rippled-deb/pool/stable/rippled_1.5.0-1_amd64.deb) | `4ed13ab7cd65fcfe95d2ea85522414509b13e49f8a1633ac51b3457974cad6c6` |
For other platforms, please compile version 1.5.0 from source.
* [Build on Ubuntu Linux](https://xrpl.org/build-run-rippled-ubuntu.html)
* [Build on macOS](https://xrpl.org/build-run-rippled-macos.html)
* [Build on other platforms](https://github.com/ripple/rippled/tree/master/Builds)
The first log entry should be the change setting the version:
```text
commit f00f263852c472938bf8e993e26c7f96f435935c
Author: Carl Hua <carlhua@gmail.com>
Date: Mon Mar 30 13:59:28 2020 -0400
Set version to 1.5.0
```
## Learn, ask questions, and discuss
Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org), including detailed example API calls and web tools for API testing, at <https://xrpl.org>.
Other resources:
- [XRP Chat Forum](http://www.xrpchat.com/)
- [Xpring Forum](https://forum.xpring.io/)
## Other Information
### Bug Bounties and Responsible Disclosures
As always, Ripple welcomes reviews of the **XRP Ledger** open source codebase and urges reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit <https://ripple.com/bug-bounty/>.
### Compilation Requirements & Compatibility
Compiling `rippled` 1.5.0 from source on any platform requires a compiler that supports the C++17 ISO standard and a compatible edition of the [Boost](https://www.boost.org/) C++ libraries. Version 1.5.0 of `rippled` is compatible with **Boost versions 1.70.0 through 1.72.0**.
## 1.5.0 Change Log
### New and Updated Features
- The `RequireFullyCanonicalSig` amendment which changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid. This protects against transaction malleability on all transactions, instead of just transactions with the tfFullyCanonicalSig flag enabled. Without this amendment, a transaction is malleable if it uses a secp256k1 signature and does not have tfFullyCanonicalSig enabled. Most signing utilities enable tfFullyCanonicalSig by default, but there are exceptions. With this amendment, no single-signed transactions are malleable. (Multi-signed transactions may still be malleable if signers provide more signatures than are necessary.) All transactions must use the fully canonical form of the signature, regardless of the tfFullyCanonicalSig flag. Signing utilities that do not create fully canonical signatures are not supported. All of Ripple's signing utilities have been providing fully-canonical signatures exclusively since at least 2014. For more information. [`ec137044a`](https://github.com/ripple/rippled/commit/ec137044a014530263cd3309d81643a5a3c1fdab)
- Native [gRPC API](https://grpc.io/) support. Currently, this API provides a subset of the full `rippled` [API](https://xrpl.org/rippled-api.html). You can enable the gRPC API on your server with a new configuration stanza. [`7d867b806`](https://github.com/ripple/rippled/commit/7d867b806d70fc41fb45e3e61b719397033b272c)
- API Versioning which allows for future breaking change of RPC methods to co-exist with existing versions. [`2aa11fa41`](https://github.com/ripple/rippled/commit/2aa11fa41d4a7849ae6a5d7a11df6f367191e3ef)
- Nodes now receive and broadcast UNLs over the peer network under various conditions. [`2c71802e3`](https://github.com/ripple/rippled/commit/2c71802e389a59118024ea0152123144c084b31c)
- Augmented `submit` method to include additional details on the status of the command. [`79e9085dd`](https://github.com/ripple/rippled/commit/79e9085dd1eb72864afe841225b78ec96e72b5ca)
- Improved `tx` method response with additional details on ledgers searched. [`47501b7f9`](https://github.com/ripple/rippled/commit/47501b7f99d4103d9ad405e399169fc251161548)
- New `validator_info` method which returns information pertaining to the current validator's keys, manifest sequence, and domain. [`3578acaf0`](https://github.com/ripple/rippled/commit/3578acaf0b5f2d27ddc33f5b4cc81d21be1903ae)
- New `manifest` method which looks up manifest information for the specified key (either master or ephemeral). [`3578acaf0`](https://github.com/ripple/rippled/commit/3578acaf0b5f2d27ddc33f5b4cc81d21be1903ae)
- Introduce handshake protocol for compression negotiation (compression is not implemented at this point) and other minor improvements. [`f6916bfd4`](https://github.com/ripple/rippled/commit/f6916bfd429ce654e017ae9686cb023d9e05408b)
- Remove various old conditionals introduced by amendments. [`(51ed7db00`](https://github.com/ripple/rippled/commit/51ed7db0027ba822739bd9de6f2613f97c1b227b), [`6e4945c56)`](https://github.com/ripple/rippled/commit/6e4945c56b1a1c063b32921d7750607587ec3063)
- Add `getRippledInfo` info gathering script to `rippled` Linux packages. [`acf4b7889`](https://github.com/ripple/rippled/commit/acf4b78892074303cb1fa22b778da5e7e7eddeda)
### Bug Fixes
- The `fixQualityUpperBound` amendment which fixes a bug in unused code for estimating the ratio of input to output of individual steps in cross-currency payments. [`9d3626fec`](https://github.com/ripple/rippled/commit/9d3626fec5b610100f401dc0d25b9ec8e4a9a362)
- `tx` method now properly fetches all historical tx if they are incorporated into a validated ledger under rules that applied at the time. [`11cf27e00`](https://github.com/ripple/rippled/commit/11cf27e00698dbfc099b23463927d1dac829ed19)
- Fix to how `fail_hard` flag is handled with the `submit` method - transactions that are submitted with the `fail_hard` flag that result in any TER code besides tesSUCCESS are neither queued nor held. [`cd9732b47`](https://github.com/ripple/rippled/commit/cd9732b47a9d4e95bcb74e048d2c76fa118b80fb)
- Remove unused `Beast` code. [`172ead822`](https://github.com/ripple/rippled/commit/172ead822159a3c1f9b73217da4316df48851ab6)
- Lag ratchet code fix to use proper ephemeral public keys instead of the long-term master public keys.[`6529d3e6f`](https://github.com/ripple/rippled/commit/6529d3e6f7333fc5226e5aa9ae65f834cb93dfe5)
## Contributions
### GitHub
[![GitHub: Stars](https://img.shields.io/github/stars/ripple/rippled.svg)](https://img.shields.io/github/stars/ripple/rippled.svg)
[![GitHub: Watchers](https://img.shields.io/github/watchers/ripple/rippled.svg)](https://img.shields.io/github/watchers/ripple/rippled.svg)
The public git repository for `rippled` is hosted on GitHub:
<https://github.com/ripple/rippled>
We welcome contributions, big and small, and invite everyone to join the community
of XRP Ledger developers and help us build the Internet of Value.
### Credits
The following people contributed directly to this release:
- Carl Hua <carlhua@gmail.com>
- CJ Cobb <ccobb@ripple.com>
- Devon White <dwhite@ripple.com>
- Edward Hennis <ed@ripple.com>
- Elliot Lee <github.public@intelliot.com>
- Howard Hinnant <howard.hinnant@gmail.com>
- Jeroen Meulemeester <jeroen.meulemeester@gmail.com>
- John Freeman <jfreeman08@gmail.com>
- John Northrup <jnorthrup@ripple.com>
- Manoj doshi <mdoshi@ripple.com>
- Mark Travis <mtravis@ripple.com>
- mbhandary <mayurbhandary96@gmail.com>
- Miguel Portilla <miguelportilla@pobros.com>
- Mike Ellery <mellery451@gmail.com>
- Mo Morsi <mo@morsi.org>
- Nik Bougalis <nikb@bougalis.net>
- p2peer <dmitry@prometheanlabs.io>
- Peng Wang <pwang200@gmail.com>
- Scott Schurr <scott@ripple.com>
- seelabs <scott.determan@yahoo.com>
- ShangyanLi <shangyanli42@gmail.com>
#### Lifetime Contributors
The following is the list of people who made code contributions, large and small, to XRP Ledger prior to the release of 1.5.0:
Aishraj Dahal, Alex Chung, Alex Dupre, Alloy Networks, Andrey Fedorov, Arthur Britto, Bharath Chari, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Casey Bodley, Christian Ramseier, crazyquark, Crypto Brad Garlinghouse, David Grogan, David 'JoelKatz' Schwartz, Devon White, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Ethan MacBrough, Evan Hubinger, Frank Cash, Howard Hinnant, Ian Roskam, invalidator, Jack Bond-Preston, James Fryman, jatchili, Jcar, Jed McCaleb, Jeff Trull, Jesper Wallin, Joe Loser, Johanna Griffin, John Freeman, John Northrup, Joseph Busch, Josh Juran, Justin Lynn, Keaton Okkonen, Lazaridis, Lieefu Way, Luke Cyca, Manoj Doshi, Mark Travis, Markus Teufelberger, Miguel Portilla, Mike Ellery, MJK, Mo Morsi, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, Patrick Dehne, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom 'Swirly' Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Vishwas Patil, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul, Yana Novikova and Yusuf Sahin HAMZA.
For a real-time view of all contributors, including links to the commits made by each, please visit the "Contributors" section of the GitHub repository: <https://github.com/ripple/rippled/graphs/contributors>.
As XRP Ledger continues to move through the 1.0 series, we look forward to more external contributions and are excited to see the broader XRP Ledger community grow and thrive.

285
content/blog/2020/rippled-1.6.0.md Normal file
View File

@@ -0,0 +1,285 @@
---
category: 2020
date: 2020-08-19
labels:
- rippled Release Notes
---
# Introducing XRP Ledger version 1.6.0
**XRP Ledger (`rippled` server) version 1.6.0** has been released. This release introduces several new features including changes to the XRP Ledger's consensus mechanism to make it even more robust in adverse conditions, as well as numerous bug fixes and optimizations. _(This post has been updated with recommendations for upgrading.)_
<!-- BREAK -->
## Action Required
This release introduces three new amendments to the XRP Ledger protocol: fixAmendmentMajorityCalc, HardenedValidations, and fix1781. These amendments are now **open for voting** according to the XRP Ledger's [amendment process](https://xrpl.org/amendments.html), which enables protocol changes following two weeks of >80% support from trusted validators.
**If you operate an XRP Ledger server,** then you should upgrade to version 1.6.0 by 2020-09-02, to ensure service continuity. The exact time that protocol changes take effect could be on that date or later, depending on the voting decisions of the decentralized network.
If you operate an XRP Ledger validator, please [learn more about these amendments](https://xrpl.org/known-amendments.html) so you can make informed decisions about if and when your validator should [support them](https://xrpl.org/amendments.html#configuring-amendment-voting). If you take no action, your validator begins voting in favor of the new amendments as soon as it has been upgraded.
### Upgrading
For instructions on updating XRP Ledger on supported platforms, see here:
- [Install `rippled`](https://xrpl.org/install-rippled.html)
The SHA-256 hashes for the official packages are as follows:
| Package | SHA-256 |
|:--------|:--------|
| [RPM for Red Hat / CentOS (x86-64)](https://repos.ripple.com/repos/rippled-rpm/stable/rippled-1.6.0-1.el7.x86_64.rpm) | `894d1a7a4713bfbf16264dbef9e0958a25572e0f1fce588d5a8c00452fb68115` |
| [DEB for Ubuntu / Debian (x86-64)](https://repos.ripple.com/repos/rippled-deb/pool/stable/rippled_1.6.0-1_amd64.deb) | `1d29124623bd81ba6eaf8a74bf7e14a18c511312d29213bfa6dc3351d30eedba` |
For other platforms, please compile version 1.6.0 from source.
* [Build on Ubuntu Linux](https://xrpl.org/build-run-rippled-ubuntu.html)
* [Build on macOS](https://xrpl.org/build-run-rippled-macos.html)
* [Build on other platforms](https://github.com/ripple/rippled/tree/master/Builds)
The first log entry should be the change setting the version:
```text
commit 01bd5a2646cda78ee09d2067c287c8f89872736d
Author: manojsdoshi <mdoshi@ripple.com>
Date: Tue Aug 18 15:32:50 2020 -0700
Set version to 1.6.0
```
## Change Summary
### New and Improved Features
- **Initial implementation of Negative UNL functionality:** This change can improve the liveness of the network during periods of network instability, by allowing servers to track which validators are temporarily offline and to adjust quorum calculations to match. This change requires an amendment, but the amendment is not in the **1.6.0** release. Ripple expects to run extensive public testing for Negative UNL functionality on the Devnet in the coming weeks. If public testing satisfies all requirements across security, reliability, stability, and performance, then the amendment could be included in a version 2.0 release. [[#3380](https://github.com/ripple/rippled/pull/3380)]
- **Validation Hardening:** This change allows servers to detect accidental misconfiguration of validators, as well as potentially Byzantine behavior by malicious validators. Servers can now log a message to notify operators if they detect a single validator issuing validations for multiple, incompatible ledger versions, or validations from multiple servers sharing a key. As part of this update, validators report the version of `rippled` they are using, as well as the hash of the last ledger they consider to be fully validated, in validation messages. [[#3291](https://github.com/ripple/rippled/pull/3291)] ![Amendment: Required](https://img.shields.io/badge/Amendment-Required-red)
- **Software Upgrade Monitoring & Notification:** After the `HardenedValidations` amendment is enabled and the validators begin reporting the versions of `rippled` they are running, a server can check how many of the validators on its UNL run a newer version of the software than itself. If more than 60% of a server's validators are running a newer version, the server writes a message to notify the operator to consider upgrading their software. [[#3447](https://github.com/ripple/rippled/pull/3447)]
- **Link Compression:** Beginning with **1.6.0**, server operators can enable support for compressing peer-to-peer messages. This can save bandwidth at a cost of higher CPU usage, which should prove useful for servers with a large number of peers. This support is disabled by default and can be enabled in your server's config file. [[#3287](https://github.com/ripple/rippled/pull/3287)]
- **Unconditionalize Amendments that were enabled in 2017:** This change removes legacy code which the network has not used since 2017. This change limits the ability to [replay](https://github.com/xrp-community/standards-drafts/issues/14) ledgers that rely on the pre-2017 behavior. [[#3292](https://github.com/ripple/rippled/pull/3292)]
- **New Health Check Method:** Perform a simple HTTP request to get a summary of the health of the server: Healthy, Warning, or Critical. [[#3365](https://github.com/ripple/rippled/pull/3365)]
- **Start work on API version 2.** Version 2 of the API will be part of a future release. The first breaking change will be to consolidate several closely related error messages that can occur when the server is not synced into a single "notSynced" error message. [[#3269](https://github.com/ripple/rippled/pull/3269)]
- **Improved shard concurrency:** Improvements to the shard engine have helped reduce the lock scope on all public functions, increasing the concurrency of the code. [[#3251](https://github.com/ripple/rippled/pull/3251)]
- **Default Port:** In the config file, the `[ips_fixed]` and `[ips]` stanzas now use the [IANA-assigned port](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2459) for the XRP Ledger protocol (2459) when no port is specified. The `connect` API method also uses the same port by default. [[#2861](https://github.com/ripple/rippled/pull/2861)].
- **Improve proposal and validation relaying**. The peer-to-peer protocol always relays trusted proposals and validations (as part of the [consensus process](https://xrpl.org/consensus.html)), but only relays _untrusted_ proposals and validations in certain circumstances. This update adds configuration options so server operators can fine-tune how their server handles untrusted proposals and validations, and changes the default behavior to prioritize untrusted validations higher than untrusted proposals. [[#3391](https://github.com/ripple/rippled/pull/3391)]
- **Various Build and CI Improvements** including updates to RocksDB 6.7.3 [[#3356](https://github.com/ripple/rippled/pull/3356)], NuDB 2.0.3 [[#3437](https://github.com/ripple/rippled/pull/3437)], adjusting CMake settings so that rippled can be built as a submodule [[#3449](https://github.com/ripple/rippled/pull/3449)], and adding Travis CI settings for Ubuntu Bionic Beaver [[#3319](https://github.com/ripple/rippled/pull/3319)].
- **Better documentation in the config file** for online deletion and database tuning. [[#3429](https://github.com/ripple/rippled/pull/3429)]
### Bug Fixes
- Fix the 14 day timer to enable amendment to start at the correct quorum size [[#3396](https://github.com/ripple/rippled/pull/3396)]
- Improve online delete backend lock which addresses a possibility in the online delete process where one or more backend shared pointer references may become invalid during rotation. [[#3342](https://github.com/ripple/rippled/pull/3342)]
- Address an issue that can occur during the loading of validator tokens, where a deliberately malformed token could cause the server to crash during startup. [[#3326](https://github.com/ripple/rippled/pull/3326)]
- Add delivered amount to GetAccountTransactionHistory. The delivered_amount field was not being populated when calling GetAccountTransactionHistory. In contrast, the delivered_amount field was being populated when calling GetTransaction. This change populates delivered_amount in the response to GetAccountTransactionHistory, and adds a unit test to make sure the results delivered by GetTransaction and GetAccountTransactionHistory match each other. [[#3370](https://github.com/ripple/rippled/pull/3370)]
- Fix build issues for GCC 10 [[#3393](https://github.com/ripple/rippled/pull/3393)]
- Fix historical ledger acquisition - this fixes an issue where historical ledgers were acquired only since the last online deletion interval instead of the configured value to allow deletion.[[#3369](https://github.com/ripple/rippled/pull/3369)]
- Fix build issue with Docker [#3416](https://github.com/ripple/rippled/pull/3416)]
- Add Shard family. The App Family utilizes a single shared Tree Node and Full Below cache for all history shards. This can create a problem when acquiring a shard that shares an account state node that was recently cached from another shard operation. The new Shard Family class solves this issue by managing separate Tree Node and Full Below caches for each shard. [#3448](https://github.com/ripple/rippled/pull/3448)]
- Amendment table clean up which fixes a calculation issue with majority. [#3428](https://github.com/ripple/rippled/pull/3428)]
- Add the `ledger_cleaner` command to rippled command line help [[#3305](https://github.com/ripple/rippled/pull/3305)]
- Various typo and comments fixes.
## New Commits in This Release
- [`2b4486837`](https://github.com/ripple/rippled/commit/2b448683736398faa4e58d8f386c32356ad1d3c2) Set version to 1.6.0-rc3
- [`f79a4a8cd`](https://github.com/ripple/rippled/commit/f79a4a8cdb6ede5dea2753129586fb78307a5f80) Revert "Remove CryptoConditionsSuite stub amendment:"
- [`7bb6b75f3`](https://github.com/ripple/rippled/commit/7bb6b75f3c8b31d00b4800b880c90ce63c287f54) Use the correct root hash for the tx tree
- [`e5d17a945`](https://github.com/ripple/rippled/commit/e5d17a945213eb154912cfe4d8ea2417ea87f03a) Set version to 1.6.0-rc2
- [`dbd5f0073`](https://github.com/ripple/rippled/commit/dbd5f0073e34bdead616ab30ae4db413363d9c4e) Revert support for deterministic shards:
- [`12c0e8148`](https://github.com/ripple/rippled/commit/12c0e8148bf1d3726bdd2d072f23c769bbe1a607) Improve naming of fields associated with the NegativeUNL
- [`72a9a2bdb`](https://github.com/ripple/rippled/commit/72a9a2bdbb82354446bd0a14d45fd42a35c70ba2) Reorder the Travis build:
- [`80860fa8f`](https://github.com/ripple/rippled/commit/80860fa8f574dba6ed2a3daeff1efaf402ca3ccf) Add preliminary support for Boost 1.74
- [`8cf542abb`](https://github.com/ripple/rippled/commit/8cf542abb04bdb58932adb7b67a6d7969b2fd789) Fix memory management issues with checkpointers:
- [`a931b020b`](https://github.com/ripple/rippled/commit/a931b020b5e8ed8ecc109e93c077554d68537f83) Switch to updated date library exception handling:
- [`d317060ae`](https://github.com/ripple/rippled/commit/d317060ae455dd31251bfe5d7d391c9c72420cd3) Fix a race condition with TrustedPublisherServer:
- [`eee07a4f9`](https://github.com/ripple/rippled/commit/eee07a4f96255296d418a8e24cafeb93116b3342) Add missing cstdint include
- [`7b048b423`](https://github.com/ripple/rippled/commit/7b048b423e8ae08a54018a89231d050b9f562855) Set version to 1.6.0-rc1
- [`a45920684`](https://github.com/ripple/rippled/commit/a459206848e8019d892b24e7c63fe4afef4a0ca4) Set version to 1.6.0-b9
- [`3a3b0b4c1`](https://github.com/ripple/rippled/commit/3a3b0b4c14af67209dcf6fc757c0f488e5412344) Modify health check API
- [`de0c52738`](https://github.com/ripple/rippled/commit/de0c52738785de8bf837f9124da65c7905e7bb5a) Set version to 1.6.0-b8
- [`b54453d1a`](https://github.com/ripple/rippled/commit/b54453d1a7f173e921c194c659264015568578d0) Fix a build issue caused by pip3 being unavailable
- [`706ca874b`](https://github.com/ripple/rippled/commit/706ca874b01d12a995dd8f914a713634878f1583) Implement negative UNL functionality:
- [`51bd4626b`](https://github.com/ripple/rippled/commit/51bd4626b191da7bd7ffea2a0ff08631fe41eae7) Implement version upgrade warning:
- [`cf6f40ea8`](https://github.com/ripple/rippled/commit/cf6f40ea8f4ddda2986d656d9ddeeb4904fe765d) Deprecate unused/obsolete error codes:
- [`d3798f629`](https://github.com/ripple/rippled/commit/d3798f62903df1bd24a5eb00a221963bf28f45f0) Remove CryptoConditionsSuite stub amendment:
- [`4e33a1abf`](https://github.com/ripple/rippled/commit/4e33a1abf72da95ce3e6f861c87c5f3719d70792) crawl_shards comment fix
- [`86e8f2e23`](https://github.com/ripple/rippled/commit/86e8f2e2324c79856bdb57e3af1fc81734163fe6) Add Shard Family
- [`91e857874`](https://github.com/ripple/rippled/commit/91e857874fdac6cf9dfee9f980ecdd7c0641921e) Improve LedgerMaster shard acquisition
- [`8f50fd051`](https://github.com/ripple/rippled/commit/8f50fd051e17c910d2d8026245d21ba35cda8f37) Use NuDB version 2.0.3
- [`94e8e9475`](https://github.com/ripple/rippled/commit/94e8e94750e0b308b3ab2e342275d47a846618f1) Add support for deterministic database shards (#2688):
- [`54ece72b6`](https://github.com/ripple/rippled/commit/54ece72b621610d3b0975ab6a63688c2232d423e) Update cmake so that rippled can build as a submodule
- [`4702c8b59`](https://github.com/ripple/rippled/commit/4702c8b591ad2681eac402371a24cb824797f1fa) Improve online_delete configuration and DB tuning:
- [`00702f28c`](https://github.com/ripple/rippled/commit/00702f28c2f56f4f5a9d1a3dd60fdb7cf9d9c96f) Improve reporting of ledger age in server_info
- [`df29e98ea`](https://github.com/ripple/rippled/commit/df29e98ea51e762491ef8549e0e9b1932e16eea0) Improve amendment processing and activation logic:
- [`fe9922d65`](https://github.com/ripple/rippled/commit/fe9922d65428136508bd6e2f62ebe787029581b3) Improve compression support:
- [`362a017ee`](https://github.com/ripple/rippled/commit/362a017eee942a36e8ab8e44c7ff1c86bebe3456) Cleanup SHAMap and simplify interfaces:
- [`e8f352522`](https://github.com/ripple/rippled/commit/e8f35252262b9efd14c84909f29c81a1434a4451) Improve Slice:
- [`1067086f7`](https://github.com/ripple/rippled/commit/1067086f71b56d58b29aaa60884495721432d4ad) Consolidate "Not Synced" error messages:
- [`0214d83aa`](https://github.com/ripple/rippled/commit/0214d83aa5fd53bae81d9e66ddb30609d0055b76) Improve handling of empty buffer in varint parsing (RIPD-1683)
- [`d69a90287`](https://github.com/ripple/rippled/commit/d69a902876e72e958bb78ea078e396d6a5f88c4d) Add comments to protobuf files
- [`f43aeda49`](https://github.com/ripple/rippled/commit/f43aeda49c5362dc83c66507cae2ec71cfa7bfdf) Set version to 1.6.0-b7
- [`27484f78a`](https://github.com/ripple/rippled/commit/27484f78a95aa8697dbaa9b898c86be941574dc7) Use libarchive version 3.4.3
- [`93bf77bde`](https://github.com/ripple/rippled/commit/93bf77bdec1321d99a52042bb53cced186421d83) Unit tests for database shards
- [`728651b5d`](https://github.com/ripple/rippled/commit/728651b5d57d8b2c6c7e7c5dbbd5768f8d3a8556) Use LZ4_decompress_safe
- [`fb74eefa9`](https://github.com/ripple/rippled/commit/fb74eefa9edff66d002beb00fce07fcbf740f32d) Update LZ4 library to 1.9.2
- [`853c96419`](https://github.com/ripple/rippled/commit/853c964194eab29781827100a0d05541b66df73e) Fix a build issue caused by the latest Docker version: * The latest docker version is not supported by artifactory causing the package build to fail. Setting the docker version to 19.03.8 to fix the build.
- [`645c06764`](https://github.com/ripple/rippled/commit/645c06764b84b8c02ea0449c92e9e2ead15f18d5) Update the default port for [ips] and [ips_fixed]:
- [`2d23e7bd1`](https://github.com/ripple/rippled/commit/2d23e7bd18f179844b838b01783307994f603a85) Use std::size in place of std::extent
- [`0290d0b82`](https://github.com/ripple/rippled/commit/0290d0b82c3dcd190d2ce9dad4985ee33d1f845a) Create health_check rpc
- [`3d86b49da`](https://github.com/ripple/rippled/commit/3d86b49dae8173344b39deb75e53170a9b6c5284) Set version to 1.6.0-b6
- [`0b9e93580`](https://github.com/ripple/rippled/commit/0b9e935806e76e66b6c22cbd434d0ea49b54cf07) Find date::date in CMake package configuration file
- [`17412d17e`](https://github.com/ripple/rippled/commit/17412d17e205c860af1d28bb9fc7ee0e101c5145) Fix historical ledger acquisition when using online deletion:
- [`99f519369`](https://github.com/ripple/rippled/commit/99f5193699485f357721df9ae81fe0bd4bfabed7) Disable formatting operator&:
- [`328e42ad4`](https://github.com/ripple/rippled/commit/328e42ad4256597f5b448179aeb86dbb7ded130d) Minor cleanups:
- [`6d28f2a8d`](https://github.com/ripple/rippled/commit/6d28f2a8d9038715201915844007f40f63ed249f) Cleanup code using move semantics
- [`421417ab0`](https://github.com/ripple/rippled/commit/421417ab07757c5b417a971ad03cd79bd70f4cb5) Fixes for gcc 10
- [`68494a308`](https://github.com/ripple/rippled/commit/68494a308e15c679af368afaebf96c15095470d1) AmendmentTable improvements
- [`16f79d160`](https://github.com/ripple/rippled/commit/16f79d160ac65cb6e4977571548475e1866f23a4) Add delivered amount to GetAccountTransactionHistory responses
- [`8f984042f`](https://github.com/ripple/rippled/commit/8f984042f42fc7f6f5f6427a77507ea8a4706d09) Try to fix usage of pkg-config for static linking
- [`eb1a699c5`](https://github.com/ripple/rippled/commit/eb1a699c5afb5f90d44b1ab0a8047c79538ea905) Fix typo in error message
- [`ac766ec0e`](https://github.com/ripple/rippled/commit/ac766ec0eb19e0e4345c4177f3f99aa285a916f2) Introduce ShardArchiveHandler improvements:
- [`21340a1c1`](https://github.com/ripple/rippled/commit/21340a1c1e092b6f444b6dda7cc0bb284dcd534d) Validate LastLedgerHash for downloaded shards:
- [`c594f3b0c`](https://github.com/ripple/rippled/commit/c594f3b0cf3833f97d307e76ef39199b2480927b) Reduce visibility of retired amendment identifiers:
- [`268e28a27`](https://github.com/ripple/rippled/commit/268e28a278b717a227e2e5398f69cb3628e04b73) Tune relaying of untrusted proposals & validations:
- [`ca664b17d`](https://github.com/ripple/rippled/commit/ca664b17d39ca747b619970f9b148127c73001bf) Improve handling of sfLedgerSequence field:
- [`3936110c8`](https://github.com/ripple/rippled/commit/3936110c8d93b48bdca7eca7ae6019d438d44260) Use boost::circular_buffer:
- [`9f91870b1`](https://github.com/ripple/rippled/commit/9f91870b1cd6b0c164f9073e1bec7cbdd218868b) Adjust frequency of mtENDPOINTS messages
- [`97712107b`](https://github.com/ripple/rippled/commit/97712107b71a8e2089d2e3fcef9ebf5362951110) Set version to 1.6.0-b5
- [`d9fa14868`](https://github.com/ripple/rippled/commit/d9fa148688f468f7773219320d5d641852189fbe) Revert "Add PR automation for project boards"
- [`d88a7c73b`](https://github.com/ripple/rippled/commit/d88a7c73b48b895df27bf8fb8c9e081e798a68e4) Improve online delete backend locking
- [`894d3463c`](https://github.com/ripple/rippled/commit/894d3463ce95122b137d838d82380a9a4bbfe0ed) Extend unit testing of account_tx with deleted account:
- [`5b5226d51`](https://github.com/ripple/rippled/commit/5b5226d518aee7fd128053a71fd70ca0257f7453) Cleanup the 'PeerSet' hierarchy:
- [`d025f3fb2`](https://github.com/ripple/rippled/commit/d025f3fb2890296620ba2b1f19570cc5a9e3d466) Add descriptive comments to 'getRippledInfo.sh':
- [`11be30dd4`](https://github.com/ripple/rippled/commit/11be30dd40f2d9a177b340aa1de167f130fdeced) Correct typo in comment
- [`4fad421c8`](https://github.com/ripple/rippled/commit/4fad421c8af28de2de12e49e0f1897f9ea62824a) Correct typos in SECURITY.md
- [`57b3543e7`](https://github.com/ripple/rippled/commit/57b3543e7bad88885279784149e27e9084bbc6e8) Support boost 1.73
- [`a00543b6b`](https://github.com/ripple/rippled/commit/a00543b6bc6255daf2c406f91c2a37d6de2cfbca) Fix docs about misconfigured neighbor port
- [`dbd25f0e3`](https://github.com/ripple/rippled/commit/dbd25f0e327f11a862a80a137e316a8871044c26) Remove excessive redirect call on PeerManager
- [`62a3f33d7`](https://github.com/ripple/rippled/commit/62a3f33d729dd50b91af81b4da81464d7aad2029) Remove the built-in "sustain" watchdog:
- [`74f9edef0`](https://github.com/ripple/rippled/commit/74f9edef079b8682969e3cd16715ad91334127a3) Prefer keylets instead of naked hashes:
- [`dbee3f01b`](https://github.com/ripple/rippled/commit/dbee3f01b7bde4b0b662cff454fc5e2fcc27beab) Clean up and modernize code:
- [`6c72d5cf7`](https://github.com/ripple/rippled/commit/6c72d5cf7e3b7afd7534df99781a1559857fd9f2) Improve loading of validator tokens (RIPD-1687):
- [`2827de4d6`](https://github.com/ripple/rippled/commit/2827de4d63d5f591addb1a16b87c1ecc23d102ba) Report the server version in published validations:
- [`381606aba`](https://github.com/ripple/rippled/commit/381606aba2efcd179517f2497dc6e8c2770c679e) Harden validations:
- [`567e42e07`](https://github.com/ripple/rippled/commit/567e42e071662720e15ed3d543f0a0341a2ac422) Deprecate 'Time to Live' fields
- [`2bf3b194f`](https://github.com/ripple/rippled/commit/2bf3b194faa23fab4c3f4c9ff263a84893269f78) Set version to 1.6.0-b4
- [`444ea5618`](https://github.com/ripple/rippled/commit/444ea5618275a6f42806fe086a240c0294da8b28) Adding support to build rippled packages for ubuntu 20.04
- [`d79758916`](https://github.com/ripple/rippled/commit/d79758916418e429f27ae6e150e098c0318baf51) Add README for gRPC protobuf folder
- [`1577c775b`](https://github.com/ripple/rippled/commit/1577c775b3011db9ffb80b4d2dbab5174b6965d3) Close download socket before result is passed to the callback:
- [`3bf0b724a`](https://github.com/ripple/rippled/commit/3bf0b724a3a9cc137a10279b8a4233779b8d31fb) Adjust timeouts in Validator Site tests:
- [`bd8dbb87b`](https://github.com/ripple/rippled/commit/bd8dbb87b6fbc5dd17563b475d65ac4efb1b0aad) Update to RocksBD 6.7.3
- [`cd78ce311`](https://github.com/ripple/rippled/commit/cd78ce3118be1275efe7c306da92c74a35388aab) Add PR automation for project boards
- [`023f5704d`](https://github.com/ripple/rippled/commit/023f5704d07d09e70091f38a0d4e5df213a3144b) Set version to 1.6.0-b3
- [`123e94c60`](https://github.com/ripple/rippled/commit/123e94c6039f854a5184957027c66e70965fd85a) Fix a build issue involving Ubuntu Docker containers:
- [`156dc2ec4`](https://github.com/ripple/rippled/commit/156dc2ec4c03c7e38882e9c915d38ccb2853c572) Add GitHub Action for checking w/ clang-format-10
- [`b7b7e098b`](https://github.com/ripple/rippled/commit/b7b7e098bea6e39e05302707e90782cb938b6f3a) Add .git-blame-ignore-revs (requires Git >= 2.24)
- [`50760c693`](https://github.com/ripple/rippled/commit/50760c693510894ca368e90369b0cc2dabfd07f3) Format first-party source according to .clang-format
- [`65dfc5d19`](https://github.com/ripple/rippled/commit/65dfc5d19e80b398e8780c42bc2f951e88059b43) Prepare code for formatting
- [`020b28580`](https://github.com/ripple/rippled/commit/020b28580816a295185aef8832a8fe07ecc40de2) Set version to 1.6.0-b2
- [`bdd22e4d5`](https://github.com/ripple/rippled/commit/bdd22e4d513d91071945204952a499e2478f926c) Improve reporting of missing node exceptions
- [`b7631d2a2`](https://github.com/ripple/rippled/commit/b7631d2a280cbb1a4e512181c7dd3b061f806a3c) Correct a typo that could result in a nullptr dereference
- [`284ed3847`](https://github.com/ripple/rippled/commit/284ed38471c0e1c26dc217b4d88c3736c8c77faf) Reduce calls to std::random_device:
- [`b96ef6adb`](https://github.com/ripple/rippled/commit/b96ef6adb8e68b922e3912bc5918417ebc08a716) Add SECURITY.md to the repository
- [`ce6b42720`](https://github.com/ripple/rippled/commit/ce6b4272021bfc85c256ab064deaf25dcfa2381e) Fix a build issue involving Ubuntu Docker containers:
- [`858e93c7f`](https://github.com/ripple/rippled/commit/858e93c7f8e8c891f1e98fbcf683181fae016960) Improve the Doxygen Workflow
- [`6477bdf3e`](https://github.com/ripple/rippled/commit/6477bdf3e85e027b489bc7e744894326a8ca6f92) Fix division by zero with shards file stats
- [`ce5f24055`](https://github.com/ripple/rippled/commit/ce5f240551a2802cb74bef678107cc5f28a696b4) Fix invalid shard removal
- [`1c3c69f8b`](https://github.com/ripple/rippled/commit/1c3c69f8b5d4c97f1e410db8458dc2da88814e5f) Update Travis to bionic
- [`be2652544`](https://github.com/ripple/rippled/commit/be2652544b4ed899ba1012398f470142ed969583) Add ledger_cleaner command to rippled cmd line help
- [`f155eaff4`](https://github.com/ripple/rippled/commit/f155eaff4bd3029c294985560bf2575528380e9e) Unit test for memo
- [`67981f002`](https://github.com/ripple/rippled/commit/67981f002fae229cbd54e01440740b4b130f91e1) Reduce strand re-execute log message severity to warning:
- [`0d8322344`](https://github.com/ripple/rippled/commit/0d83223445086ad5ff91911d8045e3a07c1f6007) Remove conditionals for fix1201 enabled 14Nov2017
- [`9f8d64851`](https://github.com/ripple/rippled/commit/9f8d648514128c58798bb0c8fb85de317b750722) Remove conditionals for fix1512 enabled 14Nov2017
- [`3d3b6d85c`](https://github.com/ripple/rippled/commit/3d3b6d85cd499865edf3999b0ca916ca4d773baa) Remove conditionals for fix1523 enabled 14Nov2017
- [`8cf7c9548`](https://github.com/ripple/rippled/commit/8cf7c9548a06944fc128d88f01d213aec3d1102f) Remove conditionals for fix1528 enabled 14Nov2017
- [`323dbc796`](https://github.com/ripple/rippled/commit/323dbc79623184f7cb44d3095957b5fce7cb983d) Remove conditionals for featureSortedDirectories enabled 14Nov2017
- [`46a76fb31`](https://github.com/ripple/rippled/commit/46a76fb3188f5cebcf875010750bd805c5a6c102) Remove conditionals for featureEnforceInvariants enabled 07Jul2017
- [`a6246b0ba`](https://github.com/ripple/rippled/commit/a6246b0baaf33dc522fe8ef0079b0f4e09bd19c8) Remove conditionals for fix1373 enabled 07Jul2017
- [`c8282795e`](https://github.com/ripple/rippled/commit/c8282795ef9404b83e4d4c4d6f27f1127c5fad8d) Remove conditionals for featureEscrow enabled 31Mar2017
- [`e93a44fe9`](https://github.com/ripple/rippled/commit/e93a44fe9bd44f3b4d6b886831b0cc7f061e9cbf) Remove conditionals for fix1368 enabled 31Mar2017
- [`3e870866e`](https://github.com/ripple/rippled/commit/3e870866e0c89e315580aa4478d1401f60da19d0) Remove conditionals for featurePayChan enabled 31Mar2017
- [`78d771af3`](https://github.com/ripple/rippled/commit/78d771af3670438089730af591bb5adaed386c30) Remove conditionals for featureTickSize enabled 21Feb2017
- [`6bb9dd22e`](https://github.com/ripple/rippled/commit/6bb9dd22e06a627b75b45cdd9bd78c6592a7d910) Remove conditionals for featureCryptoConditions enabled 03Jan2017
- [`1661c84af`](https://github.com/ripple/rippled/commit/1661c84af6776ad3146474d891b272f1a0d8561c) Remove unused featureCompareFlowV1V2
- [`4f422f6f3`](https://github.com/ripple/rippled/commit/4f422f6f393b12d5aaba11fb65c33b7885891906) Setting version to 1.6.0-b1
- [`393ca8757`](https://github.com/ripple/rippled/commit/393ca87572ef46bd7ee34b3cbf205afde4c25f38) Change the location for the project signer public keys:
- [`f4c56cbd5`](https://github.com/ripple/rippled/commit/f4c56cbd53b8352a4ec4633102af08019be959a3) Update SHAMap Documentation
- [`9470558ec`](https://github.com/ripple/rippled/commit/9470558ecc5fd1a33810e6ff9a0084e9a3c0e7fa) Remove all uses of the name scoped_lock
- [`f22fcb3b2`](https://github.com/ripple/rippled/commit/f22fcb3b2a510d6ae982834cc43c137ced31e6fe) Rename canonicalize into two functions:
- [`e257a226f`](https://github.com/ripple/rippled/commit/e257a226f367b8ad5c706512d39578194c9b7dc2) Maintain history back to the earliest persisted ledger:
- [`a4e987879`](https://github.com/ripple/rippled/commit/a4e9878790c4c2153dde7b37e3f32ad71aa6edb8) Document the 'devnet' network identifier setting:
- [`25b13978e`](https://github.com/ripple/rippled/commit/25b13978e78fe58219d6e7647ba3661b9289c4de) Fix unity build
- [`3e9cff928`](https://github.com/ripple/rippled/commit/3e9cff92873003c5b98b1c137d6914394b0c6ed1) Fix Doxygen build
- [`758a3792e`](https://github.com/ripple/rippled/commit/758a3792ebcd877a42f87f8f81a4d14fd68aad68) Add protocol message compression support:
- [`ade5eb71c`](https://github.com/ripple/rippled/commit/ade5eb71cf7e2d0316dfe2f1723206bd152915ca) Fix unneeded copies in range some range for loops:
- [`d097819c5`](https://github.com/ripple/rippled/commit/d097819c528da21791388ba80a8cf399adf38eb3) Check XRP endpoints for circular paths (RIPD-1781):
- [`905a97e0a`](https://github.com/ripple/rippled/commit/905a97e0aa02d0c6e1cf198e78c03ff66e282f4f) Make ShardArchiveHandler downloads more resilient:
- [`cc452dfa9`](https://github.com/ripple/rippled/commit/cc452dfa9b636e0656f327db72db70f1b2c46c23) Improve shard concurrency:
## Contributions
### GitHub
[![GitHub: Stars](https://img.shields.io/github/stars/ripple/rippled.svg)](https://img.shields.io/github/stars/ripple/rippled.svg)
[![GitHub: Watchers](https://img.shields.io/github/watchers/ripple/rippled.svg)](https://img.shields.io/github/watchers/ripple/rippled.svg)
The public git repository for `rippled` is hosted on GitHub:
<https://github.com/ripple/rippled>
We welcome contributions, big and small, and invite everyone to join the community
of XRP Ledger developers and help us build the Internet of Value.
### Credits
The following people contributed directly to this release:
- Alloy Networks <info@alloy.ee>
- Carl Hua <carlhua@gmail.com>
- CJ Cobb <ccobb@ripple.com>
- Devon White <dwhite@ripple.com>
- Edward Hennis <ed@ripple.com>
- Elliot Lee <github.public@intelliot.com>
- Gábor Lipták <gliptak@gmail.com>
- Gregory Tsipenyuk <gtsipenyuk@ripple.com>
- Howard Hinnant <howard.hinnant@gmail.com>
- John Freeman <jfreeman08@gmail.com>
- Kirill Fomichev <fanatid@ya.ru>
- Manoj Doshi <mdoshi@ripple.com>
- Mark Travis <mtravis@ripple.com>
- Markus Alvila
- Miguel Portilla <miguelportilla@pobros.com>
- Mo Morsi <mo@morsi.org>
- Nik Bougalis <nikb@bougalis.net>
- p2peer <dcherukhin@ripple.com>
- Peng Wang <pwang200@gmail.com>
- rabbit (Rabbit Kick Club)
- Rome Reginelli <rome@ripple.com>
- Scott Schurr <scott@ripple.com>
- Scott Determan <scott.determan@yahoo.com>
- Yusuf Sahin HAMZA <yusufsahinhamza@gmail.com>
#### Lifetime Contributors
The following is the list of people who made code contributions, large and small, to XRP Ledger prior to the release of 1.6.0:
Aishraj Dahal, Alex Chung, Alex Dupre, Alloy Networks, Andrey Fedorov, Arthur Britto, Bharath Chari, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Carl Hua, Casey Bodley, Christian Ramseier, CJ Cobb, crazyquark, Crypto Brad Garlinghouse, David Grogan, David 'JoelKatz' Schwartz, Devon White, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Ethan MacBrough, Evan Hubinger, Frank Cash, Gábor Lipták, Gregory Tsipenyuk, Howard Hinnant, Ian Roskam, invalidator, Jack Bond-Preston, James Fryman, jatchili, Jcar, Jed McCaleb, Jeff Trull, Jeroen Meulemeester, Jesper Wallin, Joe Loser, Johanna Griffin, John Freeman, John Northrup, Joseph Busch, Josh Juran, Justin Lynn, Keaton Okkonen, Kirill Fomichev, Lazaridis, Lieefu Way, Luke Cyca, Manoj Doshi, Mark Travis, Markus Alvila, Markus Teufelberger, Mayur Bhandary, Miguel Portilla, Mike Ellery, MJK, Mo Morsi, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, p2peer, Patrick Dehne, Peng Wang, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, ShangyanLi, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom 'Swirly' Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Vishwas Patil, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul, Yana Novikova and Yusuf Sahin HAMZA.
For a real-time view of all contributors, including links to the commits made by each, please visit the "Contributors" section of the GitHub repository: <https://github.com/ripple/rippled/graphs/contributors>.
As XRP Ledger continues to move through the 1.0 series, we look forward to more external contributions and are excited to see the broader XRP Ledger community grow and thrive.

43
content/blog/2020/running-an-xrp-ledger-validator.md Normal file
View File

@@ -0,0 +1,43 @@
---
category: 2020
date: 2021-02-07
labels:
- Features
---
# Running an XRP Ledger Validator
_by Mayur Bhandary, Software Engineer at Ripple_
Validators are the lifeblood of the XRP Ledger. This post seeks to explain the function and importance of validators on the XRP Ledger network.
<!-- BREAK -->
## Background
Like all decentralized ledgers, the XRP Ledger is a program that lives on a distributed set of servers. These servers run a program called [`rippled`](https://github.com/ripple/rippled). Every server can follow the network with a local copy of the ledger and submit transactions to the network. A smaller subset of servers contribute to the consensus process that helps to maintain forward progress of the network. These servers are called validators. Any server that runs rippled can operate as a validator by [enabling validation](https://xrpl.org/run-rippled-as-a-validator.html).
Validators agree on the set of the candidate transactions to be considered for the next ledger through the [consensus process](https://xrpl.org/consensus.html). Each validator evaluates transaction proposals from a specific set of trusted validators called a Unique Node List (UNL). Validators that appear on a UNL are "trusted" not to collude in an attempt to defraud the server evaluating the proposals. In each round of consensus, validators add transactions to their proposals if a threshold number of trusted validators also propose those transactions. The threshold is increased until a supermajority of validators propose the same set of transactions.
Finally, every rippled server independently computes a new ledger version with the new set of transactions. Validators broadcast the hash of the new ledger version to all rippled servers, and if a supermajority of a server’s trusted validators computes the same hash, then the ledger version is considered fully validated.
## Why Run a Validator
Those who operate validators do so because they have a demonstrated interest in the long term health of the network. For example, individuals and entities that rely on XRP for their business operations, all stand to benefit from the continued reliability, stability and performance of the XRP Ledger.
For those more familiar with crypto, the rationale for running a validator is similar to why someone would run a [Bitcoin Full Node](https://bitcoin.org/en/full-node): by contributing to the ecosystem, one hopes that it will continue to thrive and grow.
Validator operators that appear on a UNL also partake in the governance of the XRP Ledger through voting on fees and amendments, which are proposed changes to the protocol.
## Being a Good Validator
The characteristics of a good validator include high availability, agreement with the network, timeliness, and identification. In order to achieve these properties, it is important to adhere to the [recommended system specifications](https://xrpl.org/system-requirements.html#recommended-specifications) for production servers and [properly configure](https://xrpl.org/run-rippled-as-a-validator.html) the validator.
Beyond the administrative elements of running a validator, it is important for validator operators to be involved in the XRP community by announcing potential downtime or maintenance work ahead of time. Validators that appear on a UNL have the opportunity to vote on amendments and fees, thereby having a voice in the evolution of the network. Therefore, it is imperative that validator operators stay abreast of the [latest updates](https://xrpl.org/blog/) coming to the XRP Ledger.
## No Incentive: A Design Decision
Unlike other decentralized ledgers, the XRP Ledger does not provide a direct economic incentive for contributing to the consensus process by running a validator. Other blockchains offer direct incentives such as rewards from mining and staking or trading advantages. Instead, the lack of direct incentives for XRP Ledger validators attracts natural stakeholders.
If you want to learn more about natural stakeholders and the design decision behind no incentive, then we invite you to attend a talk by David Schwartz, Chief Architect of the XRP Ledger and CTO of Ripple, titled “The Best Incentive is No Incentive” at [Stanford Blockchain Conference](https://cbr.stanford.edu/sbc20/).

43
content/blog/2020/testnet-amendments-rippled-1.5.0.md Normal file
View File

@@ -0,0 +1,43 @@
# Postmortem: Testnet Amendments from rippled 1.5.0
Like most new releases, version 1.5.0 of the XRP Ledger core server (`rippled`) contains new amendments which are not understood by earlier versions of the software.
On Tuesday, March 10, 2020, Ripple upgraded its Testnet validators to rippled version 1.5.0-rc2. The new amendments, `RequireFullyCanonicalSig` and `fixQualityUpperBound`, were automatically supported by the validators because the server, by default, supports all of the amendments it knows about. The protocol enforces a 2-week delay between an amendment gaining majority support and its activation. This delay is intended to give operators time to upgrade to a version of rippled that supports the amendments. In this case, unfortunately, most operators were not given sufficient notice. The [ripple-server mailing list](https://groups.google.com/forum/#!forum/ripple-server) used for such announcements was not notified until about two hours before the amendments were activated.
On March 24, 2020, the amendments were activated by the Testnet validators. At this point, Ripple had these options:
1. Deactivate the amendments: From a technical standpoint, it is only feasible to do this by resetting the Testnet ledger, meaning that all accounts and balances would be removed.
2. Leave it alone: Testnet no longer matches Mainnet in terms of activated amendments, but the changes are minor, so it should not have much impact on testing or development. However, the amendments are only known to rippled 1.5.0, so all rippled servers connected to Testnet are [amendment blocked](https://xrpl.org/amendments.html#amendment-blocked) until they upgrade to rippled 1.5.0.
3. Roll back the testnet ledger to shortly before the amendments became activated. This would undo any transactions after that point, while leaving most Testnet accounts and balances in place. This should be possible as long as Ripple controls the Testnet validators and Ripple has at least one validator that hasn't yet online-deleted history past the rollback point. However, this has not been tried in practice, and there is no documented procedure for doing so.
Ripple opted for #2, the least disruptive option.
Therefore, all rippled servers connecting to the Testnet must be upgraded in order to continue operating. Unfortunately, every operator running a stable-version rippled server connected to Testnet [experienced a disruption](https://github.com/ripple/rippled/issues/3315) because rippled 1.5.0 was still in the release candidate process at the time. To restore service, Testnet servers could be [upgraded to an 'unstable' release candidate version](https://groups.google.com/forum/#!topic/ripple-server/21htQzq4zz0) or wait for the official release, which came out on March 31.
As new versions of rippled are released, operators should continue to upgrade their servers. Note that `unstable` repositories may update with pre-release versions in the future, so operators who opted to upgrade to a 1.5.0 release candidate should ensure that they do not get automatically upgraded to future 'unstable' versions, unless that is what they want.
## Action items
To improve this situation in the future, we recommend that the developers and participants of the XRP Ledger ecosystem incorporate the following process improvements:
1. When a new amendment is included in a beta, it should be documented on xrpl.org as soon as possible.
2. Whenever Ripple develops a new amendment with significant new features, Ripple will propose an [XRP Ledger Standard](https://github.com/xrp-community/standards-drafts), in the open source community-run GitHub repo, before merging code to the **develop** branch.
3. When Devnet/Testnet/Mainnet validators are upgraded to a new version of rippled, Ripple will post an announcement to [the ripple-server mailing list](https://groups.google.com/forum/#!forum/ripple-server), regardless of whether the release contains new amendments; these posts keep the XRP community up-to-date about new releases and invite them to review the changes. If there are new amendments, they should be emphasized and called out in the email.
4. New amendments should be vetoed on Testnet until they gain majority on Mainnet. Ripple plans to automate this with a script that monitors when an amendment gains majority (not just when it is activated) on Mainnet. The lag between the two networks would be no more than the time between flag ledgers, 20 minutes or less. Until this automation is in place, Testnet's amendments may be a day or two behind.
## Learn, ask questions, and discuss
To receive email updates whenever there are important releases or changes to the XRP Ledger server software, subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/).
Other resources:
* Ripple Technical Services: <support@ripple.com>
* [Xpring Forum](https://forum.xpring.io/)
* [XRP Chat Forum](http://www.xrpchat.com/)

40
content/blog/2020/two-fixes-enabled.md Normal file
View File

@@ -0,0 +1,40 @@
# Two Fix Amendments Are Now Enabled
As [previously announced](https://xrpl.org/blog/2020/deletableaccounts-expected.html), the [fixCheckThreading](https://xrpcharts.ripple.com/#/transactions/74AFEA8C17D25CA883D40F998757CA3B0DB1AC86794335BAA25FF20E00C2C30A) and [fixPayChanRecipientOwnerDir](https://xrpcharts.ripple.com/#/transactions/D2F8E457D08ACB185CDE3BB9BB1989A9052344678566785BACFB9DFDBDEDCF09) amendments became enabled on 2020-05-01.
The DeletableAccounts amendment is still expected for 2020-05-08.
<!-- BREAK -->
## Action Required
- If you operate a `rippled` server, you must upgrade to version 1.4.0 or higher by **2020-05-01**, for service continuity. **Version 1.5.0** is _strongly recommended_.
- If you use the [`account_channels` API method](https://xrpl.org/account_channels.html), you must upgrade to `rippled` version 1.5.0 to avoid breaking changes to the API triggered by the fixPayChanRecipientOwnerDir amendment.
- The DeletableAccounts amendment changes the starting [sequence numbers](https://xrpl.org/basic-data-types.html#account-sequence) for accounts. If you have automatic processes that send transactions from newly-funded accounts, please check that the change does not break critical processes.
For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html).
## Impact of Not Upgrading
If you operate a `rippled` server on a version older than 1.4.0, then your server is now 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
## Learn, ask questions, and discuss
To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server).
Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing.
Other resources:
* [The Xpring Forum](https://forum.xpring.io/)
* [XRP Chat Forum](http://www.xrpchat.com/)