ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-12-06 17:27:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

addressed feedback

Browse Source
This commit is contained in:
Jennifer Hasegawa
2018-02-13 18:25:57 -08:00
parent f5a8da4b18
commit 7a1de066da
7 changed files with 587 additions and 117 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
content/concept-keys.md
View File

@@ -2,7 +2,7 @@
In the XRP Ledger, a digital signature proves that a transaction is authorized to do a specific set of actions. A digital signature is created based on a key pair associated with the transaction's sending account.
You generate a key pair using the `wallet_propose` method. Here's a sample `wallet_propose` response:
You generate a key pair using the [`wallet_propose`](reference-rippled.html#wallet-propose) method. Here's a sample `wallet_propose` response:
```
{
@@ -20,32 +20,32 @@ You generate a key pair using the `wallet_propose` method. Here's a sample `wall
}
```
As you can see, in the context of the XRP Ledger, a key pair is composed of a bit more than a private key and a public key.
The response contains a key pair, a private key and a public key (in various formats), as well as an `account_id`.
**Private Key**
The `master_key`, `master_seed`, and `master_seed_hex` are the private key in various formats, all of which can be used to sign transactions. Despite being prefixed with `master_`, these keys are not necessarily the master keys for an account. In this context, the `master_` prefix refers more to the keys' role as private keys.
The `master_key`, `master_seed`, and `master_seed_hex` are the private key in various formats, all of which can be used to sign transactions. Despite being prefixed with `master_`, these keys are not necessarily the master keys for an account. In this context, the `master_` prefix refers more to the keys' role as private keys. The `master_seed` is the master seed from which all other information about this account is derived.
**Public Key**
The `public_key` and `public_key_hex` are the public key in various formats, with the `public_key_hex` being the public key corresponding to the private key that signed the transaction.
The `public_key` and `public_key_hex` are the public key in various formats, with the `public_key_hex` being the public key corresponding to the private key that signed the transaction. Both the `public_key` and `public_key_hex` are directly derived from the `master_seed`.
**account_id**
The `account_id` is [derived from the public key](concept-accounts.html#address-encoding) and designates the *potential* for an account to be created in the XRP Ledger. It is important to know that while an `account_id` exists, no actual account exists in the XRP Ledger until the `account_id` receives its first XRP payment. In addition, the `account_id` can't send any transactions until after it's received a transaction that funds and creates the account.
The `account_id` (without a funded account) can, however, be used as a regular key or a member of a signer list to authorize transactions for another account that does exist.
The `account_id` (without a funded account) can, however, be used as a [regular key](#regular-key-pair) or a [member of a signer list](reference-transaction-format.html#multi-signing) to authorize transactions for another account that does exist.
To create a funded account stored in the ledger, the `account_id` must [receive a `Payment` transaction](reference-transaction-format.html#creating-accounts) that provides enough XRP to meet the [reserve requirement](concept-reserves.html).
For more information about the `wallet_propose` response, see [`wallet_propose`](reference-rippled.html#wallet-propose).
You use this generated key pair in one of three ways: as master keys, regular keys, or [signer list members](tutorial-multisign.html).
You use this generated key pair in one of three ways: as [master keys](#master-key-pair), [regular keys](#regular-key-pair), or [signer list members](reference-transaction-format.html#multi-signing).
## Master Keys
## Master Key Pair
The master key pair, called a "master key," is composed of a private key and a public key. In addition to being able to sign all transactions that a regular key can, the master key's private key is the only key that can be used to perform the following actions:
The master key pair is composed of a private key and a public key. In addition to being able to sign all transactions that a regular key pair can, the master key pair's private key is the only key that can be used to perform the following actions:
* [Disable the master public key](reference-transaction-format.html#accountset-flags).
@@ -53,32 +53,32 @@ The master key pair, called a "master key," is composed of a private key and a p
* Send a cost-0 [key reset transaction](concept-transaction-cost.html#key-reset-transaction).
The master key for an account is generated in the same [`wallet_propose`](reference-rippled.html#wallet-propose) response as the `account_id` of the account the master key is authorized to sign transactions for. Because the master key is generated in the same response, it is [intrinsically related](concept-accounts.html#address-encoding) to the `account_id`, which is derived from the `public_key_hex`.
The master key pair for an account is generated in the same [`wallet_propose`](reference-rippled.html#wallet-propose) response as the `account_id` of the account the master key pair is authorized to sign transactions for. Because the master key pair is generated in the same response, it is [intrinsically related](concept-accounts.html#address-encoding) to the `account_id`, which is derived from the `public_key_hex`.
This is as opposed to a regular key, which is also generated using the `wallet_propose` method, but which must be explicitly assigned as a regular key to an account. Because a regular key is explicitly assigned, it are not intrinsically related to the `account_id` of the account is are authorized to sign transactions for. For more information, see [Regular Keys](#regular-keys).
This is as opposed to a regular key pair, which is also generated using the `wallet_propose` method, but which must be explicitly assigned as a regular key pair to an account. Because a regular key pair is explicitly assigned, it is not intrinsically related to the `account_id` of the account it is authorized to sign transactions for. For more information, see [Regular Key Pair](#regular-key-pair).
**Caution:** A master key cannot be changed, but it can be disabled. This means that if your master private key is compromised, rather than change it, you must [disable it](reference-transaction-format.html#accountset-flags).
**Caution:** A master key pair cannot be changed, but it can be disabled. This means that if your master private key is compromised, rather than change it, you must [disable it](reference-transaction-format.html#accountset-flags).
This is a compelling reason to keep your master key offline and set up a regular key to sign transactions from your account instead.
Because a master key pair cannot be changed and can only disabled in the event of a compromise, this is a compelling reason to keep your master key pair offline and set up a regular key pair to sign transactions from your account instead.
Keeping your master key offline means not putting your master private key somewhere malicious actors can get access to it. For example, this can mean keeping it on an air-gapped machine that never connects to the internet, on a piece of paper stored in a safe, or in general, not within reach of a computer program that interacts with the internet at large. Ideally, a master key is used only on the most trusted of devices and for emergencies only, such as to change a regular key in the event of a possible or actual compromise.
Keeping your master key pair offline means not putting your master private key somewhere malicious actors can get access to it. For example, this can mean keeping it on an air-gapped machine that never connects to the internet, on a piece of paper stored in a safe, or in general, not within reach of a computer program that interacts with the internet at large. Ideally, a master key pair is used only on the most trusted of devices and for emergencies only, such as to change a regular key pair in the event of a possible or actual compromise.
## Regular Keys
## Regular Key Pair
The XRP Ledger allows an account to authorize a secondary key pair, called a "regular key," to sign future transactions, while keeping your master keys offline. If the private key of a regular key 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 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_, to sign future transactions, while keeping your master key pair offline. 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.)
You generate a key to use as a regular key using the [`wallet_propose`](reference-rippled.html#wallet-propose) method. However, unlike with [master keys](#master-keys), which are generated alongside and intrinsically related to the `account_id` of an account they support, you must explicitly create the relationship between a regular key and the account you want them to sign transactions for. You use the [`SetRegularKey`](reference-transaction-format.html#setregularkey) method to assign a regular key to an account.
You generate a key pair to use as a regular key pair using the [`wallet_propose`](reference-rippled.html#wallet-propose) method. However, unlike with a [master key pair](#master-key-pair), which is generated alongside and intrinsically related to the `account_id` of an account it supports, you must explicitly create the relationship between a regular key pair and the account you want it to sign transactions for. You use the [`SetRegularKey`](reference-transaction-format.html#setregularkey) method to assign a regular key pair to an account.
For a tutorial on assigning a regular key, see [Working with Regular Keys](tutorial-regular-keys.html).
For a tutorial on assigning a regular key pair, see [Working with Regular Keys](tutorial-regular-keys.html).
Once you assign a regular key to an account, the account has two keys associated with it:
After you assign a regular key pair to an account, the account has two key pairs associated with it:
* A "master" key that is intrinsically related to the account's `account_id` and which you keep offline.
* A "regular" key that you've explicitly assigned to the account and which you use to sign transactions for the account.
* A "master" key pair that is intrinsically related to the account's `account_id` and which you keep offline.
* A "regular" key pair that you've explicitly assigned to the account and which you use to sign transactions for the account.
You can assign one regular key to an account and use it to sign all transactions, except for the ones reserved for [master keys](#master-keys).
You can assign one regular key pair to an account and use it to sign all transactions, except for the ones reserved for the [master key pair](#master-key-pair).
You can remove or change a regular key at any time. This means that if a regular private key is compromised (but the master private key is not), you can regain control of your account by simply removing or changing the regular key.
You can remove or change a regular key pair at any time. This means that if a regular private key is compromised (but the master private key is not), you can regain control of your account by simply removing or changing the regular key pair.
For a tutorial on changing or removing a regular key, see [Working with Regular Keys](tutorial-regular-keys.html).
For a tutorial on changing or removing a regular key pair, see [Working with Regular Keys](tutorial-regular-keys.html).

4
content/concept-signatures.md
View File

@@ -8,6 +8,8 @@ In the XRP Ledger, a digital signature proves that a transaction is authorized t
Here's an overview of some of the more common signature-related fields used in the XRP Ledger.
***TODO: address from Ryan: Where would you see these fields? Either address in text -- or ensure that this is answered via the flow diagram discussed below.***
***TODO: JHA fix the IA here. Also need to more clearly express the single-signer flow vs multi-signer flow. Provide a flow diagram. Also need to move some conceptual content out of "Authorizing Transactions" and "Signing and Submitting Transactions" and put it in this doc.***
## `SigningPubKey` (top-level)
@@ -18,7 +20,7 @@ To verify whether a single-signed transaction is valid, a `rippled` server check
1. This key hashes to an address that's authorized by the transaction's sender.
The default is that only "the address of an account" is authorized to send all transactions for that account. That address is [derived from](concept-accounts.html#address-encoding) the public key from the master key pair that was generated during address creation. Regular keys add a different address (derived from a different key pair) that's authorized to send most transactions. And of course, you can also disable the [master key](concept-keys.html) or add a [multi-signing list](reference-transaction-format.html#multi-signing).
The default is that only the address of an account is authorized to send all transactions for that account. That address is [derived from](concept-accounts.html#address-encoding) the public key from the master key pair that was generated during address creation. Regular keys add a different address (derived from a different key pair) that's authorized to send most transactions. And of course, you can also disable the [master key](concept-keys.html) or add a [multi-signing list](reference-transaction-format.html#multi-signing). ***TODO: address from Ryan: "And of course" - Nit: this seems a little informal. Maybe just drop it and go into the next sentence? JHA take a closer look at what this sentence is trying to say.***
2. This key matches the signature on the transaction.

14
content/reference-transaction-format.md
View File

@@ -15,19 +15,21 @@ In the decentralized XRP Ledger, a digital signature proves that a transaction i
A transaction can be authorized by any of the following types of signatures:
* A single signature from the master secret key that is mathematically associated with the sending address. You can disable or enable the master key using an [AccountSet transaction][].
* A single signature that matches a regular key associated with the address. You can add, remove, or replace a regular key using a [SetRegularKey transaction][].
***TODO: Question: Not sure what we mean by "signature" here. I know that I can submit/authorize a transaction with a `secret` value -- which can either be the master private key or the regular private key. When we refer to "signature" above and below - what are we referring to? Are we calling the `secret` field holding the master or regular private key value a "signature"? Or is this something else - like a signature that is derived from the `secret` value once a transaction has been submitted, but not yet authorized?***
* A single signature from the master private key that is mathematically associated with the sending address. You can disable or enable the master key pair using an [AccountSet transaction][].
* A single signature that matches the regular private key associated with the address. You can add, remove, or replace a regular key pair using a [SetRegularKey transaction][].
* A [multi-signature](#multi-signing) that matches a list of signers owned by the address. You can add, remove, or replace a list of signers using a [SignerListSet transaction][].
Any signature type can authorize any type of transaction, with the following exceptions:
* Only the master key can [disable the master key](#accountset-flags).
* Only the master key can [permanently give up the ability to freeze](concept-freeze.html#no-freeze).
* Only the master private key can [disable the master public key](#accountset-flags).
* Only the master private key can [permanently give up the ability to freeze](concept-freeze.html#no-freeze).
* You can never remove the last method of signing transactions from an address.
For more information about master and regular keys, see [Understanding Master and Regular Keys](concept-keys.html).
For more information about master and regular key pairs, see [Cryptographic Keys](concept-keys.html).
For more information about signatures, see [Understanding Signatures](concept-signatures.html).
<!--{# Add this reference after signatures concept doc is published. For more information about signatures, see [Understanding Signatures](concept-signatures.html). #}-->
## Signing and Submitting Transactions

12
content/rippled-api-methods/wallet_propose.md
View File

@@ -1,7 +1,7 @@
## wallet_propose
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/WalletPropose.cpp "Source")
Use the `wallet_propose` method to generate a key pair and XRP Ledger address. This command only generates keys, and does not affect the XRP Ledger itself in any way. To become a funded address stored in the ledger, the address must [receive a Payment transaction](reference-transaction-format.html#creating-accounts) that provides enough XRP to meet the [reserve requirement](concept-reserves.html).
Use the `wallet_propose` method to generate a key pair and XRP Ledger address. This command only generates key and address values, and does not affect the XRP Ledger itself in any way. To become a funded address stored in the ledger, the address must [receive a Payment transaction](reference-transaction-format.html#creating-accounts) that provides enough XRP to meet the [reserve requirement](concept-reserves.html).
*The `wallet_propose` request is an [admin command](#connecting-to-rippled) that cannot be run by unprivileged users!* (This command is restricted to protect against people sniffing network traffic for account secrets, since admin commands are not usually transmitted over the outside network.)
@@ -172,15 +172,15 @@ The response follows the [standard format](#response-formatting), with a success
| `master_seed_hex` | String | The master seed, in hex format. A simple, widely-supported way to represent the secret key. Can be used to sign transactions. |
| `master_key` | String | The master seed, in [RFC 1751](http://tools.ietf.org/html/rfc1751) format. An easier to remember, easier-to-write-down version of the private key. Can be used to sign transactions. |
| `account_id` | String | The [Address][] of the account in base58 format. This is not the public key, but a hash-of-a-hash of it. It also has a checksum so a typo almost certainly results in an invalid address rather than a valid, but different address. This is the primary identifier of an account in the XRP Ledger. You tell people this to get paid, and use it in transactions to indicate who you are and who you're paying, trusting, and so forth. [Multi-signing lists](tutorial-multisign.html) also use these to identify other signers. |
| `public_key` | String | The public key of the key pair, in Ripple's [base58][] encoded string format. |
| `public_key_hex` | String | This is the public key of the key pair, in hexadecimal. To validate the signature on a transaction, `rippled` needs this public key. That's why the format for a signed transaction includes the public key in the `SigningPubKey` field. |
| `public_key` | String | The public key of the key pair, in Ripple's [base58][] encoded string format. Derived from the `master_seed`. |
| `public_key_hex` | String | This is the public key of the key pair, in hexadecimal. Derived from the `master_seed`. To validate the signature on a transaction, `rippled` needs this public key. That's why the format for a signed transaction includes the public key in the `SigningPubKey` field. |
| `warning` | String | (May be omitted) If the request specified a seed value, this field provides a warning that it may be insecure. [New in: rippled 0.32.0][] |
You can also use this method to generate a key to use as a regular key for an account. You assign a regular key to an account to be able to sign most transactions with it, while keeping your master key offline whenever possible.
You can also use this method to generate a key pair to use as a regular key pair for an account. You assign a regular key pair to an account to be able to sign most transactions with it, while keeping your master key pair offline whenever possible.
In addition to using it as a regular key, you can also use it as a member of a multi-signing list (SignerList).
In addition to using it as a regular key pair, you can also use it as a member of a multi-signing list (SignerList).
For more information about master and regular keys, see [Understanding Master and Regular Keys](concept-keys.html)
For more information about master and regular key pairs, see [Cryptographic Keys](concept-keys.html)
For more information about multi-signing and signer lists, see [Multi-Signing](reference-transaction-format.html#multi-signing).

10
content/transactions/setregularkey.md
View File

@@ -2,13 +2,13 @@
[[Source]<br>](https://github.com/ripple/rippled/blob/4239880acb5e559446d2067f00dabb31cf102a23/src/ripple/app/transactors/SetRegularKey.cpp "Source")
A `SetRegularKey` transaction assigns, changes, or removes the regular key associated with an account.
A `SetRegularKey` transaction assigns, changes, or removes the regular key pair associated with an account.
You can protect your account by assigning a regular key to it and using it instead of the master key to sign transactions whenever possible. If your regular key is compromised, but your master key is not, you can use a `SetRegularKey` transaction to regain control of your account.
You can protect your account by assigning a regular key pair to it and using it instead of the master key pair to sign transactions whenever possible. If your regular key pair is compromised, but your master key pair is not, you can use a `SetRegularKey` transaction to regain control of your account.
For more information about regular and master keys, see [Understanding Master and Regular Keys](concept-keys.html).
For more information about regular and master key pairs, see [Cryptographic Keys](concept-keys.html).
For a tutorial on assigning a regular key to an account, see [Working with Regular Keys](tutorial-regular-keys.html).
For a tutorial on assigning a regular key pair to an account, see [Working with Regular Keys](tutorial-regular-keys.html).
For even greater security, you can use [multi-signing](#multi-signing), but multi-signing requires additional XRP for the [transaction cost](concept-transaction-cost.html) and [reserve](concept-reserves.html).
@@ -24,4 +24,4 @@ For even greater security, you can use [multi-signing](#multi-signing), but mult
| Field | JSON Type | [Internal Type][] | Description |
|:-------------|:----------|:------------------|:------------------------------|
| `RegularKey` | String | AccountID | _(Optional)_ A base-58-encoded [Ripple address](reference-rippled.html#addresses) to use as the regular key. If omitted, removes the existing regular key. |
| `RegularKey` | String | AccountID | _(Optional)_ A base-58-encoded [Ripple address](reference-rippled.html#addresses) that indicates the regular key pair to be assigned to the account. If omitted, removes any existing regular key pair from the account. |

604
content/tutorial-regular-keys.md
View File

@@ -1,33 +1,36 @@
# Working with Regular Keys
# Working with a Regular Key Pair
The XRP Ledger allows an account to authorize a secondary key pair, called a "regular key," to sign future transactions. If the private key of a regular key 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 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_, 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 keys, see [Understanding Master and Regular Keys](concept-keys.html).
For more information about master and regular key pairs, see [Cryptographic Keys](concept-keys.html).
This article provides the following tutorials:
* [Assigning a regular key](#assigning-a-regular-key)
* [Removing or changing a regular key](#removing-or-changing-a-regular-key)
* [Assigning a regular key pair](#assigning-a-regular-key-pair)
* [Removing or changing a regular key pair](#removing-or-changing-a-regular-key-pair)
## Assigning a Regular Key
## Assigning a Regular Key Pair
This tutorial walks you through the steps required to assign a regular key to your account:
This tutorial walks you through the steps required to assign a regular key pair to your account:
1. [Generate a key](#1-generate-a-key)
2. [Assign the key to your account as a regular key](#2-assign-the-key-to-your-account-as-a-regular-key)
3. [Submit an `AccountSet` transaction using the regular key](#3-submit-an-accountset-transaction-using-the-regular-key)
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)
### 1. Generate a Key
### 1. Generate a Key Pair
Use the [`wallet_propose`](reference-rippled.html#wallet-propose) method to generate the key that you'll assign to your account as a regular key.
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.
Here's an example `wallet_propose` request and response:
#### Request Format
An example of the request format:
#### WebSocket Request
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
@@ -35,7 +38,31 @@ Here's an example `wallet_propose` request and response:
}
```
#### WebSocket Response
*JSON-RPC*
```
{
"method": "wallet_propose"
}
```
*Commandline*
```
#Syntax: wallet_propose
rippled wallet_propose
```
<!-- MULTICODE_BLOCK_END -->
#### Response Format
An example of a successful response:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
@@ -53,42 +80,122 @@ Here's an example `wallet_propose` request and response:
}
```
In the next step, you'll use the `account_id` from this response to assign the key as a regular key to your account.
*JSON-RPC*
```
{
"result": {
"account_id": "rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
"key_type": "secp256k1",
"master_key": "KNEW BENT LYNN LED GAD BEN KENT SHAM HOBO RINK WALT ALLY",
"master_seed": "sh8i92YRnEjJy3fpFkL8txQSCVo79",
"master_seed_hex": "966C0F68643EFBA50D58D191D4CA8AA7",
"public_key": "aBRNH5wUurfhZcoyR6nRwDSa95gMBkovBJ8V4cp1C1pM28H7EPL1",
"public_key_hex": "03AEEFE1E8ED4BBC009DE996AC03A8C6B5713B1554794056C66E5B8D1753C7DD0E"
"status": "success"
}
}
```
*Commandline*
```
{
"result" : {
"account_id" : "rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
"key_type" : "secp256k1",
"master_key" : "KNEW BENT LYNN LED GAD BEN KENT SHAM HOBO RINK WALT ALLY",
"master_seed" : "sh8i92YRnEjJy3fpFkL8txQSCVo79",
"master_seed_hex" : "966C0F68643EFBA50D58D191D4CA8AA7",
"public_key" : "aBRNH5wUurfhZcoyR6nRwDSa95gMBkovBJ8V4cp1C1pM28H7EPL1",
"public_key_hex" : "03AEEFE1E8ED4BBC009DE996AC03A8C6B5713B1554794056C66E5B8D1753C7DD0E",
"status" : "success"
}
}
```
<!-- MULTICODE_BLOCK_END -->
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.
### 2. Assign the Key to Your Account as a Regular Key
### 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 you generated in step 1 to your account as a regular key.
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.
When assigning a regular key 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` 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 you make subsequent `SetRegularKey` requests, you can sign using the existing regular key to replace or [remove itself](#removing-or-changing-a-regular-key).
When you make subsequent `SetRegularKey` requests, you can sign using the existing regular private key to replace or [remove itself](#removing-or-changing-a-regular-key-pair).
#### 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.
In the transaction JSON, use your account's `account_ID` as the `Account` value, your account's `master_key`, `master_seed`, or `master_seed_hex` (master private key) as the `secret` value, and the `account_id` generated in step 1 as the `RegularKey` value.
Populate the request fields with the following values:
Here's an example `sign` request and response for a `SetRegularKey` type transaction:
| Request Field | Value |
|:--------------|:-------------------------------------------------------------|
| `Account` | `account_id` for your account. |
| `RegularKey` | `account_id` generated in step 1. |
| `secret` | `master_key`, `master_seed`, or `master_seed_hex` (master private key) for your account. |
##### WebSocket Request:
##### Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
"command": "sign",
"tx_json" : {
"TransactionType" : "SetRegularKey",
"Account" : "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
"RegularKey" : "rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7"
"tx_json": {
"TransactionType": "SetRegularKey",
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
"RegularKey": "rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7"
},
"secret" : "ssCATR7CBvn4GLd1UuU2bqqQffHki"
"secret": "ssCATR7CBvn4GLd1UuU2bqqQffHki"
}
```
*JSON-RPC*
##### WebSocket Response:
```
{
"method": "sign",
"params": [
{
"tx_json": {
"TransactionType": "SetRegularKey",
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
"RegularKey": "rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7"
},
"secret": "ssCATR7CBvn4GLd1UuU2bqqQffHki"
}
]
}
```
*Commandline*
```
#Syntax: sign secret tx_json
rippled sign ssCATR7CBvn4GLd1UuU2bqqQffHki '{"TransactionType": "SetRegularKey", "Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93", "RegularKey": "rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7"}'
```
<!-- MULTICODE_BLOCK_END -->
##### Response Format
An example of a successful response:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
@@ -111,6 +218,52 @@ Here's an example `sign` request and response for a `SetRegularKey` type transac
}
```
*JSON-RPC*
```
{
"result": {
"status": "success",
"tx_blob": "1200052280000000240000000768400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402201453CA3D4D17F0EE3828B9E3D6ACF65327F5D4FC2BA30953CACF6CBCB4145E3502202F2154BED1D7462CAC1E3DBB31864E48C3BA0B3133ACA5E37EC54F0D0C339E2D8114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540",
"tx_json": {
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
"Fee": "10",
"Flags": 2147483648,
"RegularKey": "rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
"Sequence": 4,
"SigningPubKey": "0384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A",
"TransactionType": "SetRegularKey",
"TxnSignature": "304402201453CA3D4D17F0EE3828B9E3D6ACF65327F5D4FC2BA30953CACF6CBCB4145E3502202F2154BED1D7462CAC1E3DBB31864E48C3BA0B3133ACA5E37EC54F0D0C339E2D",
"hash": "AB73BBF7C99061678B59FB48D72CA0F5FC6DD2815B6736C6E9EB94439EC236CE"
}
}
}
```
*Commandline*
```
{
"result" : {
"status" : "success",
"tx_blob" : "1200052280000000240000000768400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402201453CA3D4D17F0EE3828B9E3D6ACF65327F5D4FC2BA30953CACF6CBCB4145E3502202F2154BED1D7462CAC1E3DBB31864E48C3BA0B3133ACA5E37EC54F0D0C339E2D8114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540",
"tx_json" : {
"Account" : "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
"Fee" : "10",
"Flags" : 2147483648,
"RegularKey" : "rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
"Sequence" : 4,
"SigningPubKey" : "0384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A",
"TransactionType" : "SetRegularKey",
"TxnSignature" : "304402201453CA3D4D17F0EE3828B9E3D6ACF65327F5D4FC2BA30953CACF6CBCB4145E3502202F2154BED1D7462CAC1E3DBB31864E48C3BA0B3133ACA5E37EC54F0D0C339E2D",
"hash" : "AB73BBF7C99061678B59FB48D72CA0F5FC6DD2815B6736C6E9EB94439EC236CE"
}
}
}
```
<!-- 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.
@@ -120,10 +273,13 @@ Next, use the `submit` command to transmit the transaction blob (`tx_blob` or `s
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.
Here's an example `submit` request and response for a `SetRegularKey` type transaction.
##### Request Format
An example of the request format:
##### WebSocket Request:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
@@ -132,8 +288,36 @@ Here's an example `submit` request and response for a `SetRegularKey` type trans
}
```
*JSON-RPC*
##### WebSocket Response:
```
{
"method":"submit",
"params": [
{
"tx_blob": "1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540"
}
]
}
```
*Commandline*
```
#Syntax: submit tx_blob
rippled submit 1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540
```
<!-- MULTICODE_BLOCK_END -->
##### Response Format
An example of a successful response:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
@@ -159,33 +343,129 @@ Here's an example `submit` request and response for a `SetRegularKey` type trans
}
```
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. Submit an `AccountSet` Transaction Using the Regular Key
To verify that your account has the regular key set correctly, send an [`AccountSet`](reference-transaction-format.html#accountset) transaction from your account, signing it with the regular key you assigned to your account in step 2.
In the request, send your account's `account_id` as the `Account` value and the `master_key`, `master_seed`, or `master_seed_hex` (regular private key) generated in step 1 as the `secret` value.
Here's an example `AccountSet` request and response. 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 is set correctly for your account (and to destroy the transaction cost).
#### WebSocket Request:
*JSON-RPC*
```
{
"command": "submit",
"tx_json" : {
"TransactionType": "AccountSet",
"Account" : "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"
},
"secret" : "sh8i92YRnEjJy3fpFkL8txQSCVo79"
"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": "1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540",
"tx_json": {
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
"Fee": "10",
"Flags": 2147483648,
"RegularKey": "rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
"Sequence": 4,
"SigningPubKey": "0384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A",
"TransactionType": "SetRegularKey",
"TxnSignature": "304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C26",
"hash": "AB73BBF7C99061678B59FB48D72CA0F5FC6DD2815B6736C6E9EB94439EC236CE"
}
}
}
```
*Commandline*
#### WebSocket Response:
```
{
"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" : "1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540",
"tx_json" : {
"Account" : "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
"Fee" : "10",
"Flags" : 2147483648,
"RegularKey" : "rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
"Sequence" : 4,
"SigningPubKey" : "0384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A",
"TransactionType" : "SetRegularKey",
"TxnSignature" : "304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C26",
"hash" : "AB73BBF7C99061678B59FB48D72CA0F5FC6DD2815B6736C6E9EB94439EC236CE"
}
}
}
```
<!-- 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).
### 3. Verify the Regular Key Pair
To verify that your account has the regular key pair set correctly, send 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.
Populate the request fields with the following values:
| Request Field | Value |
|:--------------|:-------------------------------------------------------------|
| `Account` | `account_id` for your account. |
| `secret` | `master_key`, `master_seed`, or `master_seed_hex` (regular private key) generated in step 1 and assigned in step 2. |
Here's an example `AccountSet` request and response. 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).
#### Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
"command": "submit",
"tx_json": {
"TransactionType": "AccountSet",
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"
},
"secret": "sh8i92YRnEjJy3fpFkL8txQSCVo79"
}
```
*JSON-RPC*
```
{
"method": "submit",
"params": [
{
"tx_json": {
"TransactionType": "AccountSet",
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"
},
"secret": "sh8i92YRnEjJy3fpFkL8txQSCVo79"
}
]
}
```
*Commandline*
```
#Syntax: submit secret tx_json
rippled submit sh8i92YRnEjJy3fpFkL8txQSCVo79 '{"TransactionType": "AccountSet", "Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"}'
```
<!-- MULTICODE_BLOCK_END -->
#### Response Format
An example of a successful response:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
@@ -210,44 +490,129 @@ Here's an example `AccountSet` request and response. Note that the request does
}
```
*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": "1200032280000000240000000368400000000000000A732103AEEFE1E8ED4BBC009DE996AC03A8C6B5713B1554794056C66E5B8D1753C7DD0E744730450221008F44064A901C3A170A046673EFC8091F2C409E1DB7D78A5EF0D18E9D868AE21002207F594F3BF3821E6DF64CD283F590F6578F809DFD1CAAF654F187645A7CAB91C48114830923439D307E642CED308FD91EF701A7BAA747",
"tx_json": {
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
"Fee": "10",
"Flags": 2147483648,
"Sequence": 3,
"SigningPubKey": "03AEEFE1E8ED4BBC009DE996AC03A8C6B5713B1554794056C66E5B8D1753C7DD0E",
"TransactionType": "AccountSet",
"TxnSignature": "30450221008F44064A901C3A170A046673EFC8091F2C409E1DB7D78A5EF0D18E9D868AE21002207F594F3BF3821E6DF64CD283F590F6578F809DFD1CAAF654F187645A7CAB91C4",
"hash": "5F6A2DF78FC9B22CFE85D5257167A4103502ABD230B4ED63D8A4FB42F6E4B7DE"
}
}
}
```
*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" : "1200032280000000240000000368400000000000000A732103AEEFE1E8ED4BBC009DE996AC03A8C6B5713B1554794056C66E5B8D1753C7DD0E744730450221008F44064A901C3A170A046673EFC8091F2C409E1DB7D78A5EF0D18E9D868AE21002207F594F3BF3821E6DF64CD283F590F6578F809DFD1CAAF654F187645A7CAB91C48114830923439D307E642CED308FD91EF701A7BAA747",
"tx_json" : {
"Account" : "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
"Fee" : "10",
"Flags" : 2147483648,
"Sequence" : 3,
"SigningPubKey" : "03AEEFE1E8ED4BBC009DE996AC03A8C6B5713B1554794056C66E5B8D1753C7DD0E",
"TransactionType" : "AccountSet",
"TxnSignature" : "30450221008F44064A901C3A170A046673EFC8091F2C409E1DB7D78A5EF0D18E9D868AE21002207F594F3BF3821E6DF64CD283F590F6578F809DFD1CAAF654F187645A7CAB91C4",
"hash" : "5F6A2DF78FC9B22CFE85D5257167A4103502ABD230B4ED63D8A4FB42F6E4B7DE"
}
}
}
```
<!-- MULTICODE_BLOCK_END -->
### 4. Explore Next Steps
Now that you're familiar with the benefits of assigning a regular key to an account, consider taking a look at these related topics and tutorials:
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)
## Removing or Changing a Regular Key
## Removing or Changing a Regular Key Pair
If your account's regular key is compromised, or if you just want to periodically change the regular key as a security measure, use the [`SetRegularKey`](reference-transaction-format.html#setregularkey) method to remove or change the regular key for your account.
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.
The steps to change your existing regular key are almost the same as the steps to [assign a regular key](#assigning-a-regular-key) for the first time. You generate the key and assign it to your account as a regular key, overwriting the existing regular key. However, the main difference is that when changing the existing regular key, you can use the existing regular key to replace itself, whereas when assigning a regular key to an account for the first time, you have to use the account's master key to do it.
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 keys, see [Understanding Master and Regular Keys](concept-keys.html).
For more information about master and regular key pairs, see [Cryptographic Keys](concept-keys.html).
If you want to simply remove a compromised regular key from your account, you don't need to generate a key pair first and 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 or a signer list).
If you want to simply remove a compromised regular key pair from your account, you don't need to generate a key pair first and 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).
Here's an example `SetRegularKey` request and response that removes an existing regular key from an account:
### Request Format
An example of the request format that removes an existing regular key pair from an account:
#### WebSocket Request:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
"command" : "submit",
"tx_json" : {
"TransactionType" : "SetRegularKey",
"Account" : "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"
"command": "submit",
"tx_json": {
"TransactionType": "SetRegularKey",
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"
},
"secret" : "sh8i92YRnEjJy3fpFkL8txQSCVo79"
"secret": "sh8i92YRnEjJy3fpFkL8txQSCVo79"
}
```
*JSON-RPC*
#### WebSocket Response:
```
{
"method": "submit",
"params": [
{
"tx_json": {
"Account" : "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
"TransactionType": "SetRegularKey"
},
"secret": "sh8i92YRnEjJy3fpFkL8txQSCVo79"
}
]
}
```
*Commandline*
```
#Syntax: submit secret tx_json
rippled submit sh8i92YRnEjJy3fpFkL8txQSCVo79 '{"TransactionType": "SetRegularKey", "Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"}'
```
<!-- MULTICODE_BLOCK_END -->
### Response Format
An example of a successful response:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
@@ -272,12 +637,69 @@ Here's an example `SetRegularKey` request and response that removes an existing
}
```
The way to verify that regular key removal succeeded is to confirm that you can't send a transaction using the removed regular key.
*JSON-RPC*
Here's an example error response for an `AccountSet` transaction signed using the regular key removed by the `SetRegularKey` transaction above.
```
{
"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": "1200052280000000240000000668400000000000000A732103AEEFE1E8ED4BBC009DE996AC03A8C6B5713B1554794056C66E5B8D1753C7DD0E744630440220703F4EB4D1DF90632DDEB0F3B72B41B7E85C739933C9AF55472BB154637645B202202689C22A10965DA0F0EA1D745EBB8E94E242572490FED69A059D724172E9DCFC8114830923439D307E642CED308FD91EF701A7BAA747",
"tx_json": {
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
"Fee": "10",
"Flags": 2147483648,
"Sequence": 6,
"SigningPubKey": "03AEEFE1E8ED4BBC009DE996AC03A8C6B5713B1554794056C66E5B8D1753C7DD0E",
"TransactionType": "SetRegularKey",
"TxnSignature": "30440220703F4EB4D1DF90632DDEB0F3B72B41B7E85C739933C9AF55472BB154637645B202202689C22A10965DA0F0EA1D745EBB8E94E242572490FED69A059D724172E9DCFC",
"hash": "15234F29930BFB8A87EB604D4E657CDEE277BAF9D670A90CDE2453A608A9A81C"
}
}
}
```
*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" : "1200052280000000240000000668400000000000000A732103AEEFE1E8ED4BBC009DE996AC03A8C6B5713B1554794056C66E5B8D1753C7DD0E744630440220703F4EB4D1DF90632DDEB0F3B72B41B7E85C739933C9AF55472BB154637645B202202689C22A10965DA0F0EA1D745EBB8E94E242572490FED69A059D724172E9DCFC8114830923439D307E642CED308FD91EF701A7BAA747",
"tx_json" : {
"Account" : "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
"Fee" : "10",
"Flags" : 2147483648,
"Sequence" : 6,
"SigningPubKey" : "03AEEFE1E8ED4BBC009DE996AC03A8C6B5713B1554794056C66E5B8D1753C7DD0E",
"TransactionType" : "SetRegularKey",
"TxnSignature" : "30440220703F4EB4D1DF90632DDEB0F3B72B41B7E85C739933C9AF55472BB154637645B202202689C22A10965DA0F0EA1D745EBB8E94E242572490FED69A059D724172E9DCFC",
"hash" : "15234F29930BFB8A87EB604D4E657CDEE277BAF9D670A90CDE2453A608A9A81C"
}
}
}
```
<!-- MULTICODE_BLOCK_END -->
#### WebSocket 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` 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*
```
{
@@ -297,4 +719,48 @@ Here's an example error response for an `AccountSet` transaction signed using th
}
```
*JSON-RPC*
```
{
"result": {
"error": "badSecret",
"error_code": 41,
"error_message": "Secret does not match account.",
"request": {
"command": "submit",
"secret": "sh8i92YRnEjJy3fpFkL8txQSCVo79",
"tx_json": {
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
"TransactionType": "SetRegularKey"
}
},
"status": "error"
}
}
```
*Commandline*
```
{
"result" : {
"error" : "badSecret",
"error_code" : 41,
"error_message" : "Secret does not match account.",
"request" : {
"command" : "submit",
"secret" : "sh8i92YRnEjJy3fpFkL8txQSCVo79",
"tx_json" : {
"Account" : "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
"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.

14
dactyl-config.yml
View File

@@ -296,6 +296,13 @@ pages:
- local
- ripple.com
- category: Features
html: concept-keys.html
md: concept-keys.md
targets:
- local
- ripple.com
- md: concept-escrow.md
category: Features
targets:
@@ -326,13 +333,6 @@ pages:
- local
- ripple.com
- category: Features
html: concept-keys.html
md: concept-keys.md
targets:
- local
- ripple.com
- md: concept-money.md
category: Features
html: concept-money.html