mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-12-03 18:15:49 +00:00
Merge branch 'master' into regular-keys
This commit is contained in:
Jess Heron
64
content/concept-depositauth.md
Normal file
64
content/concept-depositauth.md
Normal file
@@ -0,0 +1,64 @@
|
||||
# Deposit Authorization
|
||||
|
||||
_(Requires the [DepositAuth amendment](reference-amendments.html#depositauth).)_
|
||||
|
||||
Deposit Authorization is an optional feature of an [account](concept-accounts.html) in the XRP Ledger. With Deposit Authorization enabled, transactions cannot send value of any kind to the account unless the sender of those transactions is the account itself. This includes transfers of XRP and issued currencies.
|
||||
|
||||
By default, new accounts have DepositAuth disabled.
|
||||
|
||||
## Background
|
||||
|
||||
Financial services regulations and licenses may require that a business or entity must know the sender of all transactions it receives. This presents a challenge on a decentralized system like the XRP Ledger where participants are identified by pseudonyms which can be freely generated and the default behavior is for any address to be able to pay any other.
|
||||
|
||||
The Deposit Authorization flag introduces an option for those using the XRP Ledger to comply with such regulations without changing the fundamental nature of the decentralized ledger. With Deposit Authorization enabled, an account can only receive funds it explicitly approves by sending a transaction. The owner of an account using Deposit Authorization can perform the due diligence necessary to identify the sender of any funds _before_ sending the transaction that causes the account to receive the money.
|
||||
|
||||
Deposit Authorization is intended to be used with [Checks](reference-amendments.html#checks), [Escrow](concept-escrow.html), and [Payment Channels](reference-amendments.html#paychan). In this "two-step" model, first the source sends a transaction to authorize sending funds, then the destination sends a transaction to authorize receiving those funds. Deposit Authorization cannot be used with [Payment transactions][].
|
||||
|
||||
## Recommended Usage
|
||||
|
||||
To get the full effect of Deposit Authorization, Ripple recommends also doing the following:
|
||||
|
||||
- Always maintain an XRP balance higher than the minimum [reserve requirement](concept-reserves.html).
|
||||
- Keep the DefaultRipple flag in its default (disabled) state. Do not enable [rippling](concept-noripple.html) on any trust lines. When sending TrustSet transactions, always use the [`tfSetNoRipple` flag](reference-transaction-format.html#trustset-flags).
|
||||
- Do not place [Offers](reference-transaction-format.html#offercreate). It is impossible to know in advance which matching offers will be consumed to execute such a trade.
|
||||
|
||||
## Precise Semantics
|
||||
|
||||
An account with Deposit Authorization enabled:
|
||||
|
||||
- **Cannot** be the destination of [Payment transactions][], with **one exception**:
|
||||
- If the account's XRP balance is equal to or below the minimum account [reserve requirement](concept-reserves.html), it can be the destination of an XRP Payment whose `Amount` is equal or less than the minimum account reserve (currently 20 XRP). This is to prevent an account from becoming "stuck" by being unable to send transactions but also unable to receive XRP. The account's owner reserve does not matter for this case.
|
||||
- Can receive XRP from [PaymentChannelClaim transactions][] **only if** the sender of the PaymentChannelClaim transaction is the destination of the payment channel.
|
||||
- Can receive XRP from [EscrowFinish transactions][] **only if** the sender of the EscrowFinish transaction is the destination of the escrow.
|
||||
- **Can** receive XRP or issued currencies by sending a [CheckCash][] transaction. _(Requires the [Checks amendment](reference-amendments.html#checks).)_
|
||||
- **Can** receive XRP or issued currencies by sending [OfferCreate transactions][].
|
||||
- If the account sends an OfferCreate transaction that is not fully executed immediately, it **can** receive the remainder of the ordered XRP or issued currency later when the offer is consumed by other accounts' [Payment][] and [OfferCreate][] transactions.
|
||||
- If the account has created any trust lines without the [NoRipple flag](concept-noripple.html) enabled, or has enabled the DefaultRipple flag and issued any currency, the account **can** receive the issued currencies of those trust lines in [Payment transactions][] as a result of rippling. It cannot be the destination of those transactions.
|
||||
- In general, an account in the XRP Ledger **cannot** receive any non-XRP currencies in the XRP Ledger as long as all of the following are true. (This rule is not specific to the DepositAuth flag.)
|
||||
- The account has not created any trust lines with a nonzero limit.
|
||||
- The account has not issued currency on trust lines created by others
|
||||
- The account has not placed any offers.
|
||||
|
||||
The following table summarizes whether a transaction type can deposit money with DepositAuth enabled or disabled:
|
||||
|
||||
{% include 'snippets/depositauth-semantics-table.html' %}
|
||||
|
||||
|
||||
## Enabling or Disabling Deposit Authorization
|
||||
|
||||
An account can enable deposit authorization by sending an [AccountSet transaction][] with the `SetFlag` field set to the `asfDepositAuth` value (9). The account can disable deposit authorization by sending an [AccountSet transaction][] with the `ClearFlag` field set to the `asfDepositAuth` value (9). For more information on AccountSet flags, see [AccountSet flags](reference-transaction-format.html#accountset-flags).
|
||||
|
||||
## Checking Whether an Account Has DepositAuth Enabled
|
||||
|
||||
To see whether an account has Deposit Authorization enabled, use the [`account_info` command](reference-rippled.html#account-info) to look up the account. Compare the value of the `Flags` field (in the `result.account_data` object) with the [bitwise flags defined for an AccountRoot ledger object](reference-ledger-format.html#accountroot-flags).
|
||||
|
||||
If the result of the `Flags` value bitwise-AND the `lsfDepositAuth` flag value (0x01000000) is nonzero, then the account has DepositAuth enabled. If the result is zero, then the account has DepositAuth disabled.
|
||||
|
||||
## See Also
|
||||
|
||||
- The [Authorized Accounts](tutorial-gateway-guide.html#authorized-accounts) feature (`RequireAuth` flag) limits which counterparties can hold non-XRP currencies issued by an account.
|
||||
- The `DisallowXRP` flag indicates that an account should not receive XRP. This is a softer protection than Deposit Authorization, and is not enforced by the XRP Ledger. (Client applications should honor this flag or at least warn about it.)
|
||||
- The `RequireDest` flag indicates that an account can only receive currency amounts if the sending transaction specifies a [Destination Tag](tutorial-gateway-guide.html#source-and-destination-tags). This protects users from forgetting to indicate the purpose of a payment, but does not protect recipients from unknown senders, who can make up arbitrary destination tags.
|
||||
- [Partial Payments](concept-partial-payments.html) provide a way for accounts to return unwanted payments while subtracting [transfer fees](concept-transfer-fees.html) and exchange rates from the amount delivered instead of adding them to the amount sent.
|
||||
|
||||
{% include 'snippets/tx-type-links.md' %}
|
||||
55
content/concept-history-sharding.md
Normal file
55
content/concept-history-sharding.md
Normal file
@@ -0,0 +1,55 @@
|
||||
New in `rippled` 0.90.0
|
||||
|
||||
# History Sharding
|
||||
|
||||
As servers operate, they naturally produce a database containing data about the ledgers they witnessed or acquired during network runtime. Each `rippled` server stores that ledger data in its ledger store, but the online delete logic rotates these databases when the number of stored ledgers exceeds configured space limitations.
|
||||
|
||||
Historical sharding distributes the transaction history of the XRP Ledger into segments, called shards, across servers in the XRP Ledger network. A shard is a range of ledgers, consisting of a header and two SHAMaps. A `rippled` server stores ledgers in both the ledger store and the shard store in the same way.
|
||||
|
||||
Using the history sharding feature, individual `rippled` servers can contribute to storing historical data without needing to store the entire (multiple terabyte) history. A shard store does not replace a ledger store, but implements a reliable path towards distributed ledger history across the XRP Ledger Network.
|
||||
|
||||
[](img/xrp-ledger-network-ledger-store-and-shard-store.png)
|
||||
|
||||
## Acquiring and Sharing History Shards
|
||||
|
||||
`rippled` servers acquire and store history shards only if configured to do so. For those servers, acquiring shards begins after synchronizing with the network and backfilling ledger history to the configured number of recent ledgers. During this time of lower network activity, a `rippled` server set to maintain a `shard_db` randomly chooses a shard to add to its shard store. To increase the probability for an even distribution of the network ledger history, shards are randomly selected for acquisition, and the current shard is given no special consideration.
|
||||
|
||||
Once a shard is selected, the ledger acquire process begins by fetching the sequence of the last ledger in the shard and working backwards toward the first. The retrieval process begins with the server checking for the data locally. For data that is not available, the server requests data from its peer `rippled` servers. Those servers that have the data available for the requested period respond with their history. The requesting server combines those responses to create the shard. The shard is complete when it contains all the ledgers in a specific range.
|
||||
|
||||
If a `rippled` server runs out of space before completely acquiring a shard, it stops its retrieval process until it has space available to continue. After that point, the most recently completed shard may replace an older shard. If there is sufficient disk space, the `rippled` server acquires additional randomly selected shards to add to the shard store until reaching the maximum allocated disk space for shards (`max_size_gb`).
|
||||
|
||||
## XRP Ledger Network Data Integrity
|
||||
|
||||
The history of all ledgers is shared by servers agreeing to keep particular ranges of historical ledgers. This makes it possible for servers to confirm that they have all the data they agreed to maintain, and produce proof trees or ledger deltas. Since `rippled` servers that are configured with history sharding randomly select the shards that they store, the entire history of all closed ledgers is stored in a normal distribution curve, increasing the probability that the XRP Ledger Network evenly maintains the history.
|
||||
|
||||
## Shard Store Configuration
|
||||
|
||||
To configure your `rippled` to store shards of ledger history, add a `shard_db` section to your `rippled.cfg` file.
|
||||
|
||||
### Shard Configuration Example
|
||||
The following snippet from an example `rippled.cfg` file shows the configuration fields for adding sharding to a `rippled` server:
|
||||
|
||||
```
|
||||
[shard_db]
|
||||
type=NuDB
|
||||
path=/var/lib/rippled/db/shards/nudb
|
||||
max_size_gb=50
|
||||
```
|
||||
|
||||
**Tip:** Ripple recommends using NuDB for the shard store (`type=NuDB`). NuDB uses fewer file handles per shard than RocksDB. RocksDB uses memory that scales with the size of data it stores, which may require excessive memory overhead.
|
||||
|
||||
**Tip:** While both validator and tracking (or stock) `rippled` servers can be configured to use history shard stores, Ripple recommends adding history sharding only for non-validator `rippled` servers to reduce overhead for validators. If you run a validator and want to manage ledger history using sharding, run a separate `rippled` server with sharding enabled.
|
||||
|
||||
For more information, reference the `[shard_db]` example in the [rippled.cfg configuration example](https://github.com/ripple/rippled/blob/master/doc/rippled-example.cfg).
|
||||
|
||||
### Sizing the Shard Store
|
||||
Determining a suitable size for the shard store involves careful consideration. You should consider the following when deciding what size your shard store should be:
|
||||
|
||||
- Although redundant, it is possible to hold full ledger history in the ledger store and the history shard store.
|
||||
- An effective configuration might limit the ledger store only to recent history.
|
||||
- The ledger store history size should at minimum be twice the ledgers per shard, due to the fact that the current shard may be chosen to be stored and it would be wasteful to reacquire that data.
|
||||
- The time to acquire, number of file handles, and memory cache usage is directly affected by sizing.
|
||||
- Each shard contains 2^14 ledgers (16384).
|
||||
- A shard occupies approximately 200 MB to 4 GB based on the age of the shard. Older shards are smaller because there was less activity in the XRP Ledger at the time.
|
||||
- A shard occupies approximately 200 MB to 4 GB based on the age of the shard. Older shards are smaller because there was less activity in the XRP Ledger at the time.
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
https://docs.google.com/drawings/d/15rIV9apyiVZo6lquys3CBSY9iyiMc0ZorMXOzYN4lW8/edit?usp=sharing
|
||||
@@ -52,14 +52,15 @@ AccountRoot objects can have the following flag values:
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Description | Corresponding [AccountSet Flag](reference-transaction-format.html#accountset-flags) |
|
||||
|-----------|-----------|---------------|-------------|-------------------------------|
|
||||
| lsfPasswordSpent | 0x00010000 | 65536 | Indicates that the account has used its free SetRegularKey transaction. | (None) |
|
||||
| lsfRequireDestTag | 0x00020000 | 131072 | Requires incoming payments to specify a Destination Tag. | asfRequireDest |
|
||||
| lsfRequireAuth | 0x00040000 | 262144 | This account must individually approve other users for those users to hold this account's issuances. | asfRequireAuth |
|
||||
| lsfDisallowXRP | 0x00080000 | 524288 | Client applications should not send XRP to this account. Not enforced by `rippled`. | asfDisallowXRP |
|
||||
| lsfDisableMaster | 0x00100000 | 1048576 | Disallows use of the master key to sign transactions for this account. | asfDisableMaster |
|
||||
| lsfNoFreeze | 0x00200000 | 2097152 | This address cannot freeze trust lines connected to it. Once enabled, cannot be disabled. | asfNoFreeze |
|
||||
| lsfGlobalFreeze | 0x00400000 | 4194304 | All assets issued by this address are frozen. | asfGlobalFreeze |
|
||||
| lsfDefaultRipple | 0x00800000 | 8388608 | Enable [rippling](concept-noripple.html) on this addresses's trust lines by default. Required for issuing addresses; discouraged for others. | asfDefaultRipple |
|
||||
| lsfDepositAuth | 0x01000000 | 16777216 | This account can only receive funds from transactions it sends. (It has [DepositAuth](concept-depositauth.html) enabled.) | asfDepositAuth |
|
||||
| lsfDisableMaster | 0x00100000 | 1048576 | Disallows use of the master key to sign transactions for this account. | asfDisableMaster |
|
||||
| lsfDisallowXRP | 0x00080000 | 524288 | Client applications should not send XRP to this account. Not enforced by `rippled`. | asfDisallowXRP |
|
||||
| lsfGlobalFreeze | 0x00400000 | 4194304 | All assets issued by this address are frozen. | asfGlobalFreeze |
|
||||
| lsfNoFreeze | 0x00200000 | 2097152 | This address cannot freeze trust lines connected to it. Once enabled, cannot be disabled. | asfNoFreeze |
|
||||
| lsfPasswordSpent | 0x00010000 | 65536 | The account has used its free SetRegularKey transaction. | (None) |
|
||||
| lsfRequireAuth | 0x00040000 | 262144 | This account must individually approve other users for those users to hold this account's issuances. | asfRequireAuth |
|
||||
| lsfRequireDestTag | 0x00020000 | 131072 | Requires incoming payments to specify a Destination Tag. | asfRequireDest |
|
||||
|
||||
### AccountRoot ID Format
|
||||
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
# Known Amendments
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/release/src/ripple/app/main/Amendments.cpp "Source")
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/app/main/Amendments.cpp "Source")
|
||||
<!--{# TODO: after 0.90.0 releases, change to https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/Feature.cpp #}-->
|
||||
|
||||
The following is a comprehensive list of all known amendments and their status on the production XRP Ledger:
|
||||
|
||||
@@ -89,6 +90,8 @@ When an account enables this flag, Payment transactions fail if the account is t
|
||||
|
||||
As an exception, accounts with `DepositAuth` enabled can receive Payment transactions for small amounts of XRP (equal or less than the minimum [account reserve](concept-reserves.html)) if their current XRP balance is below the account reserve.
|
||||
|
||||
Also fixes a bug in the EscrowCreate and PaymentChannelCreate transactions where they mistakenly enforced the DisallowXRP flag, which is meant to be a non-binding advisory flag. (By not enforcing DisallowXRP in the ledger itself an account can still receive the necessary XRP to meet its [account reserve](concept-reserves.html) and pay [transaction costs](concept-transaction-cost.html).)
|
||||
|
||||
**Caution:** This amendment is [in development](https://github.com/ripple/rippled/pull/2239) and is expected for `rippled` v0.90.0.
|
||||
|
||||
|
||||
@@ -392,4 +395,4 @@ With this amendment enabled, a `TrustSet` transaction with [`tfSetfAuth` enabled
|
||||
|
||||
|
||||
{% include 'snippets/rippled_versions.md' %}
|
||||
{% include 'snippets/tx-type-links.md' %}
|
||||
{% include 'snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -714,7 +714,7 @@ For the most part, transactions with `tec` codes take no action other than to de
|
||||
| `tecNO_LINE` | 135 | The `TakerPays` field of the [OfferCreate transaction][] specifies an asset whose issuer has `lsfRequireAuth` enabled, and the account making the offer does not have a trust line for that asset. (Normally, making an offer implicitly creates a trust line if necessary, but in this case it does not bother because you cannot hold the asset without authorization.) If the trust line exists, but is not authorized, `tecNO_AUTH` occurs instead. |
|
||||
| `tecNO_LINE_INSUF_RESERVE` | 126 | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](concept-reserves.html)) This error occurs when the counterparty does not have a trust line to this account for the same currency. (See `tecINSUF_RESERVE_LINE` for the other case.) |
|
||||
| `tecNO_LINE_REDUNDANT` | 127 | The transaction failed because it tried to set a trust line to its default state, but the trust line did not exist. |
|
||||
| `tecNO_PERMISSION` | 139 | The sender does not have permission to do this operation. For example, the [EscrowFinish transaction][] tried to release a held payment before its `FinishAfter` time, or someone tried to use [PaymentChannelFund][] on a channel the sender does not own. |
|
||||
| `tecNO_PERMISSION` | 139 | The sender does not have permission to do this operation. For example, the [EscrowFinish transaction][] tried to release a held payment before its `FinishAfter` time, someone tried to use [PaymentChannelFund][] on a channel the sender does not own, or a [Payment][] tried to deliver funds to an account with the "DepositAuth" flag enabled. |
|
||||
| `tecNO_REGULAR_KEY` | 131 | The [AccountSet transaction][] tried to disable the master key, but the account does not have another way to [authorize transactions](#authorizing-transactions). If [multi-signing](#multi-signing) is enabled, this code is deprecated and `tecNO_ALTERNATIVE_KEY` is used instead. |
|
||||
| `tecNO_TARGET` | 138 | The transaction referenced an Escrow or PayChannel ledger object that doesn't exist, either because it never existed or it has already been deleted. (For example, another [EscrowFinish transaction][] has already executed the held payment.) Alternatively, the destination account has `asfDisallowXRP` set so it cannot be the destination of this [PaymentChannelCreate][] or [EscrowCreate][] transaction. |
|
||||
| `tecOVERSIZE` | 145 | This transaction could not be processed, because the server created an excessively large amount of metadata when it tried to apply the transaction. [New in: rippled 0.29.0-hf1][] |
|
||||
|
||||
@@ -52,9 +52,9 @@ A request can include the following parameters:
|
||||
| `account` | String | A unique identifier for the account, most commonly the account's [Address][]. |
|
||||
| `ledger` | Unsigned integer, or String | (Deprecated, Optional) A unique identifier for the ledger version to use, such as a ledger sequence number, a hash, or a shortcut such as "validated". |
|
||||
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string identifying the ledger version to use. |
|
||||
| `ledger_index` | _(Optional)_ [Ledger Index][] | (Optional, defaults to `current`) The sequence number of the ledger to use, or "current", "closed", or "validated" to select a ledger dynamically. (See [Specifying Ledgers](#specifying-ledgers)) |
|
||||
| `ledger_index` | _(Optional)_ [Ledger Index][] | (Optional, defaults to `current`) The sequence number of the ledger to use, or "current", "closed", or "validated" to select a ledger dynamically. (See [Specifying Ledgers](#specifying-ledgers)) |
|
||||
| `limit` | Integer | (Optional, default varies) Limit the number of transactions to retrieve. The server is not required to honor this value. Must be within the inclusive range 10 to 400. [New in: rippled 0.26.4][] |
|
||||
| `marker` | [(Not Specified)](#markers-and-pagination) | Value from a previous paginated response. Resume retrieving data where that response left off. [New in: rippled 0.26.4][] |
|
||||
| `marker` | [(Not Specified)](#markers-and-pagination) | _(Optional)_ Value from a previous paginated response. Resume retrieving data where that response left off. [New in: rippled 0.26.4][] |
|
||||
|
||||
The following parameter is deprecated and may be removed without further notice: `ledger`.
|
||||
|
||||
@@ -163,8 +163,8 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
| `offers` | Array | Array of objects, where each object represents an offer made by this account that is outstanding as of the requested ledger version. If the number of offers is large, only returns up to `limit` at a time. |
|
||||
| `ledger_current_index` | Integer | (Omitted if `ledger_hash` or `ledger_index` provided) Sequence number of the ledger version used when retrieving this data. [New in: rippled 0.26.4-sp1][] |
|
||||
| `ledger_index` | Integer | (Omitted if `ledger_current_index` provided instead) Sequence number, provided in the request, of the ledger version that was used when retrieving this data. [New in: rippled 0.26.4-sp1][] |
|
||||
| `ledger_hash` | String | (May be omitted) Hex hash, provided in the request, of the ledger version that was used when retrieving this data. [New in: rippled 0.26.4-sp1][] |
|
||||
| `marker` | [(Not Specified)](#markers-and-pagination) | Server-defined value indicating the response is paginated. Pass this to the next call to resume where this call left off. Omitted when there are no pages of information after this one. [New in: rippled 0.26.4][] |
|
||||
| `ledger_hash` | String | _(May be omitted)_ Hex hash, provided in the request, of the ledger version that was used when retrieving this data. [New in: rippled 0.26.4-sp1][] |
|
||||
| `marker` | [(Not Specified)](#markers-and-pagination) | _(May be omitted)_ Server-defined value indicating the response is paginated. Pass this to the next call to resume where this call left off. Omitted when there are no pages of information after this one. [New in: rippled 0.26.4][] |
|
||||
|
||||
|
||||
Each offer object contains the following fields:
|
||||
@@ -175,7 +175,7 @@ Each offer object contains the following fields:
|
||||
| `seq` | Unsigned integer | Sequence number of the transaction that created this entry. (Transaction [sequence numbers](#account-sequence) are relative to accounts.) |
|
||||
| `taker_gets` | String or Object | The amount the account accepting the offer receives, as a String representing an amount in XRP, or a currency specification object. (See [Specifying Currency Amounts](#specifying-currency-amounts)) |
|
||||
| `taker_pays` | String or Object | The amount the account accepting the offer provides, as a String representing an amount in XRP, or a currency specification object. (See [Specifying Currency Amounts](#specifying-currency-amounts)) |
|
||||
| `quality` | Number | The exchange rate of the offer, as the ratio of the original `taker_pays` divided by the original `taker_gets`. When executing offers, the offer with the most favorable (lowest) quality is consumed first; offers with the same quality are executed from oldest to newest. [New in: rippled 0.29.0][] |
|
||||
| `quality` | String | The exchange rate of the offer, as the ratio of the original `taker_pays` divided by the original `taker_gets`. When executing offers, the offer with the most favorable (lowest) quality is consumed first; offers with the same quality are executed from oldest to newest. [New in: rippled 0.29.0][] |
|
||||
| `expiration` | Unsigned integer | (May be omitted) A time after which this offer is considered unfunded, as [the number of seconds since the Ripple Epoch](#specifying-time). See also: [Offer Expiration](reference-transaction-format.html#expiration). [New in: rippled 0.30.1][] |
|
||||
|
||||
#### Possible Errors
|
||||
|
||||
@@ -60,14 +60,15 @@ rippled book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6
|
||||
|
||||
The request includes the following parameters:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:---------------|:---------------------------|:-------------------------------|
|
||||
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. (See [Specifying a Ledger](#specifying-ledgers)) |
|
||||
| `ledger_index` | String or Unsigned Integer | _(Optional)_ The sequence number of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-ledgers)) |
|
||||
| `limit` | Unsigned Integer | _(Optional)_ If provided, the server does not provide more than this many offers in the results. The total number of results returned may be fewer than the limit, because the server omits unfunded offers. |
|
||||
| `taker` | String | _(Optional)_ The [Address][] of an account to use as a perspective. [Unfunded offers](reference-transaction-format.html#lifecycle-of-an-offer) placed by this account are always included in the response. (You can use this to look up your own orders to cancel them.) |
|
||||
| `taker_gets` | Object | Specification of which currency the account taking the offer would receive, as an object with `currency` and `issuer` fields (omit issuer for XRP), like [currency amounts](#specifying-currency-amounts). |
|
||||
| `taker_pays` | Object | Specification of which currency the account taking the offer would pay, as an object with `currency` and `issuer` fields (omit issuer for XRP), like [currency amounts](#specifying-currency-amounts). |
|
||||
| `Field` | Type | Description |
|
||||
|:---------------|:-------------------------------------------|:-------------------------------|
|
||||
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. (See [Specifying a Ledger](#specifying-ledgers)) |
|
||||
| `ledger_index` | String or Unsigned Integer | _(Optional)_ The sequence number of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-ledgers)) |
|
||||
| `limit` | Unsigned Integer | _(Optional)_ If provided, the server does not provide more than this many offers in the results. The total number of results returned may be fewer than the limit, because the server omits unfunded offers. |
|
||||
| `marker` | [(Not Specified)](#markers-and-pagination) | _(Optional)_ Value from a previous paginated response. Resume retrieving data where that response left off. |
|
||||
| `taker` | String | _(Optional)_ The [Address][] of an account to use as a perspective. [Unfunded offers](reference-transaction-format.html#lifecycle-of-an-offer) placed by this account are always included in the response. (You can use this to look up your own orders to cancel them.) |
|
||||
| `taker_gets` | Object | Specification of which currency the account taking the offer would receive, as an object with `currency` and `issuer` fields (omit issuer for XRP), like [currency amounts](#specifying-currency-amounts). |
|
||||
| `taker_pays` | Object | Specification of which currency the account taking the offer would pay, as an object with `currency` and `issuer` fields (omit issuer for XRP), like [currency amounts](#specifying-currency-amounts). |
|
||||
|
||||
#### Response Format
|
||||
|
||||
@@ -154,12 +155,13 @@ An example of a successful response:
|
||||
|
||||
The response follows the [standard format](#response-formatting), with a successful result containing the following fields:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:-----------------------|:--------|:------------------------------------------|
|
||||
| `ledger_current_index` | Integer | (Omitted if ledger version provided) Sequence number of the ledger version used when retrieving this data. |
|
||||
| `ledger_index` | Integer | (Omitted if ledger\_current\_index provided instead) Sequence number, provided in the request, of the ledger version that was used when retrieving this data. |
|
||||
| `ledger_hash` | String | (May be omitted) Hex hash, provided in the request, of the ledger version that was used when retrieving this data. |
|
||||
| `offers` | Array | Array of offer objects, each of which has the fields of an [OfferCreate transaction](reference-transaction-format.html#offercreate) |
|
||||
| `Field` | Type | Description |
|
||||
|:-----------------------|:-------------------------------------------|:------------------------------------------|
|
||||
| `ledger_current_index` | Integer | (Omitted if ledger version provided) Sequence number of the ledger version used when retrieving this data. |
|
||||
| `ledger_index` | Integer | (Omitted if ledger\_current\_index provided instead) Sequence number, provided in the request, of the ledger version that was used when retrieving this data. |
|
||||
| `ledger_hash` | String | (May be omitted) Hex hash, provided in the request, of the ledger version that was used when retrieving this data. |
|
||||
| `marker` | [(Not Specified)](#markers-and-pagination) | (May be omitted) Server-defined value indicating the response is paginated. Pass this to the next call to resume where this call left off. Omitted when there are no pages of information after this one. |
|
||||
| `offers` | Array | Array of offer objects, each of which has the fields of an [OfferCreate transaction](reference-transaction-format.html#offercreate) |
|
||||
|
||||
In addition to the standard Offer fields, the following fields may be included in members of the `offers` array:
|
||||
|
||||
|
||||
@@ -201,6 +201,7 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:-----------------------|:-------|:-------------------------------------------|
|
||||
| `account` | String | Unique [Address][] identifying the account that issued the balances. |
|
||||
| `obligations` | Object | (Omitted if empty) Total amounts issued to addresses not excluded, as a map of currencies to the total value issued. |
|
||||
| `balances` | Object | (Omitted if empty) Amounts issued to the `hotwallet` addresses from the request. The keys are addresses and the values are arrays of currency amounts they hold. |
|
||||
| `assets` | Object | (Omitted if empty) Total amounts held that are issued by others. In the recommended configuration, the [issuing address](concept-issuing-and-operational-addresses.html) should have none. |
|
||||
|
||||
159
content/snippets/depositauth-semantics-table.html
Normal file
159
content/snippets/depositauth-semantics-table.html
Normal file
@@ -0,0 +1,159 @@
|
||||
<table class="depauth">
|
||||
<thead>
|
||||
<tr>
|
||||
<th> </th>
|
||||
<th colspan="2" class="depauth-status">DepositAuth Disabled</th>
|
||||
<th class="depauth-spacer"> </th>
|
||||
<th colspan="2" class="depauth-status">DepositAuth Enabled</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Transaction Type</th>
|
||||
<th>Sent by Destination</th><th>Sent by Others</th>
|
||||
<th class="depauth-spacer"> </th>
|
||||
<th>Sent by Destination</th><th>Sent by Others</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td class="depauth-txtype">AccountSet</td>
|
||||
<td colspan="5" class="depauth-na">(This transaction type never sends money.)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">CheckCancel</td>
|
||||
<td colspan="5" class="depauth-na">(This transaction type never sends money.)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">CheckCash</td>
|
||||
<td class="depauth-ok">OK</td>
|
||||
<td class="depauth-no">No Permission</td>
|
||||
<td class="depauth-spacer"> </td>
|
||||
<td class="depauth-ok">OK</td>
|
||||
<td class="depauth-no">No Permission</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">CheckCreate</td>
|
||||
<td colspan="5" class="depauth-na">(This transaction type never sends money.)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">EscrowCancel</td>
|
||||
<td class="depauth-maybe" colspan="5">Can return XRP from an expired escrow</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">EscrowCreate</td>
|
||||
<td colspan="5" class="depauth-na">(This transaction type can only debit XRP, not credit it.)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">EscrowFinish</td>
|
||||
<td class="depauth-ok">OK</td>
|
||||
<td class="depauth-ok">OK</td>
|
||||
<td class="depauth-spacer"> </td>
|
||||
<td class="depauth-ok">OK</td>
|
||||
<td class="depauth-no">No Permission</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">OfferCancel</td>
|
||||
<td colspan="5" class="depauth-na">This transaction type never sends money.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">OfferCreate</td>
|
||||
<td class="depauth-ok">OK</td>
|
||||
<td class="depauth-maybe">Only if account previously created a matching offer</td>
|
||||
<td class="depauth-spacer"> </td>
|
||||
<td class="depauth-ok">OK</td>
|
||||
<td class="depauth-maybe">Only if account previously created a matching offer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">Payment <div class="depauth-subtype">(If account has more than the minimum XRP reserve, enables NoRipple on all trust lines, and places no offers)</div></td>
|
||||
<td class="depauth-maybe">Cross-currency only</td>
|
||||
<td class="depauth-ok">OK</td>
|
||||
<td class="depauth-spacer"> </td>
|
||||
<td class="depauth-no">No Permission</td>
|
||||
<td class="depauth-no">No Permission</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">Payment <div class="depauth-subtype">(If account XRP balance is below the minimum XRP reserve)</div></td>
|
||||
<td class="depauth-maybe">Cross-currency only</td>
|
||||
<td class="depauth-ok">OK</td>
|
||||
<td class="depauth-spacer"> </td>
|
||||
<td class="depauth-no">No Permission</td>
|
||||
<td class="depauth-maybe">XRP payments up to the minimum reserve</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">Payment <div class="depauth-subtype">(If account has any trust lines with NoRipple disabled)</div></td>
|
||||
<td class="depauth-maybe">Cross-currency only</td>
|
||||
<td class="depauth-ok">OK</td>
|
||||
<td class="depauth-spacer"> </td>
|
||||
<td class="depauth-no">No Permission</td>
|
||||
<td class="depauth-maybe">Balance changes from rippling</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">Payment <div class="depauth-subtype">(If account has placed offers)</div></td>
|
||||
<td class="depauth-maybe">Cross-currency only</td>
|
||||
<td class="depauth-ok">OK</td>
|
||||
<td class="depauth-spacer"> </td>
|
||||
<td class="depauth-no">No Permission</td>
|
||||
<td class="depauth-maybe">Balance changes from executing offers</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">PaymentChannelClaim</td>
|
||||
<td class="depauth-ok">OK</td>
|
||||
<td class="depauth-ok">OK</td>
|
||||
<td class="depauth-spacer"> </td>
|
||||
<td class="depauth-ok">OK</td>
|
||||
<td class="depauth-no">No Permission</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">PaymentChannelCreate</td>
|
||||
<td colspan="5" class="depauth-na">(This transaction type can only debit XRP, not credit it.)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">PaymentChannelFund</td>
|
||||
<td class="depauth-maybe" colspan="5">Can return XRP when closing a channel created by self</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">SetRegularKey</td>
|
||||
<td colspan="5" class="depauth-na">(This transaction type never sends money.)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">SignerListSet</td>
|
||||
<td colspan="5" class="depauth-na">(This transaction type never sends money.)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="depauth-txtype">TrustSet</td>
|
||||
<td colspan="5" class="depauth-na">(This transaction type never sends money.)</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<style type="text/css">
|
||||
.depauth-txtype {
|
||||
font-weight: bold;
|
||||
}
|
||||
.depauth-status {
|
||||
text-align: center;
|
||||
}
|
||||
.depauth-na {
|
||||
background-color: #999;
|
||||
}
|
||||
.depauth-ok {
|
||||
background-color: #afa;
|
||||
}
|
||||
.depauth-no {
|
||||
background-color: #faa;
|
||||
}
|
||||
.depauth-maybe {
|
||||
background-color: #ffa;
|
||||
}
|
||||
.depauth-subtype {
|
||||
font-weight: normal;
|
||||
font-size: 8pt;
|
||||
}
|
||||
.depauth-spacer {
|
||||
background-color: black;
|
||||
padding: 2px !important;
|
||||
font-size: 2px;
|
||||
}
|
||||
th.depauth-spacer {
|
||||
border: 1px solid #dbdde2;
|
||||
border-bottom-color: black;
|
||||
}
|
||||
</style>
|
||||
@@ -46,24 +46,25 @@ There are several options which can be either enabled or disabled for an account
|
||||
|
||||
* The `AccountSet` transaction type has several "AccountSet Flags" (prefixed **asf**) that can enable an option when passed as the `SetFlag` parameter, or disable an option when passed as the `ClearFlag` parameter.
|
||||
* The `AccountSet` transaction type has several transaction flags (prefixed **tf**) that can be used to enable or disable specific account options when passed in the `Flags` parameter. This style is discouraged. New account options do not have corresponding transaction (tf) flags.
|
||||
* The `AccountRoot` ledger object type has several ledger-specific-flags (prefixed **lsf**) which represent the state of particular account options within a particular ledger. Naturally, the values apply until a later ledger version changes them.
|
||||
* The `AccountRoot` ledger object type has several ledger-specific-flags (prefixed **lsf**) which represent the state of particular account options within a particular ledger. These settings apply until a transaction changes them.
|
||||
|
||||
The preferred way to enable and disable Account Flags is using the `SetFlag` and `ClearFlag` parameters of an AccountSet transaction. AccountSet flags have names that begin with **asf**.
|
||||
|
||||
All flags are off by default.
|
||||
All flags are disabled by default.
|
||||
|
||||
The available AccountSet flags are:
|
||||
|
||||
| Flag Name | Decimal Value | Corresponding Ledger Flag | Description |
|
||||
|:-----------------|:--------------|:--------------------------|:--------------|
|
||||
| asfRequireDest | 1 | lsfRequireDestTag | Require a destination tag to send transactions to this account. |
|
||||
| asfRequireAuth | 2 | lsfRequireAuth | Require authorization for users to hold balances issued by this address. Can only be enabled if the address has no trust lines connected to it. |
|
||||
| asfDisallowXRP | 3 | lsfDisallowXRP | XRP should not be sent to this account. (Enforced by client applications, not by `rippled`) |
|
||||
| asfDisableMaster | 4 | lsfDisableMaster | Disallow use of the master key. Can only be enabled if the account has configured another way to sign transactions, such as a [Regular Key](#setregularkey) or a [Signer List](#signerlistset). |
|
||||
| asfAccountTxnID | 5 | (None) | Track the ID of this account's most recent transaction. Required for [AccountTxnID](#accounttxnid) |
|
||||
| asfNoFreeze | 6 | lsfNoFreeze | Permanently give up the ability to [freeze individual trust lines or disable Global Freeze](concept-freeze.html). This flag can never be disabled after being enabled. |
|
||||
| asfGlobalFreeze | 7 | lsfGlobalFreeze | [Freeze](concept-freeze.html) all assets issued by this account. |
|
||||
| asfDefaultRipple | 8 | lsfDefaultRipple | Enable [rippling](concept-noripple.html) on this account's trust lines by default. [New in: rippled 0.27.3][] |
|
||||
| asfDepositAuth | 9 | lsfDepositAuth | Enable [Deposit Authorization](concept-depositauth.html) on this account. _(Requires the [DepositAuth amendment](reference-amendments.html#depositauth).)_ |
|
||||
| asfDisableMaster | 4 | lsfDisableMaster | Disallow use of the master key. Can only be enabled if the account has configured another way to sign transactions, such as a [Regular Key](#setregularkey) or a [Signer List](#signerlistset). |
|
||||
| asfDisallowXRP | 3 | lsfDisallowXRP | XRP should not be sent to this account. (Enforced by client applications, not by `rippled`) |
|
||||
| asfGlobalFreeze | 7 | lsfGlobalFreeze | [Freeze](concept-freeze.html) all assets issued by this account. |
|
||||
| asfNoFreeze | 6 | lsfNoFreeze | Permanently give up the ability to [freeze individual trust lines or disable Global Freeze](concept-freeze.html). This flag can never be disabled after being enabled. |
|
||||
| asfRequireAuth | 2 | lsfRequireAuth | Require authorization for users to hold balances issued by this address. Can only be enabled if the address has no trust lines connected to it. |
|
||||
| asfRequireDest | 1 | lsfRequireDestTag | Require a destination tag to send transactions to this account. |
|
||||
|
||||
To enable the `asfDisableMaster` or `asfNoFreeze` flags, you must [authorize the transaction](#authorizing-transactions) by signing it with the master key. You cannot use a regular key or a multi-signature. [New in: rippled 0.28.0][]
|
||||
|
||||
@@ -78,6 +79,7 @@ The following [Transaction flags](#flags), specific to the AccountSet transactio
|
||||
| tfDisallowXRP | 0x00100000 | 1048576 | asfDisallowXRP (SetFlag) |
|
||||
| tfAllowXRP | 0x00200000 | 2097152 | asfDisallowXRP (ClearFlag) |
|
||||
|
||||
**Caution:** The numeric values of `tf` and `asf` flags in transactions do not match up with the values they set in the accounts "at rest" in the ledger. To read the flags of an account in the ledger, see [`AccountRoot` flags](reference-ledger-format.html#accountroot-flags).
|
||||
|
||||
|
||||
#### Blocking Incoming Transactions
|
||||
|
||||
191
content/tutorial-build-run-rippled-ubuntu.md
Normal file
191
content/tutorial-build-run-rippled-ubuntu.md
Normal file
@@ -0,0 +1,191 @@
|
||||
# Build and Run `rippled` on Ubuntu
|
||||
|
||||
`rippled` is the core peer-to-peer server that manages the XRP Ledger. A `rippled` server can connect to a network of peers, relay cryptographically signed transactions, and maintain a local copy of the complete shared global ledger.
|
||||
|
||||
For an overview of `rippled`, see [Operating rippled Servers](tutorial-rippled-setup.html).
|
||||
|
||||
Use these instructions to build a `rippled` executable from source version 0.90.0 or higher on Ubuntu Linux 16.04 or higher. These instructions were tested on Ubuntu 16.04 LTS.
|
||||
|
||||
For information about building `rippled` for other platforms, see [Builds](https://github.com/ripple/rippled/tree/develop/Builds) in the `rippled` GitHub repository.
|
||||
|
||||
|
||||
## System Requirements
|
||||
|
||||
**_To build `rippled`:_**
|
||||
|
||||
You need a **minimum** of 8GB of RAM.
|
||||
|
||||
**_To run `rippled`:_**
|
||||
|
||||
Meet these [system requirements](tutorial-rippled-setup.html#system-requirements).
|
||||
|
||||
|
||||
## 1. Build `rippled`
|
||||
|
||||
These instructions use Ubuntu's APT (Advanced Packaging Tool) to install the software prerequisites you need to build and run `rippled`.
|
||||
|
||||
1. Update the list of packages that are available for `apt-get` to install or upgrade.
|
||||
|
||||
sudo apt-get update
|
||||
|
||||
2. Upgrade currently installed packages.
|
||||
|
||||
sudo apt-get -y upgrade
|
||||
|
||||
3. Install Git.
|
||||
|
||||
sudo apt-get -y install git
|
||||
|
||||
4. Install SCons.
|
||||
|
||||
sudo apt-get -y install scons
|
||||
|
||||
5. Install `pkg-config`.
|
||||
|
||||
sudo apt-get -y install pkg-config
|
||||
|
||||
6. Install Protocol Buffers.
|
||||
|
||||
sudo apt-get -y install protobuf-compiler
|
||||
sudo apt-get -y install libprotobuf-dev
|
||||
|
||||
7. Install Secure Socket Layer (SSL) toolkit development files.
|
||||
|
||||
sudo apt-get -y install libssl-dev
|
||||
|
||||
8. Install `wget` to be able to download Boost in the next step.
|
||||
|
||||
sudo apt-get -y install wget
|
||||
|
||||
9. Compile Boost.
|
||||
|
||||
Starting in `rippled` 0.90, the compatible Boost version is 1.66.0. Because Boost version 1.66.0 isn't available in the Ubuntu 16.04 repos, you must compile it yourself.
|
||||
|
||||
a. Download Boost 1.66.0.
|
||||
|
||||
wget https://dl.bintray.com/boostorg/release/1.66.0/source/boost_1_66_0.tar.gz
|
||||
|
||||
b. Untar `boost_1_66_0.tar.gz`.
|
||||
|
||||
tar xvzf boost_1_66_0.tar.gz
|
||||
|
||||
c. Access the new `boost_1_66_0` directory:
|
||||
|
||||
cd boost_1_66_0
|
||||
|
||||
d. To prepare the Boost.Build system for use, run:
|
||||
|
||||
./bootstrap.sh
|
||||
|
||||
e. To invoke Boost.Build to build the separately-compiled Boost libraries, run the following command. Replace `<number of jobs>` with the number of job, or commands, to run in parallel. This may take about 15 minutes, depending on your hardware specs.
|
||||
|
||||
./b2 -j <number of jobs>
|
||||
|
||||
f. Set the environment variable `BOOST_ROOT` to point to the new `boost_1_66_0` directory. It's best to put this environment variable in your `.profile`, or equivalent, file for your shell so it's automatically set when you log in. Add the following line to the file:
|
||||
|
||||
export BOOST_ROOT=/home/ubuntu/boost_1_66_0
|
||||
|
||||
g. Source your updated `.profile` file. For example:
|
||||
|
||||
source ~/.profile
|
||||
|
||||
10. Get `rippled` source code.
|
||||
|
||||
git clone https://github.com/ripple/rippled.git
|
||||
cd rippled
|
||||
git checkout master
|
||||
|
||||
11. If you previously built, or (more importantly) tried and failed to build `rippled`, you should delete the `build/` directory to start clean before moving on to the next step. Otherwise, you may get unexpected behavior, like a `rippled` executable that crashes due to a segmentation fault (segfault).
|
||||
|
||||
If this is your first time building `rippled,` you won't have a `build/` directory and can move on to the next step.
|
||||
|
||||
12. Build a `rippled` binary executable from source code. This may take about 20 minutes, depending on your hardware specs.
|
||||
|
||||
scons
|
||||
|
||||
SCons saves the built executable in `rippled/build`.
|
||||
|
||||
13. _(Optional)_ Run `rippled` unit tests. If there are no test failures, you can be fairly certain that your `rippled` executable compiled correctly.
|
||||
|
||||
./rippled -u
|
||||
|
||||
|
||||
## 2. Configure `rippled`
|
||||
|
||||
Complete the following configurations that are required for `rippled` to start up successfully. All other configuration is optional and can be tweaked after you have a working server.
|
||||
|
||||
1. Create a copy of the example config file (assumes you're in the `rippled` folder already). Saving the config file to this location enables you to run `rippled` as a non-root user (recommended).
|
||||
|
||||
mkdir -p ~/.config/ripple
|
||||
cp doc/rippled-example.cfg ~/.config/ripple/rippled.cfg
|
||||
|
||||
2. Edit the config file to set necessary file paths. The user you plan to run `rippled` as must have write permissions to all of the paths you specify here.
|
||||
|
||||
1. Set the `[node_db]`'s path to the location where you want to store the ledger database.
|
||||
|
||||
2. Set the `[database_path]` to the location where you want to store other database data. (This includes an SQLite database with configuration data, and is typically one level above the `[node_db]` path field.)
|
||||
|
||||
3. Set the `[debug_logfile]` to a path where `rippled` can write logging information.
|
||||
|
||||
3. Copy the example `validators.txt` file to the same folder as `rippled.cfg`:
|
||||
|
||||
cp doc/validators-example.txt ~/.config/ripple/validators.txt
|
||||
|
||||
**Warning:** Ripple has designed a [decentralization plan](https://ripple.com/dev-blog/decentralization-strategy-update/) with maximum safety in mind. During the transition, you *should not* modify the `validators.txt` file except as recommended by Ripple. Even minor modifications to your validator settings could cause your server to diverge from the rest of the network and report out of date, incomplete, or inaccurate data. Acting on such data can cause you to lose money.
|
||||
|
||||
## 3. Run `rippled`
|
||||
|
||||
To run your stock `rippled` server from the executable you built, using the configurations you defined:
|
||||
```
|
||||
cd build
|
||||
./rippled
|
||||
```
|
||||
|
||||
|
||||
### What to Expect
|
||||
|
||||
Once you've run `rippled`, here are excerpts of what you can expect to see in your terminal.
|
||||
|
||||
```
|
||||
Loading: "/home/ubuntu/.config/ripple/rippled.cfg"
|
||||
Watchdog: Launching child 1
|
||||
2018-Jan-31 20:19:40 JobQueue:NFO Auto-tuning to 4 validation/transaction/proposal threads.
|
||||
2018-Jan-31 20:19:40 Amendments:DBG Amendment 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 is supported.
|
||||
2018-Jan-31 20:19:40 Amendments:DBG Amendment 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC is supported.
|
||||
...
|
||||
2018-Jan-31 20:19:40 OrderBookDB:DBG Advancing from 0 to 3
|
||||
2018-Jan-31 20:19:40 OrderBookDB:DBG OrderBookDB::update>
|
||||
2018-Jan-31 20:19:40 OrderBookDB:DBG OrderBookDB::update< 0 books found
|
||||
2018-Jan-31 20:19:40 ValidatorList:DBG Loading configured trusted validator list publisher keys
|
||||
2018-Jan-31 20:19:40 ValidatorList:DBG Loaded 1 keys
|
||||
2018-Jan-31 20:19:40 ValidatorList:DBG Loading configured validator keys
|
||||
...
|
||||
2018-Jan-31 20:19:40 LedgerConsensus:NFO Entering consensus process, watching, synced=no
|
||||
2018-Jan-31 20:19:40 LedgerConsensus:NFO Consensus mode change before=observing, after=observing
|
||||
...
|
||||
2018-Jan-31 20:19:40 Application:FTL Startup RPC:
|
||||
{
|
||||
"command" : "log_level",
|
||||
"severity" : "warning"
|
||||
}
|
||||
...
|
||||
2018-Jan-31 20:20:32 NetworkOPs:WRN We are not running on the consensus ledger
|
||||
2018-Jan-31 20:20:32 LedgerConsensus:WRN Need consensus ledger 17F251A5AD7120BD0D3ED9EB1B45598AACA1D76EA67C7FFC3384E629C25E198B
|
||||
2018-Jan-31 20:20:35 NetworkOPs:WRN We are not running on the consensus ledger
|
||||
2018-Jan-31 20:20:35 LedgerConsensus:WRN Need consensus ledger 0EAEFBC6C63DE7CEA32415336C7524D50E2531781704CE86895EAF84A63477D7
|
||||
...
|
||||
2018-Jan-31 20:20:53 LedgerConsensus:WRN View of consensus changed during establish status=establish, mode=wrongLedger
|
||||
2018-Jan-31 20:20:53 LedgerConsensus:WRN E5C6EF6AB5C1DB0EA5EF1C43C2EDC1179459FBAC5ABDF6523F488DEE276FA9E6 to 7F0E5EE15F8FC41776BA230094C364DE045C35A15073C9E057407506A9E53892
|
||||
2018-Jan-31 20:20:53 LedgerConsensus:WRN {"accepted":true,"account_hash":"8EE80E7E8ADCE2AB550611752BC4EC748D9DFEBB4B4B98F05BD5F6147CF61ED5","close_flags":0,"close_time":570745240,"close_time_human":"2018-Jan-31 20:20:40","close_time_resolution":20,"closed":true,"hash":"9FA1BAF2A4F6A908B10303E6624E175CCD53D1E87E6B44D09FC28E8FCC63D3C3","ledger_hash":"9FA1BAF2A4F6A908B10303E6624E175CCD53D1E87E6B44D09FC28E8FCC63D3C3","ledger_index":"8","parent_close_time":570745234,"parent_hash":"9AF26062D241A16EDD8436EB1A9B533281D43949A7DA2E4F35A50110537BD596","seqNum":"8","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
|
||||
```
|
||||
|
||||
|
||||
## Explore Next Steps
|
||||
|
||||
* Now that you have a stock `rippled` server running, you may want to consider running it as a validating server. For information about validating servers and why you might want to run one, see the [rippled Setup Tutorial](tutorial-rippled-setup.html).
|
||||
|
||||
* For information about communicating with your `rippled` server using the `rippled` API, see the [`rippled` API reference](reference-rippled.html).
|
||||
|
||||
* As a development best practice, you may want to build a `rippled` `.deb` file. For more information, see _Ubuntu Packaging Guide_: [Packaging New Software](http://packaging.ubuntu.com/html/packaging-new-software.html).
|
||||
|
||||
* 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-package-builder/blob/staging/rpm-builder/rippled.service) or modify it to suit your needs.
|
||||
@@ -55,7 +55,7 @@ There are several properties that define a good validator. The more of these pro
|
||||
* **Identified**. It should be clear who runs the validator. Ideally, a list of trusted validators should include validators operated by different owners in multiple legal jurisdictions and geographic areas, to reduce the chance that any localized events could interfere with the validator's impartial operation.
|
||||
* Setting up [Domain Verification](#domain-verification) is a good start.
|
||||
|
||||
At present, Ripple (the company) cannot recommend any validators aside from the 5 core validators run by Ripple: these validators are included in the default `rippled` configuration. However, we are collecting data on other validators and building tools to report on their performance. For metrics on validators, see [validators.ripple.com](https://validators.ripple.com).
|
||||
At present, Ripple (the company) cannot recommend any validators aside from those in the default validator list. However, we are collecting data on other validators and building tools to report on their performance. For metrics on validators, see [validators.ripple.com](https://validators.ripple.com).
|
||||
|
||||
|
||||
# Installing rippled
|
||||
|
||||
Reference in New Issue
Block a user