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

Set up rippled api links include

Browse Source
This commit is contained in:
mDuo13
2018-05-03 18:23:39 -07:00
parent b606735efd
commit 23f73a38a1
33 changed files with 169 additions and 89 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
content/concepts/complex-payment-types/checks.md
View File

@@ -81,7 +81,7 @@ Checks require `rippled` v0.90.0 or later. The Checks amendment gained support o
<!-- {***TODO:*** update this with the...other pseudo-transaction that will enable this amendment after two weeks with majority support? } -->
When not using the production XRP Ledger, you can check the status of the Checks amendment using the [`feature` command](reference-rippled.html#feature).
When not using the production XRP Ledger, you can check the status of the Checks amendment using the [feature method][].
## Further Reading

2
content/concepts/complex-payment-types/escrow.md
View File

@@ -48,7 +48,7 @@ When testing in [stand-alone mode](concept-stand-alone-mode.html), you can force
[features]
Escrow
You can check the status of the Escrow amendment using the [`feature` command](reference-rippled.html#feature).
You can check the status of the Escrow amendment using the [feature method][].
## EscrowFinish Transaction Cost

6
content/concepts/complex-payment-types/partial-payments.md
View File

@@ -57,9 +57,9 @@ You can find the `delivered_amount` field in the following places:
| API | Method | Field |
|-----|--------|-------|
| [JSON-RPC / WebSocket][] | [`account_tx` command](reference-rippled.html#account-tx) | `result.transactions` array members' `meta.delivered_amount` |
| [JSON-RPC / WebSocket][] | [`tx` command](reference-rippled.html#tx) | `result.meta.delivered_amount` |
| [JSON-RPC / WebSocket][] | [`transaction_entry` command](reference-rippled.html#transaction-entry) | `result.metadata.delivered_amount` |
| [JSON-RPC / WebSocket][] | [account_tx method][] | `result.transactions` array members' `meta.delivered_amount` |
| [JSON-RPC / WebSocket][] | [tx method][] | `result.meta.delivered_amount` |
| [JSON-RPC / WebSocket][] | [transaction_entry method][] | `result.metadata.delivered_amount` |
| [RippleAPI][] | [`getTransaction` method](reference-rippleapi.html#gettransaction) | `outcome.deliveredAmount` |
| [RippleAPI][] | [`getTransactions` method](reference-rippleapi.html#gettransactions) | array members' `outcome.deliveredAmount` |

2
content/concepts/consensus-network/amendments.md
View File

@@ -58,7 +58,7 @@ As with all aspects of the consensus process, amendment votes are only taken int
### Configuring Amendment Voting
You can temporarily configure an amendment using the [`feature` command](reference-rippled.html#feature). To make a persistent change to your server's support for an amendment, change your server's `rippled.cfg` file.
You can temporarily configure an amendment using the [feature method][]. To make a persistent change to your server's support for an amendment, change your server's `rippled.cfg` file.
Use the `[veto_amendments]` stanza to list amendments you do not want the server to vote for. Each line should contain one amendment's unique ID, optionally followed by the short name for the amendment. For example:

8
content/concepts/issued-currencies/authorized-trust-lines.md
View File

@@ -24,7 +24,7 @@ To use the Authorized Trust Lines feature, an issuer must also enable `RequireAu
### Enabling RequireAuth
The following is an example of using a locally-hosted `rippled`'s [`submit` command](reference-rippled.html#submit) to send an [AccountSet transaction][] to enable the RequireAuth flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.)
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an [AccountSet transaction][] to enable the RequireAuth flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.)
Request:
@@ -51,7 +51,7 @@ POST http://localhost:5005/
## Checking Whether an Account Has RequireAuth Enabled
To see whether an account has the RequireAuth setting 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).
To see whether an account has the RequireAuth setting enabled, use the [account_info method][] 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 `lsfRequireAuth` flag value (0x00040000) is nonzero, then the account has RequireAuth enabled. If the result is zero, then the account has RequireAuth disabled.
@@ -61,7 +61,7 @@ If you are using the Authorized Trust Lines feature, others cannot hold balances
To authorize a trust line, submit a [TrustSet transaction][] from your issuing address, with the user to trust as the `issuer` of the `LimitAmount`. Leave the `value` (the amount to trust them for) as **0**, and enable the [tfSetfAuth](reference-transaction-format.html#trustset-flags) flag for the transaction.
The following is an example of using a locally-hosted `rippled`'s [`submit` command](reference-rippled.html#submit) to send a TrustSet transaction authorizing the customer address rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn to hold issuances of USD from the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW:
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send a TrustSet transaction authorizing the customer address rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn to hold issuances of USD from the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW:
Request:
@@ -92,7 +92,7 @@ POST http://localhost:8088/
## Checking Whether Trust Lines Are Authorized
To see whether a trust line has been authorized, use the [`account_lines` command](reference-rippled.html#account-lines) to look up the trust line. In the request, provide the customer's address in the `account` field and the issuer's address in the `peer` field.
To see whether a trust line has been authorized, use the [account_lines method][] to look up the trust line. In the request, provide the customer's address in the `account` field and the issuer's address in the `peer` field.
In the response's `result.lines` array, find the object whose `currency` field indicates that it represents a trust line for the currency you want. If that object has a `peer_authorized` field with the value `true`, then the issuer (the address you used as the request's `peer` field) has authorized the trust line.

4
content/concepts/issued-currencies/freeze.md
View File

@@ -230,7 +230,7 @@ Example JavaScript (ECMAScript 6) code to enable No Freeze on an address:
### Using `rippled`
To see if a trust line has an Individual Freeze enabled, use the [`account_lines` method](reference-rippled.html#account-lines) with the following parameters:
To see if a trust line has an Individual Freeze enabled, use the [account_lines method][] with the following parameters:
| Field | Value | Description |
|----------|---------|-------------|
@@ -313,7 +313,7 @@ Example JavaScript (ECMAScript 6) code to check whether a trust line is frozen:
### Using `rippled`
To see if an address has enabled Global Freeze, No Freeze, or both, use the [`account_info` method](reference-rippled.html#account-lines) with the following parameters:
To see if an address has enabled Global Freeze, No Freeze, or both, use the [account_info method][] with the following parameters:
| Field | Value | Description |
|----------|---------|-------------|

4
content/concepts/issued-currencies/paths.md
View File

@@ -27,9 +27,9 @@ In both types of steps, each intermediate address gains and loses approximately
## Pathfinding
The `rippled` API has two methods that can be used for pathfinding. The [`ripple_path_find` command](reference-rippled.html#ripple-path-find) does a one-time lookup of possible path sets. The [`path_find` command](reference-rippled.html#path-find) (WebSocket only) expands on the search with follow-up responses whenever a ledger closes or the server finds a better path.
The `rippled` API has two methods that can be used for pathfinding. The [ripple_path_find method][] does a one-time lookup of possible path sets. The [path_find method][] (WebSocket only) expands on the search with follow-up responses whenever a ledger closes or the server finds a better path.
You can have `rippled` automatically fill in paths when you sign it, by including the `build_path` field in a request to the [`sign` command](reference-rippled.html#sign) or [`submit` command (sign-and-submit mode)](reference-rippled.html#sign-and-submit-mode). However, we recommend pathfinding separately and confirming the results before signing, to avoid surprises.
You can have `rippled` automatically fill in paths when you sign it, by including the `build_path` field in a request to the [sign method][] or [`submit` command (sign-and-submit mode)](reference-rippled.html#sign-and-submit-mode). However, we recommend pathfinding separately and confirming the results before signing, to avoid surprises.
**Caution:** Although `rippled` is designed to search for the cheapest paths possible, it may not always find them. Untrustworthy `rippled` instances could also be modified to change this behavior for profit. The actual cost to execute a payment along a path can change between submission and transaction execution.

2
content/concepts/issued-currencies/transfer-fees.md
View File

@@ -47,4 +47,4 @@ In `rippled`'s JSON-RPC and WebSocket APIs, the transfer fee is specified in the
A financial institution can submit an [AccountSet transaction](reference-transaction-format.html#accountset) from its [issuing address][] to change the `TransferRate` for its issuances.
You can check an account's `TransferRate` with the [`account_info` command](reference-rippled.html#account-info). If the `TransferRate` is omitted, then that indicates no fee.
You can check an account's `TransferRate` with the [account_info method][]. If the `TransferRate` is omitted, then that indicates no fee.

2
content/concepts/payment-system-basics/accounts/accounts.md
View File

@@ -23,7 +23,7 @@ There is not a dedicated "create account" transaction. The [Payment transaction]
The typical way to get an account in the XRP Ledger is as follows:
1. Generate a key pair from a strong source of randomness and calculate the address of that key pair. (For example, you can use the [`wallet_propose` command](reference-rippled.html#wallet-propose) to do this.)
1. Generate a key pair from a strong source of randomness and calculate the address of that key pair. (For example, you can use the [wallet_propose method][] to do this.)
2. Have someone who already has an account in the XRP Ledger send XRP to the address you generated.

2
content/concepts/payment-system-basics/accounts/concept-depositauth.md
View File

@@ -50,7 +50,7 @@ An account can enable deposit authorization by sending an [AccountSet transactio
## 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).
To see whether an account has Deposit Authorization enabled, use the [account_info method][] 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.

4
content/concepts/payment-system-basics/accounts/cryptographic-keys.md
View File

@@ -50,7 +50,7 @@ You can use this generated key pair in one of three ways: as a [master key pair]
**Key Type**
The field `key_type` indicates what [cryptographic signing algorithm](#signing-algorithms) was used to generate this key pair. You can specify the `key_type` when you make the request to generate a key pair using the [`wallet_propose` command](reference-rippled.html#wallet-propose).
The field `key_type` indicates what [cryptographic signing algorithm](#signing-algorithms) was used to generate this key pair. You can specify the `key_type` when you make the request to generate a key pair using the [wallet_propose method][].
## Master Key Pair
@@ -105,7 +105,7 @@ The XRP Ledger supports the following cryptographic signing algorithms:
| `secp256k1` | [ECDSA](https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/dss2/ecdsa2vs.pdf) using the elliptic curve [secp256k1](https://en.bitcoin.it/wiki/Secp256k1) | This is the scheme used in Bitcoin. The XRP Ledger uses these key types by default. |
| `ed25519` | [EdDSA](https://tools.ietf.org/html/rfc8032) using the elliptic curve [Ed25519](https://ed25519.cr.yp.to/) | This is a newer algorithm which has better performance and other convenient properties. Since Ed25519 public keys are one byte shorter than secp256k1 keys, `rippled` prefixes Ed25519 public keys with the byte `0xED` so both types of public key are 33 bytes. |
When you generate a key pair with the [`wallet_propose` command](reference-rippled.html#wallet-propose), you can specify the `key_type` to choose which cryptographic signing algorithm to use to derive the keys. If you generated a key type other than the default, you must also specify the `key_type` when signing transactions.
When you generate a key pair with the [wallet_propose method][], you can specify the `key_type` to choose which cryptographic signing algorithm to use to derive the keys. If you generated a key type other than the default, you must also specify the `key_type` when signing transactions.
The supported types of key pairs can be used interchangeably throughout the XRP Ledger as master key pairs, regular key pairs, and members of signer lists. The process of [deriving an address](concept-accounts.html#address-encoding) is the same for secp256k1 and Ed25519 key pairs.

8
content/concepts/payment-system-basics/transaction-cost.md
View File

@@ -109,18 +109,18 @@ _Fee levels_ represent the proportional difference between the minimum cost and
The `rippled` APIs have two ways to query the local load-based transaction cost: the `server_info` command (intended for humans) and the `server_state` command (intended for machines).
If the [FeeEscalation amendment](reference-amendments.html#feeescalation) is enabled, you can use the [`fee` command](reference-rippled.html#fee) to check the open ledger cost.
If the [FeeEscalation amendment](reference-amendments.html#feeescalation) is enabled, you can use the [fee method][] to check the open ledger cost.
### server_info
The [`server_info` command](reference-rippled.html#server-info) reports the unscaled minimum XRP cost, as of the previous ledger, as `validated_ledger.base_fee_xrp`, in the form of decimal XRP. The actual cost necessary to relay a transaction is scaled by multiplying that `base_fee_xrp` value by the `load_factor` parameter in the same response, which represents the server's current load level. In other words:
The [server_info method][] reports the unscaled minimum XRP cost, as of the previous ledger, as `validated_ledger.base_fee_xrp`, in the form of decimal XRP. The actual cost necessary to relay a transaction is scaled by multiplying that `base_fee_xrp` value by the `load_factor` parameter in the same response, which represents the server's current load level. In other words:
**Current Transaction Cost in XRP = `base_fee_xrp` × `load_factor`**
### server_state
The [`server_state` command](reference-rippled.html#server-state) returns a direct representation of `rippled`'s internal load calculations. In this case, the effective load rate is the ratio of the current `load_factor` to the `load_base`. The `validated_ledger.base_fee` parameter reports the minimum transaction cost in [drops of XRP](reference-rippled.html#specifying-currency-amounts). This design enables `rippled` to calculate the transaction cost using only integer math, while still allowing a reasonable amount of fine-tuning for server load. The actual calculation of the transaction cost is as follows:
The [server_state method][] returns a direct representation of `rippled`'s internal load calculations. In this case, the effective load rate is the ratio of the current `load_factor` to the `load_base`. The `validated_ledger.base_fee` parameter reports the minimum transaction cost in [drops of XRP](reference-rippled.html#specifying-currency-amounts). This design enables `rippled` to calculate the transaction cost using only integer math, while still allowing a reasonable amount of fine-tuning for server load. The actual calculation of the transaction cost is as follows:
**Current Transaction Cost in Drops = (`base_fee` × `load_factor`) ÷ `load_base`**
@@ -142,7 +142,7 @@ When you sign a transaction online, you can omit the `Fee` field. In this case,
* If the network's transaction cost goes up between signing and distributing the transaction, the transaction may not be confirmed.
* In the worst case, the transaction may be stuck in a state of being neither definitively confirmed or rejected, unless it included a `LastLedgerSequence` parameter or until you cancel it with a new transaction that uses the same `Sequence` number. See [reliable transaction submission](tutorial-reliable-transaction-submission.html) for best practices.
* You do not know in advance exactly what value you are signing for the `Fee` field.
* If you are using `rippled`, you can also use the `fee_mult_max` and `fee_div_max` parameters of the [`sign` command](reference-rippled.html#sign) to set a limit to the load scaling you are willing to sign.
* If you are using `rippled`, you can also use the `fee_mult_max` and `fee_div_max` parameters of the [sign method][] to set a limit to the load scaling you are willing to sign.
* You cannot look up the current transaction cost from an offline machine.
* You cannot automatically specify the transaction cost when [multi-signing](reference-transaction-format.html#multi-signing).

8
content/concepts/the-rippled-server/stand-alone-mode.md
View File

@@ -47,7 +47,7 @@ rippled --conf=/path/to/rippled.cfg
### 2. Wait until `rippled` is synced.
Use the [`server_info` command](reference-rippled.html#server-info) to check the state of your server relative to the network. Your server is synced when the `server_state` value shows any of the following values:
Use the [server_info method][] to check the state of your server relative to the network. Your server is synced when the `server_state` value shows any of the following values:
* `full`
* `proposing`
@@ -59,13 +59,13 @@ For more information, see [Possible Server States](reference-rippled.html#possib
If you only want the most recent ledger, you can skip this step.
If you want to load a specific historical ledger version, use the [`ledger_request` command](reference-rippled.html#ledger-request) to make `rippled` fetch it. If `rippled` does not already have the ledger version, you may have to run the `ledger_request` command multiple times until it has finished retrieving the ledger.
If you want to load a specific historical ledger version, use the [ledger_request method][] to make `rippled` fetch it. If `rippled` does not already have the ledger version, you may have to run the `ledger_request` command multiple times until it has finished retrieving the ledger.
If you want to replay a specific historical ledger version, you must fetch both the ledger version to replay and the ledger version before it. (The previous ledger version sets up the initial state upon which you apply the changes described by the ledger version you replay.)
### 4. Shut down `rippled`.
Use the [`stop` command](reference-rippled.html#stop):
Use the [stop method][]:
```
rippled stop --conf=/path/to/rippled.cfg
@@ -96,7 +96,7 @@ rippled ledger_accept --conf=/path/to/rippled.cfg
## Advancing Ledgers 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` command](reference-rippled.html#ledger-accept):
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][]:
```
rippled ledger_accept --conf=/path/to/rippled.cfg