mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-21 04:05:49 +00:00
IA: add links for tutorials
IA: more tutorial links IA: Tutorials stuff - Move 'Cancel or Skip a Transaction' to 'About Canceling a Transaction' (Fixes #582) - Add more 'See Also' links to Escrow & Payment Channel tutorials
This commit is contained in:
mDuo13
@@ -28,8 +28,9 @@
|
||||
[AccountRoot object]: accountroot.html
|
||||
|
||||
<!--{# Links to external sites #}-->
|
||||
[crypto-condition]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-03
|
||||
[crypto-conditions]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-03
|
||||
[crypto-condition]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-04
|
||||
[crypto-conditions]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-04
|
||||
[Crypto-Conditions Specification]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-04
|
||||
[hexadecimal]: https://en.wikipedia.org/wiki/Hexadecimal
|
||||
[Interledger Protocol]: https://interledger.org/
|
||||
[RFC-1751]: https://tools.ietf.org/html/rfc1751
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
# About Canceling a Transaction
|
||||
|
||||
An important and intentional feature of the XRP Ledger is that a [transaction](transaction-basics.html)'s outcome is [final](finality-of-results.html) as soon as it has been incorporated in a [ledger version](ledgers.html) that is validated by the [consensus process](consensus.html).
|
||||
|
||||
If a transaction has _not_ yet been included in a validated ledger, it may be possible to effectively cancel it by sending another transaction from the same sending address with the same `Sequence` value. If you do not want the replacement transaction to do anything, send an [AccountSet transaction][] with no options.
|
||||
|
||||
**Caution:** There is no guaranteed way to cancel a valid transaction after it has been distributed to the network. The process described here may or may not work depending on a number of factors including how busy the network is, the network topology, and the [transaction cost](transaction-cost.html) of the proposed transaction.
|
||||
|
||||
If the transaction has already been distributed to the network and proposed as a [candidate transaction](consensus.html#consensus-1) in servers' consensus proposals, it may be too late to cancel. It is more likely that you can successfully cancel a transaction that is [queued](transaction-queue.html) or is stuck "in limbo" because its [transaction cost](transaction-cost.html) is not high enough to meet the network's current requirements. In this case, the replacement transaction can either do nothing, or do the same thing as the transaction to be canceled. The replacement transaction is more likely to succeed if its transaction cost is higher.
|
||||
|
||||
For example, if you try to submit 3 transactions with sequence numbers 11, 12, and 13, but transaction 11 gets lost somehow or does not have a high enough [transaction cost](transaction-cost.html) to be propagated to the network, then you can cancel transaction 11 by submitting an AccountSet transaction with no options and sequence number 11. This does nothing (except destroying the transaction cost for the new transaction 11), but it allows transactions 12 and 13 to become valid.
|
||||
|
||||
This approach is preferable to renumbering and resubmitting transactions 12 and 13, because it prevents transactions from being effectively duplicated under different sequence numbers.
|
||||
|
||||
In this way, an AccountSet transaction with no options is the canonical "[no-op](http://en.wikipedia.org/wiki/NOP)" transaction.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,4 +1,4 @@
|
||||
# RippleAPI Beginners Guide
|
||||
# Get Started with RippleAPI for JavaScript
|
||||
|
||||
This tutorial guides you through the basics of building an XRP Ledger-connected application using [Node.js](http://nodejs.org/) and [RippleAPI](rippleapi-reference.html), a JavaScript API for accessing the XRP Ledger.
|
||||
|
||||
@@ -327,3 +327,16 @@ To use this example, you must first [build a browser-compatible version of Rippl
|
||||
```
|
||||
|
||||
This demo HTML loads Lodash v4.17.11 from CDNJS on Cloudflare and then loads ripple-lib v1.1.2, but you could also download and load a variant of Lodash locally. <!--#{ no specific recommended or required version at this time. Update this once we have some guidance to provide here. }#-->
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [XRP Ledger Overview](xrp-ledger-overview.html)
|
||||
- [Software Ecosystem](software-ecosystem.html)
|
||||
- **Tutorials:**
|
||||
- [Send XRP](send-xrp.html)
|
||||
- **References:**
|
||||
- [RippleAPI Reference](rippleapi-reference.html)
|
||||
- [rippled API Conventions](api-conventions.html)
|
||||
- [base58 Encodings](base58-encodings.html)
|
||||
- [rippled Transaction Formats](transaction-formats.html)
|
||||
|
||||
@@ -6,6 +6,7 @@ Alternatively, you can [run your own local copy of `rippled`](install-rippled.ht
|
||||
|
||||
The [example config file](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1050-L1073) listens for connections on the local loopback network (127.0.0.1), with JSON-RPC (HTTP) on port 5005 and WebSocket (WS) on port 6006, and treats all connected clients as admin.
|
||||
|
||||
|
||||
## WebSocket API
|
||||
|
||||
If you are looking to try out some methods on the XRP Ledger, you can skip writing your own WebSocket code and go straight to using the API at the [Ripple WebSocket API Tool](websocket-api-tool.html). Later on, when you want to connect to your own `rippled` server, you can [build your own client in the browser](monitor-incoming-payments-with-websocket.html) or [in Node.js](https://www.npmjs.com/package/ws).
|
||||
@@ -84,6 +85,7 @@ rippled --conf=/etc/rippled.cfg server_info
|
||||
|
||||
The commandline puts the command after any normal (dash-prefaced) commandline options, followed by a limited set of parameters, separated by spaces. For any parameter values that might contain spaces or other unusual characters, use single-quotes to encapsulate them.
|
||||
|
||||
|
||||
## Example Request
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
@@ -124,6 +126,7 @@ rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated true
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
## Response Formatting
|
||||
|
||||
### Example Successful Response
|
||||
@@ -176,6 +179,7 @@ HTTP Status: 200 OK
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
@@ -211,4 +215,19 @@ The fields of a successful response include:
|
||||
| `result` | Object | The result of the query; contents vary depending on the command. |
|
||||
|
||||
### Commandline
|
||||
|
||||
The response format for commandline methods is the same as JSON-RPC responses, because they use the same interface.
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [XRP Ledger Overview](xrp-ledger-overview.html)
|
||||
- [Software Ecosystem](software-ecosystem.html)
|
||||
- [Parallel Networks](parallel-networks.html)
|
||||
- **Tutorials:**
|
||||
- [Get Started with RippleAPI for JavaScript](get-started-with-rippleapi-for-javascript.html)
|
||||
- [Reliable Transaction Submission](reliable-transaction-submission.html)
|
||||
- [Manage the rippled Server](manage-the-rippled-server.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [Ripple Data API v2](data-api.html)
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Look Up Transaction Results
|
||||
|
||||
To use the XRP Ledger effectively, you need to be able to understand transaction outcomes: did the transaction succeed? What did it accomplish? If it failed, why?
|
||||
To use the XRP Ledger effectively, you need to be able to understand [transaction](transaction-basics.html) outcomes: did the transaction succeed? What did it accomplish? If it failed, why?
|
||||
|
||||
The XRP Ledger is a shared system, with all data recorded publicly and carefully, securely updated with each new [ledger version](ledgers.html). Anyone can look up the exact outcome of any transaction and read the [transaction metadata](transaction-metadata.html) to see what it did.
|
||||
|
||||
@@ -427,9 +427,16 @@ Most other transactions create a specific type of ledger entry and [adjust the s
|
||||
|
||||
## See Also
|
||||
|
||||
- [Ledger Object Types Reference](ledger-object-types.html) - All possible fields of all types of ledger objects
|
||||
- [Transaction Metadata](transaction-metadata.html) - Summary of the metadata format and fields that appear in metadata
|
||||
- [Finality of Results](finality-of-results.html) - How to know when a transaction's success or failure is final. (Short version: if a transaction is in a validated ledger, its outcome and metadata are final.)
|
||||
- **Concepts:**
|
||||
- [Finality of Results](finality-of-results.html) - How to know when a transaction's success or failure is final. (Short version: if a transaction is in a validated ledger, its outcome and metadata are final.)
|
||||
- **Tutorials:**
|
||||
- [Reliable Transaction Submission](reliable-transaction-submission.html)
|
||||
- [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html)
|
||||
- **References:**
|
||||
- [Ledger Object Types Reference](ledger-object-types.html) - All possible fields of all types of ledger objects
|
||||
- [Transaction Metadata](transaction-metadata.html) - Summary of the metadata format and fields that appear in metadata
|
||||
- [Transaction Results](transaction-results.html) - Tables of all possible result codes for transactions.
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Monitor Incoming Payments with WebSocket
|
||||
|
||||
This tutorial shows how to monitor for incoming payments using the [WebSocket `rippled` API](rippled-api.html). Since all XRP Ledger transactions are public, anyone can monitor incoming payments to any address.
|
||||
This tutorial shows how to monitor for incoming [payments](payment-types.html) using the [WebSocket `rippled` API](rippled-api.html). Since all XRP Ledger transactions are public, anyone can monitor incoming payments to any address.
|
||||
|
||||
WebSocket follows a model where the client and server establish one connection, then send messages both ways through the same connection, which remains open until explicitly closed (or until the connection fails). This is in contrast to the HTTP-based API model (including JSON-RPC and RESTful APIs), where the client opens and closes a new connection for each request.[¹](#footnote-1)<a id="from-footnote-1"></a>
|
||||
|
||||
**Tip:** The examples in this page use JavaScript so that the examples can run natively in a web browser. If you are developing in JavaScript, you can also use the [RippleAPI library for JavaScript](https://xrpl.org/rippleapi-reference.html) to simplify some tasks. This tutorial shows how to monitor for transactions _without_ using RippleAPI so that you can translate the steps to other programming languages that don't have RippleAPI.
|
||||
**Tip:** The examples in this page use JavaScript so that the examples can run natively in a web browser. If you are developing in JavaScript, you can also use the [RippleAPI library for JavaScript](rippleapi-reference.html) to simplify some tasks. This tutorial shows how to monitor for transactions _without_ using RippleAPI so that you can translate the steps to other programming languages that don't have RippleAPI.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -580,6 +580,18 @@ func main() {
|
||||
|
||||
[1.](#from-footnote-1) <a id="footnote-1"></a> In practice, when calling an HTTP-based API multiple times, the client and server may reuse the same connection for several requests and responses. This practice is called [HTTP persistent connection, or keep-alive](https://en.wikipedia.org/wiki/HTTP_persistent_connection). From a development standpoint, the code to use an HTTP-based API is the same regardless of whether the underlying connection is new or reused.
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Transaction Basics](transaction-basics.html)
|
||||
- [Finality of Results](finality-of-results.html) - How to know when a transaction's success or failure is final. (Short version: if a transaction is in a validated ledger, its outcome and metadata are final.)
|
||||
- **Tutorials:**
|
||||
- [Reliable Transaction Submission](reliable-transaction-submission.html)
|
||||
- [Look Up Transaction Results](look-up-transaction-results.html)
|
||||
- **References:**
|
||||
- [Transaction Types](transaction-types.html)
|
||||
- [Transaction Metadata](transaction-metadata.html) - Summary of the metadata format and fields that appear in metadata
|
||||
- [Transaction Results](transaction-results.html) - Tables of all possible result codes for transactions.
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Set Up Secure Signing
|
||||
|
||||
To submit transactions to the XRP Ledger, you need a way to digitally sign them without compromising the security of your secret keys. (If others gain access to your secret keys, they have as much control over your accounts as you do, and can steal or destroy all your money.) This page summarizes how to set up such an environment so you can sign transactions securely.
|
||||
To submit [transactions](transaction-basics.html) to the XRP Ledger, you need a way to digitally sign them without compromising the security of your [secret keys](cryptographic-keys.html). (If others gain access to your secret keys, they have as much control over your accounts as you do, and can steal or destroy all your money.) This page summarizes how to set up such an environment so you can sign transactions securely.
|
||||
|
||||
**Tip:** If you are not submitting transactions to the network, you can safely use a trustworthy public server, such as the ones run by Ripple, to monitor for incoming transactions or just to read other network activity. All transactions, balances, and data in the XRP Ledger are public.
|
||||
|
||||
@@ -103,6 +103,22 @@ This configuration uses a `rippled` server hosted remotely, such as in a colocat
|
||||
To use this configuration, follow the steps for [running `rippled` on a private LAN](#run-rippled-on-the-same-lan), but use a VPN to connect to the LAN of the remote `rippled` server. Instructions for setting up the VPN are specific to your environment and are not described in this guide.
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Cryptographic Keys](cryptographic-keys.html)
|
||||
- [Multi-Signing](multi-signing.html)
|
||||
- **Tutorials:**
|
||||
- [Install rippled](install-rippled.html)
|
||||
- [Assign a Regular Key Pair](assign-a-regular-key-pair.html)
|
||||
- [Reliable Transaction Submission](reliable-transaction-submission.html)
|
||||
- [Enable Public Signing](enable-public-signing.html)
|
||||
- **References:**
|
||||
- [sign method][]
|
||||
- [submit method][]
|
||||
- [RippleAPI Reference](rippleapi-reference.html)
|
||||
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Assign a Regular Key Pair
|
||||
|
||||
The XRP Ledger allows an account to authorize a secondary key pair, called a _regular key pair_, to sign future transactions. If the private key of a regular key pair is compromised, you can remove or replace it without changing the rest of your account and re-establishing its relationships to other accounts. You can also rotate a regular key pair proactively. (Neither of those things is possible for the master key pair of an account, which is intrinsically linked to the account's address.)
|
||||
The XRP Ledger allows an account to authorize a secondary key pair, called a _[regular key pair](cryptographic-keys.html)_, to sign future transactions. If the private key of a regular key pair is compromised, you can remove or replace it without changing the rest of your [account](accounts.html) and re-establishing its relationships to other accounts. You can also rotate a regular key pair proactively. (Neither of those things is possible for the master key pair of an account, which is intrinsically linked to the account's address.)
|
||||
|
||||
For more information about master and regular key pairs, see [Cryptographic Keys](cryptographic-keys.html).
|
||||
|
||||
@@ -9,7 +9,7 @@ This tutorial walks through the steps required to assign a regular key pair to y
|
||||
1. [Generate a key pair](#1-generate-a-key-pair)
|
||||
2. [Assign the key pair to your account as a regular key pair](#2-assign-the-key-pair-to-your-account-as-a-regular-key-pair)
|
||||
3. [Verify the regular key pair](#3-verify-the-regular-key-pair)
|
||||
4. [Explore next steps](#4-explore-next-steps)
|
||||
4. [Explore next steps](#see-also)
|
||||
|
||||
|
||||
## 1. Generate a Key Pair
|
||||
@@ -660,14 +660,27 @@ An example of a successful response:
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
## 4. Explore Next Steps
|
||||
## See Also
|
||||
|
||||
Now that you're familiar with the benefits of assigning a regular key pair to an account, consider taking a look at these related topics and tutorials:
|
||||
|
||||
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
|
||||
- [Set Up Multi-Signing](set-up-multi-signing.html)
|
||||
- [Issuing and Operational Addresses](issuing-and-operational-addresses.html)
|
||||
- [List XRP as an Exchange](list-xrp-as-an-exchange.html)
|
||||
- **Concepts:**
|
||||
- [Cryptographic Keys](cryptographic-keys.html)
|
||||
- [Multi-Signing](multi-signing.html)
|
||||
- [Issuing and Operational Addresses](issuing-and-operational-addresses.html)
|
||||
- **Tutorials:**
|
||||
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
|
||||
- [Set Up Multi-Signing](set-up-multi-signing.html)
|
||||
- [List XRP as an Exchange](list-xrp-as-an-exchange.html)
|
||||
- **References:**
|
||||
- [wallet_propose method][]
|
||||
- [sign method][]
|
||||
- [SetRegularKey transaction][]
|
||||
- [AccountRoot object](accountroot.html) where the regular key is stored in the field `RegularKey`
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Change or Remove a Regular Key Pair
|
||||
|
||||
The XRP Ledger allows an account to authorize a secondary key pair, called a _regular key pair_, to sign future transactions. If your account's regular key pair is compromised, or if you just want to periodically change the regular key pair as a security measure, use a [SetRegularKey transaction][] to remove or change the regular key pair for your account.
|
||||
The XRP Ledger allows an account to authorize a secondary key pair, called a _[regular key pair](cryptographic-keys.html)_, to sign future transactions. If your [account](accounts.html)'s regular key pair is compromised, or if you just want to periodically change the regular key pair as a security measure, use a [SetRegularKey transaction][] to remove or change the regular key pair for your account.
|
||||
|
||||
For more information about master and regular key pairs, see [Cryptographic Keys](cryptographic-keys.html).
|
||||
|
||||
@@ -40,7 +40,7 @@ An example of the request format:
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"command": "sign",
|
||||
"tx_json": {
|
||||
@@ -53,7 +53,7 @@ An example of the request format:
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"method": "sign",
|
||||
"params": [
|
||||
@@ -70,7 +70,7 @@ An example of the request format:
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
```sh
|
||||
#Syntax: sign secret tx_json
|
||||
rippled sign snoPBrXtMeMyMHUVTgbuqAfg1SUTb '{"TransactionType": "SetRegularKey", "Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"}'
|
||||
```
|
||||
@@ -86,7 +86,7 @@ An example of a successful response:
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
@@ -108,8 +108,8 @@ An example of a successful response:
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{NEWWWWWWWWWWWW
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"status": "success",
|
||||
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
@@ -129,7 +129,7 @@ An example of a successful response:
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"result" : {
|
||||
"status" : "success",
|
||||
@@ -167,7 +167,7 @@ An example of the request format:
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"command": "submit",
|
||||
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E"
|
||||
@@ -176,7 +176,7 @@ An example of the request format:
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"method":"submit",
|
||||
"params":[
|
||||
@@ -189,7 +189,7 @@ An example of the request format:
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
```sh
|
||||
#Syntax: submit tx_blob
|
||||
rippled submit 1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E
|
||||
```
|
||||
@@ -205,7 +205,7 @@ An example of a successful response:
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"engine_result": "tesSUCCESS",
|
||||
@@ -230,7 +230,7 @@ An example of a successful response:
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"engine_result": "tesSUCCESS",
|
||||
@@ -254,7 +254,7 @@ An example of a successful response:
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"result" : {
|
||||
"engine_result" : "tesSUCCESS",
|
||||
@@ -291,7 +291,7 @@ An example of a successful response:
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"error": "badSecret",
|
||||
"error_code": 41,
|
||||
@@ -311,8 +311,8 @@ An example of a successful response:
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{NEWWWWWWWWWWWW
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"error": "badSecret",
|
||||
"error_code": 41,
|
||||
@@ -332,7 +332,7 @@ An example of a successful response:
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"result" : {
|
||||
"error" : "badSecret",
|
||||
@@ -355,6 +355,22 @@ An example of a successful response:
|
||||
|
||||
In some cases, you can even use the `SetRegularKey` transaction to send a [key reset transaction](transaction-cost.html#key-reset-transaction) without paying the [transaction cost](transaction-cost.html). With the enablement of the FeeEscalation amendment, `rippled` prioritizes key reset transactions above other transactions even though the nominal transaction cost of a key reset transaction is zero.
|
||||
|
||||
|
||||
- **Concepts:**
|
||||
- [Cryptographic Keys](cryptographic-keys.html)
|
||||
- [Multi-Signing](multi-signing.html)
|
||||
- [Transaction Cost](transaction-cost.html)
|
||||
- **Tutorials:**
|
||||
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
|
||||
- [Set Up Multi-Signing](set-up-multi-signing.html)
|
||||
- [List XRP as an Exchange](list-xrp-as-an-exchange.html)
|
||||
- **References:**
|
||||
- [wallet_propose method][]
|
||||
- [sign method][]
|
||||
- [SetRegularKey transaction][]
|
||||
- [AccountRoot object](accountroot.html) where the regular key is stored in the field `RegularKey`
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -1,14 +1,19 @@
|
||||
# Require Destination Tags
|
||||
|
||||
The `RequireDest` setting (`requireDestinationTag` in RippleAPI) is designed to prevent customers from sending payments to your address if they forgot the [destination tag](source-and-destination-tags.html) that identifies who should be credited for the payment. When enabled, the XRP Ledger rejects any payment to your address that does not specify a destination tag.
|
||||
The `RequireDest` setting (`requireDestinationTag` in RippleAPI) is designed to prevent customers from sending [payments](payment-types.html) to your address if they forgot the [destination tag](source-and-destination-tags.html) that identifies whom to credit for the payment. When enabled, the XRP Ledger rejects any payment to your address if it does not specify a destination tag.
|
||||
|
||||
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction to enable the `RequireDest` flag:
|
||||
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an [AccountSet transaction][] to enable the `RequireDest` flag:
|
||||
|
||||
Request:
|
||||
|
||||
```
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
POST http://localhost:5005/
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [
|
||||
@@ -29,9 +34,15 @@ Content-Type: application/json
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
Response:
|
||||
|
||||
```
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
200 OK
|
||||
|
||||
{
|
||||
@@ -57,11 +68,24 @@ Response:
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- [Source and Destination Tags](source-and-destination-tags.html)
|
||||
- [XRP Ledger Businesses](xrp-ledger-businesses.html)
|
||||
- [Payment Types](payment-types.html)
|
||||
- **Concepts:**
|
||||
- [Accounts](accounts.html)
|
||||
- [Source and Destination Tags](source-and-destination-tags.html)
|
||||
- [Transaction Cost](transaction-cost.html)
|
||||
- [Payment Types](payment-types.html)
|
||||
- **Tutorials:**
|
||||
- [XRP Ledger Businesses](xrp-ledger-businesses.html)
|
||||
- **References:**
|
||||
- [account_info method][]
|
||||
- [AccountSet transaction][]
|
||||
- [AccountRoot Flags](accountroot.html#accountroot-flags)
|
||||
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
|
||||
@@ -1,37 +1,34 @@
|
||||
# Set Up Multi-Signing
|
||||
|
||||
Multi-signing is one of three ways to authorize transactions for the XRP Ledger, alongside signing with [regular keys and master keys](cryptographic-keys.html). You can configure your address to allow any combination of the three methods to authorize transactions.
|
||||
[Multi-signing](multi-signing.html) is one of three ways to authorize [transactions](transaction-basics.html) for the XRP Ledger, alongside signing with [regular keys and master keys](cryptographic-keys.html). You can configure your [address](accounts.html) to allow any combination of the three methods to authorize transactions.
|
||||
|
||||
This tutorial demonstrates how to enable multi-signing for an address.
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- You must have a funded XRP Ledger address.
|
||||
- You must have a funded XRP Ledger [address](accounts.html) with enough spare XRP to send transactions and meet the [reserve requirement](reserves.html) of a new signer list.
|
||||
|
||||
- With the [MultiSignReserve amendment][] enabled, multi-signing requires 5 XRP for the account reserve, regardless of the number of signers and signatures you use. (The MultiSignReserve amendment has been enabled in the production XRP Ledger since **2019-04-07**.)
|
||||
|
||||
- If you are on a test network that does not have the [MultiSignReserve amendment][] enabled, multi-signing requires more than the usual amount of XRP for the [account reserve](reserves.html), increasing with the number of signers in the list.
|
||||
|
||||
- You must have access to a tool that can generate key pairs in the XRP Ledger format. If you are using a `rippled` server for this, you must have admin access because the [wallet_propose method][] is admin-only.
|
||||
|
||||
- Multi-signing must be available. Multi-signing has been enabled by an [**Amendment**](amendments.html) to the XRP Ledger Consensus Protocol since 2016-06-27.
|
||||
- Alternatively, if you are authorizing others who already have XRP Ledger addresses to be signers for your address, you only need to know the account addresses of those people or entities.
|
||||
|
||||
- Multi-signing must be available. (The MultiSign amendment has been enabled in the production XRP Ledger since **2016-06-27**.)
|
||||
|
||||
## 1. Prepare a funded address
|
||||
## 1. Design Your Configuration
|
||||
|
||||
You need an XRP Ledger address that can send transactions, and has enough XRP available.
|
||||
|
||||
Without the [MultiSignReserve amendment][], multi-signing requires more than the usual amount of XRP for the [account reserve](reserves.html) and [transaction cost](transaction-cost.html), increasing with the number of signers and signatures you use.
|
||||
|
||||
With the [MultiSignReserve amendment][] enabled, multi-signing requires 5 XRP for the account reserve, regardless of the number of signers and signatures you use. The [transaction cost](transaction-cost.html) of a multi-signed transaction is unaffected by this amendment and still increases with the number of signers and signatures you use.
|
||||
|
||||
If you started `rippled` in [stand-alone mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode) with a new genesis ledger, you must:
|
||||
|
||||
1. Generate keys for a new address, or reuse keys you already have.
|
||||
2. Submit a Payment transaction to fund the new address from the genesis account. (Send at least 100,000,000 [drops of XRP][].)
|
||||
3. Manually close the ledger.
|
||||
Decide how many signers you want to include (up to 8). Choose a quorum number for your signer list and weights for your signers based on how many signatures you want to require for a given transaction. For a straightforward "M-of-N" signing setup, assign each signer weight **`1`** and set your list's quorum to be "M", the number of signatures to require.
|
||||
|
||||
|
||||
## 2. Prepare member keys
|
||||
|
||||
You need several sets of XRP Ledger keys (address and secret) to include as members of your SignerList. These can be funded addresses that exist in the ledger, or you can generate new addresses using the [wallet_propose method][]. For example:
|
||||
You need one or more validly-formed XRP Ledger addresses to include as members of your signer list. You or your chosen signers must know the secret keys associated with these addresses. The addresses can be funded accounts that exist in the ledger, but they do not need to be.
|
||||
|
||||
You can generate new addresses using the [wallet_propose method][]. For example:
|
||||
|
||||
$ rippled wallet_propose
|
||||
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
|
||||
@@ -136,21 +133,9 @@ Make sure that the [Transaction Result](transaction-results.html) is [**tesSUCCE
|
||||
**Note:** Without the [MultiSignReserve amendment][], the more members in the SignerList, the more XRP your address must have for purposes of the [owner reserve](reserves.html#owner-reserves). If your address does not have enough XRP, the transaction fails with [tecINSUFFICIENT_RESERVE](tec-codes.html). With the [MultiSignReserve amendment][] enabled, the XRP your address must have for purposes of the [owner reserve](reserves.html#owner-reserves) is 5 XRP, regardless of the number of members in the SignerList. See also: [SignerLists and Reserves](signerlist.html#signerlists-and-reserves).
|
||||
|
||||
|
||||
## 4. Close the ledger
|
||||
## 4. Wait for validation
|
||||
|
||||
On the live network, you can wait 4-7 seconds for the ledger to close automatically.
|
||||
|
||||
If you're running `rippled` in stand-alone mode, use the [ledger_accept method][] to manually close the ledger:
|
||||
|
||||
$ rippled ledger_accept
|
||||
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"ledger_current_index" : 6,
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
{% include '_snippets/wait-for-validation.md' %} <!--#{ fix md highlighting_ #}-->
|
||||
|
||||
|
||||
## 5. Confirm the new signer list
|
||||
@@ -211,7 +196,25 @@ If the SignerList is present with the expected contents, then your address is re
|
||||
At this point, your address is ready to [send a multi-signed transaction](send-a-multi-signed-transaction.html). You may also want to:
|
||||
|
||||
* Disable the address's master key pair by sending an [AccountSet transaction][] using the `asfDisableMaster` flag.
|
||||
* Remove the address's regular key pair (if you previously set one) by sending a [SetRegularKey transaction][].
|
||||
* [Remove the address's regular key pair](change-or-remove-a-regular-key-pair.html) (if you previously set one) by sending a [SetRegularKey transaction][].
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Cryptographic Keys](cryptographic-keys.html)
|
||||
- [Multi-Signing](multi-signing.html)
|
||||
- **Tutorials:**
|
||||
- [Install rippled](install-rippled.html)
|
||||
- [Assign a Regular Key Pair](assign-a-regular-key-pair.html)
|
||||
- [Reliable Transaction Submission](reliable-transaction-submission.html)
|
||||
- [Enable Public Signing](enable-public-signing.html)
|
||||
- **References:**
|
||||
- [wallet_propose method][]
|
||||
- [account_objects method][]
|
||||
- [sign_for method][]
|
||||
- [submit_multisigned method][]
|
||||
- [SignerListSet transaction][]
|
||||
- [SignerList object](signerlist.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
# Manage Issued Currencies
|
||||
|
||||
These tutorials walk through monitoring and managing issued currencies in the XRP Ledger, both as an issuer and as a user of issued currencies.
|
||||
@@ -1,6 +1,6 @@
|
||||
# Cluster rippled Servers
|
||||
|
||||
If you run multiple `rippled` servers in the same data center, you can configure them in a [cluster](clustering.html) to maximize efficiency. To configure clustering:
|
||||
If you run multiple [`rippled` servers](the-rippled-server.html) in the same data center, you can configure them in a [cluster](clustering.html) to maximize efficiency. To configure clustering:
|
||||
|
||||
1. For each of your servers, note the IP address of the server.
|
||||
|
||||
@@ -79,7 +79,15 @@ If you run multiple `rippled` servers in the same data center, you can configure
|
||||
}
|
||||
}
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Peer Protocol](peer-protocol.html)
|
||||
- **Tutorials:**
|
||||
- [Install rippled](install-rippled.html)
|
||||
- **References:**
|
||||
- [validation_create method][]
|
||||
- [peers method][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Configure Advisory Deletion
|
||||
|
||||
The default config file sets `rippled` to automatically delete outdated history of XRP Ledger state and transactions as new ledger versions become available. If your server uses most of its hardware resources during peak hours, you can configure the server to delete ledgers only when prompted by a command scheduled to run during off-peak hours, so that online deletion is less likely to impact server performance.
|
||||
The default config file sets [`rippled`](the-rippled-server.html) to automatically delete outdated [history](ledger-history.html) of XRP Ledger state and transactions as new ledger versions become available. If your server uses most of its hardware resources during peak hours, you can configure the server to delete ledgers only when prompted by a command scheduled to run during off-peak hours, so that online deletion is less likely to impact [server performance](capacity-planning.html).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -92,6 +92,21 @@ If online deletion does not seem to be running after configuring it, try the fol
|
||||
- Check that the `rippled` executable is available at the path specified in your `cron` configuration. If necessary, specify the absolute path to the executable, such as `/opt/ripple/bin/rippled`.
|
||||
- Check your `rippled` logs for messages that begin with `SHAMapStore::WRN`. This can indicate that [online deletion is being interrupted](online-deletion.html#interrupting-online-deletion) because your server fell out of sync with the network.
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Ledger History](ledger-history.html)
|
||||
- [Online Deletion](online-deletion.html)
|
||||
- **Tutorials:**
|
||||
- [Configure Online Deletion](configure-online-deletion.html)
|
||||
- [Diagnosing Problems with rippled](diagnosing-problems.html)
|
||||
- [Understanding Log Messages](understanding-log-messages.html)
|
||||
- **References:**
|
||||
- [server_info method][]
|
||||
- [can_delete method][]
|
||||
- [logrotate method][]
|
||||
- [Ledger Data Formats](ledger-data-formats.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -83,8 +83,24 @@ To configure your server to acquire and store full history, complete the followi
|
||||
|
||||
The range of available ledgers reported in the `complete_ledgers` field should increase over time.
|
||||
|
||||
The earliest available ledger version in the production XRP Ledger's history is ledger index **32570**. The first two weeks or so of ledger history was lost due to a bug in the server at the time. Test nets and other chains generally have history going back to ledger index **1**.
|
||||
The earliest available ledger version in the production XRP Ledger's history is ledger index **32570**. The first two weeks or so of ledger history was lost due to a bug in the server at the time. [Test nets and other chains](parallel-networks.html) generally have history going back to ledger index **1**.
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Ledger History](ledger-history.html)
|
||||
- [Consensus Network](consensus-network.html)
|
||||
- [rippled Server Modes](rippled-server-modes.html)
|
||||
- **Tutorials:**
|
||||
- [Capacity Planning](capacity-planning.html), particularly [Disk Space](capacity-planning.html#disk-space)
|
||||
- [Configure Online Deletion](configure-online-deletion.html)
|
||||
- [Diagnosing Problems with rippled](diagnosing-problems.html)
|
||||
- [Understanding Log Messages](understanding-log-messages.html)
|
||||
- **References:**
|
||||
- [server_info method][]
|
||||
- [can_delete method][]
|
||||
- [Ledger Data Formats](ledger-data-formats.html)
|
||||
- [rippled Commandline Usage Reference](commandline-usage.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -51,8 +51,24 @@ After your server syncs to the network, it automatically starts downloading hist
|
||||
|
||||
This folder should contain a numbered folder for each shard your server has. At any given time, up to one folder may contain a `control.txt` file, indicating it is incomplete.
|
||||
|
||||
<!-- TODO: add download_shard and crawl_shards commands: https://github.com/ripple/ripple-dev-portal/issues/629 -->
|
||||
You can instruct your server to download and import a shard from an archive file using the [download_shard method][].
|
||||
|
||||
To list the shards your server and its peers have available, you can use the [crawl_shards method][] or the [Peer Crawler](peer-crawler.html).
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Ledger History](ledger-history.html)
|
||||
- [Online Deletion](online-deletion.html)
|
||||
- **Tutorials:**
|
||||
- [Configure Online Deletion](configure-online-deletion.html)
|
||||
- [Configure the Peer Crawler](configure-the-peer-crawler.html)
|
||||
- [Capacity Planning](capacity-planning.html)
|
||||
- **References:**
|
||||
- [download_shard method][]
|
||||
- [crawl_shards method][]
|
||||
- [Ledger Data Formats](ledger-data-formats.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Configure Online Deletion
|
||||
|
||||
In its default configuration, the `rippled` server [deletes history](online-deletion.html) older than the most recent 2000 ledger versions, keeping approximately 15 minutes of ledger history (based on the current rate between ledgers). This page describes how to configure the amount of history your `rippled` server stores before deleting.
|
||||
In its default configuration, [the `rippled` server](the-rippled-server.html) [deletes history](online-deletion.html) older than the most recent 2000 [ledger versions](ledgers.html), keeping approximately 15 minutes of [ledger history](ledger-history.html) (based on the current rate between ledgers). This page describes how to configure the amount of history your `rippled` server stores before deleting.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -12,7 +12,7 @@ This tutorial assumes your server meets the following prerequisites:
|
||||
|
||||
If you followed the installation instructions for a recommended platform, online deletion is enabled by default.
|
||||
|
||||
- Your server has [enough disk space](capacity-planning.html) to store your chosen amount of history in its ledger store.
|
||||
- Your server has [enough disk space](capacity-planning.html#disk-space) to store your chosen amount of history in its ledger store.
|
||||
|
||||
|
||||
## Configuration Steps
|
||||
@@ -63,10 +63,17 @@ To change the amount of history your server stores, perform the following steps:
|
||||
|
||||
## See Also
|
||||
|
||||
- [Online Deletion](online-deletion.html)
|
||||
- [Configure Advisory Deletion](configure-advisory-deletion.html)
|
||||
- [Configure History Sharding](configure-history-sharding.html)
|
||||
- [Configure Full History](configure-full-history.html)
|
||||
- **Concepts:**
|
||||
- [Ledger History](ledger-history.html)
|
||||
- [Online Deletion](online-deletion.html)
|
||||
- **Tutorials:**
|
||||
- [Configure Advisory Deletion](configure-advisory-deletion.html)
|
||||
- [Configure History Sharding](configure-history-sharding.html)
|
||||
- [Capacity Planning](capacity-planning.html)
|
||||
- **References:**
|
||||
- [server_info method][]
|
||||
- [Ledger Data Formats](ledger-data-formats.html)
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Configure the Peer Crawler
|
||||
|
||||
By default, `rippled` servers provide statistics publicly to anyone who asks using the [peer crawler API](peer-crawler.html), to make it easier to track the health and topology of the XRP Ledger's peer-to-peer network. You can configure your server to provide more or less information, or to reject peer crawler requests entirely. [New in: rippled 1.2.0][]
|
||||
By default, [`rippled` servers](the-rippled-server.html) provide statistics publicly to anyone who asks using the [peer crawler API](peer-crawler.html), to make it easier to track the health and topology of [the XRP Ledger's peer-to-peer network](consensus-network.html). You can configure your server to provide more or less information, or to reject peer crawler requests entirely. [New in: rippled 1.2.0][]
|
||||
|
||||
This document contains steps for two options:
|
||||
|
||||
@@ -54,6 +54,16 @@ To disable the peer crawler API on your server, so it does not respond to peer c
|
||||
systemctl restart rippled
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Peer Protocol](peer-protocol.html)
|
||||
- **Tutorials:**
|
||||
- [Manage the rippled Server](manage-the-rippled-server.html)
|
||||
- **References:**
|
||||
- [server_info method][]
|
||||
- [peers method][]
|
||||
- [Peer Crawler](peer-crawler.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Connect Your rippled to an XRPL Altnet
|
||||
|
||||
Ripple has created [alternative test and development networks](parallel-networks.html) for developers to test their apps on the latest non-production version of the XRP Ledger (Testnet) or to test and experiment with features on the latest beta version (Devnet). **The funds used on these networks are not real funds and are intended for testing only.** You can connect your `rippled` server to either the Testnet or Devnet.
|
||||
Ripple has created [alternative test and development networks](parallel-networks.html) for developers to test their apps on the latest non-production version of the XRP Ledger (Testnet) or to test and experiment with features on the latest beta version (Devnet). **The funds used on these networks are not real funds and are intended for testing only.** You can connect your [`rippled` server](the-rippled-server.html) to either the Testnet or Devnet.
|
||||
|
||||
**Note:** The XRP Testnet and Devnet ledger and balances are reset on a regular basis.
|
||||
|
||||
@@ -62,8 +62,20 @@ To connect your `rippled` server to the XRP Testnet or Devnet, set the following
|
||||
|
||||
## See Also
|
||||
|
||||
- [Parallel Networks](parallel-networks.html)
|
||||
- [XRP Testnet Faucet](xrp-test-net-faucet.html)
|
||||
- **Tools:**
|
||||
- [XRP Faucets](xrp-testnet-faucet.html)
|
||||
- [WebSocket API Tool](websocket-api-tool.html) - Select 'Testnet Public Server' in the connection options.
|
||||
- **Concepts:**
|
||||
- [Parallel Networks](parallel-networks.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- **Tutorials:**
|
||||
- [Run rippled as a Validator](run-rippled-as-a-validator.html)
|
||||
- [Test `rippled` Offline in Stand-Alone Mode](use-stand-alone-mode.html)
|
||||
- [Troubleshooting `rippled`](troubleshoot-the-rippled-server.html)
|
||||
- **References:**
|
||||
- [server_info method][]
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Enable Public Signing
|
||||
|
||||
[New in: rippled 1.1.0][] By default, the signing methods for `rippled` are limited to administrative connections. If you want to allow signing methods to be used as public API methods (like with versions of `rippled` before v1.1.0), you can enable it with a configuration change.
|
||||
By default, the signing methods for [`rippled`](the-rippled-server.html) are limited to [administrative connections](admin-rippled-methods.html). If you want to allow signing methods to be used as public API methods (like with versions of `rippled` before v1.1.0), you can enable it with a configuration change. [New in: rippled 1.1.0][]
|
||||
|
||||
This enables the following methods to be used on "public" [JSON-RPC and WebSocket connections](get-started-with-the-rippled-api.html), if your server accepts them:
|
||||
|
||||
@@ -29,6 +29,20 @@ To enable public signing, perform the following steps:
|
||||
|
||||
systemctl restart rippled
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Transaction Basics](transaction-basics.html)
|
||||
- [Cryptographic Keys](cryptographic-keys.html)
|
||||
- **Tutorials:**
|
||||
- [Set Up Secure Signing](set-up-secure-signing.html)
|
||||
- [Get Started with the rippled API](get-started-with-the-rippled-api.html)
|
||||
- [Get Started with RippleAPI for JavaScript](get-started-with-rippleapi-for-javascript.html)
|
||||
- **References:**
|
||||
- [sign method][]
|
||||
- [sign_for method][]
|
||||
- [submit method][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# Run rippled as a Validator
|
||||
|
||||
A `rippled` server running in validator mode does everything a stock server does:
|
||||
A [`rippled` server](the-rippled-server.html) running in [validator mode](rippled-server-modes.html) does everything a stock server does:
|
||||
|
||||
- Connects to a network of peers
|
||||
- Connects to a [network of peers](consensus-network.html)
|
||||
|
||||
- Relays cryptographically signed transactions
|
||||
- Relays cryptographically signed [transactions](transaction-basics.html)
|
||||
|
||||
- Maintains a local copy of the complete shared global ledger
|
||||
- Maintains a local copy of the complete shared global [ledger](ledgers.html)
|
||||
|
||||
What makes a validator _different_ is that it also issues validation messages, which are sets of candidate transactions for evaluation by the XRP Ledger network during the [consensus process](consensus-principles-and-rules.html#how-consensus-works).
|
||||
|
||||
@@ -325,3 +325,21 @@ To provide domain verification:
|
||||
If your validator's master private key is compromised, you must revoke it immediately and permanently.
|
||||
|
||||
For information about how to revoke a master key pair you generated for your validator using the `validator-keys` tool, see [Key Revocation](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation).
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [XRP Ledger Overview](xrp-ledger-overview.html)
|
||||
- [Consensus Network](consensus-network.html)
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- **Tutorials:**
|
||||
- [Cluster rippled Servers](cluster-rippled-servers.html)
|
||||
- [Install `rippled`](install-rippled.html)
|
||||
- [Capacity Planning](capacity-planning.html)
|
||||
- [XRP Ledger Businesses](xrp-ledger-businesses.html)
|
||||
- **References:**
|
||||
- [Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)
|
||||
- [consensus_info method][]
|
||||
- [validator_list_sites method][]
|
||||
- [validators method][]
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Build and Run rippled on macOS
|
||||
|
||||
At this time, Ripple doesn't recommend using the macOS platform for `rippled` production use. For production, consider using the [Ubuntu platform](install-rippled-on-ubuntu-with-alien.html), which has received the highest level of quality assurance and testing.
|
||||
The macOS platform is not recommended for [`rippled`](the-rippled-server.html) production use. For production, consider using the [Ubuntu platform](install-rippled-on-ubuntu-with-alien.html), which has received the highest level of quality assurance and testing.
|
||||
|
||||
That said, macOS is suitable for many development and testing tasks. `rippled` has been tested for use with macOS up to 10.13 High Sierra.
|
||||
|
||||
For development purposes Ripple recommends running `rippled` as your own user, not using `sudo`.
|
||||
For development purposes, run `rippled` as a non-admin user, not using `sudo`.
|
||||
|
||||
1. Install [Xcode](https://developer.apple.com/download/).
|
||||
|
||||
@@ -169,7 +169,21 @@ For information about `rippled` log messages, see [Understanding Log Messages](u
|
||||
|
||||
## See Also
|
||||
|
||||
- [Install rippled on Ubuntu Linux](install-rippled-on-ubuntu.html) (Pre-built binary on Ubuntu for production use)
|
||||
- [Install rippled on Red Hat Enterprise Linux](install-rippled-on-centos-rhel-with-yum.html) (Pre-built binary on RHEL or CentOS for production use)
|
||||
- [Build and Run `rippled` on Ubuntu](build-run-rippled-ubuntu.html) (Compile `rippled` yourself on Ubuntu)
|
||||
- [Compilation instructions for other platforms](https://github.com/ripple/rippled/tree/develop/Builds)
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- **Tutorials:**
|
||||
- [Install rippled on Ubuntu Linux](install-rippled-on-ubuntu.html) - Install a pre-built binary on Ubuntu for production use
|
||||
- [Configure rippled](configure-rippled.html)
|
||||
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
|
||||
- [Get Started with the rippled API](get-started-with-the-rippled-api.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [server_info method][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -216,3 +216,23 @@ Watchdog: Launching child 1
|
||||
cmake --build . --target dpkg
|
||||
|
||||
* You may also want to install a `systemd` unit. For more information, see [systemd for Upstart Users](https://wiki.ubuntu.com/SystemdForUpstartUsers). You can use the [official `rippled` system unit file](https://github.com/ripple/rippled/blob/master/Builds/containers/shared/rippled.service) or modify it to suit your needs.
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- **Tutorials:**
|
||||
- [Configure rippled](configure-rippled.html)
|
||||
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
|
||||
- [Get Started with the rippled API](get-started-with-the-rippled-api.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [server_info method][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -186,3 +186,25 @@ Here are examples of observed network bandwidth use for common `rippled` tasks:
|
||||
| Process current transaction volumes | 2Mbps transmit, 2 Mbps receive |
|
||||
| Serve historical ledger and transaction reports | 100Mbps transmit |
|
||||
| Start up `rippled` | 20Mbps receive |
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- **Tutorials:**
|
||||
- [Configure rippled](configure-rippled.html)
|
||||
- [Configure Online Deletion](configure-online-deletion.html) - Adjust how many historical ledger versions your server should keep at a time.
|
||||
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [logrotate method][] - Closes and reopens the server's debug log so you can rotate it with standard tools.
|
||||
- [server_info method][] - General information about the server including sync status and how many historical ledger versions it has available on disk.
|
||||
- [get_counts method][] - Additional health information, especially how many objects of various types it holds in RAM.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -51,10 +51,23 @@ Before you install `rippled`, you must meet the [System Requirements](system-req
|
||||
|
||||
{% include '_snippets/post-rippled-install.md' %}<!--_ -->
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- [Update Automatically on Linux](update-rippled-automatically-on-linux.html)
|
||||
- [Install rippled on Ubuntu Linux](install-rippled-on-ubuntu.html) (Pre-built binary for Ubuntu or Debian)
|
||||
- [Build and Run `rippled` on Ubuntu](build-run-rippled-ubuntu.html) (Compile `rippled` yourself on Ubuntu)
|
||||
- [Build and Run `rippled` on macOS](build-run-rippled-macos.html) (Compile `rippled` yourself on macOS)
|
||||
- [Compilation instructions for other platforms](https://github.com/ripple/rippled/tree/develop/Builds)
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- **Tutorials:**
|
||||
- [Configure rippled](configure-rippled.html)
|
||||
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
|
||||
- [Get Started with the rippled API](get-started-with-the-rippled-api.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [server_info method][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -80,6 +80,22 @@ Before you install `rippled`, you must meet the [System Requirements](system-req
|
||||
## Next Steps
|
||||
|
||||
{% include '_snippets/post-rippled-install.md' %}
|
||||
<!--_ -->
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- **Tutorials:**
|
||||
- [Configure rippled](configure-rippled.html)
|
||||
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
|
||||
- [Get Started with the rippled API](get-started-with-the-rippled-api.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [server_info method][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
|
||||
@@ -83,3 +83,24 @@ If you no longer need Alien for any other packages, you may optionally uninstall
|
||||
### Automatic Updates
|
||||
|
||||
The `rippled` v1.3 package includes an updated auto-update script that works on Ubuntu and Debian Linux. For more information, see [Update `rippled` Automatically on Linux](update-rippled-automatically-on-linux.html).
|
||||
|
||||
## See Also
|
||||
|
||||
- **[`rippled` v1.3.1 Release Notes](https://github.com/ripple/rippled/releases/1.3.1)**
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- **Tutorials:**
|
||||
- [Update Automatically on Linux](update-rippled-automatically-on-linux.html)
|
||||
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
|
||||
- [Get Started with the rippled API](get-started-with-the-rippled-api.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [server_info method][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -30,6 +30,23 @@ For best performance in enterprise production environments, Ripple recommends ru
|
||||
|
||||
A `rippled` server relies on maintaining accurate time. It is recommended that the system synchronize time using the Network Time Protocol (NTP) with daemons such as `ntpd` or `chrony`.
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
For more information on the recommended specifications and planning for production needs, see [Capacity Planning](capacity-planning.html).
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- **Tutorials:**
|
||||
- [Capacity Planning](capacity-planning.html) - More information on the recommended specifications and planning for production needs
|
||||
- [Install `rippled`](install-rippled.html)
|
||||
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [server_info method][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -15,3 +15,23 @@ To set up automatic updates, complete the following steps:
|
||||
This cron configuration runs a script to update the installed `rippled` package within an hour of each new release. To reduce the chance of outages from all servers updating simultaneously, the script delays the update for a random number of minutes, up to 59.
|
||||
|
||||
**Caution:** In the future, it is possible that changes to Ripple's repositories may require manual intervention to update the URLs where your script searches for updates. Stay tuned to the [XRP Ledger Blog](/blog/) or the [ripple-server mailing list](https://groups.google.com/forum/#!forum/ripple-server) for announcements on any required changes.
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- **Tutorials:**
|
||||
- [Capacity Planning](capacity-planning.html)
|
||||
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [server_info method][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -19,3 +19,23 @@ To update manually, complete the following steps:
|
||||
3. Restart the `rippled` service:
|
||||
|
||||
$ sudo service rippled restart
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- **Tutorials:**
|
||||
- [`rippled` v1.3.x Migration Instructions](rippled-1-3-migration-instructions.html) <!-- Note: remove when versions older than v1.3 are basically extinct -->
|
||||
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [server_info method][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -23,3 +23,23 @@ To update manually, complete the following steps:
|
||||
4. Restart the `rippled` service:
|
||||
|
||||
$ sudo service rippled restart
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- **Tutorials:**
|
||||
- [`rippled` v1.3.x Migration Instructions](rippled-1-3-migration-instructions.html) <!-- Note: remove when versions older than v1.3 are basically extinct -->
|
||||
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [server_info method][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Advance the Ledger in Stand-Alone Mode
|
||||
|
||||
In stand-alone mode, `rippled` does not communicate to other members of the peer-to-peer network or participate in a consensus process. Instead, you must manually advance the ledger index using the [ledger_accept method][]:
|
||||
In [stand-alone mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode), `rippled` does not communicate to other members of the peer-to-peer network or participate in a consensus process. Since there is no consensus process in this mode, you must manually advance the ledger index using the [ledger_accept method][]:
|
||||
|
||||
```
|
||||
rippled ledger_accept --conf=/path/to/rippled.cfg
|
||||
@@ -11,6 +11,20 @@ In stand-alone mode, `rippled` makes no distinction between a "closed" ledger ve
|
||||
Whenever `rippled` closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since transactions may arrive at different parts of the network in different order.) When using `rippled` in stand-alone mode, you should manually advance the ledger before submitting a transaction that depends on the result of a transaction from a different address. Otherwise, the two transactions might be executed in reverse order when the ledger is closed. **Note:** You can safely submit multiple transactions from a single address to a single ledger, because `rippled` sorts transactions from the same address in ascending order by [`Sequence` number](transaction-common-fields.html).
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [`rippled` Server Modes](rippled-server-modes.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- [Amendments](amendments.html)
|
||||
- **References:**
|
||||
- [ledger_accept method][]
|
||||
- [server_info method][]
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- **Use Cases:**
|
||||
- [Contribute Code to `rippled`](contribute-code-to-rippled.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# Load a Saved Ledger in Stand-Alone Mode
|
||||
|
||||
You can start with a ledger version that was saved to disk if your `rippled` server was previously synced with the XRP Ledger peer-to-peer network (either the production network or the [Test Net](parallel-networks.html)).
|
||||
You can start a `rippled` server in [Stand-Alone Mode](TODO) using a [historical ledger version](TODO) that was previously saved to disk. For example, if your `rippled` server was previously synced with any XRP Ledger peer-to-peer network including [the production Mainnet, the Testnet, or the Devnet](parallel-networks.html), you can load any ledger version your server had available.
|
||||
|
||||
Loading a historical ledger version so may be useful for "replaying" a ledger to verify that transactions were processed according to the rules of the network, or to compare the results of processing transaction sets with different [amendments](amendments.html) enabled. In the unlikely event that [an attack against the XRP Ledger's consensus mechanism](consensus-protections.html) caused unwanted effects to the shared ledger state, a consensus of validators could "roll back" to a previous, known-good network state starting with this process.
|
||||
|
||||
## 1. Start `rippled` normally.
|
||||
|
||||
@@ -60,6 +62,21 @@ When you load a ledger with `--ledger` in stand-alone mode, it goes to the curre
|
||||
rippled ledger_accept --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [`rippled` Server Modes](rippled-server-modes.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- [Amendments](amendments.html)
|
||||
- **References:**
|
||||
- [ledger_accept method][]
|
||||
- [server_info method][]
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- **Use Cases:**
|
||||
- [Contribute Code to `rippled`](contribute-code-to-rippled.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -22,6 +22,21 @@ In a new genesis ledger, the hard-coded default [Reserve](reserves.html) is **20
|
||||
|
||||
By default, a new genesis ledger has no [amendments](amendments.html) enabled. If you start a new genesis ledger with `--start`, the genesis ledger contains an [EnableAmendment pseudo-transaction](enableamendment.html) to turn on all amendments natively supported by the `rippled` server, except for amendments that you explicitly disable in the config file. The effects of those amendments are available starting from the very next ledger version. (Reminder: in stand-alone mode, you must [advance the ledger manually](advance-the-ledger-in-stand-alone-mode.html).) [New in: rippled 0.50.0][]
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [`rippled` Server Modes](rippled-server-modes.html)
|
||||
- [Parallel Networks](parallel-networks.html)
|
||||
- [Amendments](amendments.html)
|
||||
- [Fee Voting](fee-voting.html)
|
||||
- **References:**
|
||||
- [ledger_accept method][]
|
||||
- [server_info method][]
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- **Use Cases:**
|
||||
- [Contribute Code to `rippled`](contribute-code-to-rippled.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -69,6 +69,20 @@ It is normal for a `rippled` the server to print many warning-level (`WRN`) mess
|
||||
For a more thorough explanation of various types of log messages, see [Understanding Log Messages](understanding-log-messages.html).
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [Amendments](amendments.html)
|
||||
- **Tutorials:**
|
||||
- [Capacity Planning](capacity-planning.html)
|
||||
- [Configure rippled](configure-rippled.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [log_level method][]
|
||||
- [server_info method][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Fix SQLite Transaction Database Page Size Issue
|
||||
|
||||
`rippled` servers with full transaction history (or a very large amount of transaction history) and a database that was initially created with a `rippled` version earlier than 0.40.0 (released January 2017) may encounter a problem with their SQLite database page size that stops the server from operating properly. Servers that store only recent transaction history (the default configuration) and servers whose database files were created with `rippled` version 0.40.0 and later are not likely to encounter this problem.
|
||||
`rippled` servers with full [ledger history](ledger-history.html) (or a very large amount of transaction history) and a database that was initially created with a `rippled` version earlier than 0.40.0 (released January 2017) may encounter a problem with their SQLite database page size that stops the server from operating properly. Servers that store only recent transaction history (the default configuration) and servers whose database files were created with `rippled` version 0.40.0 and later are not likely to encounter this problem.
|
||||
|
||||
This document describes steps to detect and correct this problem if it occurs.
|
||||
|
||||
@@ -167,6 +167,20 @@ To migrate your transaction database to a larger page size, perform the followin
|
||||
If you mounted additional storage to hold the temporary copy of the transaction database, you can unmount and remove it now.
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [Ledger History](ledger-history.html)
|
||||
- **Tutorials:**
|
||||
- [Understanding Log Messages](understanding-log-messages.html)
|
||||
- [Configure Full History](configure-full-history.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [server_info method][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# rippled Server Won't Start
|
||||
|
||||
This page explains possible reasons the `rippled` server does not start and how to fix them.
|
||||
This page explains possible reasons [the `rippled` server](the-rippled-server.html) does not start and how to fix them.
|
||||
|
||||
These instructions assume you have [installed `rippled`](install-rippled.html) on a supported platform.
|
||||
|
||||
@@ -196,6 +196,19 @@ To fix this problem, do one of the following, then restart the server:
|
||||
- Disable history sharding.
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [Technical FAQ](technical-faq.html)
|
||||
- **Tutorials:**
|
||||
- [Understanding Log Messages](understanding-log-messages.html)
|
||||
- [Capacity Planning](capacity-planning.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [server_info method][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Understanding Log Messages
|
||||
|
||||
The following sections describe some of the most common types of log messages that can appear in a `rippled` server's debug log and how to interpret them.
|
||||
The following sections describe some of the most common types of log messages that can appear in a [`rippled` server's](the-rippled-server.html) debug log and how to interpret them.
|
||||
|
||||
This is an important step in [Diagnosing Problems](diagnosing-problems.html) with `rippled`.
|
||||
|
||||
@@ -208,6 +208,19 @@ NetworkOPs:WRN We are not running on the consensus ledger
|
||||
<!--_ -->
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- [Technical FAQ](technical-faq.html)
|
||||
- **Tutorials:**
|
||||
- [Diagnosing Problems](diagnosing-problems.html)
|
||||
- [Capacity Planning](capacity-planning.html)
|
||||
- **References:**
|
||||
- [rippled API Reference](rippled-api.html)
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [server_info method][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
# Use Complex Payment Types
|
||||
|
||||
In addition to simple, direct XRP Payments, <!--{# TODO:link tutorial or concept (DOC-1560) for simple XRP payments #}--> the XRP Ledger supports a variety of more complex payments for building smart apps on the decentralized ledger.
|
||||
@@ -125,6 +125,26 @@ In the above example, `r3wN3v2vTUkr5qd6daqDc2xE4LSysdVjkT` is the sender of the
|
||||
**Tip:** If you don't know what `OfferSequence` to use in the [EscrowFinish transaction][] to execute an escrow, use the [tx method][] to look up the transaction that created the escrow, using the identifying hash of the transaction in the Escrow's `PreviousTxnID` field. Use the `Sequence` value of that transaction as the `OfferSequence` value when finishing the escrow.
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [XRP](xrp.html)
|
||||
- [Payment Types](payment-types.html)
|
||||
- [Escrow](escrow.html)
|
||||
- **Tutorials:**
|
||||
- [Send XRP](send-xrp.html)
|
||||
- [Look Up Transaction Results](look-up-transaction-results.html)
|
||||
- [Reliable Transaction Submission](reliable-transaction-submission.html)
|
||||
- **References:**
|
||||
- [EscrowCancel transaction][]
|
||||
- [EscrowCreate transaction][]
|
||||
- [EscrowFinish transaction][]
|
||||
- [account_objects method][]
|
||||
- [tx method][]
|
||||
- [Escrow ledger object](escrow-object.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -77,6 +77,27 @@ _Websocket_
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [XRP](xrp.html)
|
||||
- [Payment Types](payment-types.html)
|
||||
- [Escrow](escrow.html)
|
||||
- **Tutorials:**
|
||||
- [Send XRP](send-xrp.html)
|
||||
- [Look Up Transaction Results](look-up-transaction-results.html)
|
||||
- [Reliable Transaction Submission](reliable-transaction-submission.html)
|
||||
- **References:**
|
||||
- [EscrowCancel transaction][]
|
||||
- [EscrowCreate transaction][]
|
||||
- [EscrowFinish transaction][]
|
||||
- [account_objects method][]
|
||||
- [tx method][]
|
||||
- [Escrow ledger object](escrow-object.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## 1. Generate condition and fulfillment
|
||||
|
||||
XRP Ledger escrows require PREIMAGE-SHA-256 [Crypto-Conditions](https://tools.ietf.org/html/draft-thomas-crypto-conditions-03). To calculate a condition and fulfillment in the proper format, you should use a Crypto-Conditions library such as [five-bells-condition](https://github.com/interledgerjs/five-bells-condition). For fulfillments, Ripple recommends using one of the following methods to generate the fulfillment:
|
||||
XRP Ledger escrows require PREIMAGE-SHA-256 [crypto-conditions][]. To calculate a condition and fulfillment in the proper format, you should use a crypto-conditions library such as [five-bells-condition](https://github.com/interledgerjs/five-bells-condition). For fulfillments, the following methods are recommended to generate the fulfillment:
|
||||
|
||||
- Use a cryptographically secure source of randomness to generate at least 32 random bytes.
|
||||
- Follow Interledger Protocol's [PSK specification](https://github.com/interledger/rfcs/blob/master/deprecated/0016-pre-shared-key/0016-pre-shared-key.md) and use an HMAC-SHA-256 of the ILP packet as the fulfillment.
|
||||
@@ -181,6 +181,27 @@ Response:
|
||||
```
|
||||
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- [Crypto-Conditions Specification][]
|
||||
- **Concepts:**
|
||||
- [XRP](xrp.html)
|
||||
- [Payment Types](payment-types.html)
|
||||
- [Escrow](escrow.html)
|
||||
- **Tutorials:**
|
||||
- [Send XRP](send-xrp.html)
|
||||
- [Look Up Transaction Results](look-up-transaction-results.html)
|
||||
- [Reliable Transaction Submission](reliable-transaction-submission.html)
|
||||
- **References:**
|
||||
- [EscrowCancel transaction][]
|
||||
- [EscrowCreate transaction][]
|
||||
- [EscrowFinish transaction][]
|
||||
- [account_objects method][]
|
||||
- [tx method][]
|
||||
- [Escrow ledger object](escrow-object.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -200,6 +200,23 @@ Response:
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [XRP](xrp.html)
|
||||
- [Payment Types](payment-types.html)
|
||||
- [Escrow](escrow.html)
|
||||
- **Tutorials:**
|
||||
- [Send XRP](send-xrp.html)
|
||||
- [Look Up Transaction Results](look-up-transaction-results.html)
|
||||
- [Reliable Transaction Submission](reliable-transaction-submission.html)
|
||||
- **References:**
|
||||
- [EscrowCancel transaction][]
|
||||
- [EscrowCreate transaction][]
|
||||
- [EscrowFinish transaction][]
|
||||
- [account_objects method][]
|
||||
- [tx method][]
|
||||
- [Escrow ledger object](escrow-object.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Use Payment Channels
|
||||
|
||||
Payment Channels are an advanced feature for sending "asynchronous" XRP payments that can be divided into very small increments and settled later. This tutorial walks through the entire process of using a [payment channel](payment-channels.html), with examples using the [JSON-RPC API](rippled-api.html) of a local `rippled` server.
|
||||
[Payment Channels](payment-channels.html) are an advanced feature for sending "asynchronous" XRP payments that can be divided into very small increments and settled later. This tutorial walks through the entire process of using a payment channel, with examples using the [JSON-RPC API](rippled-api.html) of a local [`rippled` server](the-rippled-server.html).
|
||||
|
||||
Ideally, to step through this tutorial, you would have two people, each with the keys to a [funded XRP Ledger account](accounts.html). However, you can also step through the tutorial as one person managing two XRP Ledger addresses.
|
||||
|
||||
@@ -19,7 +19,7 @@ The example addresses used in this tutorial are:
|
||||
|
||||
Additionally, you'll need a `rippled` server to send transactions to. The examples in this tutorial assume a `rippled` server is running on the test machine (`localhost`) with an unencrypted JSON-RPC API endpoint on port **5005**.
|
||||
|
||||
To test without transferring real XRP, you can use [XRP Ledger Test Net](xrp-test-net-faucet.html) addresses with Test Net XRP. If you do use the Test Net, you can use the Test Net servers' JSON-RPC API by connecting to `https://api.altnet.rippletest.net:51234` instead of `http://localhost:5005/`.
|
||||
To test without transferring real XRP, you can use [XRP Ledger Testnet](xrp-testnet-faucet.html) addresses with Testnet XRP. If you do use the Testnet, you can use the Testnet servers' JSON-RPC API by connecting to `https://api.altnet.rippletest.net:51234` instead of `http://localhost:5005/`.
|
||||
|
||||
You can use any amount of XRP for the payment channels. The example values in this tutorial set aside 100 XRP (`100000000` drops) in a payment channel for at least 1 day.
|
||||
|
||||
@@ -599,6 +599,23 @@ Those fields indicate that the payment channel is closed.
|
||||
|
||||
This concludes the tutorial of Payment Channel usage. Ripple encourages users to find unique and interesting use cases to take full advantage of the speed and convenience of payment channels.
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [XRP](xrp.html)
|
||||
- [Payment Types](payment-types.html)
|
||||
- [Payment Channels](payment-channels.html)
|
||||
- **Tutorials:**
|
||||
- [Send XRP](send-xrp.html)
|
||||
- [Look Up Transaction Results](look-up-transaction-results.html)
|
||||
- [Reliable Transaction Submission](reliable-transaction-submission.html)
|
||||
- **References:**
|
||||
- [PaymentChannelClaim transaction][]
|
||||
- [PaymentChannelCreate transaction][]
|
||||
- [PaymentChannelFund transaction][]
|
||||
- [channel_authorize method][]
|
||||
- [channel_verify method][]
|
||||
- [PayChannel ledger object](paychannel.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
|
||||
@@ -1,16 +0,0 @@
|
||||
# Cancel or Skip a Transaction
|
||||
|
||||
An important and intentional feature of the XRP Ledger is that a transaction is final as soon as it has been incorporated in a validated ledger.
|
||||
|
||||
However, if a transaction has not yet been included in a validated ledger, you can effectively cancel it by rendering it invalid. Typically, this means sending another transaction with the same `Sequence` value from the same account. If you do not want the replacement transaction to do anything, send an [AccountSet transaction][] with no options.
|
||||
|
||||
For example, if you try to submit 3 transactions with sequence numbers 11, 12, and 13, but transaction 11 gets lost somehow or does not have a high enough [transaction cost](transaction-cost.html) to be propagated to the network, then you can cancel transaction 11 by submitting an AccountSet transaction with no options and sequence number 11. This does nothing (except destroying the transaction cost for the new transaction 11), but it allows transactions 12 and 13 to become valid.
|
||||
|
||||
This approach is preferable to renumbering and resubmitting transactions 12 and 13, because it prevents transactions from being effectively duplicated under different sequence numbers.
|
||||
|
||||
In this way, an AccountSet transaction with no options is the canonical "[no-op](http://en.wikipedia.org/wiki/NOP)" transaction.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -511,6 +511,15 @@ pages:
|
||||
targets:
|
||||
- local
|
||||
|
||||
- md: concepts/consensus-network/about-canceling-a-transaction.md
|
||||
html: about-canceling-a-transaction.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Consensus Network
|
||||
blurb: Understand when and how it's possible to cancel a transaction that has already been sent.
|
||||
targets:
|
||||
- local
|
||||
|
||||
- md: concepts/consensus-network/transaction-malleability.md
|
||||
html: transaction-malleability.html
|
||||
funnel: Docs
|
||||
@@ -747,11 +756,14 @@ pages:
|
||||
targets:
|
||||
- local
|
||||
|
||||
- md: tutorials/use-simple-xrp-payments/cancel-or-skip-a-transaction.md
|
||||
# Redirect for this page's new home outside of tutorials
|
||||
- name: Cancel or Skip a Transaction
|
||||
html: cancel-or-skip-a-transaction.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Use Simple XRP Payments
|
||||
template: template-redirect.html
|
||||
redirect_url: about-canceling-a-transaction.html
|
||||
blurb: Replace a pending transaction if it gets stuck from paying too low a transaction cost.
|
||||
targets:
|
||||
- local
|
||||
@@ -1268,13 +1280,13 @@ pages:
|
||||
targets:
|
||||
- local
|
||||
|
||||
- name: Use rippled in Stand-Alone Mode
|
||||
- name: Test rippled Functionality in Stand-Alone Mode
|
||||
html: use-stand-alone-mode.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Stand-Alone Mode
|
||||
blurb: Use rippled's Stand Alone Mode for testing new features or configurations.
|
||||
blurb: For new features and experiments, you can use Stand-Alone Mode to test features with a full network.
|
||||
template: template-landing-children.html
|
||||
targets:
|
||||
- local
|
||||
|
||||
Reference in New Issue
Block a user