mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-24 05:35:51 +00:00
Migrate content syntax via script
The changes in this commit were auto-generated by running tool/migrate.sh Following this commit, the Dactyl build no longer works but the Redocly build (mostly) should.
This commit is contained in:
mDuo13
@@ -1,8 +1,12 @@
|
||||
---
|
||||
html: key-generation-methods.html
|
||||
parent: admin-api-methods.html
|
||||
template: pagetype-category.html.jinja
|
||||
metadata:
|
||||
indexPage: true
|
||||
---
|
||||
# Key Generation Methods
|
||||
|
||||
Use these methods to generate and manage keys.
|
||||
Use these methods to generate and manage keys.
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
|
||||
@@ -9,22 +9,21 @@ labels:
|
||||
# validation_create
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/315a8b6b602798a4cff4d8e1911936011e12abdb/src/ripple/rpc/handlers/ValidationCreate.cpp "Source")
|
||||
|
||||
Use the `validation_create` command to generate [cryptographic keys a `rippled` server can use to identify itself to the network](peer-protocol.html#node-key-pair). Similar to the [wallet_propose method][], this method only generates a set of keys in the proper format. It does not any makes changes to the XRP Ledger data or server configuration.
|
||||
Use the `validation_create` command to generate [cryptographic keys a `rippled` server can use to identify itself to the network](../../../../concepts/networks-and-servers/peer-protocol.md#node-key-pair). Similar to the [wallet_propose method][], this method only generates a set of keys in the proper format. It does not any makes changes to the XRP Ledger data or server configuration.
|
||||
|
||||
_The `validation_create` method is an [admin method](admin-api-methods.html) that cannot be run by unprivileged users._
|
||||
_The `validation_create` method is an [admin method](../index.md) that cannot be run by unprivileged users._
|
||||
|
||||
You can configure your server to use the generated key pair to sign validations (validation key pair) or regular peer-to-peer communications ([node key pair](peer-protocol.html#node-key-pair)).
|
||||
You can configure your server to use the generated key pair to sign validations (validation key pair) or regular peer-to-peer communications ([node key pair](../../../../concepts/networks-and-servers/peer-protocol.md#node-key-pair)).
|
||||
|
||||
**Tip:** For configuring a robust validator, you should use the `validator-keys` tool (included in the `rippled` RPM) to generate validator tokens (which can be rotated) with an offline master key. For more information, see [Validator Setup](run-rippled-as-a-validator.html#3-enable-validation-on-your-rippled-server).
|
||||
**Tip:** For configuring a robust validator, you should use the `validator-keys` tool (included in the `rippled` RPM) to generate validator tokens (which can be rotated) with an offline master key. For more information, see [Validator Setup](../../../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md#3-enable-validation-on-your-rippled-server).
|
||||
|
||||
|
||||
### Request Format
|
||||
An example of the request format:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"id": 0,
|
||||
@@ -32,9 +31,9 @@ An example of the request format:
|
||||
"secret": "BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIRE"
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
{
|
||||
"method": "validation_create",
|
||||
@@ -45,15 +44,16 @@ An example of the request format:
|
||||
]
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
*Commandline*
|
||||
|
||||
{% tab label="Commandline" %}
|
||||
```sh
|
||||
#Syntax: validation_create [secret]
|
||||
rippled validation_create "BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIRE"
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
{% /tabs %}
|
||||
|
||||
The request includes the following parameters:
|
||||
|
||||
@@ -67,10 +67,9 @@ The request includes the following parameters:
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC*
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
{
|
||||
"result" : {
|
||||
@@ -81,9 +80,9 @@ An example of a successful response:
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
*Commandline*
|
||||
|
||||
{% tab label="Commandline" %}
|
||||
```json
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
@@ -97,8 +96,9 @@ Connecting to 127.0.0.1:5005
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
{% /tabs %}
|
||||
|
||||
The response follows the [standard format][], with a successful result containing the following fields:
|
||||
|
||||
@@ -113,7 +113,4 @@ The response follows the [standard format][], with a successful result containin
|
||||
* Any of the [universal error types][].
|
||||
* `badSeed` - The request provided an invalid seed value. This usually means that the seed value appears to be a valid string of a different format, such as an account address or validation public key.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -9,20 +9,19 @@ labels:
|
||||
# wallet_propose
|
||||
[[Source]](https://github.com/XRPLF/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 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](accounts.html#creating-accounts) that provides enough XRP to meet the [reserve requirement](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](../../../../concepts/accounts/accounts.md#creating-accounts) that provides enough XRP to meet the [reserve requirement](../../../../concepts/accounts/reserves.md).
|
||||
|
||||
*The `wallet_propose` method is an [admin method](admin-api-methods.html) 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.)
|
||||
*The `wallet_propose` method is an [admin method](../index.md) 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.)
|
||||
|
||||
[Updated in: rippled 0.31.0][]
|
||||
{% badge href="https://github.com/XRPLF/rippled/releases/tag/0.31.0" %}Updated in: rippled 0.31.0{% /badge %}
|
||||
|
||||
### Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket (with key type)*
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket (with key type)" %}
|
||||
```json
|
||||
{
|
||||
"command": "wallet_propose",
|
||||
@@ -30,18 +29,18 @@ An example of the request format:
|
||||
"key_type": "secp256k1"
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
*WebSocket (no key type)*
|
||||
|
||||
{% tab label="WebSocket (no key type)" %}
|
||||
```json
|
||||
{
|
||||
"command": "wallet_propose",
|
||||
"passphrase": "masterpassphrase"
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
*JSON-RPC (with key type)*
|
||||
|
||||
{% tab label="JSON-RPC (with key type)" %}
|
||||
```json
|
||||
{
|
||||
"method": "wallet_propose",
|
||||
@@ -53,9 +52,9 @@ An example of the request format:
|
||||
]
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
*JSON-RPC (no key type)*
|
||||
|
||||
{% tab label="JSON-RPC (no key type)" %}
|
||||
```json
|
||||
{
|
||||
"method": "wallet_propose",
|
||||
@@ -66,21 +65,22 @@ An example of the request format:
|
||||
]
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
*Commandline*
|
||||
|
||||
{% tab label="Commandline" %}
|
||||
```sh
|
||||
#Syntax: wallet_propose [passphrase]
|
||||
rippled wallet_propose masterpassphrase
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
{% /tabs %}
|
||||
|
||||
The request can contain the following parameters:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:-------------|:-------|:-----------------------------------------------------|
|
||||
| `key_type` | String |Which [signing algorithm](cryptographic-keys.html#signing-algorithms) to use to derive this key pair. Valid values are `ed25519` and `secp256k1` (all lower case). The default is `secp256k1`. |
|
||||
| `key_type` | String |Which [signing algorithm](../../../../concepts/accounts/cryptographic-keys.md#signing-algorithms) to use to derive this key pair. Valid values are `ed25519` and `secp256k1` (all lower case). The default is `secp256k1`. |
|
||||
| `passphrase` | String | _(Optional)_ Generate a key pair and address from this seed value. This value can be formatted in [hexadecimal][], the XRP Ledger's [base58][] format, [RFC-1751][], or as an arbitrary string. Cannot be used with `seed` or `seed_hex`. |
|
||||
| `seed` | String | _(Optional)_ Generate the key pair and address from this seed value in the XRP Ledger's [base58][]-encoded format. Cannot be used with `passphrase` or `seed_hex`. |
|
||||
| `seed_hex` | String | _(Optional)_ Generate the key pair and address from this seed value in [hexadecimal][] format. Cannot be used with `passphrase` or `seed`. |
|
||||
@@ -91,7 +91,7 @@ You must provide **at most one** of the following fields: `passphrase`, `seed`,
|
||||
|
||||
#### Specifying a Seed
|
||||
|
||||
For most cases, you should use a seed value generated from a strong source of randomness. Anyone who knows the seed value for an address has full power to [send transactions signed by that address](transactions.html#authorizing-transactions). Generally, running this command with no parameters is a good way to generate a random seed.
|
||||
For most cases, you should use a seed value generated from a strong source of randomness. Anyone who knows the seed value for an address has full power to [send transactions signed by that address](../../../../concepts/transactions/index.md#authorizing-transactions). Generally, running this command with no parameters is a good way to generate a random seed.
|
||||
|
||||
Cases where you would specify a known seed include:
|
||||
|
||||
@@ -112,10 +112,9 @@ If you do specify a seed, you can specify it in any of the following formats:
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"id": 2,
|
||||
@@ -132,9 +131,9 @@ An example of a successful response:
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
@@ -149,9 +148,9 @@ An example of a successful response:
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
*Commandline*
|
||||
|
||||
{% tab label="Commandline" %}
|
||||
```json
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
@@ -169,29 +168,30 @@ Connecting to 127.0.0.1:5005
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
{% /tabs %}
|
||||
|
||||
The response follows the [standard format][], with a successful result containing various important information about the new (potential) account, including the following fields:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:------------------|:-------|:------------------------------------------------|
|
||||
| `key_type` | String | Which [signing algorithm](cryptographic-keys.html#signing-algorithms) was used to derive this key pair. Valid values are `ed25519` and `secp256k1` (all lower case). |
|
||||
| `master_seed` | String | The [master seed](cryptographic-keys.html#key-components), in the XRP Ledger's [base58][] encoded string format. Typically, you use the key in this format to sign transactions. |
|
||||
| `key_type` | String | Which [signing algorithm](../../../../concepts/accounts/cryptographic-keys.md#signing-algorithms) was used to derive this key pair. Valid values are `ed25519` and `secp256k1` (all lower case). |
|
||||
| `master_seed` | String | The [master seed](../../../../concepts/accounts/cryptographic-keys.md#key-components), in the XRP Ledger's [base58][] encoded string format. Typically, you use the key in this format to sign transactions. |
|
||||
| `master_seed_hex` | String | The master seed, in hex format. |
|
||||
| `master_key` | String | **DEPRECATED** The master seed, in [RFC-1751][] format. **Note:** The `rippled` implementation reverses the byte order of the key after decoding from RFC-1751 and before encoding to RFC-1751; if you read or write keys for use with the XRP Ledger using a different RFC-1751 implementation, you must do the same to be compatible with `rippled`'s RFC-1751 encoding. |
|
||||
| `account_id` | String | The [Address][] of the account in the XRP Ledger's [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](multi-signing.html) also use these to identify other signers. |
|
||||
| `account_id` | String | The [Address][] of the account in the XRP Ledger's [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](../../../../concepts/accounts/multi-signing.md) also use these to identify other signers. |
|
||||
| `public_key` | String | The public key of the key pair, in the XRP Ledger'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][] |
|
||||
| `warning` | String | (May be omitted) If the request specified a seed value, this field provides a warning that it may be insecure. {% badge href="https://github.com/XRPLF/rippled/releases/tag/0.32.0" %}New in: rippled 0.32.0{% /badge %} |
|
||||
|
||||
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 pair, you can also use it as a member of a multi-signing list (SignerList).
|
||||
|
||||
For more information about master and regular key pairs, see [Cryptographic Keys](cryptographic-keys.html)
|
||||
For more information about master and regular key pairs, see [Cryptographic Keys](../../../../concepts/accounts/cryptographic-keys.md)
|
||||
|
||||
For more information about multi-signing and signer lists, see [Multi-Signing](multi-signing.html).
|
||||
For more information about multi-signing and signer lists, see [Multi-Signing](../../../../concepts/accounts/multi-signing.md).
|
||||
|
||||
|
||||
### Possible Errors
|
||||
@@ -200,7 +200,4 @@ For more information about multi-signing and signer lists, see [Multi-Signing](m
|
||||
* `invalidParams` - One or more fields are specified incorrectly.
|
||||
* `badSeed` - The request specified a disallowed seed value (in the `passphrase`, `seed`, or `seed_hex` fields), such as an empty string, or a string resembling a XRP Ledger address.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
Reference in New Issue
Block a user