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

IA: add links for tutorials

Browse Source 
IA: more tutorial links

IA: Tutorials stuff

- Move 'Cancel or Skip a Transaction' to 'About Canceling a Transaction'
  (Fixes #582)
- Add more 'See Also' links to Escrow & Payment Channel tutorials
This commit is contained in:
mDuo13
2019-09-03 14:39:28 -07:00
parent faff49afbd
commit d972643b6e
46 changed files with 774 additions and 145 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -1,6 +1,6 @@
# Assign a Regular Key Pair
The XRP Ledger allows an account to authorize a secondary key pair, called a _regular key pair_, to sign future transactions. If the private key of a regular key pair is compromised, you can remove or replace it without changing the rest of your account and re-establishing its relationships to other accounts. You can also rotate a regular key pair proactively. (Neither of those things is possible for the master key pair of an account, which is intrinsically linked to the account's address.)
The XRP Ledger allows an account to authorize a secondary key pair, called a _[regular key pair](cryptographic-keys.html)_, to sign future transactions. If the private key of a regular key pair is compromised, you can remove or replace it without changing the rest of your [account](accounts.html) and re-establishing its relationships to other accounts. You can also rotate a regular key pair proactively. (Neither of those things is possible for the master key pair of an account, which is intrinsically linked to the account's address.)
For more information about master and regular key pairs, see [Cryptographic Keys](cryptographic-keys.html).
@@ -9,7 +9,7 @@ This tutorial walks through the steps required to assign a regular key pair to y
1. [Generate a key pair](#1-generate-a-key-pair)
2. [Assign the key pair to your account as a regular key pair](#2-assign-the-key-pair-to-your-account-as-a-regular-key-pair)
3. [Verify the regular key pair](#3-verify-the-regular-key-pair)
4. [Explore next steps](#4-explore-next-steps)
4. [Explore next steps](#see-also)
## 1. Generate a Key Pair
@@ -660,14 +660,27 @@ An example of a successful response:
<!-- MULTICODE_BLOCK_END -->
## 4. Explore Next Steps
## See Also
Now that you're familiar with the benefits of assigning a regular key pair to an account, consider taking a look at these related topics and tutorials:
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
- [Set Up Multi-Signing](set-up-multi-signing.html)
- [Issuing and Operational Addresses](issuing-and-operational-addresses.html)
- [List XRP as an Exchange](list-xrp-as-an-exchange.html)
- **Concepts:**
- [Cryptographic Keys](cryptographic-keys.html)
- [Multi-Signing](multi-signing.html)
- [Issuing and Operational Addresses](issuing-and-operational-addresses.html)
- **Tutorials:**
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
- [Set Up Multi-Signing](set-up-multi-signing.html)
- [List XRP as an Exchange](list-xrp-as-an-exchange.html)
- **References:**
- [wallet_propose method][]
- [sign method][]
- [SetRegularKey transaction][]
- [AccountRoot object](accountroot.html) where the regular key is stored in the field `RegularKey`
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

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

@@ -1,6 +1,6 @@
# Change or Remove a Regular Key Pair
The XRP Ledger allows an account to authorize a secondary key pair, called a _regular key pair_, to sign future transactions. If your account's regular key pair is compromised, or if you just want to periodically change the regular key pair as a security measure, use a [SetRegularKey transaction][] to remove or change the regular key pair for your account.
The XRP Ledger allows an account to authorize a secondary key pair, called a _[regular key pair](cryptographic-keys.html)_, to sign future transactions. If your [account](accounts.html)'s regular key pair is compromised, or if you just want to periodically change the regular key pair as a security measure, use a [SetRegularKey transaction][] to remove or change the regular key pair for your account.
For more information about master and regular key pairs, see [Cryptographic Keys](cryptographic-keys.html).
@@ -40,7 +40,7 @@ An example of the request format:
*WebSocket*
```
```json
{
"command": "sign",
"tx_json": {
@@ -53,7 +53,7 @@ An example of the request format:
*JSON-RPC*
```
```json
{
"method": "sign",
"params": [
@@ -70,7 +70,7 @@ An example of the request format:
*Commandline*
```
```sh
#Syntax: sign secret tx_json
rippled sign snoPBrXtMeMyMHUVTgbuqAfg1SUTb '{"TransactionType": "SetRegularKey", "Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"}'
```
@@ -86,7 +86,7 @@ An example of a successful response:
*WebSocket*
```
```json
{
"result": {
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
@@ -108,8 +108,8 @@ An example of a successful response:
*JSON-RPC*
```
{NEWWWWWWWWWWWW
```json
{
"result": {
"status": "success",
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
@@ -129,7 +129,7 @@ An example of a successful response:
*Commandline*
```
```json
{
"result" : {
"status" : "success",
@@ -167,7 +167,7 @@ An example of the request format:
*WebSocket*
```
```json
{
"command": "submit",
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E"
@@ -176,7 +176,7 @@ An example of the request format:
*JSON-RPC*
```
```json
{
"method":"submit",
"params":[
@@ -189,7 +189,7 @@ An example of the request format:
*Commandline*
```
```sh
#Syntax: submit tx_blob
rippled submit 1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E
```
@@ -205,7 +205,7 @@ An example of a successful response:
*WebSocket*
```
```json
{
"result": {
"engine_result": "tesSUCCESS",
@@ -230,7 +230,7 @@ An example of a successful response:
*JSON-RPC*
```
```json
{
"result": {
"engine_result": "tesSUCCESS",
@@ -254,7 +254,7 @@ An example of a successful response:
*Commandline*
```
```json
{
"result" : {
"engine_result" : "tesSUCCESS",
@@ -291,7 +291,7 @@ An example of a successful response:
*WebSocket*
```
```json
{
"error": "badSecret",
"error_code": 41,
@@ -311,8 +311,8 @@ An example of a successful response:
*JSON-RPC*
```
{NEWWWWWWWWWWWW
```json
{
"result": {
"error": "badSecret",
"error_code": 41,
@@ -332,7 +332,7 @@ An example of a successful response:
*Commandline*
```
```json
{
"result" : {
"error" : "badSecret",
@@ -355,6 +355,22 @@ An example of a successful response:
In some cases, you can even use the `SetRegularKey` transaction to send a [key reset transaction](transaction-cost.html#key-reset-transaction) without paying the [transaction cost](transaction-cost.html). With the enablement of the FeeEscalation amendment, `rippled` prioritizes key reset transactions above other transactions even though the nominal transaction cost of a key reset transaction is zero.
- **Concepts:**
- [Cryptographic Keys](cryptographic-keys.html)
- [Multi-Signing](multi-signing.html)
- [Transaction Cost](transaction-cost.html)
- **Tutorials:**
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
- [Set Up Multi-Signing](set-up-multi-signing.html)
- [List XRP as an Exchange](list-xrp-as-an-exchange.html)
- **References:**
- [wallet_propose method][]
- [sign method][]
- [SetRegularKey transaction][]
- [AccountRoot object](accountroot.html) where the regular key is stored in the field `RegularKey`
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

38
content/tutorials/manage-account-settings/require-destination-tags.md
View File

@@ -1,14 +1,19 @@
# Require Destination Tags
The `RequireDest` setting (`requireDestinationTag` in RippleAPI) is designed to prevent customers from sending payments to your address if they forgot the [destination tag](source-and-destination-tags.html) that identifies who should be credited for the payment. When enabled, the XRP Ledger rejects any payment to your address that does not specify a destination tag.
The `RequireDest` setting (`requireDestinationTag` in RippleAPI) is designed to prevent customers from sending [payments](payment-types.html) to your address if they forgot the [destination tag](source-and-destination-tags.html) that identifies whom to credit for the payment. When enabled, the XRP Ledger rejects any payment to your address if it does not specify a destination tag.
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction to enable the `RequireDest` flag:
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an [AccountSet transaction][] to enable the `RequireDest` flag:
Request:
```
<!-- MULTICODE_BLOCK_START -->
*JSON-RPC*
```json
POST http://localhost:5005/
Content-Type: application/json
{
"method": "submit",
"params": [
@@ -29,9 +34,15 @@ Content-Type: application/json
{% include '_snippets/secret-key-warning.md' %}
<!--{#_ #}-->
<!-- MULTICODE_BLOCK_END -->
Response:
```
<!-- MULTICODE_BLOCK_START -->
*JSON-RPC*
```json
200 OK
{
@@ -57,11 +68,24 @@ Response:
}
```
<!-- MULTICODE_BLOCK_END -->
## See Also
- [Source and Destination Tags](source-and-destination-tags.html)
- [XRP Ledger Businesses](xrp-ledger-businesses.html)
- [Payment Types](payment-types.html)
- **Concepts:**
- [Accounts](accounts.html)
- [Source and Destination Tags](source-and-destination-tags.html)
- [Transaction Cost](transaction-cost.html)
- [Payment Types](payment-types.html)
- **Tutorials:**
- [XRP Ledger Businesses](xrp-ledger-businesses.html)
- **References:**
- [account_info method][]
- [AccountSet transaction][]
- [AccountRoot Flags](accountroot.html#accountroot-flags)
<!--{# common link defs #}-->

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

@@ -1,37 +1,34 @@
# Set Up Multi-Signing
Multi-signing is one of three ways to authorize transactions for the XRP Ledger, alongside signing with [regular keys and master keys](cryptographic-keys.html). You can configure your address to allow any combination of the three methods to authorize transactions.
[Multi-signing](multi-signing.html) is one of three ways to authorize [transactions](transaction-basics.html) for the XRP Ledger, alongside signing with [regular keys and master keys](cryptographic-keys.html). You can configure your [address](accounts.html) to allow any combination of the three methods to authorize transactions.
This tutorial demonstrates how to enable multi-signing for an address.
## Prerequisites
- You must have a funded XRP Ledger address.
- You must have a funded XRP Ledger [address](accounts.html) with enough spare XRP to send transactions and meet the [reserve requirement](reserves.html) of a new signer list.
- With the [MultiSignReserve amendment][] enabled, multi-signing requires 5 XRP for the account reserve, regardless of the number of signers and signatures you use. (The MultiSignReserve amendment has been enabled in the production XRP Ledger since **2019-04-07**.)
- If you are on a test network that does not have the [MultiSignReserve amendment][] enabled, multi-signing requires more than the usual amount of XRP for the [account reserve](reserves.html), increasing with the number of signers in the list.
- You must have access to a tool that can generate key pairs in the XRP Ledger format. If you are using a `rippled` server for this, you must have admin access because the [wallet_propose method][] is admin-only.
- Multi-signing must be available. Multi-signing has been enabled by an [**Amendment**](amendments.html) to the XRP Ledger Consensus Protocol since 2016-06-27.
- Alternatively, if you are authorizing others who already have XRP Ledger addresses to be signers for your address, you only need to know the account addresses of those people or entities.
- Multi-signing must be available. (The MultiSign amendment has been enabled in the production XRP Ledger since **2016-06-27**.)
## 1. Prepare a funded address
## 1. Design Your Configuration
You need an XRP Ledger address that can send transactions, and has enough XRP available.
Without the [MultiSignReserve amendment][], multi-signing requires more than the usual amount of XRP for the [account reserve](reserves.html) and [transaction cost](transaction-cost.html), increasing with the number of signers and signatures you use.
With the [MultiSignReserve amendment][] enabled, multi-signing requires 5 XRP for the account reserve, regardless of the number of signers and signatures you use. The [transaction cost](transaction-cost.html) of a multi-signed transaction is unaffected by this amendment and still increases with the number of signers and signatures you use.
If you started `rippled` in [stand-alone mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode) with a new genesis ledger, you must:
1. Generate keys for a new address, or reuse keys you already have.
2. Submit a Payment transaction to fund the new address from the genesis account. (Send at least 100,000,000 [drops of XRP][].)
3. Manually close the ledger.
Decide how many signers you want to include (up to 8). Choose a quorum number for your signer list and weights for your signers based on how many signatures you want to require for a given transaction. For a straightforward "M-of-N" signing setup, assign each signer weight **`1`** and set your list's quorum to be "M", the number of signatures to require.
## 2. Prepare member keys
You need several sets of XRP Ledger keys (address and secret) to include as members of your SignerList. These can be funded addresses that exist in the ledger, or you can generate new addresses using the [wallet_propose method][]. For example:
You need one or more validly-formed XRP Ledger addresses to include as members of your signer list. You or your chosen signers must know the secret keys associated with these addresses. The addresses can be funded accounts that exist in the ledger, but they do not need to be.
You can generate new addresses using the [wallet_propose method][]. For example:
$ rippled wallet_propose
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
@@ -136,21 +133,9 @@ Make sure that the [Transaction Result](transaction-results.html) is [**tesSUCCE
**Note:** Without the [MultiSignReserve amendment][], the more members in the SignerList, the more XRP your address must have for purposes of the [owner reserve](reserves.html#owner-reserves). If your address does not have enough XRP, the transaction fails with [tecINSUFFICIENT_RESERVE](tec-codes.html). With the [MultiSignReserve amendment][] enabled, the XRP your address must have for purposes of the [owner reserve](reserves.html#owner-reserves) is 5 XRP, regardless of the number of members in the SignerList. See also: [SignerLists and Reserves](signerlist.html#signerlists-and-reserves).
## 4. Close the ledger
## 4. Wait for validation
On the live network, you can wait 4-7 seconds for the ledger to close automatically.
If you're running `rippled` in stand-alone mode, use the [ledger_accept method][] to manually close the ledger:
$ rippled ledger_accept
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"ledger_current_index" : 6,
"status" : "success"
}
}
{% include '_snippets/wait-for-validation.md' %} <!--#{ fix md highlighting_ #}-->
## 5. Confirm the new signer list
@@ -211,7 +196,25 @@ If the SignerList is present with the expected contents, then your address is re
At this point, your address is ready to [send a multi-signed transaction](send-a-multi-signed-transaction.html). You may also want to:
* Disable the address's master key pair by sending an [AccountSet transaction][] using the `asfDisableMaster` flag.
* Remove the address's regular key pair (if you previously set one) by sending a [SetRegularKey transaction][].
* [Remove the address's regular key pair](change-or-remove-a-regular-key-pair.html) (if you previously set one) by sending a [SetRegularKey transaction][].
## See Also
- **Concepts:**
- [Cryptographic Keys](cryptographic-keys.html)
- [Multi-Signing](multi-signing.html)
- **Tutorials:**
- [Install rippled](install-rippled.html)
- [Assign a Regular Key Pair](assign-a-regular-key-pair.html)
- [Reliable Transaction Submission](reliable-transaction-submission.html)
- [Enable Public Signing](enable-public-signing.html)
- **References:**
- [wallet_propose method][]
- [account_objects method][]
- [sign_for method][]
- [submit_multisigned method][]
- [SignerListSet transaction][]
- [SignerList object](signerlist.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}