mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 03:35:51 +00:00
Reorg Manage Account Settings tutorials
This commit is contained in:
mDuo13
@@ -0,0 +1,12 @@
|
||||
# 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.
|
||||
|
||||
Benefits of multi-signing include:
|
||||
|
||||
* You can require keys from different devices, so that a malicious actor must compromise multiple machines to send transactions on your behalf.
|
||||
* You can share custody of an address between multiple people, each of whom only has one of several keys necessary to send transactions from that address.
|
||||
* You can delegate the power to send transactions from your address to a group of people, who can control your address if you are unavailable or unable to sign normally.
|
||||
* ... and more.
|
||||
|
||||
<!--{# TODO: Expand this and add it to the dactyl-config #}-->
|
||||
@@ -1,18 +1,10 @@
|
||||
# Working with a Regular Key Pair
|
||||
# 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.)
|
||||
|
||||
For more information about master and regular key pairs, see [Cryptographic Keys](concept-cryptographic-keys.html).
|
||||
|
||||
This article provides the following tutorials:
|
||||
|
||||
* [Assigning a regular key pair](#assigning-a-regular-key-pair)
|
||||
* [Changing or removing a regular key pair](#changing-or-removing-a-regular-key-pair)
|
||||
|
||||
|
||||
## Assigning a Regular Key Pair
|
||||
|
||||
This tutorial walks you through the steps required to assign a regular key pair to your account:
|
||||
This tutorial walks through the steps required to assign a regular key pair to your account:
|
||||
|
||||
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)
|
||||
@@ -20,11 +12,11 @@ This tutorial walks you through the steps required to assign a regular key pair
|
||||
4. [Explore next steps](#4-explore-next-steps)
|
||||
|
||||
|
||||
### 1. Generate a Key Pair
|
||||
## 1. Generate a Key Pair
|
||||
|
||||
Use the [`wallet_propose`](reference-rippled.html#wallet-propose) method to generate the key pair that you'll assign to your account as a regular key pair.
|
||||
|
||||
#### Request Format
|
||||
### Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
@@ -56,7 +48,7 @@ rippled wallet_propose
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### Response Format
|
||||
### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
@@ -119,7 +111,7 @@ An example of a successful response:
|
||||
In the next step, you'll use the `account_id` from this response to assign the key pair as a regular key pair to your account. Also, save the `master_seed` value somewhere securely. (Everything else, you can forget about.)
|
||||
|
||||
|
||||
### 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
|
||||
|
||||
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.
|
||||
|
||||
@@ -128,9 +120,10 @@ When assigning a regular key pair to your account for the first time, the `SetRe
|
||||
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.
|
||||
|
||||
|
||||
#### Sign Your Transaction
|
||||
### Sign Your Transaction
|
||||
|
||||
{% include '_snippets/tutorial-sign-step.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
Populate the request fields with the following values:
|
||||
|
||||
@@ -141,7 +134,7 @@ Populate the request fields with the following values:
|
||||
| `secret` | `master_key`, `master_seed`, or `master_seed_hex` (master private key) for your account. |
|
||||
|
||||
|
||||
##### Request Format
|
||||
#### Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
@@ -189,7 +182,7 @@ rippled sign ssCATR7CBvn4GLd1UuU2bqqQffHki '{"TransactionType": "SetRegularKey",
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
##### Response Format
|
||||
#### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
@@ -269,11 +262,11 @@ The `sign` command response contains a `tx_blob` value, as shown above. The offl
|
||||
Next, use the `submit` command to transmit the transaction blob (`tx_blob` or `signedTransaction`) to the network.
|
||||
|
||||
|
||||
#### Submit Your Transaction
|
||||
### 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
|
||||
#### Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
@@ -311,7 +304,7 @@ rippled submit 1200052280000000240000000468400000000000000A73210384CA3C528F10C75
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
##### Response Format
|
||||
#### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
@@ -399,14 +392,14 @@ An example of a successful response:
|
||||
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).
|
||||
|
||||
|
||||
### 3. Verify the Regular Key Pair
|
||||
## 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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
#### Sign Your Transaction
|
||||
### Sign Your Transaction
|
||||
|
||||
The most secure way to sign a transaction is to do it offline with a signing library, such as [RippleAPI](reference-rippleapi.html#offline-functionality). Alternatively, you can sign the transaction using the [`sign`](reference-rippled.html#sign) command, but this must be done through a trusted and encrypted connection, or through a local connection, and only to a server you control.
|
||||
|
||||
@@ -418,7 +411,7 @@ Populate the request fields with the following values:
|
||||
| `secret` | `master_key`, `master_seed`, or `master_seed_hex` (regular private key) generated in step 1 and assigned to your account in step 2. |
|
||||
|
||||
|
||||
##### Request Format
|
||||
#### Request Format
|
||||
|
||||
Here's an example of the request format. Note that the request does not include any `AccountSet` options. This means that a successful transaction has no effect other than to confirm that the regular key pair is set correctly for your account (and to destroy the transaction cost).
|
||||
|
||||
@@ -465,7 +458,7 @@ rippled sign sh8i92YRnEjJy3fpFkL8txQSCVo79 '{"TransactionType": "AccountSet", "A
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
##### Response Format
|
||||
#### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
@@ -542,11 +535,11 @@ The `sign` command response contains a `tx_blob` value, as shown above. The offl
|
||||
Next, use the `submit` command to transmit the transaction blob (`tx_blob` or `signedTransaction`) to the network.
|
||||
|
||||
|
||||
#### Submit Your Transaction
|
||||
### 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.
|
||||
|
||||
##### Request Format
|
||||
#### Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
@@ -584,7 +577,7 @@ rippled submit 1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
##### Response Format
|
||||
#### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
@@ -666,365 +659,16 @@ An example of a successful response:
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
### 4. Explore Next Steps
|
||||
## 4. Explore Next Steps
|
||||
|
||||
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:
|
||||
|
||||
* [How to Multi-Sign](tutorial-multisign.html)
|
||||
* [Issuing and Operational Addresses](concept-issuing-and-operational-addresses.html)
|
||||
* [Listing XRP as an Exchange](tutorial-listing-xrp.html)
|
||||
|
||||
|
||||
## Changing or Removing a Regular Key Pair
|
||||
|
||||
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 the [`SetRegularKey`](reference-transaction-format.html#setregularkey) method to remove or change the regular key pair for your account.
|
||||
|
||||
|
||||
### Changing a Regular Key Pair
|
||||
|
||||
The steps to change your existing regular key pair are almost the same as the steps to [assign a regular key](#assigning-a-regular-key-pair) for the first time. You generate the key pair and assign it to your account as a regular key pair, overwriting the existing regular key pair. However, the main difference is that when changing the existing regular key pair, you can use the existing regular private key to replace itself, whereas when assigning a regular key pair to an account for the first time, you have to use the account's master private key to do it.
|
||||
|
||||
For more information about master and regular key pairs, see [Cryptographic Keys](concept-cryptographic-keys.html).
|
||||
|
||||
|
||||
### Removing a Regular Key Pair
|
||||
|
||||
If you want to simply remove a compromised regular key pair from your account, you don't need to generate a key pair first. Just use the [`SetRegularKey`](reference-transaction-format.html#setregularkey) method, omitting the `RegularKey` value in the request. Note that the method fails if you don't have another way of signing for your account currently enabled (either the master key pair or a [signer list](reference-transaction-format.html#multi-signing)).
|
||||
|
||||
|
||||
When removing a regular key pair to your account, the `SetRegularKey` method requires signing by your account's master private key (secret) or existing regular key pair. Transmitting your master or regular private key is dangerous, so we'll complete this transaction in two steps to keep transaction signing separate from transaction submission to the network.
|
||||
|
||||
#### Sign Your Transaction
|
||||
|
||||
The most secure way to sign a transaction is to do it offline with a signing library, such as [RippleAPI](reference-rippleapi.html#offline-functionality). Alternatively, you can sign the transaction using the [`sign`](reference-rippled.html#sign) command, but this must be done through a trusted and encrypted connection, or through a local connection, and only to a server you control.
|
||||
|
||||
Populate the request fields with the following values:
|
||||
|
||||
| Request Field | Value |
|
||||
|:--------------|:-------------------------------------------------------------|
|
||||
| `Account` | The address of your account. |
|
||||
| `secret` | `master_key`, `master_seed`, or `master_seed_hex` (master or regular private key) for your account. |
|
||||
|
||||
|
||||
##### Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command": "sign",
|
||||
"tx_json": {
|
||||
"TransactionType": "SetRegularKey",
|
||||
"Account": "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8"
|
||||
},
|
||||
"secret": "snoPBrXtMeMyMHUVTgbuqAfg1SUTb"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "sign",
|
||||
"params": [
|
||||
{
|
||||
"secret" : "snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"tx_json" : {
|
||||
"TransactionType" : "SetRegularKey",
|
||||
"Account" : "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
#Syntax: sign secret tx_json
|
||||
rippled sign snoPBrXtMeMyMHUVTgbuqAfg1SUTb '{"TransactionType": "SetRegularKey", "Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"}'
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
##### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json": {
|
||||
"Account": "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee": "10",
|
||||
"Flags": 2147483648,
|
||||
"Sequence": 2,
|
||||
"SigningPubKey": "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType": "SetRegularKey",
|
||||
"TxnSignature": "3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash": "59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{NEWWWWWWWWWWWW
|
||||
"result": {
|
||||
"status": "success",
|
||||
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json": {
|
||||
"Account": "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee": "10",
|
||||
"Flags": 2147483648,
|
||||
"Sequence": 2,
|
||||
"SigningPubKey": "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType": "SetRegularKey",
|
||||
"TxnSignature": "3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash": "59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
{
|
||||
"result" : {
|
||||
"status" : "success",
|
||||
"tx_blob" : "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json" : {
|
||||
"Account" : "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee" : "10",
|
||||
"Flags" : 2147483648,
|
||||
"Sequence" : 2,
|
||||
"SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType" : "SetRegularKey",
|
||||
"TxnSignature" : "3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash" : "59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
The `sign` command response contains a `tx_blob` value, as shown above. The offline signing response contains a `signedTransaction` value. Both are signed binary representations (blobs) of the transaction.
|
||||
|
||||
Next, use the `submit` command to transmit the transaction blob (`tx_blob` or `signedTransaction`) to the network.
|
||||
|
||||
|
||||
#### 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.
|
||||
|
||||
##### Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command": "submit",
|
||||
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method":"submit",
|
||||
"params":[
|
||||
{
|
||||
"tx_blob":"1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
#Syntax: submit tx_blob
|
||||
rippled submit 1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
##### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"engine_result": "tesSUCCESS",
|
||||
"engine_result_code": 0,
|
||||
"engine_result_message": "The transaction was applied. Only final in a validated ledger.",
|
||||
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json": {
|
||||
"Account": "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee": "10",
|
||||
"Flags": 2147483648,
|
||||
"Sequence": 2,
|
||||
"SigningPubKey": "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType": "SetRegularKey",
|
||||
"TxnSignature": "3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash": "59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"engine_result": "tesSUCCESS",
|
||||
"engine_result_code": 0,
|
||||
"engine_result_message": "The transaction was applied. Only final in a validated ledger.",
|
||||
"status": "success",
|
||||
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json": {
|
||||
"Account": "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee": "10",
|
||||
"Flags": 2147483648,
|
||||
"Sequence": 2,
|
||||
"SigningPubKey": "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType": "SetRegularKey",
|
||||
"TxnSignature": "3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash": "59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
{
|
||||
"result" : {
|
||||
"engine_result" : "tesSUCCESS",
|
||||
"engine_result_code" : 0,
|
||||
"engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
|
||||
"status" : "success",
|
||||
"tx_blob" : "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json" : {
|
||||
"Account" : "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee" : "10",
|
||||
"Flags" : 2147483648,
|
||||
"Sequence" : 2,
|
||||
"SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType" : "SetRegularKey",
|
||||
"TxnSignature" : "3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash" : "59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
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.
|
||||
|
||||
|
||||
#### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"error": "badSecret",
|
||||
"error_code": 41,
|
||||
"error_message": "Secret does not match account.",
|
||||
"request": {
|
||||
"command": "submit",
|
||||
"secret": "snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"tx_json": {
|
||||
"Account": "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"TransactionType": "AccountSet"
|
||||
}
|
||||
},
|
||||
"status": "error",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{NEWWWWWWWWWWWW
|
||||
"result": {
|
||||
"error": "badSecret",
|
||||
"error_code": 41,
|
||||
"error_message": "Secret does not match account.",
|
||||
"request": {
|
||||
"command": "submit",
|
||||
"secret": "snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"tx_json": {
|
||||
"Account": "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"TransactionType": "AccountSet"
|
||||
}
|
||||
},
|
||||
"status": "error"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
{
|
||||
"result" : {
|
||||
"error" : "badSecret",
|
||||
"error_code" : 41,
|
||||
"error_message" : "Secret does not match account.",
|
||||
"request" : {
|
||||
"command" : "submit",
|
||||
"secret" : "snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"tx_json" : {
|
||||
"Account" : "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"TransactionType" : "AccountSet"
|
||||
}
|
||||
},
|
||||
"status" : "error"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
In some cases, you can even use the `SetRegularKey` method to send a [key reset transaction](concept-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.
|
||||
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
|
||||
- [How to Multi-Sign](tutorial-multisign.html)
|
||||
- [Issuing and Operational Addresses](concept-issuing-and-operational-addresses.html)
|
||||
- [Listing XRP as an Exchange](tutorial-listing-xrp.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,360 @@
|
||||
# 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.
|
||||
|
||||
For more information about master and regular key pairs, see [Cryptographic Keys](concept-cryptographic-keys.html).
|
||||
|
||||
|
||||
## Changing a Regular Key Pair
|
||||
|
||||
The steps to change your existing regular key pair are almost the same as the steps to [assign a regular key](assign-a-regular-key-pair.html) for the first time. You generate the key pair and assign it to your account as a regular key pair, overwriting the existing regular key pair. However, the main difference is that when changing the existing regular key pair, you can use the existing regular private key to replace itself, whereas when assigning a regular key pair to an account for the first time, you have to use the account's master private key to do it.
|
||||
|
||||
For more information about master and regular key pairs, see [Cryptographic Keys](cryptographic-keys.html).
|
||||
|
||||
|
||||
## Removing a Regular Key Pair
|
||||
|
||||
If you want to simply remove a compromised regular key pair from your account, you don't need to generate a key pair first. Use a [SetRegularKey transaction][], omitting the `RegularKey` field. Note that the transaction fails if you don't have another way of signing for your account currently enabled (either the master key pair or a [signer list](reference-transaction-format.html#multi-signing)).
|
||||
|
||||
|
||||
When removing a regular key pair to your account, the `SetRegularKey` transaction requires signing by your account's master private key (secret) or existing regular key pair. Transmitting your master or regular private key is dangerous, so we'll complete this transaction in two steps to keep transaction signing separate from transaction submission to the network.
|
||||
|
||||
### Sign Your Transaction
|
||||
|
||||
The most secure way to sign a transaction is to do it offline with a signing library, such as [RippleAPI](reference-rippleapi.html#offline-functionality). Alternatively, you can sign the transaction using the [`sign`](reference-rippled.html#sign) command, but this must be done through a trusted and encrypted connection, or through a local connection, and only to a server you control.
|
||||
|
||||
Populate the request fields with the following values:
|
||||
|
||||
| Request Field | Value |
|
||||
|:--------------|:-------------------------------------------------------------|
|
||||
| `Account` | The address of your account. |
|
||||
| `secret` | `master_key`, `master_seed`, or `master_seed_hex` (master or regular private key) for your account. |
|
||||
|
||||
|
||||
#### Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command": "sign",
|
||||
"tx_json": {
|
||||
"TransactionType": "SetRegularKey",
|
||||
"Account": "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8"
|
||||
},
|
||||
"secret": "snoPBrXtMeMyMHUVTgbuqAfg1SUTb"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "sign",
|
||||
"params": [
|
||||
{
|
||||
"secret" : "snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"tx_json" : {
|
||||
"TransactionType" : "SetRegularKey",
|
||||
"Account" : "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
#Syntax: sign secret tx_json
|
||||
rippled sign snoPBrXtMeMyMHUVTgbuqAfg1SUTb '{"TransactionType": "SetRegularKey", "Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"}'
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json": {
|
||||
"Account": "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee": "10",
|
||||
"Flags": 2147483648,
|
||||
"Sequence": 2,
|
||||
"SigningPubKey": "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType": "SetRegularKey",
|
||||
"TxnSignature": "3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash": "59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{NEWWWWWWWWWWWW
|
||||
"result": {
|
||||
"status": "success",
|
||||
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json": {
|
||||
"Account": "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee": "10",
|
||||
"Flags": 2147483648,
|
||||
"Sequence": 2,
|
||||
"SigningPubKey": "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType": "SetRegularKey",
|
||||
"TxnSignature": "3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash": "59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
{
|
||||
"result" : {
|
||||
"status" : "success",
|
||||
"tx_blob" : "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json" : {
|
||||
"Account" : "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee" : "10",
|
||||
"Flags" : 2147483648,
|
||||
"Sequence" : 2,
|
||||
"SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType" : "SetRegularKey",
|
||||
"TxnSignature" : "3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash" : "59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
The `sign` command response contains a `tx_blob` value, as shown above. The offline signing response contains a `signedTransaction` value. Both are signed binary representations (blobs) of the transaction.
|
||||
|
||||
Next, use the `submit` command to transmit the transaction blob (`tx_blob` or `signedTransaction`) to the network.
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
#### Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command": "submit",
|
||||
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method":"submit",
|
||||
"params":[
|
||||
{
|
||||
"tx_blob":"1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
#Syntax: submit tx_blob
|
||||
rippled submit 1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"engine_result": "tesSUCCESS",
|
||||
"engine_result_code": 0,
|
||||
"engine_result_message": "The transaction was applied. Only final in a validated ledger.",
|
||||
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json": {
|
||||
"Account": "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee": "10",
|
||||
"Flags": 2147483648,
|
||||
"Sequence": 2,
|
||||
"SigningPubKey": "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType": "SetRegularKey",
|
||||
"TxnSignature": "3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash": "59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"engine_result": "tesSUCCESS",
|
||||
"engine_result_code": 0,
|
||||
"engine_result_message": "The transaction was applied. Only final in a validated ledger.",
|
||||
"status": "success",
|
||||
"tx_blob": "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json": {
|
||||
"Account": "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee": "10",
|
||||
"Flags": 2147483648,
|
||||
"Sequence": 2,
|
||||
"SigningPubKey": "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType": "SetRegularKey",
|
||||
"TxnSignature": "3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash": "59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
{
|
||||
"result" : {
|
||||
"engine_result" : "tesSUCCESS",
|
||||
"engine_result_code" : 0,
|
||||
"engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
|
||||
"status" : "success",
|
||||
"tx_blob" : "1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json" : {
|
||||
"Account" : "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee" : "10",
|
||||
"Flags" : 2147483648,
|
||||
"Sequence" : 2,
|
||||
"SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType" : "SetRegularKey",
|
||||
"TxnSignature" : "3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash" : "59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
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.
|
||||
|
||||
|
||||
### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"error": "badSecret",
|
||||
"error_code": 41,
|
||||
"error_message": "Secret does not match account.",
|
||||
"request": {
|
||||
"command": "submit",
|
||||
"secret": "snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"tx_json": {
|
||||
"Account": "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"TransactionType": "AccountSet"
|
||||
}
|
||||
},
|
||||
"status": "error",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{NEWWWWWWWWWWWW
|
||||
"result": {
|
||||
"error": "badSecret",
|
||||
"error_code": 41,
|
||||
"error_message": "Secret does not match account.",
|
||||
"request": {
|
||||
"command": "submit",
|
||||
"secret": "snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"tx_json": {
|
||||
"Account": "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"TransactionType": "AccountSet"
|
||||
}
|
||||
},
|
||||
"status": "error"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
{
|
||||
"result" : {
|
||||
"error" : "badSecret",
|
||||
"error_code" : 41,
|
||||
"error_message" : "Secret does not match account.",
|
||||
"request" : {
|
||||
"command" : "submit",
|
||||
"secret" : "snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"tx_json" : {
|
||||
"Account" : "r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"TransactionType" : "AccountSet"
|
||||
}
|
||||
},
|
||||
"status" : "error"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
In some cases, you can even use the `SetRegularKey` transaction to send a [key reset transaction](concept-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.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,25 +0,0 @@
|
||||
# Manage Account Settings
|
||||
<!--{# TODO: updated this tutorial section to include account creation -- which was in the Send and Receive Money tutorials section. I did this because to manage account settings - you need an account first. Seems to flow better? Or we can say before you can use these tutorials, you must create an account - see the related tutorial section in Send and Receive Money. #}-->
|
||||
|
||||
Create an XRP Ledger account and configure it to send and receive payments the way you want it to.
|
||||
|
||||
* **[Create an XRP Ledger Account](x)**
|
||||
|
||||
Learn how to generate and fund an XRP Ledger address to create an XRP Ledger account.
|
||||
|
||||
* **[Set Up Your Account to Work with a Regular Key Pair](x)**
|
||||
|
||||
Learn how to set up your account to use a regular key pair to sign transactions. Unlike with the private key of your primary key pair, if the private key of your regular key pair is compromised, you can remove or replace it without changing the rest of your account and having to re-establishing its relationships to other accounts.
|
||||
|
||||
* **[Set Up Issuing and Operational Addresses for Your Account](x)**
|
||||
|
||||
Learn how to set up your account with multiple XRP Ledger addresses to be used strategically to minimize the risk associated with a compromised secret key.
|
||||
|
||||
* **[Set Up Your Account to Use Issued Currencies](x)**
|
||||
|
||||
Learn how to set up your account to use issued currencies, including how to set the `NoRipple` flag and require authorization for users to hold balances issued by this account.
|
||||
|
||||
* **[Set Up Your Account to Use XRP](x)**
|
||||
|
||||
Learn how to set up your account to use XRP, including how to enable deposit authorization, which strictly rejects any incoming money from transactions sent by other accounts.
|
||||
<!--{# TODO: the doc for this setting says: This includes transfers of XRP and issued currencies. So, is this one needs to go in that "third bucket" that applies to both XRP and issued currencies? Or is this a setting only for XRP accounts that stops it from holding issued currencies? #}-->
|
||||
@@ -0,0 +1,215 @@
|
||||
# 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.
|
||||
|
||||
This tutorial demonstrates how to enable multi-signing for an address.
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- You must have a funded XRP Ledger address.
|
||||
|
||||
- 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**](concept-amendments.html) to the XRP Ledger Consensus Protocol since 2016-06-27.
|
||||
|
||||
|
||||
## 1. Prepare a funded address
|
||||
|
||||
You need an XRP Ledger address that can send transactions, and has enough XRP available. Multi-signing requires more than the usual amount of XRP for the [account reserve](concept-reserves.html) and [transaction cost](concept-transaction-cost.html), increasing with the number of signers and signatures you use.
|
||||
|
||||
If you started `rippled` in [stand-alone mode](concept-stand-alone-mode.html) 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](reference-rippled.html#specifying-currency-amounts).)
|
||||
3. Manually close the ledger.
|
||||
|
||||
|
||||
## 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:
|
||||
|
||||
$ rippled wallet_propose
|
||||
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"account_id" : "rnRJ4dpSBKDR2M1itf4Ah6tZZm5xuNZFPH",
|
||||
"key_type" : "secp256k1",
|
||||
"master_key" : "FLOG SEND GOES CUFF GAGE FAT ANTI DEL GUM TIRE ISLE BEAR",
|
||||
"master_seed" : "snheH5UUjU4CWqiNVLny2k21TyKPC",
|
||||
"master_seed_hex" : "A9F859765EB8614D26809836382AFB82",
|
||||
"public_key" : "aBR4hxFXcDNHnGYvTiqb2KU8TTTV1cYV9wXTAuz2DjBm7S8TYEBU",
|
||||
"public_key_hex" : "03C09A5D112B393D531E4F092E3A5769A5752129F0A9C55C61B3A226BB9B567B9B",
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
|
||||
Take note of the `account_id` (XRP Ledger Address) and `master_seed` (secret key) for each one you generate.
|
||||
|
||||
|
||||
## 3. Send SignerListSet transaction
|
||||
|
||||
[Sign and submit](reference-transaction-format.html#signing-and-submitting-transactions) a [SignerListSet transaction](reference-transaction-format.html#signerlistset) in the normal (single-signature) way. This associates a SignerList with your XRP Ledger address, so that a combination of signatures from the members of that SignerList can multi-sign later transactions on your behalf.
|
||||
|
||||
In this example, the SignerList has 3 members, with the weights and quorum set up such that multi-signed transactions need a signature from rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other two members of the list.
|
||||
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
$ rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{
|
||||
> "Flags": 0,
|
||||
> "TransactionType": "SignerListSet",
|
||||
> "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
|
||||
> "Fee": "10000",
|
||||
> "SignerQuorum": 3,
|
||||
> "SignerEntries": [
|
||||
> {
|
||||
> "SignerEntry": {
|
||||
> "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
> "SignerWeight": 2
|
||||
> }
|
||||
> },
|
||||
> {
|
||||
> "SignerEntry": {
|
||||
> "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
> "SignerWeight": 1
|
||||
> }
|
||||
> },
|
||||
> {
|
||||
> "SignerEntry": {
|
||||
> "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
|
||||
> "SignerWeight": 1
|
||||
> }
|
||||
> }
|
||||
> ]
|
||||
> }'
|
||||
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"engine_result" : "tesSUCCESS",
|
||||
"engine_result_code" : 0,
|
||||
"engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
|
||||
"status" : "success",
|
||||
"tx_blob" : "12000C2200000000240000000120230000000368400000000000271073210303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D74473045022100BEDFA12502C66DDCB64521972E5356F4DB965F553853D53D4C69B4897F11B4780220595202D1E080345B65BAF8EBD6CA161C227F1B62C7E72EA5CA282B9434A6F04281142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1F4EB1300028114204288D2E47F8EF6C99BCC457966320D12409711E1EB13000181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1EB13000181143A4C02EA95AD6AC3BED92FA036E0BBFB712C030CE1F1",
|
||||
"tx_json" : {
|
||||
"Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
|
||||
"Fee" : "10000",
|
||||
"Flags" : 0,
|
||||
"Sequence" : 1,
|
||||
"SignerEntries" : [
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"SignerWeight" : 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
"SignerWeight" : 1
|
||||
}
|
||||
},
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
|
||||
"SignerWeight" : 1
|
||||
}
|
||||
}
|
||||
],
|
||||
"SignerQuorum" : 3,
|
||||
"SigningPubKey" : "0303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D",
|
||||
"TransactionType" : "SignerListSet",
|
||||
"TxnSignature" : "3045022100BEDFA12502C66DDCB64521972E5356F4DB965F553853D53D4C69B4897F11B4780220595202D1E080345B65BAF8EBD6CA161C227F1B62C7E72EA5CA282B9434A6F042",
|
||||
"hash" : "3950D98AD20DA52EBB1F3937EF32F382D74092A4C8DF9A0B1A06ED25200B5756"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
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).
|
||||
|
||||
**Note:** The more members in the SignerList, the more XRP your address must have for purposes of the [owner reserve](concept-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).
|
||||
|
||||
|
||||
## 4. Close the ledger
|
||||
|
||||
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"
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
## 5. Confirm the new signer list
|
||||
|
||||
Use the [account_objects method][] to confirm that the SignerList is associated with the address in the latest validated ledger.
|
||||
|
||||
Normally, an account can own many objects of different types (such as trust lines and offers). If you funded a new address for this tutorial, the SignerList is the only object in the response.
|
||||
|
||||
$ rippled account_objects rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC validated
|
||||
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
|
||||
"account_objects" : [
|
||||
{
|
||||
"Flags" : 0,
|
||||
"LedgerEntryType" : "SignerList",
|
||||
"OwnerNode" : "0000000000000000",
|
||||
"PreviousTxnID" : "8FDC18960455C196A8C4DE0D24799209A21F4A17E32102B5162BD79466B90222",
|
||||
"PreviousTxnLgrSeq" : 5,
|
||||
"SignerEntries" : [
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"SignerWeight" : 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
|
||||
"SignerWeight" : 1
|
||||
}
|
||||
},
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
"SignerWeight" : 1
|
||||
}
|
||||
}
|
||||
],
|
||||
"SignerListID" : 0,
|
||||
"SignerQuorum" : 3,
|
||||
"index" : "79FD203E4DDDF2EA78B798C963487120C048C78652A28682425E47C96D016F92"
|
||||
}
|
||||
],
|
||||
"ledger_hash" : "56E81069F06492FB410A70218C08169BE3AB3CFD5AEA20E999662D81DC361D9F",
|
||||
"ledger_index" : 5,
|
||||
"status" : "success",
|
||||
"validated" : true
|
||||
}
|
||||
}
|
||||
|
||||
If the SignerList is present with the expected contents, then your address is ready to multi-sign.
|
||||
|
||||
## 6. Further steps
|
||||
|
||||
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).
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,236 +1,13 @@
|
||||
# How to Multi-Sign
|
||||
# Send a Multi-Signed Transaction
|
||||
|
||||
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.
|
||||
The following procedure demonstrates how to create, sign, and submit a multi-signed transaction.
|
||||
|
||||
Benefits of multi-signing include:
|
||||
## Prerequisites
|
||||
|
||||
* You can require keys from different devices, so that a malicious actor must compromise multiple machines to send transactions on your behalf.
|
||||
* You can share custody of an address between multiple people, each of whom only has one of several keys necessary to send transactions from that address.
|
||||
* You can delegate the power to send transactions from your address to a group of people, who can control your address if you are unavailable or unable to sign normally.
|
||||
* ... and more.
|
||||
- You must have already [set up multi-signing](set-up-multi-signing.html) for your address.
|
||||
|
||||
To use multi-signing:
|
||||
- Multi-signing must be available. Multi-signing has been enabled by an [**Amendment**](concept-amendments.html) to the XRP Ledger Consensus Protocol since 2016-06-27.
|
||||
|
||||
1. [The XRP Ledger peer-to-peer network must have multi-signing enabled.](#availability-of-multi-signing)
|
||||
2. [Set up a list of signers on your account.](#setting-up-multi-signing)
|
||||
3. [Send transactions using multiple signatures.](#sending-a-multi-signed-transaction)
|
||||
|
||||
|
||||
## Availability of Multi-Signing
|
||||
|
||||
Multi-signing has been enabled by an [**Amendment**](concept-amendments.html) to the XRP Ledger Consensus Protocol since 2016-06-27.
|
||||
|
||||
If you want to use multi-signing with `rippled` with a fresh ledger in [stand-alone mode](concept-stand-alone-mode.html), you must force the MultiSign feature to be enabled. You can check the status of the MultiSign amendment using the [feature method][].
|
||||
|
||||
To force the multi-signing feature to be enabled, add the following stanza to your `rippled.cfg`: <!--{# TODO: Link to rippled.cfg docs when those exist. #}-->
|
||||
|
||||
[features]
|
||||
MultiSign
|
||||
|
||||
|
||||
## Setting up Multi-Signing
|
||||
|
||||
To multi-sign transactions from a particular address, you must create a list of addresses that can contribute to a multi-signature for your address. This list is stored in the XRP Ledger as a [SignerList node](reference-ledger-format.html#signerlist). The following procedure demonstrates how to set up a SignerList for your address:
|
||||
|
||||
|
||||
### 1. Prepare a funded address
|
||||
|
||||
You need an XRP Ledger address that can send transactions, and has enough XRP available. Multi-signing requires more than the usual amount of XRP for the [account reserve](concept-reserves.html) and [transaction cost](concept-transaction-cost.html), increasing with the number of signers and signatures you use.
|
||||
|
||||
If you started `rippled` in [stand-alone mode](concept-stand-alone-mode.html) 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](reference-rippled.html#specifying-currency-amounts).)
|
||||
3. Manually close the ledger.
|
||||
|
||||
|
||||
### 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:
|
||||
|
||||
$ rippled wallet_propose
|
||||
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"account_id" : "rnRJ4dpSBKDR2M1itf4Ah6tZZm5xuNZFPH",
|
||||
"key_type" : "secp256k1",
|
||||
"master_key" : "FLOG SEND GOES CUFF GAGE FAT ANTI DEL GUM TIRE ISLE BEAR",
|
||||
"master_seed" : "snheH5UUjU4CWqiNVLny2k21TyKPC",
|
||||
"master_seed_hex" : "A9F859765EB8614D26809836382AFB82",
|
||||
"public_key" : "aBR4hxFXcDNHnGYvTiqb2KU8TTTV1cYV9wXTAuz2DjBm7S8TYEBU",
|
||||
"public_key_hex" : "03C09A5D112B393D531E4F092E3A5769A5752129F0A9C55C61B3A226BB9B567B9B",
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
|
||||
Take note of the `account_id` (XRP Ledger Address) and `master_seed` (secret key) for each one you generate.
|
||||
|
||||
|
||||
### 3. Send SignerListSet transaction
|
||||
|
||||
[Sign and submit](reference-transaction-format.html#signing-and-submitting-transactions) a [SignerListSet transaction](reference-transaction-format.html#signerlistset) in the normal (single-signature) way. This associates a SignerList with your XRP Ledger address, so that a combination of signatures from the members of that SignerList can multi-sign later transactions on your behalf.
|
||||
|
||||
In this example, the SignerList has 3 members, with the weights and quorum set up such that multi-signed transactions need a signature from rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other two members of the list.
|
||||
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
|
||||
$ rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{
|
||||
> "Flags": 0,
|
||||
> "TransactionType": "SignerListSet",
|
||||
> "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
|
||||
> "Fee": "10000",
|
||||
> "SignerQuorum": 3,
|
||||
> "SignerEntries": [
|
||||
> {
|
||||
> "SignerEntry": {
|
||||
> "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
> "SignerWeight": 2
|
||||
> }
|
||||
> },
|
||||
> {
|
||||
> "SignerEntry": {
|
||||
> "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
> "SignerWeight": 1
|
||||
> }
|
||||
> },
|
||||
> {
|
||||
> "SignerEntry": {
|
||||
> "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
|
||||
> "SignerWeight": 1
|
||||
> }
|
||||
> }
|
||||
> ]
|
||||
> }'
|
||||
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"engine_result" : "tesSUCCESS",
|
||||
"engine_result_code" : 0,
|
||||
"engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
|
||||
"status" : "success",
|
||||
"tx_blob" : "12000C2200000000240000000120230000000368400000000000271073210303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D74473045022100BEDFA12502C66DDCB64521972E5356F4DB965F553853D53D4C69B4897F11B4780220595202D1E080345B65BAF8EBD6CA161C227F1B62C7E72EA5CA282B9434A6F04281142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1F4EB1300028114204288D2E47F8EF6C99BCC457966320D12409711E1EB13000181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1EB13000181143A4C02EA95AD6AC3BED92FA036E0BBFB712C030CE1F1",
|
||||
"tx_json" : {
|
||||
"Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
|
||||
"Fee" : "10000",
|
||||
"Flags" : 0,
|
||||
"Sequence" : 1,
|
||||
"SignerEntries" : [
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"SignerWeight" : 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
"SignerWeight" : 1
|
||||
}
|
||||
},
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
|
||||
"SignerWeight" : 1
|
||||
}
|
||||
}
|
||||
],
|
||||
"SignerQuorum" : 3,
|
||||
"SigningPubKey" : "0303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D",
|
||||
"TransactionType" : "SignerListSet",
|
||||
"TxnSignature" : "3045022100BEDFA12502C66DDCB64521972E5356F4DB965F553853D53D4C69B4897F11B4780220595202D1E080345B65BAF8EBD6CA161C227F1B62C7E72EA5CA282B9434A6F042",
|
||||
"hash" : "3950D98AD20DA52EBB1F3937EF32F382D74092A4C8DF9A0B1A06ED25200B5756"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
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).
|
||||
|
||||
**Note:** The more members in the SignerList, the more XRP your address must have for purposes of the [owner reserve](concept-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).
|
||||
|
||||
|
||||
### 4. Close the ledger
|
||||
|
||||
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"
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
### 5. Confirm the new signer list
|
||||
|
||||
Use the [account_objects method][] to confirm that the SignerList is associated with the address in the latest validated ledger.
|
||||
|
||||
Normally, an account can own many objects of different types (such as trust lines and offers). If you funded a new address for this tutorial, the SignerList is the only object in the response.
|
||||
|
||||
$ rippled account_objects rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC validated
|
||||
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
|
||||
"account_objects" : [
|
||||
{
|
||||
"Flags" : 0,
|
||||
"LedgerEntryType" : "SignerList",
|
||||
"OwnerNode" : "0000000000000000",
|
||||
"PreviousTxnID" : "8FDC18960455C196A8C4DE0D24799209A21F4A17E32102B5162BD79466B90222",
|
||||
"PreviousTxnLgrSeq" : 5,
|
||||
"SignerEntries" : [
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"SignerWeight" : 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
|
||||
"SignerWeight" : 1
|
||||
}
|
||||
},
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
"SignerWeight" : 1
|
||||
}
|
||||
}
|
||||
],
|
||||
"SignerListID" : 0,
|
||||
"SignerQuorum" : 3,
|
||||
"index" : "79FD203E4DDDF2EA78B798C963487120C048C78652A28682425E47C96D016F92"
|
||||
}
|
||||
],
|
||||
"ledger_hash" : "56E81069F06492FB410A70218C08169BE3AB3CFD5AEA20E999662D81DC361D9F",
|
||||
"ledger_index" : 5,
|
||||
"status" : "success",
|
||||
"validated" : true
|
||||
}
|
||||
}
|
||||
|
||||
If the SignerList is present with the expected contents, then your address is ready to multi-sign.
|
||||
|
||||
### 6. Further steps
|
||||
|
||||
At this point, your address is ready to [send a multi-signed transaction](#sending-a-multi-signed-transaction). 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).
|
||||
|
||||
|
||||
## Sending a Multi-Signed Transaction
|
||||
|
||||
Before you can multi-sign a transaction, first [set up multi-signing](#setting-up-multi-signing) for your address. The following procedure demonstrates how to create, sign, and submit a multi-signed transaction.
|
||||
|
||||
### 1. Create the transaction
|
||||
|
||||
@@ -262,6 +39,7 @@ Here's an example transaction ready to be multi-signed:
|
||||
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.
|
||||
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
$ rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW <rsA2L..'s secret> '{
|
||||
> "TransactionType": "TrustSet",
|
||||
@@ -320,6 +98,7 @@ You can collect additional signatures in parallel or in serial:
|
||||
* In serial: Use the `sign_for` command with the `tx_json` value from the previous `sign_for` response. Each response adds a new signature to the existing `Signers` array.
|
||||
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
$ rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v <rUpy..'s secret> '{
|
||||
> "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
|
||||
@@ -600,3 +379,8 @@ In stand-alone mode, the server automatically considers a ledger to be `validate
|
||||
"validated": true
|
||||
}
|
||||
}
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
Reference in New Issue
Block a user