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

Fix more links in tutorials

Browse Source
This commit is contained in:
mDuo13
2018-05-12 14:54:58 -07:00
parent 04c696ef31
commit 87c0695506
18 changed files with 60 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
content/tutorials/get-started/get-started-with-rippleapi-for-javascript.md
View File

@@ -2,7 +2,7 @@
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.
The scripts and configuration files used in this guide are [available in the Ripple Dev Portal GitHub Repository](https://github.com/ripple/ripple-dev-portal/tree/master/content/code_samples/rippleapi_quickstart).
The scripts and configuration files used in this guide are [available in the Ripple Dev Portal GitHub Repository](https://github.com/ripple/ripple-dev-portal/tree/master/content/_code-samples/rippleapi_quickstart).
# Environment Setup
@@ -282,7 +282,7 @@ The following HTML file demonstrates basic usage of the browser version of Rippl
To use this example, you must first [build RippleAPI](#build-instructions) and then copy one of the resulting output files to the same folder as this HTML file. (You can use either the minified or full-size version.) Change the first `<script>` tag in this example to use the correct file name for the version of RippleAPI you built.
[**browser-demo.html:**](https://github.com/ripple/ripple-dev-portal/blob/master/content/code_samples/rippleapi_quickstart/browser-demo.html "Source on GitHub")
[**browser-demo.html:**](https://github.com/ripple/ripple-dev-portal/blob/master/content/_code-samples/rippleapi_quickstart/browser-demo.html "Source on GitHub")
```
{% include '_code-samples/rippleapi_quickstart/browser-demo.html' %}

8
content/tutorials/get-started/get-started-with-the-rippled-api.md
View File

@@ -2,13 +2,13 @@
Before you can run any commands against a `rippled` server, you must know which server you are connecting to. Most servers are configured not to accept API requests directly from the outside network.
Alternatively, you can [run your own local copy of `rippled`](install-rippled.html). This is required if you want to access any of the [Admin Commands](#list-of-admin-commands). In this case, you should use whatever IP and port you configured the server to bind. (For example, `127.0.0.1:54321`) Additionally, to access admin functionality, you must connect from a port/IP address marked as admin in the config file.
Alternatively, you can [run your own local copy of `rippled`](install-rippled.html). This is required if you want to access any of the [Admin Methods](admin-rippled-methods.html). In this case, you should use whatever IP and port you configured the server to bind. (For example, `127.0.0.1:54321`) Additionally, to access admin functionality, you must connect from a port/IP address marked as admin in the config file.
The [example config file](https://github.com/ripple/rippled/blob/release/doc/rippled-example.cfg#L907-L930) 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.
The [example config file](https://github.com/ripple/rippled/blob/718d217158c41b21b4947fe77f380ae468f6e33a/doc/rippled-example.cfg#L1028-L1056) 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](ripple-api-tool.html). Later on, when you want to connect to your own `rippled` server, you can [build your own client in the browser](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications) or [in Node.js](https://www.npmjs.com/package/ws).
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](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications) or [in Node.js](https://www.npmjs.com/package/ws).
### Request Formatting
@@ -201,7 +201,7 @@ The fields of a successful response include:
| `id` | (Varies) | (WebSocket only) ID provided in the request that prompted this response |
| `status` | String | (WebSocket only) The value `success` indicates the request was successfully received and understood by the server. |
| `result.status` | String | (JSON-RPC and Commandline) The value `success` indicates the request was successfully received and understood by the server. |
| `type` | String | (WebSocket only) The value `response` indicates a successful response to a command. [Asynchronous notifications](#subscriptions) use a different value such as `ledgerClosed` or `transaction`. |
| `type` | String | (WebSocket only) The value `response` indicates a successful response to a command. [Asynchronous notifications](subscriptions.html) use a different value such as `ledgerClosed` or `transaction`. |
| `result` | Object | The result of the query; contents vary depending on the command. |
### Commandline

20
content/tutorials/get-started/get-started.md
View File

@@ -1,20 +0,0 @@
# Get Started
Get up and running with some of the key tools you'll use to work with the XRP Ledger.
* **[Get Started with the `rippled` API](x)**
Learn how to make your first requests to the `rippled` API using our WebSocket and JSON-RPC interfaces. We'll also show you how to make requests to the command line interface, which is not officially supported, but which can be useful for testing and development.
* **[Get Started with `ripple-lib` for JavaScript](x)**
Learn how to make your first requests to `ripple-lib` (aka RippleAPI), a JavaScript API for accessing the XRP Ledger using Node.js and a browser. `ripple-lib` is the official client library of the XRP Ledger.
<!--{# TODO: Need to refine this language -- but the point is that we need to disambiguate ripple-lib, RippleAPI, and rippled API. When you're new (and even if you just haven't used the material in a while) -- to understand the difference between these three very similarly named and related techs. #}-->
* **[Get Started with the Data API v2](x)**
Learn how to make your first calls to the Ripple Data API v2, which provides access to information about changes in the XRP Ledger, including transaction history and processed analytical data.
<!--{# TODO: It would be great to more clearly define the use case for this API vs the rippled API. You could get some of the same info from either -- but what differentiates the Data API? When would I want to call this one vs rippled API? I know it has to do with transactional data and processed data -- but what is the common use case? #}-->
* **[Get Started with Dev Tools](x)**
Learn how and when to use each of our Dev Tools, including the XRP Ledger Test Net and other tools that enable you make requests to our APIs from your browser.

14
content/tutorials/manage-account-settings/assign-a-regular-key-pair.md
View File

@@ -113,11 +113,11 @@ In the next step, you'll use the `account_id` from this response to assign the k
## 2. Assign the Key Pair to Your Account as a Regular Key Pair
Use the [`SetRegularKey`](reference-transaction-format.html#setregularkey) method to assign the key pair you generated in step 1 to your account as a regular key pair.
Use a [SetRegularKey transaction][] to assign the key pair you generated in step 1 to your account as a regular key pair.
When assigning a regular key pair to your account for the first time, the `SetRegularKey` method requires signing by your account's master private key (secret). Transmitting your master private key is dangerous, so we'll complete this transaction in two steps to keep transaction signing separate from transaction submission to the network.
When assigning a regular key pair to your account for the first time, the SetRegularKey transaction requires signing by your account's master private key (secret). Transmitting your master private key is dangerous, so we'll complete this transaction in two steps to keep transaction signing separate from transaction submission to the network.
When you make subsequent `SetRegularKey` requests, you can sign using the existing regular private key to replace or [remove itself](#changing-or-removing-a-regular-key-pair). Note that you should still not submit your regular private key across the network.
When you send subsequent SetRegularKey transactions, you can sign using the existing regular private key to replace or [remove itself](change-or-remove-a-regular-key-pair.html). Note that you should still not submit your regular private key across the network.
### Sign Your Transaction
@@ -389,12 +389,12 @@ An example of a successful response:
<!-- MULTICODE_BLOCK_END -->
Note that the response contains a `hash` of the transaction, which you can use to [look up the transaction's final outcome](reference-rippled.html#tx).
Note that the response contains a `hash` of the transaction, which you can use to [look up the transaction's final outcome](tx.html).
## 3. Verify the Regular Key Pair
To verify that your account has the regular key pair set correctly, submit an [`AccountSet`](reference-transaction-format.html#accountset) transaction from your account, signing it with the regular private key you assigned to your account in step 2.
To verify that your account has the regular key pair set correctly, submit an [AccountSet transaction][] from your account, signing it with the regular private key you assigned to your account in step 2.
As discussed in step 2, transmitting your master private key is dangerous. It is equally risky to transmit your regular private key, though the consequences of being comprised might be less severe. Therefore, we'll complete this transaction in two steps to keep transaction signing separate from transaction submission to the network.
@@ -538,7 +538,7 @@ Next, use the `submit` command to transmit the transaction blob (`tx_blob` or `s
### Submit Your Transaction
Take the `signedTransaction` value from the offline signing response or the `tx_blob` value from the `sign` command response and submit it as the `tx_blob` value using the [`submit`](reference-rippled.html#submit) command.
Take the `signedTransaction` value from the offline signing response or the `tx_blob` value from the `sign` command response and submit it as the `tx_blob` value using the [submit method][].
#### Request Format
@@ -667,7 +667,7 @@ Now that you're familiar with the benefits of assigning a regular key pair to an
- [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)
- [Listing XRP as an Exchange](tutorial-listing-xrp.html)
- [List XRP as an Exchange](list-xrp-as-an-exchange.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

6
content/tutorials/manage-account-settings/change-or-remove-a-regular-key-pair.md
View File

@@ -157,7 +157,7 @@ Next, use the `submit` command to transmit the transaction blob (`tx_blob` or `s
### Submit Your Transaction
Take the `signedTransaction` value from the offline signing response or the `tx_blob` value from the `sign` command response and submit it as the `tx_blob` value using the [`submit`](reference-rippled.html#submit) command.
Take the `signedTransaction` value from the offline signing response or the `tx_blob` value from the `sign` command response and submit it as the `tx_blob` value using the [submit method][].
#### Request Format
@@ -280,7 +280,7 @@ An example of a successful response:
The way to verify that regular key pair removal succeeded is to confirm that you can't send a transaction using the removed regular private key.
Here's an example error response for an [`AccountSet`](reference-transaction-format.html#accountset) transaction signed using the regular private key removed by the `SetRegularKey` transaction above.
Here's an example error response for an [AccountSet transaction][] signed using the regular private key removed by the `SetRegularKey` transaction above.
### Response Format
@@ -353,7 +353,7 @@ An example of a successful response:
<!-- MULTICODE_BLOCK_END -->
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](reference-transaction-format.html#transaction-cost). 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.
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.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

10
content/tutorials/manage-account-settings/set-up-multi-signing.md
View File

@@ -1,6 +1,6 @@
# Set Up Multi-Signing
Multi-signing is one of three ways to authorize transactions for the XRP Ledger, alongside signing with [regular keys](reference-transaction-format.html#setregularkey) and master keys. You can configure your address to allow any combination of the three methods to authorize transactions.
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.
This tutorial demonstrates how to enable multi-signing for an address.
@@ -127,9 +127,9 @@ In this example, the SignerList has 3 members, with the weights and quorum set u
}
}
Make sure that the [Transaction Result](reference-transaction-format.html#transaction-results) is [**tesSUCCESS**](reference-transaction-format.html#tes-success). Otherwise, the transaction failed. If you have a problem in stand-alone mode or a non-production network, check that [multi-sign is enabled](#availability-of-multi-signing).
Make sure that the [Transaction Result](transaction-results.html) is [**tesSUCCESS**](tes-success.html). Otherwise, the transaction failed. If you have a problem in stand-alone mode or a non-production network, check that [multi-sign is enabled](start-a-new-genesis-ledger-in-stand-alone-mode.html#settings-in-new-genesis-ledgers).
**Note:** 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](reference-transaction-format.html#tec-codes). See also: [SignerLists and Reserves](reference-ledger-format.html#signerlists-and-reserves).
**Note:** 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). See also: [SignerLists and Reserves](signerlist.html#signerlists-and-reserves).
## 4. Close the ledger
@@ -206,8 +206,8 @@ 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](reference-transaction-format.html#accountset) using the `asfDisableMaster` flag.
* Remove the address's regular key pair (if you previously set one) by sending a [SetRegularKey transaction](reference-transaction-format.html#setregularkey).
* 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][].
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

2
content/tutorials/manage-the-rippled-server/load-a-saved-ledger-in-stand-alone-mode.md
View File

@@ -52,7 +52,7 @@ rippled -a --load --ledger 19860944 --conf=/path/to/rippled.cfg
## 6. Manually advance the ledger.
When you load a ledger with `--ledger` in stand-alone mode, it goes to the current open ledger, so you must [manually advance the ledger](#advancing-ledgers-in-stand-alone-mode):
When you load a ledger with `--ledger` in stand-alone mode, it goes to the current open ledger, so you must [manually advance the ledger](advance-the-ledger-in-stand-alone-mode.html):
```
rippled ledger_accept --conf=/path/to/rippled.cfg

7
content/tutorials/manage-the-rippled-server/start-a-new-genesis-ledger-in-stand-alone-mode.md
View File

@@ -18,4 +18,9 @@ In a genesis ledger, the [genesis address](accounts.html#special-addresses) hold
In a new genesis ledger, the hard-coded default [Reserve](reserves.html) is **200 XRP** minimum for funding a new address, with an increment of **50 XRP** per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: [Fee Voting](fee-voting.html))
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](reference-transaction-format.html#enableamendment) to turn on all amendments natively supported by the `rippled` server, except for amendments that you explicitly disable in the configuration 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](#advancing-ledgers-in-stand-alone-mode).) [New in: rippled 0.50.0][]
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 configuration 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][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

2
content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-sender.md
View File

@@ -2,7 +2,7 @@
_Requires the [Checks Amendment](known-amendments.html#checks)._
This tutorial shows how to look up [Checks](checks.html) by their sender. You may also want to [look up Checks by recipient](tutorial-checks-lookup-by-recipient.html).
This tutorial shows how to look up [Checks](checks.html) by their sender. You may also want to [look up Checks by recipient](look-up-checks-by-recipient.html).
## 1. Look up all Checks for the address

2
content/tutorials/use-complex-payment-types/use-checks/send-a-check.md
View File

@@ -183,7 +183,7 @@ Use the [tx method][] with the CheckCreate transaction's identifying hash to che
Look for a `CreatedNode` object in the transaction metadata to indicate that the transaction created a [Check ledger object](check.html). The `LedgerIndex` of this object is the ID of the Check. In the following example, the Check's ID is `49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0`.
**Note:** RippleAPI does not report the Check's ID when you look up a CheckCreate transaction. You can work around this by calculating the Check's ID from the [Check ID format](reference-ledger-format.html#check-id-format), as in the example RippleAPI code below. <!--{# TODO: Remove this and update the code samples if ripple-lib #876 gets fixed. #}-->
**Note:** RippleAPI does not report the Check's ID when you look up a CheckCreate transaction. You can work around this by calculating the Check's ID from the [Check ID format](check.html#check-id-format), as in the example RippleAPI code below. <!--{# TODO: Remove this and update the code samples if ripple-lib #876 gets fixed. #}-->
### Example Request

2
content/tutorials/use-complex-payment-types/use-escrows/cancel-an-expired-escrow.md
View File

@@ -57,7 +57,7 @@ _Websocket_
## 2. Submit EscrowCancel transaction
***Anyone*** can cancel an expired escrow in the XRP Ledger by [signing and submitting](reference-transaction-format.html#signing-and-submitting-transactions) an [EscrowCancel transaction][]. Set the `Owner` field of the transaction to the `Account` of the `EscrowCreate` transaction that created this escrow. Set the `OfferSequence` field to the `Sequence` of the `EscrowCreate` transaction.
***Anyone*** can cancel an expired escrow in the XRP Ledger by [signing and submitting](transaction-basics.html#signing-and-submitting-transactions) an [EscrowCancel transaction][]. Set the `Owner` field of the transaction to the `Account` of the `EscrowCreate` transaction that created this escrow. Set the `OfferSequence` field to the `Sequence` of the `EscrowCreate` transaction.
{% include '_snippets/secret-key-warning.md' %} <!--#{ fix md highlighting_ #}-->

6
content/tutorials/use-complex-payment-types/use-escrows/send-a-conditionally-held-escrow.md
View File

@@ -60,7 +60,7 @@ print(cancel_after)
## 3. Submit EscrowCreate transaction
[Sign and submit](reference-transaction-format.html#signing-and-submitting-transactions) an [EscrowCreate transaction][]. Set the `Condition` field of the transaction to the time when the held payment should be released. Set the `Destination` to the recipient, which can be the same address as the sender. Include the `CancelAfter` or `FinishAfter` time you calculated in the previous step. Set the `Amount` to the total amount of [XRP, in drops][], to escrow.
[Sign and submit](transaction-basics.html#signing-and-submitting-transactions) an [EscrowCreate transaction][]. Set the `Condition` field of the transaction to the time when the held payment should be released. Set the `Destination` to the recipient, which can be the same address as the sender. Include the `CancelAfter` or `FinishAfter` time you calculated in the previous step. Set the `Amount` to the total amount of [XRP, in drops][], to escrow.
{% include '_snippets/secret-key-warning.md' %} <!--#{ fix md highlighting_ #}-->
@@ -122,9 +122,9 @@ Response:
## 6. Submit EscrowFinish transaction
[Sign and submit](reference-transaction-format.html#signing-and-submitting-transactions) an [EscrowFinish transaction][] to execute the release of the funds after the `FinishAfter` time has passed. Set the `Owner` field of the transaction to the `Account` address from the EscrowCreate transaction, and the `OfferSequence` to the `Sequence` number from the EscrowCreate transaction. Set the `Condition` and `Fulfillment` fields to the condition and fulfillment values, in hexadecimal, that you generated in step 1. Set the `Fee` ([transaction cost](concept-transaction-cost.html)) value based on the size of the fulfillment in bytes: a conditional EscrowFinish requires at least 330 drops of XRP plus 10 drops per 16 bytes in the size of the fulfillment.
[Sign and submit](transaction-basics.html#signing-and-submitting-transactions) an [EscrowFinish transaction][] to execute the release of the funds after the `FinishAfter` time has passed. Set the `Owner` field of the transaction to the `Account` address from the EscrowCreate transaction, and the `OfferSequence` to the `Sequence` number from the EscrowCreate transaction. Set the `Condition` and `Fulfillment` fields to the condition and fulfillment values, in hexadecimal, that you generated in step 1. Set the `Fee` ([transaction cost](transaction-cost.html)) value based on the size of the fulfillment in bytes: a conditional EscrowFinish requires at least 330 drops of XRP plus 10 drops per 16 bytes in the size of the fulfillment.
**Note:** If you included a `FinishAfter` field in the EscrowCreate transaction, you cannot execute it before that time has passed, even if you provide the correct fulfillment for the Escrow's condition. The EscrowFinish transaction fails with the [result code](reference-transaction-format.html#transaction-results) `tecNO_PERMISSION` if the previously-closed ledger's close time is before the `FinishAfter` time.
**Note:** If you included a `FinishAfter` field in the EscrowCreate transaction, you cannot execute it before that time has passed, even if you provide the correct fulfillment for the Escrow's condition. The EscrowFinish transaction fails with the [result code](transaction-results.html) `tecNO_PERMISSION` if the previously-closed ledger's close time is before the `FinishAfter` time.
If the escrow has expired, you can only [cancel the escrow](cancel-an-expired-escrow.html) instead.

2
content/tutorials/use-complex-payment-types/use-escrows/send-a-time-held-escrow.md
View File

@@ -37,7 +37,7 @@ print(release_date_ripple)
## 2. Submit EscrowCreate transaction
[Sign and submit](reference-transaction-format.html#signing-and-submitting-transactions) an [EscrowCreate transaction][]. Set the `FinishAfter` field of the transaction to the time when the held payment should be released. Omit the `Condition` field to make time the only condition for releasing the held payment. Set the `Destination` to the recipient, which may be the same address as the sender. Set the `Amount` to the total amount of [XRP, in drops][], to escrow.
[Sign and submit](transaction-basics.html#signing-and-submitting-transactions) an [EscrowCreate transaction][]. Set the `FinishAfter` field of the transaction to the time when the held payment should be released. Omit the `Condition` field to make time the only condition for releasing the held payment. Set the `Destination` to the recipient, which may be the same address as the sender. Set the `Amount` to the total amount of [XRP, in drops][], to escrow.
{% include '_snippets/secret-key-warning.md' %} <!--#{ fix md highlighting_ #}-->

4
content/tutorials/use-complex-payment-types/use-payment-channels.md
View File

@@ -287,7 +287,7 @@ Response:
}
}
If the response shows `"signature_verified": true` then the claim's signature is genuine. The payee must **also** confirm that the channel has enough XRP available to honor the claim. To do this, the payee makes an [`account_channels` request](reference-rippled.html#account-channels) to confirm the most recent validated state of the payment channel.
If the response shows `"signature_verified": true` then the claim's signature is genuine. The payee must **also** confirm that the channel has enough XRP available to honor the claim. To do this, the payee uses the [account_channels method][] to confirm the most recent validated state of the payment channel.
Request:
@@ -354,7 +354,7 @@ The payer and payee can repeat steps 3 through 6 (creating, transmitting, and ve
- The amount of XRP in the payment channel. (If necessary, the payer can send a [PaymentChannelFund transaction][] to increase the total amount of XRP available to the channel.)
- The immutable expiration of the payment channel, if one is set. (The `cancel_after` field in the [`account_channels`](reference-rippled.html#account-channels) response shows this.)
- The immutable expiration of the payment channel, if one is set. (The `cancel_after` field in the response to the [account_channels method][] shows this.)
## 8. When ready, the payee redeems a claim for the authorized amount.

10
content/tutorials/use-simple-xrp-payments/reliable-transaction-submission.md
View File

@@ -54,7 +54,7 @@ Each validated ledger has a canonical order in which transactions apply. This or
### LastLedgerSequence
[`LastLedgerSequence`](reference-transaction-format.html#lastledgersequence) is an optional parameter of all transactions. This instructs the XRP Ledger that a transaction must be validated on or before a specific ledger instance. The XRP Ledger never includes a transaction in a ledger instance whose sequence number is higher than the transaction's `LastLedgerSequence` parameter.
`LastLedgerSequence` is an optional [parameter of all transactions](transaction-common-fields.html). This instructs the XRP Ledger that a transaction must be validated on or before a specific ledger instance. The XRP Ledger never includes a transaction in a ledger instance whose sequence number is higher than the transaction's `LastLedgerSequence` parameter.
Use the `LastLedgerSequence` parameter to prevent undesirable cases where a transaction is not confirmed promptly but could be included in a future ledger. You should specify the `LastLedgerSequence` parameter on every transaction. Automated processes should use a value of 4 greater than the last validated ledger index to make sure that a transaction is validated or rejected in a predictable and prompt way.
@@ -138,14 +138,14 @@ The difference between the two transaction failure cases (labeled (1) and (2) in
- In failure case (1), the transaction was included in a ledger and destroyed the [XRP transaction cost](transaction-cost.html), but did nothing else. This could be caused by a lack of liquidity, improperly specified [paths](paths.html), or other circumstances. For many such failures, immediately retrying with a similar transaction is likely to have the same result. You may get different results if you wait for circumstances to change.
- In failure case (2), the transaction was not included in a validated ledger, so it did nothing at all, not even destroy the transaction cost. This could be the result of the transaction cost being too low for the current load on the XRP Ledger, the `LastLedgerSequence` being too soon, or it could be due to other conditions such as an unstable network connection. In contrast to failure case (1), it is more likely that a new transaction is likely to succeed if you change only the `LastLedgerSequence` and possibly the `Fee` and submit again.
- It is also possible that the transaction could not succeed due to the state of the ledger, for example because the sending address disabled the key pair used to sign the transaction. If the transaction's provisional result was a [`tef`-class code](reference-transaction-format.html#tef-codes), the transaction is less likely to succeed without further modification.
- It is also possible that the transaction could not succeed due to the state of the ledger, for example because the sending address disabled the key pair used to sign the transaction. If the transaction's provisional result was a [`tef`-class code](tef-codes.html), the transaction is less likely to succeed without further modification.
#### Ledger Gaps
If your server does not have continuous ledger history from when the transaction was originally submitted up to and including the ledger identified by `LastLedgerSequence`, you may not know the final outcome of the transaction. (If it was included in one of the ledger versions your server is missing, you do not know whether it succeeded or failed.)
Your `rippled` server should automatically acquire the missing ledger versions when it has spare resources (CPU/RAM/disk IO) to do so, unless the ledgers are older than its [configured amount of history to store](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg#L581). Depending on the size of the gap and the resource usage of your server, acquiring missing ledgers should take a few minutes. You can also manually request your server to acquire historical ledger versions using the [`ledger_request` command](reference-rippled.html#ledger-request).
Your `rippled` server should automatically acquire the missing ledger versions when it has spare resources (CPU/RAM/disk IO) to do so, unless the ledgers are older than its [configured amount of history to store](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg#L581). Depending on the size of the gap and the resource usage of your server, acquiring missing ledgers should take a few minutes. You can also manually request your server to acquire historical ledger versions using the [ledger_request method][].
Alternatively, you can look up the status of the transaction using a different `rippled` server that already has the needed ledger history, such as Ripple's full-history servers at `s2.ripple.com`. Only use a server you trust for this purpose. A malicious server could be programmed to provide false information about the status and outcome of a transaction.
@@ -176,7 +176,7 @@ How the application does these actions depends on the API the application uses.
#### Determine the Account Sequence
`rippled` provides the [account_info](reference-rippled.html#account-info) method to learn an account's sequence number in the last validated ledger.
`rippled` provides the [account_info method][] to learn an account's sequence number in the last validated ledger.
JSON-RPC Request:
@@ -222,7 +222,7 @@ If an application were to submit three transactions signed by this account, they
#### Determine the Last Validated Ledger
`rippled` provides the [server_state](reference-rippled.html#server-state) command which returns the ledger sequence number of the last validated ledger.
The [server_state method][] returns the ledger index of the last validated ledger.
Request:

14
content/tutorials/use-simple-xrp-payments/send-a-multisigned-transaction.md
View File

@@ -9,7 +9,7 @@ The following procedure demonstrates how to create, sign, and submit a multi-sig
- 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.
### 1. Create the transaction
## 1. Create the transaction
Create a JSON object that represents the transaction you want to submit. You have to specify _everything_ about this transaction, including `Fee` and `Sequence`. Also include the field `SigningPubKey` as an empty string, to indicate that the transaction is multi-signed.
@@ -34,7 +34,7 @@ Here's an example transaction ready to be multi-signed:
(This transaction creates an accounting relationship from rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC to rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh with a maximum balance of 100 USD.)
### 2. Get one signature
## 2. Get one signature
Use the [sign_for method][] with the secret key and address of one of the members of your SignerList to get a signature for that member.
@@ -88,9 +88,9 @@ Use the [sign_for method][] with the secret key and address of one of the member
Save the `tx_json` field of the response: it has the new signature in the `Signers` field. You can discard the value of the `tx_blob` field.
If you have a problem in stand-alone mode or a non-production network, check that [multi-sign is enabled](#availability-of-multi-signing).
If you have a problem in stand-alone mode or a non-production network, check that [multi-sign is enabled](start-a-new-genesis-ledger-in-stand-alone-mode.html#settings-in-new-genesis-ledgers).
### 3. Get additional signatures
## 3. Get additional signatures
You can collect additional signatures in parallel or in serial:
@@ -165,7 +165,7 @@ You can collect additional signatures in parallel or in serial:
Depending on the SignerList you configured, you may need to repeat this step several times to get signatures from all the necessary parties.
### 4. Combine signatures and submit
## 4. Combine signatures and submit
If you collected the signatures in serial, the `tx_json` from the last `sign_for` response has all the signatures assembled, so you can use that as the argument to the [submit_multisigned method][].
@@ -244,7 +244,7 @@ If you collected the signatures in parallel, you must manually construct a `tx_j
Take note of the `hash` value from the response so you can check the results of the transaction later. (In this case, the hash is `BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6`.)
### 5. Close the ledger
## 5. Close the ledger
If you are using the live network, you can wait 4-7 seconds for the ledger to close automatically.
@@ -261,7 +261,7 @@ If you're running `rippled` in stand-alone mode, use the [ledger_accept method][
}
### 6. Confirm transaction results
## 6. Confirm transaction results
Use the hash value from the response to the `submit_multisigned` command to look up the transaction using the [tx method][]. In particular, check that the `TransactionResult` is the string `tesSUCCESS`.

2
content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md
View File

@@ -443,7 +443,7 @@ Response:
}
```
To confirm that an address has DefaultRipple enabled, look up the address using the [account_info command](reference-rippled.html#account-info), specifying a validated ledger version. Use [a bitwise-AND operator](https://en.wikipedia.org/wiki/Bitwise_operation#AND) to compare the `Flags` field with 0x00800000 (the [ledger flag lsfDefaultRipple](accountroot.html#accountroot-flags)). If the result of the bitwise-AND operation is nonzero, then the address has DefaultRipple enabled.
To confirm that an address has DefaultRipple enabled, look up the address using the [account_info method][], specifying a validated ledger version. Use [a bitwise-AND operator](https://en.wikipedia.org/wiki/Bitwise_operation#AND) to compare the `Flags` field with 0x00800000 (the [ledger flag lsfDefaultRipple](accountroot.html#accountroot-flags)). If the result of the bitwise-AND operation is nonzero, then the address has DefaultRipple enabled.
## Generating Source and Destination Tags

11
dactyl-config.yml
View File

@@ -511,7 +511,7 @@ pages:
targets:
- local
- md: tutorials/get-started/get-started.md
- name: Get Started
html: get-started.html
funnel: Docs
doc_type: Tutorials
@@ -622,6 +622,15 @@ pages:
targets:
- local
- md: tutorials/use-simple-xrp-payments/send-a-multisigned-transaction.md
html: send-a-multisigned-transaction.html
funnel: Docs
doc_type: Tutorials
category: Manage Account Settings
blurb: Send a transaction authorized with multiple signatures.
targets:
- local
# TODO: "Use Deposit Authorization to Block Unwanted Payments" (DOC-1555)
- name: Use Complex Payment Types