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

15
content/blog/2016/data-api-v2.2.md Normal file
View File

@@ -0,0 +1,15 @@
# Data API v2.2 Released
The Data team is proud to announce the release of the [Ripple Data API v2.2](https://github.com/ripple/rippled-historical-database/releases/tag/v2.2.0)! This release includes lots of new features, including a total of 15 new methods, improvements in data quality, and documentation.
One of the biggest changes in the new version is the incorporation of data relating to the Ripple network itself. This includes expanded information on [validator reports](https://ripple.com/build/data-api-v2/#get-daily-validator-reports), [network topology](https://ripple.com/build/data-api-v2/#get-topology), and the [XRP transaction costs](https://ripple.com/build/data-api-v2/#get-transaction-costs) currently being paid to the network. You can interact with all of the new methods using our [Data API Tool](https://ripple.com/build/data-api-tool/).
Also part of the new release is a method to calculate the [distribution of XRP](https://ripple.com/build/data-api-v2/#get-xrp-distribution) from Ripple (the company) to others, along with the total amount of XRP in existence. The [XRP Portal](https://ripple.com/xrp-portal/) is already using the new method to report the most recent totals automatically.
For more information, check out the following resources:
* [Data API Docs in the Ripple Developer Center](https://ripple.com/build/data-api-v2/)
* [Data API source code](https://github.com/ripple/rippled-historical-database)
* [Data visualizations on Ripple Charts](https://xrpcharts.ripple.com/)
We look forward to seeing what you developers can do with all this data!

33
content/blog/2016/flow-available.md Normal file
View File

@@ -0,0 +1,33 @@
# The Flow Amendment is Now Available
The Flow Amendment became available on the Ripple Consensus Ledger in ledger 24,970,753 [(2016-10-21T19:47:22Z)](https://xrpcharts.ripple.com/#/transactions/C06CE3CABA3907389E4DD296C5F31C73B1548CC20BD7B83416C78CD7D4CD38FC).
This amendment replaces the payment processing engine with a more robust and efficient rewrite called the Flow engine. The new payments engine adds no new features, but improves efficiency and robustness in payment handling.
## Action Required
**If you operate a `rippled` server, then you should upgrade to version 0.33.0 or later, immediately, for service continuity.**
## Impact of Not Upgrading
If you operate a `rippled` server but don’t upgrade to version 0.33.0 or later, immediately, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server:
* Cannot determine the validity of a ledger
* Cannot submit or process transactions
* Does not participate in the consensus process
* Does not vote on future amendments
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
For other platforms, please [compile version 0.33.0 from source](https://github.com/ripple/rippled/tree/master/Builds).
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: <support@ripple.com>
* [XRP Chat](http://www.xrpchat.com/)

33
content/blog/2016/flow-reminder.md Normal file
View File

@@ -0,0 +1,33 @@
# The Flow Amendment Will Soon Be Available
A majority of `rippled` validators voted to enable the [Flow Amendment](https://ripple.com/build/amendments/#flow), which is scheduled to become active on the protocol on Thursday, 2016-10-20. This amendment replaces the payment processing engine with a more robust and efficient rewrite called the Flow engine. The new payments engine adds no new features, but improves efficiency and robustness in payment handling.
## Action Required
**If you operate a `rippled` server, then you should upgrade to version 0.33.0 or later by Thursday, 2016-10-20, for service continuity.**
## Impact of Not Upgrading
If you operate a `rippled` server but don’t upgrade to version 0.33.0 by Thursday, 2016-10-20, when Flow is expected to be enabled via Amendment, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server:
* Cannot determine the validity of a ledger
* Cannot submit or process transactions
* Does not participate in the consensus process
* Does not vote on future amendments
If the Flow amendment is vetoed or does not pass, then your server will not become amendment blocked and should continue to operate.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
For other platforms, please [compile version 0.33.0-hf1 from source](https://github.com/ripple/rippled/tree/master/Builds).
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: support@ripple.com
* [XRP Chat](http://www.xrpchat.com/)

33
content/blog/2016/flow-voting.md Normal file
View File

@@ -0,0 +1,33 @@
# The Flow Amendment is Open for Voting
Originally introduced in `rippled` [version 0.32.1](https://developers.ripple.com/blog/2016/rippled-0.32.1.html), but later [vetoed](https://developers.ripple.com/blog/2016/flowv2-vetoed.html) after a flaw was discovered in the code while testing, the new [Flow Amendment](https://ripple.com/build/amendments/#flow) is now open for voting. This amendment replaces the payment processing engine with a more robust and efficient rewrite called the Flow engine. The new payments engine adds no new features, but improves efficiency and robustness in payment handling.
## Action Required
**If you operate a `rippled` server, then you should upgrade to version 0.33.0 by Thursday, 2016-10-20, for service continuity.**
## Impact of Not Upgrading
If you operate a `rippled` server but don’t upgrade to version 0.33.0 by Thursday, 2016-10-20, when Flow is expected to be enabled via Amendment, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server:
* Cannot determine the validity of a ledger
* Cannot submit or process transactions
* Does not participate in the consensus process
* Does not vote on future amendments
If the Flow amendment is vetoed or does not pass, then your server will not become amendment blocked and should continue to operate.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
For other platforms, please [compile version 0.33.0-hf1 from source](https://github.com/ripple/rippled/tree/master/Builds).
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: support@ripple.com
* [XRP Chat](http://www.xrpchat.com/)

34
content/blog/2016/flowv2-vetoed.md Normal file
View File

@@ -0,0 +1,34 @@
# The FlowV2 Amendment Was Vetoed
## Background
[Originally](https://developers.ripple.com/blog/2016/rippled-0.32.1.html), the [FlowV2 amendment](https://ripple.com/build/amendments/#flowv2) was planned to replace `rippled`’s payment processing engine with a more robust and efficient implementation. It was previously expected to become active on Wednesday, 2016-08-24.
## FlowV2 Was Vetoed
The `rippled` team found a flaw in FlowV2 while testing. As a result, the Ripple network has [vetoed](https://ripple.com/build/amendments/#amendment-voting) the new payment engine amendment.
A corrected version of the payment processing engine has been created and is now undergoing further testing. It is scheduled to be included in a future version of `rippled` as an amendment called [Flow](https://github.com/seelabs/rippled/blob/6466629f935821583eeddadbd06fabd9ea0875d0/src/ripple/app/main/Amendments.cpp#L50-L51).
This demonstrates the robustness of Ripple’s amendment process. The review period and governance code with vetoing working as intended.
## Action Recommended
No action is currently required. However, Ripple recommends that validator operators also veto the FlowV2 amendment to ensure it does not regain a majority.
To veto the amendment, add the following, single line, under the `[veto_amendments]` stanza to the `rippled.cfg` file on validators:
```
5CC22CFF2864B020BD79E0E1F048F63EF3594F95E650E43B3F837EF1DF5F4B26 FlowV2
```
## Learn, Ask Questions, and Discuss
Related documentation is available in the Ripple Developer Portal, including detailed example API calls and web tools for API testing: <https://ripple.com/build/>
### Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* The Ripple Dev Blog: <https://developers.ripple.com/blog/>
* Ripple Technical Services: <support@ripple.com>
* XRP Chat: <http://www.xrpchat.com>

30
content/blog/2016/flowv2-voting.md Normal file
View File

@@ -0,0 +1,30 @@
# The FlowV2 Amendment is Open for Voting
The [FlowV2 Amendment](https://ripple.com/build/amendments/#flowv2) is now open for voting. This amendment replaces the payment processing engine with a more robust and efficient rewrite called the FlowV2 engine. The new version of the payment processing engine is intended to follow the same rules as the old engine. However, the new engine occasionally produces different results due to floating point rounding.
The FlowV2 Engine also makes it easier to improve and expand the payment engine with further Amendments. Ripple’s validators will vote in favor of the FlowV2 amendment. We expect the new feature to become active on Wednesday, 2016-08-24.
## Actions Required
If you operate a `rippled` server, you should upgrade to version 0.32.1 by Wednesday, 2016-08-24 for the best performance.
**Note:** A previous version of this post incorrectly stated that backend software must be updated to construct transactions for the new payment processing engine. The process of creating and submitting transactions for the FlowV2 payment engine is the same as for the previous payment engine.
## Impact of Not Upgrading
If you operate a `rippled` server but don’t upgrade to version 0.32.1 by Wednesday, 2016-08-24 (when FlowV2 is expected to become available via Amendment) then your server will become "amendment blocked" and unable to process transactions or evaluate the validity of ledgers.
For instruction on updating `rippled` on supported platforms, see: <https://ripple.com/build/rippled-setup/#updating-rippled>
For other platforms, please compile version 0.32.1 from source. For details, see <https://github.com/ripple/rippled/tree/master/Builds>
## Learn, Ask Questions, and Discuss
Related documentation is available in the Ripple Developer Portal, including detailed example API calls and web tools for API testing: <https://ripple.com/build/>
## Other Resources
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* The Ripple Dev Blog: <https://developers.ripple.com/blog/>
* Ripple Technical Services: support@ripple.com
* XRP Chat: <http://www.xrpchat.com>

44
content/blog/2016/introducing-rippleapi.md Normal file
View File

@@ -0,0 +1,44 @@
# Introducing RippleAPI
Ripple is proud to announce an improved, unified interface to the Ripple Consensus Ledger: the new **RippleAPI**! RippleAPI merges ripple-lib and Ripple-REST into a single high-level interface for JavaScript that is fully-documented, fully-tested, schema-validated, stateless, and easier to use.
If you’re excited to get started with the new RippleAPI right away, jump right in with the following resources:
1. [RippleAPI Beginners Guide](https://ripple.com/build/rippleapi-beginners-guide/) - A tutorial that introduces the basics of RippleAPI, even if you have minimal prior experience writing JavaScript applications.
2. [RippleAPI Reference](https://ripple.com/build/rippleapi/) - A thorough reference of all methods and features contained in the new API.
3. [Sample Code](https://github.com/ripple/ripple-lib/tree/develop/docs/samples) - Additional code samples for a growing variety of use cases.
4. [`ripple-lib` on GitHub](https://github.com/ripple/ripple-lib) - The RippleAPI source code is available under an open-source license so you can freely download, modify, and contribute back to the project.
For more information on how and why we built RippleAPI, read on.
## Background and Rationale
Prior to RippleAPI, there were three very different APIs to the Ripple Consensus Ledger:
1. The `rippled` APIs: a low-level interface, not designed for ease of use.
2. The ripple-lib API: a low-level javascript interface, largely undocumented
3. The Ripple-REST API: a high-level HTTP interface
In order to better focus our efforts as a company, as well as providing a better experience for all users, we merged \#2 and \#3 into a single high-level JavaScript interface.
Unfortunately, all good things come to an end, and this is the end of the line for Ripple-REST. We are no longer developing or supporting Ripple-REST, and we recommend you migrate your applications away from it. Fortunately, RippleAPI also includes an [experimental REST-like HTTP API](https://github.com/ripple/ripple-lib/blob/0.17.1/src/index.js#L7-L8), although this interface is currently unsupported.
Meanwhile, the [`rippled` APIs](https://ripple.com/build/rippled-apis/) continue to provide an alternative method of interacting with the Ripple Consensus Ledger, providing maximum power at a cost of increased complexity, so you can choose the tradeoffs that are best for your use case.
## Source Code Improvements
The RippleAPI source code is written in ECMAScript 6 (the latest JavaScript standard) and uses [Promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) to return values from asynchronous calls. The new source code also follows many of the paradigms of [functional programming](https://en.wikipedia.org/wiki/Functional_programming). The result is that the we reduced 15,000 lines of source code in ripple-lib and 6,000 lines in Ripple-REST to just 4,000 lines total in RippleAPI.
For better organization, we used the “weak layering principle” to structure the source, according to which each layer can only depend on layers below it. This means that the source files are structured into subdirectories and there are very few imports that reach into parent or sibling directories.
## Testing and Documentation
RippleAPI comes with a comprehensive array of tests, including 100% unit test coverage, integration tests for every method, flow type checking, ESLint checks, and automated testing of the documentation.
All API methods have JSON schemas that specify the return values and parameter types. The unit tests use the schemas to validate the return values, which guarantees that the API results are consistent with expectations.
We generate human-readable documentation using Embedded JavaScript, which utilizes the schemas to generate parameter tables and the test fixtures as code samples. Every Git commit comes with the latest copy of the resulting Markdown documentation, thanks to unit tests which ensure that the documentation has been re-generated whenever changes are made. As long as the unit tests are passing, the documentation is consistent with the tests, and therefore with the source code.
## Conclusion
We hope that RippleAPI will help developers harness the power of the Ripple Consensus Ledger. So [get started](https://xrpl.org/get-started-with-rippleapi-for-javascript.html), and let us know on the forums how we’re doing!

34
content/blog/2016/multisign-available.md Normal file
View File

@@ -0,0 +1,34 @@
# Multi-Signing Now Available #
As [predicted previously](https://developers.ripple.com/blog/2016/multisign-reminder.html), multi-signing became available on the Ripple Consensus Ledger this afternoon in Pacific time ([2016-06-27T11:34:41Z](https://xrpcharts.ripple.com/#/transactions/168F8B15F643395E59B9977FC99D6310E8708111C85659A9BAF8B9222EEAC5A7), to be exact).
Multi-signing provides more flexibility for sending transactions from your Ripple address. You can use multi-signing alongside a master key pair or regular key pair, or you can disable your other keys and use multi-signing exclusively. You can set and update a list of up to 8 signers, with customizable weights and quorum enabling many different use cases. The members of your signer list can be any Ripple addresses, whether they're funded addresses in the ledger or not.
Institutional users, in particular, can use the greater security of requiring multiple keys stored in different places to protect high-value addresses and large XRP holdings. Makers and experimenters should find lots of potential applications relating to internet-of-things and smart contracts. Here are just a few ideas of ways you might set up multi-signing for an address:
- **N-factor Auth:** Store 2 or more keys on different devices, and require all the devices to sign each transaction.
- **M-of-N:** Give keys to multiple people, and require a majority of signers to sign each transaction.
- **Delegate a backup plan:** Designate a team of people who can send transactions for you by working together, in case you're unavailable. Keep using single signatures for normal business.
- **Primary and Approvals:** Use the weights in your signer list to require a specific signer along with at least one other.
The Ripple Consensus Ledger's multi-signing feature also allows signers to independently rotate their keys, for even greater security. Here's a brief look at how:
1. Include the signer's address in your SignerList.
2. Fund the signer's address in the ledger.
3. Assign a [Regular Key Pair](https://ripple.com/build/transactions/#setregularkey) to the signer's address and disable its master key. (Funded addresses can only sign using their master key pair if it's not disabled.)
4. Have that signer use its regular key pair to contribute to your multi-signatures.
## Further Reading ##
- [Multi-Signing Summary](https://ripple.com/build/transactions/#multi-signing)
- [How to Multi-Sign](https://ripple.com/build/how-to-multi-sign/)
- [MultiSign Amendment](https://ripple.com/build/amendments/#multisign)
## Other resources: ##
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* The Ripple Dev Blog: <https://developers.ripple.com/blog/>
* Ripple Technical Services: [support@ripple.com](mailto:support@ripple.com)
* XRP Chat: <http://www.xrpchat.com/>

10
content/blog/2016/multisign-reminder.md Normal file
View File

@@ -0,0 +1,10 @@
# Multi-Signing Will Soon Be Available #
The multi-signing amendment is currently supported by the majority of voting validators on Ripple, and is scheduled to become active on the protocol on Monday, **2016-06-27**. For more information, please see the multi-signing documentation in the Ripple Developer Portal:
* [How to Multi-Sign](https://ripple.com/build/how-to-multi-sign/)
* [MultiSign Amendment Information](https://ripple.com/build/amendments/#multisign)
To continue receiving updates about the `rippled` server, please subscribe to the Ripple Server Google Group:
<https://groups.google.com/forum/#!forum/ripple-server>

7
content/blog/2016/rippled-0.30.1.md Normal file
View File

@@ -0,0 +1,7 @@
# rippled 0.30.1 Released
The latest version of `rippled`, the core server of the Ripple Consensus Ledger, is here! Version 0.30.1 contains lots of small features and improvements, including updates to account\_offers, server\_info, peer subscriptions, and more. It also adds several optimizations to the consensus process that have already led to a dramatic increase in the number of ledgers validated per day! Learn more:
- See the full [rippled 0.30.1 Release Notes](https://github.com/ripple/rippled/releases/0.30.1).
- See our [installation instructions](https://ripple.com/build/rippled-setup/#installing-rippled) to set up `rippled` yourself.
- Visit the [Developer Center](https://ripple.com/build/) for more information on how to use the Ripple Consensus Ledger.

50
content/blog/2016/rippled-0.31.2-updates.md Normal file
View File

@@ -0,0 +1,50 @@
# rippled 0.31.2 and Other Updates
The `rippled` team is proud to announce a bundle of related news items:
* [`rippled` release 0.31.2](#rippled-0312)
* [Amendments system](#amendments-system)
* [Transaction cost changes](#transaction-cost-changes)
* [Multi-signing](#multi-signing)
## rippled 0.31.2 ##
`rippled` 0.31 introduced several new features, including Amendments, Multi-Signing, a transaction queue, and changes to transaction cost escalation. Version 0.31.2 includes important fixes for security, stability, and compatibility with the official validators run by Ripple (the company).
We recommend all users, especially validators, upgrade as soon as possible:
* For Red Hat Enterprise Linux 7 or CentOS, you can [update to the new version using `yum`](https://ripple.com/build/rippled-setup/#updating-rippled).
* For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds).
* For more information, see the `rippled` [0.31.2 release notes](https://github.com/ripple/rippled/releases/tag/0.31.2) and [0.31.0 release notes](https://github.com/ripple/rippled/releases/tag/0.31.0) on GitHub.
## Amendments System ##
Amendments are a new feature introduced in `rippled` 0.31.0. The Amendments system provides a means of introducing new features to the decentralized Ripple consensus network without causing disruptions. The first amendment, FeeEscalation, is already live, having been approved on 2016-05-05. This amendment provides improvements to the handling of transactions when the network is under load.
The next amendment, MultiSign, introduces a way to authorize transactions using multiple signatures, for greater security and flexibility.
For more information, see [Amendments in the Ripple Developer Center](https://ripple.com/build/amendments/).
## Transaction Cost Changes ##
We have brought two significant changes to [transaction costs](https://ripple.com/build/transaction-cost/) in the `rippled` 0.31 releases. First, the FeeEscalation amendment changed the way the network escalates transaction costs under load. Second, `rippled` 0.31.2 has decreased the minimum transaction cost back to its previous value of 0.00001 XRP (10 drops).
Previously, transaction costs tended to spike rapidly when the network was under load and drop quickly when the backlog was processed, causing network volatility. As a temporary fix, Ripple configured the official validating servers to always report a load multiplier of 1000 or more. This effectively increased transaction costs from 0.00001 XRP to 0.01 XRP.
The FeeEscalation amendment, introduced in `rippled` 0.31.0 and approved by consensus on 2016-05-05, fixes this problem. The new algorithm dynamically adjusts the transaction cost based on the number of unconfirmed transactions relative to the number the network is able to confirm each round. The new algorithm reduces volatility and gives users more control over the XRP costs they pay for transactions.
An integral part of the new transaction cost algorithm is a transaction queue. If transaction costs rise because of high network load, users can submit low priority, legitimate transactions to the transaction queue to be considered for future ledgers when load decreases and transaction costs drop. The queue also makes transactions submitted during high traffic periods more likely to succeed.
With the new algorithm in place, the transaction cost escalation actually works better without the load multiplier artificially increased. Consequently, `rippled` version 0.31.2 removes the 1000× minimum from the load multiplier. Effective immediately, the minimum transaction cost is back to 0.00001 XRP. When load on the consensus network is higher, you can queue a transaction for a later ledger by paying this cost, or pay a higher XRP cost to get into the current open ledger. (How much higher depends on how large the transaction backlog is.)
## Multi-signing ##
The `rippled` team is excited to announce that the next feature to be enabled by Amendment is the ability to multi-sign transactions. Multi-signing is a new way of authorizing transactions for the Ripple Consensus Ledger, using multiple secret keys. After setting up multi-signing for an account, you can put the master secret in cold storage, or even disable the master key entirely. With multiple secret keys required to authorize a multi-signature, you can improve security in many ways.
Ripple plans to configure its validators to start voting in favor of the MultiSign amendment on 2016-06-13. If the feature maintains a majority for two weeks after that, multi-signing will become an active part of the protocol starting **2016-06-27**.
For more information, see the following articles in the Ripple Developer Center:
* [MultiSign Amendment](https://ripple.com/build/amendments/#multisign)
* [Multi-Signing transaction reference](https://ripple.com/build/transactions/#multi-signing)
* [How to Multi-Sign Tutorial](https://ripple.com/build/how-to-multi-sign/)

48
content/blog/2016/rippled-0.32.0.md Normal file
View File

@@ -0,0 +1,48 @@
# rippled version 0.32.0 has been released #
Ripple is proud to announce the release of `rippled` version 0.32.0. This release introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger. Ripple recommends that all server operators upgrade to the new version.
Highlights of this release include:
* The transaction queue now supports batching and can hold up to 10 transactions per account, allowing users to queue multiple transactions for processing when the network load is high. This encourages liquidity for XRP since important transactions now have a more reliable way of getting into the ledger. For more information, see [Queued Transactions](https://ripple.com/build/transaction-cost/#queued-transactions) in the Ripple Developer Portal.
* The `server_info` and `server_state` commands now include information on transaction cost multipliers. Customers who want to robustly submit transactions now have additional tools for accurately setting the fee based on changing network conditions. Furthermore, the `fee` command is now available to unprivileged users. For more information, see the [`rippled` API Method Reference](https://ripple.com/build/rippled-apis/#api-methods) in the Ripple Developer Portal.
* There's a new WebSocket implementation based on [Beast](https://github.com/vinniefalco/Beast). Use of this implementation is optional. A future version of `rippled` will make this WebSocket implementation the default, with the old implementation removed.
Read the complete [release notes in GitHub](https://github.com/ripple/rippled/releases/tag/0.32.0).
## Actions Required ##
1. If you operate a `rippled` server, you should upgrade to version 0.32.0 for the best performance.
2. If you have backend software which constructs and submits transactions to the Ripple network, you may need to adapt it to correctly use the network’s new transaction queue mechanism.
## Impact of Not Upgrading
If you operate a `rippled` server but don’t upgrade to version 0.32.0, your server might lose synchronization with the rest of the upgraded network for brief periods of time. That is, the local view of ledgers may be slightly behind the rest of the network.
For instruction on updating rippled on supported platforms, please see [Updating `rippled`](https://ripple.com/build/rippled-setup/#updating-rippled) in the Ripple Developer Center.
The md5sum for the rpm is: **1b37fd80fd869e42a715f17a9e30c81a**.
The md5sum for the source rpm is: **d43f4d371416b213d6197fb1c630cf44**.
For other platforms, please compile version 0.32.0 from source. See [`rippled` Build Instructions](https://github.com/ripple/rippled/tree/master/Builds) for details.
The first log entry should be the change setting the version:
commit d22eb0caa25ecfbd373cc9af0347e56031a23646
Author: seelabs <scott.determan@yahoo.com>
Date: Fri Jun 24 11:30:09 2016 -0400
Set version to 0.32.0
## Network Update ##
The Ripple operations team plans to deploy version 0.32.0 to all rippled servers under its operational control, including private clusters, starting at 1:00 PM PDT on Wednesday, 2016-06-29. The deployment is expected to complete within 4 hours.
## Learn, ask questions, and discuss ##
Ripple supported documentation including detailed example API calls and web tools for API testing are located on the Ripple Developer Portal: <https://ripple.com/build/>
### Other resources: ###
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* The Ripple Dev Blog: <https://developers.ripple.com/blog/>
* Ripple Technical Services: [support@ripple.com](mailto:support@ripple.com)
* XRP Chat: <http://www.xrpchat.com/>

81
content/blog/2016/rippled-0.32.1.md Normal file
View File

@@ -0,0 +1,81 @@
# rippled version 0.32.1
Ripple is proud to announce the release of `rippled` version 0.32.1, which introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger. Ripple recommends that all server operators upgrade to version 0.32.1 by Wednesday, 2016-08-24, for the best performance.
Highlights of this release include:
* A new, optional WebSocket implementation based on [Beast](https://github.com/vinniefalco/Beast). See below for details.
* An improved version of the payment code, which we expect to be available via an [Amendment named "FlowV2"](https://ripple.com/build/amendments/#flowv2) on Wednesday, 2016-08-24. See below for details.
## Actions Required
1. If you operate a `rippled` server, you should upgrade to version 0.32.1 by Wednesday, 2016-08-24, for the best performance.
2. If you have backend software which constructs and submits transactions to the Ripple network, you need to adapt it to correctly use the network’s new payment engine.
## Impact of Not Upgrading
If you operate a rippled server but don’t upgrade to version 0.32.1 by Wednesday, 2016-08-24, when FlowV2 is expected to become available via Amendment, then your server might lose synchronization with the rest of the upgraded network for brief periods of time. That is, the local view of ledgers may be slightly behind the rest of the network. Any rippled server operator running versions prior to 0.32.1, will also become amendment blocked.
For supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The md5sum for the rpm is: 5dcdcef01f3cfc452b0b503eaaeb07bb
The md5sum for the source rpm is: 3180fca1e83001307346f85628823a9c
For other platforms, please [compile version 0.32.1 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
commit 1ff972fbd3b82f0f7062f05f64f1abd5e274a7bc
Author: Nik Bougalis <nikb@bougalis.net>
Date: Fri Jul 29 12:52:26 2016 -0700
Set version to 0.32.1
## Network Update
The Ripple operations team plans to deploy version 0.32.1 to all rippled servers under its operational control, including private clusters, starting at 1:00 PM PDT on Thursday, 2016-08-04. The deployment is expected to complete within 4 hours. The network will continue operating during deployment and no outage is expected.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: support@ripple.com
* [XRP Chat](http://www.xrpchat.com/)
## Full Release Notes
The `rippled` 0.32.1 release includes an improved version of the payment code, which we expect to be available via Amendment on Wednesday, 2016-08-24 with the name FlowV2, and a completely new implementation of the WebSocket protocol for serving clients.
You can [update to the new version](https://ripple.com/build/rippled-setup/#updating-rippled) on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds).
**New and Updated Features**
An improved version of the payment processing engine, which we expect to be available via Amendment on Wednesday, 2016-08-24 with the name “FlowV2”. The new payments code adds no new features, but improves efficiency and robustness in payment handling.
The FlowV2 code may occasionally produce slightly different results than the old payment processing engine due to the effects of floating point rounding. Once FlowV2 is enabled on the network then old servers without the FlowV2 amendment will lose sync more frequently because of these differences.
**Beast WebSocket**
A completely new implementation of the WebSocket protocol for serving clients is available as a configurable option for `rippled` administrators. To enable this new implementation, change the “protocol” field in `rippled.cfg` from “ws” to “ws2” (or from “wss” to “wss2” for Secure WebSockets), as illustrated in this example:
[port_ws_public]
port = 5006
ip = 0.0.0.0
protocol = wss2
The new implementation paves the way for increased reliability and future performance when submitting commands over WebSocket. The behavior and syntax of commands should be identical to the previous implementation. Please report any issues to support@ripple.com. A future version of rippled will remove the old WebSocket implementation, and use only the new one.
**Bug fixes**
Fix a non-exploitable, intermittent crash in some client pathfinding requests (RIPD-1219)
Fix a non-exploitable crash caused by a race condition in the HTTP server. (RIPD-1251)
Fix bug that could cause a previously fee queued transaction to not be relayed after being in the open ledger for an extended time without being included in a validated ledger. Fix bug that would allow an account to have more than the allowed limit of transactions in the fee queue. Fix bug that could crash debug builds in rare cases when replacing a dropped transaction. (RIPD-1200)
Remove incompatible OS X switches in Test.py (RIPD-1250)
Autofilling a transaction fee (sign / submit) with the experimental `x-queue-okay` parameter will use the user’s maximum fee if the open ledger fee is higher, improving queue position, and giving the tx more chance to succeed. (RIPD-1194)

44
content/blog/2016/rippled-0.33.0-hf1.md Normal file
View File

@@ -0,0 +1,44 @@
# rippled version 0.33.0-hf1
Ripple has released `rippled` version 0.33.0-hf1, which fixes a JSON parsing issue in all `rippled` servers. Ripple recommends upgrading to 0.33.0-hf1 only if server operators are experiencing a `jsonInvalid` error response to client requests. There are no new or updated features in the 0.33.0-hf1 release.
## Action Recommended
**If you operate a `rippled` server and are experiencing a `jsonInvalid` error response to client requests, then you should upgrade to 0.33.0-hf1 immediately.**
## Impact of Not Upgrading
If you operate a `rippled` server and are experiencing a `jsonInvalid` error response to client requests, but don’t upgrade to version 0.33.0-hf1, then your server will continue to experience failing client requests.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The md5sum for the rpm is: f181f1fc801e3387487d246f9a975517
The md5sum for the source rpm is: 7993f125ed05bfeeda4e091761021429
For other platforms, please [compile version 0.33.0-hf1 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
commit 98f878cf10a32e26021b6a6ed44990bccbbc92c2
Author: Vinnie Falco <vinnie.falco@gmail.com>
Date: Sat Oct 1 12:12:34 2016 -0400
Set version to 0.33.0-hf1
## Bug Fixes
Fix a JSON parsing issue that can fail to parse valid JSON requests when the data received by the server is broken up into more than one contiguous buffer. [(#1863)](https://github.com/ripple/rippled/commit/69b47890e69cea46c403e6354742c3653f125c6f)
## Network Update
The Ripple operations team has deployed version 0.33.0-hf1 to all client facing `rippled` servers under its operational control.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: support@ripple.com
* [XRP Chat](http://www.xrpchat.com/)

95
content/blog/2016/rippled-0.33.0.md Normal file
View File

@@ -0,0 +1,95 @@
# rippled version 0.33.0
Ripple has released `rippled` version 0.33.0, which introduces several new enhancements that improve the reliability and scalability of the Ripple Consensus Ledger (RCL). Ripple recommends that all server operators upgrade to version 0.33.0 by Wednesday, 2016-10-20, for service continuity.
Highlights of this release include:
* An improved version of the payment code, which Ripple expects to be available via an [Amendment named "Flow"](https://ripple.com/build/amendments/#flow) on Wednesday, 2016-10-20. See below for details.
* Payment Channels that permit scalable, off-ledger checkpoints for high volume, low value payments flowing in a single direction, which Ripple expects to be activated via an [Amendment named “PayChan”](https://ripple.com/build/amendments/#paychan) on a future date TBA. See below for details.
* SHAMapV2 changes the hash tree structure that rippled uses to represent a ledger, which Ripple expects to be activated via an [Amendment named SHAMapV2](https://ripple.com/build/amendments/#shamapv2) on a future date TBA. See below for details.
## Action Required
**If you operate a `rippled` server, then you should upgrade to version 0.33.0 by Wednesday, 2016-10-20, for service continuity.**
## Impact of Not Upgrading
The Flow amendment is expected to be activated on Wednesday, 2016-10-20. If you operate a rippled server but don't upgrade to version 0.33.0 by that time, then your server will become amendment blocked, which means 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
If the Flow amendment is vetoed or does not pass via majority vote, then your server will not become amendment blocked and should continue to operate.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The md5sum for the rpm is: 5ad8fa43e9acf645a76d0a383eb5600a
The md5sum for the source rpm is: 38fe8c022e2fe5086f71fb9623a18064
For other platforms, please [compile version 0.33.0 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
commit f05321d501002cd7b8e7fba3ef361834689b3c26
Author: Nik Bougalis <nikb@bougalis.net>
Date: Thu Sep 29 09:25:46 2016 -0700
Set version to 0.33.0
## Network Update
The Ripple operations team plans to deploy version 0.33.0 to all rippled servers under its operational control, including private clusters, starting at 2:00 PM PDT on Thursday, 2016-09-29. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: support@ripple.com
* [XRP Chat](http://www.xrpchat.com/)
## Full Release Notes
The `rippled` 0.33.0 release includes:
* The ["Flow"](https://ripple.com/build/amendments/#flow) amendment. Ripple expects this amendment to be on Wednesday, 2016-10-20.
* XRP Payment Channels. Payment channels are a new structure in the ledger designed to support [Interledger Protocol](https://interledger.org/) trust lines as balances get substantial. Ripple expects to be activated via Amendment on a future date (TBA) with the name [“PayChan”](https://ripple.com/build/amendments/#paychan).
* Changes to the hash tree structure, which `rippled` uses hash trees to represent a ledger. Ripple expects these changes expect to be available via Amendment on a future date (TBA) with the name [SHAMapV2](https://ripple.com/build/amendments/#shamapv2).
You can [update to the new version](https://ripple.com/build/rippled-setup/#updating-rippled) on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds).
**New and Updated Features**
A fixed version of the new payment processing engine, which Ripple initially [announced on Friday, 2016-07-29](https://developers.ripple.com/blog/2016/rippled-0.32.1.html), is expected to be available via Amendment on Wednesday, 2016-10-20 with the name ["Flow"](https://ripple.com/build/amendments/#flow). The new payments code adds no new features, but improves efficiency and robustness in payment handling.
Ripple will be introducing changes to the hash tree structure that rippled uses to represent a ledger. Ripple expects these changes to be activated via Amendment on a future date (TBA) with the name [SHAMapV2](https://ripple.com/build/amendments/#shamapv2). The new structure is more compact and efficient than the previous version. This affects how ledger hashes are calculated, but has no other user-facing consequences. The activation of the SHAMapV2 amendment will require brief scheduled allowable downtime, while the changes to the hash tree structure are propagated by the network. Ripple will keep the community updated as we progress towards this date (TBA).
In an effort to make RCL more scalable and to support [Interledger Protocol](https://interledger.org/) (ILP) trust lines as balances get more substantial, Ripple is introducing XRP Payment Channels, a new structure in the ledger, which we expect to be available via Amendment on a future date (TBA) with the name [“PayChan”](https://ripple.com/build/amendments/#paychan).
XRP Payment Channels permit scalable, intermittent, off-ledger settlement of ILP trust lines for high volume, low value payments flowing in a single direction. For bidirectional channels, an XRP Payment Channel can be used in each direction. The recipient can claim any unpaid balance at any time. The owner can top off the channel as needed. The owner must wait out a delay to close the channel to give the recipient a chance to supply any claims. The total amount paid increases monotonically as newer claims are issued.
The initial concept behind payment channels was discussed as [early as 2011](https://bitcointalk.org/index.php?topic=25786.0) and the first implementation was done by Mike Hearn [in bitcoinj](https://bitcoinj.github.io/working-with-micropayments). Recent work being done by [Lightning Network](https://en.bitcoin.it/wiki/Lightning_Network) has showcased examples of the many use cases for payment channels. The introduction of XRP Payment Channels allows for a more efficient integration between RCL and ILP to further support enterprise use cases for high volume, low value payments.
* The account_info command can now return information about queued transactions - [RIPD-1205]
* Automatically-provided sequence numbers now consider the transaction queue - [RIPD-1206]
* The server_info and server_state commands now include the queue-related escalated fee factor in the load_factor field of the response - [RIPD-1207]
* A transaction with a high transaction cost can now cause transactions from the same sender queued in front of it to get into the open ledger if the transaction costs are high enough on average across all such transactions. - [RIPD-1246]
* Reorganization: Move LoadFeeTrack to app/tx and clean up functions - [RIPD-956]
* Reorganization: unit test source files - [RIPD-1132]
* Reorganization: NuDB stand-alone repository - [RIPD-1163]
* Reorganization: Add BEAST_EXPECT to Beast - [RIPD-1243]
* Reorganization: Beast 64-bit CMake/Bjam target on Windows - [RIPD-1262]
**Bug Fixes**
Correct an issue with PaymentSandbox::balanceHook that can return the wrong issuer, which could cause the transfer fee to be incorrectly by-passed in rare circumstances. [(#1827)](https://github.com/ripple/rippled/commit/cf8b6be494c3537f3d6eeeb0a23d5454402688b1)
Correct an issue with the new websocket implementation, which could cause concurrent writes on a single websocket connection. This could result in sporadic crashes when the server was under high load. [(#1806)](https://github.com/ripple/rippled/commit/e8a7ad47487aba3490bb63359ff17cfe584cd58c)
Add HTTP status page for new websocket implementation. [(#1855)](https://github.com/ripple/rippled/commit/b2499c8fa015ac0121b81dcf8f1a92d9e1fd6a4b)

80
content/blog/2016/rippled-0.40.0.md Normal file
View File

@@ -0,0 +1,80 @@
# rippled version 0.40.0
Ripple has released `rippled` version 0.40.0, which introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger (RCL). Ripple recommends that all server operators upgrade to version 0.40.0 by Tuesday, 2017-01-17, for service continuity.
Highlights of this release include:
* Suspended Payments, a new transaction type on the Ripple network that functions similar to an escrow service, which permits users to cryptographically escrow XRP on RCL with an expiration date. Ripple expects Suspended Payments to be enabled via an [Amendment named “SusPay”](https://ripple.com/build/amendments/#suspay) on Tuesday, 2017-01-17. See below for details.
## Action Required
If you operate a `rippled` server, then you should upgrade to version 0.40.0 by Tuesday, 2017-01-17, for service continuity.
## Impact of Not Upgrading
If you operate a `rippled` server but don’t upgrade to version 0.40.0 by Wednesday, 2017-01-17, when SusPay is expected to be activated via Amendment, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server:
* Cannot determine the validity of a ledger
* Cannot submit or process transactions
* Does not participate in the consensus process
* Does not vote on future amendments
* Could rely on potentially invalid data
If the SusPay amendment is vetoed or does not pass via majority vote, then your server will not become amendment blocked.
For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled).
The md5sum for the rpm is: 27d0d142f29bcde7d240d91d44b5d7dc
The md5sum for the source rpm is: b3b5ab6897f3c08b492f383ef7763c21
For other platforms, please [compile version 0.40.0 from source](https://github.com/ripple/rippled/tree/master/Builds).
The first log entry should be the change setting the version:
commit 7fc780dd70faef819eace27a12de35dd1363c069
Author: Nik Bougalis <nikb@bougalis.net>
Date: Tue Dec 20 09:20:17 2016 -0800
Set version to 0.40.0
## Network Update
The Ripple operations team plans to deploy version 0.40.0 to a subset of rippled servers under its operational control configured with the new websocket implementation, starting at 2:00 PM PDT on Thursday, 2017-12-20. The network will continue operating during deployment and no outage is expected.
## Learn, ask questions, and discuss
Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing.
Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* [The Ripple Dev Blog](https://developers.ripple.com/blog/)
* Ripple Technical Services: support@ripple.com
* [XRP Chat](http://www.xrpchat.com/)
## Full Release Notes
The `rippled` 0.40.0 release includes Suspended Payments, a new transaction type on the Ripple network that functions similar to an escrow service, which permits users to lock XRP until a cryptographic condition is met or it expires. Ripple expects Suspended Payments to be enabled via an [Amendment named “SusPay”](https://ripple.com/build/amendments/#suspay) on Tuesday, 2017-01-17.
You can [update to the new version](https://ripple.com/build/rippled-setup/#updating-rippled) on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds).
**New and Updated Features**
Previously, Ripple [announced](https://developers.ripple.com/blog/2016/rippled-0.33.0.html) the introduction of Payment Channels during the release of rippled version 0.33.0, which permit scalable, off-ledger checkpoints of high volume, low value payments flowing in a single direction. This was the first step in a multi-phase effort to make RCL more scalable and to support [Interledger Protocol](https://interledger.org/interledger.pdf) (ILP). Ripple expects Payment Channels to be enabled via an [Amendment called PayChan](https://ripple.com/build/amendments/#paychan) on a future date to be determined.
In the second phase towards making RCL more scalable and compatible with ILP, Ripple is introducing Suspended Payments, a new transaction type on the Ripple network that functions similar to an escrow service, which permits users to cryptographically escrow XRP on RCL with an expiration date. Ripple expects Suspended Payments to be enabled via an [Amendment named “SusPay”](https://ripple.com/build/amendments/#suspay) on Tuesday, 2017-01-17.
A Suspended Payment can be created, which deducts the funds from the sending account. It can then be either fulfilled or canceled. It can only be fulfilled if the fulfillment transaction makes it into a ledger with a CloseTime lower than the expiry date of the transaction. It can be canceled with a transaction that makes it into a ledger with a CloseTime greater than the expiry date of the transaction.
In the third phase towards making RCL more scalable and compatible with ILP, Ripple plans to introduce additional library support for crypto-conditions, which are distributable event descriptions written in a standard format that describe how to recognize a fulfillment message without saying exactly what the fulfillment is. Fulfillments are cryptographically verifiable messages that prove an event occurred. If you transmit a fulfillment, then everyone who has the condition can agree that the condition has been met. Fulfillment requires the submission of a signature that matches the condition (message hash and public key). This format supports multiple algorithms, including different hash functions and cryptographic signing schemes. Crypto-conditions can be nested in multiple levels, with each level possibly having multiple signatures.
Lastly, we do not have an update on the [previously announced](https://developers.ripple.com/blog/2016/rippled-0.33.0.html) changes to the hash tree structure that rippled uses to represent a ledger, called [SHAMapV2](https://ripple.com/build/amendments/#shamapv2). This will require brief scheduled allowable downtime while the changes to the hash tree structure are propagated by the network. We will keep the community updated as we progress towards this date (TBA).
* Consensus refactor [(#1874)](https://github.com/ripple/rippled/pull/1874)
**Bug Fixes**
* Correct an issue in payment flow code that did not remove an unfunded offer [(#1860)](https://github.com/ripple/rippled/pull/1860)
* Sign validator manifests with both ephemeral and master keys [(#1865)](https://github.com/ripple/rippled/pull/1865)
* Correctly parse multi-buffer JSON messages [(#1862)](https://github.com/ripple/rippled/pull/1862)

32
content/blog/2016/testnet-ledger-reset.md Normal file
View File

@@ -0,0 +1,32 @@
# Ripple Test Network Ledger Will Be Reset
## Summary
On 2016-09-02, Ripple will be resetting the [test network](https://xrpl.org/xrp-test-net-faucet.html) ledger and balances. This means that all test net order books will be deleted and all account balances will be depleted.
This will have absolutely no effect on the live, production Ripple Consensus Ledger (RCL).
## Action Required
If you have projects built or scripts running on test net, then new order books will have to be created and new account balances will have to be topped up.
## Background
Ripple operates the test network to ensure new features and fixes operate as planned before rolling them out to the live network. As a matter of policy, we have always stated publicly that the test net will be be reset on a regular basis, however in practice the ledger and balances have never been reset. As the Ripple network continues to grow, we view this as necessary.
## Schedule
Moving forward, we will likely be resetting the test net ledger and balances on or around the first of every month.
We hope that this new planned schedule will also help the community plan their development projects and tests accordingly, although the test net may also be reset from time to time without notice.
## Learn, Ask Questions, and Discuss
Please refer to the Test Net page for information on generating new test net credentials and connecting to test net servers: <https://xrpl.org/xrp-test-net-faucet.html>
### Other resources:
* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`)
* The Ripple Dev Blog: <https://developers.ripple.com/blog/>
* Ripple Technical Services: <support@ripple.com>
* XRP Chat: <http://www.xrpchat.com>

29
content/blog/2016/trustsetauth-available.md Normal file
View File

@@ -0,0 +1,29 @@
# TrustSetAuth is Now Available
As [predicted previously](https://developers.ripple.com/blog/2016/trustsetauth-reminder.html), TrustSetAuth became available on the Ripple Consensus Ledger this afternoon (PDT) in ledger 22,721,281 ([2016-07-19T15:10](https://xrpcharts.ripple.com/#/transactions/0E589DE43C38AED63B64FF3DA87D349A038F1821212D370E403EB304C76D70DF)).
This amendment allows pre-authorization of accounting relationships (zero-balance trust lines) when using Authorized Accounts.
## Action Required
To remain operational, all `rippled` instances running on a version earlier than 0.31.0 must be [upgraded](https://ripple.com/build/rippled-setup/#updating-rippled) to `rippled` server **[version 0.32.0](https://developers.ripple.com/blog/2016/rippled-0.32.0.html)** immediately.
See [Updating `rippled`](https://ripple.com/build/rippled-setup/#updating-rippled) for more information about upgrading `rippled`.
## Impact of Not Upgrading
If you operate a `rippled` server on a version earlier than 0.31.0 but do not upgrade to version 0.32.0 immediately, then your server will not be able to synchronize with the rest of the upgraded network.
## Why is the TrustSetAuth Amendment Important?
With this amendment enabled, currency issuers can authorize other addresses to hold their issued currencies without waiting for the counterparty to take action. Without the amendment enabled, currency issuers cannot authorize other addresses to hold their issued currencies unless the currency holder first creates an accounting relationship with the currency issuer and sets a limit with a TrustSet transaction.
## Learn More
For more information, please see the TrustSetAuth documentation in the [Ripple Developer Portal](https://ripple.com/build/):
* [Authorized Accounts](https://ripple.com/build/gateway-guide/#authorized-accounts)
* [Amendments](https://ripple.com/build/amendments/#trustsetauth)
To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: https://groups.google.com/forum/#!forum/ripple-server

26
content/blog/2016/trustsetauth-reminder.md Normal file
View File

@@ -0,0 +1,26 @@
TrustSetAuth Will Soon Be Available
===================================
This notice is for all validator operators, and may be useful for gateways that utilize the Authorized Accounts feature.
A majority of trusted validators voted to enable the TrustSetAuth amendment, which is scheduled to become active on the protocol on Tuesday, 2016-07-19. This amendment allows pre-authorization of accounting relationships (zero-balance trust lines) when using Authorized Accounts.
With this amendment enabled, currency issuers can authorize other addresses to hold their issued currencies without waiting for the other addresses to take action. Without the amendment, currency holders must first create the accounting relationship with the issuer by setting a limit with a TrustSet transaction.
## Action Required ##
To remain operational, all `rippled` instances running on the version below 0.31.0 must be upgraded to `rippled` server **[version 0.32.0](https://developers.ripple.com/blog/2016/rippled-0.32.0.html)** by Tuesday, 2016-07-19.
## Impact of Not Upgrading ##
If you operate a `rippled` server on a version below 0.31.0 but do not upgrade to [version 0.32.0](https://developers.ripple.com/blog/2016/rippled-0.32.0.html) by Tuesday, 2016-07-19, then your server will not be able to synchronize with the rest of the upgraded network.
## Learn More ##
For more information, please see the documentation in the Ripple Developer Portal:
* [Upgrading `rippled`](https://ripple.com/build/rippled-setup/#updating-rippled)
* [Authorized Accounts](https://ripple.com/build/gateway-guide/#authorized-accounts)
* [TrustSetAuth Amendment](https://ripple.com/build/amendments/#trustsetauth)
To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: <https://groups.google.com/forum/#!forum/ripple-server>

16
content/blog/2016/trustsetauth-voting.md Normal file
View File

@@ -0,0 +1,16 @@
# The TrustSetAuth Amendment Is Open For Voting #
This notice is for all validator operators, and may be relevant to gateways that utilize the Authorized Account feature.
The new [TrustSetAuth amendment](https://ripple.com/build/amendments/#trustsetauth) is open for voting now. This amendment allows pre-authorization of accounting relationships (zero-balance trust lines) when using [Authorized Accounts](https://ripple.com/build/gateway-guide/#authorized-accounts). With this amendment enabled, currency issuers can authorize other addresses to hold their issued currencies without waiting for the other addresses to take action. Without the amendment, currency holders must first create the accounting relationship with the issuer by setting a limit with a [TrustSet transaction](https://ripple.com/build/transactions/#trustset).
Ripple's validators will vote in favor of the TrustSetAuth amendment, and we expect the new feature to become active by 2016-07-19.
For more information, see the following articles in the Ripple Developer Center:
* Authorized Accounts: <https://ripple.com/build/gateway-guide/#authorized-accounts>
* Amendments: <https://ripple.com/build/amendments/>
To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group:
<https://groups.google.com/forum/#!forum/ripple-server>