mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 19:55:54 +00:00
* Update look up escrows to remove redundant info about lookups via sender/destination. Modify cancel expired escrow for brevity. * Cancel escrow: fix notes * Add draft of updated cancel-escrow.js. * Update intro to escrows. * Add Escrow Tutorial * Minor corrections * Fix headings, add HTML * Update escrow docs This commit re-createsf205a92db2with some adjustments: - Omit the accidentally-created dir full of junk - Fix some typos and one mistake in the Escrow limitations section - Add a table to the EscrowCreate ref to clarify valid combos of fields. * Concept info from send-a-time-held-escrow added to escrow.md * IA: Move "Consensus Network" files This re-creates some work from the original commit56fffe0b9f* Rewrite escrows article (re-created) This commit re-creates relevant work from the following commits:9a4a588f2bUpdate escrow.md context infoe1b017dc83Remove references to using escrow for interledger payments. * IA: Move "XRPL servers" files This re-creates some work from original commit7611979abf* IA: move "production readiness" files. Re-creates work from the following commit:692438693aMove tutorials to concepts * New intro articles Original commit:56fffe0b9f* IA: Reorg account concepts Re-creates some work from original commit56fffe0b9f* IA: reorg transaction concepts Original commits:9d4eff9940WIP - reorg accounts7611979abfWIP dir. reorg * IA: reorg consensus concepts Original commit:56fffe0b9f* IA: Reorg ledger docs Original commit:56fffe0b9f- Rephrased some details of the section * IA: rename issuing/operational addresses page Original commit:56fffe0b9f* Moving use cases * Fleshing out Use Cases Note, the dactyl-config.yml file has not been fully updated. * Clean up checks conceptual info. * Remove redundant checks use case section Original commit:3c29e9c05e* IA: move Dex under tokens Original commit:d08b3ba7d7* Touch up stablecoin issuer use case (#1856) * Consolidate stablecoin use case * Stablecoin issuer: cleanup progress through sending * Stablecoin issuer: reorg second half (Note: the dactyl-config.yml is not fully reconciled yet) * Move rippled and clio tutorials into infrastructure * Remove link to checks amendement. * Add note to account_objects.md about commandline interface type field. * Merge expiration case with lifecycle section. * Interoperability Use Cases * Add graphics to intro * Move escrow use cases to dedicated page. * Update use case page intros and corresponding concept info. * Clarify meaning of direct XRP payments. * Intro link updates * Payment use cases * Remove some unnecessary links in transactions section Original commit:e6fcf4a4dc* Link cleanup in Tokens section Original commit:9588dd5e70* Touch up 'Configure Peering' section Original commit:fc8f0990b8* Clean up links in accounts section Original commit:3da5fde7a8* Add NFT mkt use case * p2p payments: edits to Wallets * Clean up payments use cases * Refine history description * IA: use case cleanup * IA: reconcile servers, ledgers sections * IA: reconcile payment types, tx, tokens * IA: reconcile accounts section * IA: reconcile infra * IA: Fix most broken links * Full Docs Index: omit from sidebar * IA: fix up most broken links * fix Absolute path link to internal content * Quick updates to Software Ecosystem * Remove some absolute links to internal resources * Fix remaining broken links in JA target * Contributing: tweak formatting * Tutorials: fix some minor issues * remove interop use cases * remove intro image and personal references to dennis * alphabetize-transaction-nav * Remove unused files * Add QS escrow tutorials * IA: move ledgers, consensus protocol files around * IA: update nav for new page hierarchy * reordering of topics under new networks and servers top-nav * Move "Naming" to "What is XRP?" * Update dactyl-config.yml Remove xrp.md from the TOC. * Update list-xrp-as-an-exchange.md Update link to what-is-xrp * Update list-xrp-as-an-exchange.ja.md Change link to what-is-xrp * Update currency-formats.md Change link to what-is-xrp * Update currency-formats.ja.md Change link to what-is-xrp * Update cancel-an-expired-escrow.md Change link to what-is-xrp * Update paymentchannelfund.md Change link to what-is-xml * Update look-up-escrows.md Change link to what-is-xrp * Update tokens.md change link to what-is-xrp * Update use-payment-channels.md * Update send-a-time-held-escrow.md Update link to what-is-xml * fix broken links * Update parallel-networks.md Change link to what-is-xml * Update parallel-networks.ja.md * Update invariant-checking.md Remove link to xrp.html * Update invariant-checking.ja.md Remove link to xrp.html * Update transaction-cost.md Change link to what-is-xrp * Update transaction-cost.ja.md Change link to what-is-xrp * Update send-a-conditionally-held-escrow.md Change link to what-is-xrp * Update stablecoin-issuer.md Change link to what-is-xrp * Update tokens.ja.md Change link to what-is-xml * Update autobridging.ja.md Change link to what-is-xrp * Update currency-formats.md update text * reorganize infrastructure nav section * Update currency-formats.md Try removing link altogether. * Update currency-formats.ja.md Remove link to what-is-xrp.html * move commandline usage topic to infrastructure * initial intro rewrite * minor update to language * IA.v3: rm Production Readiness * Delete xrp.md * Update xrp link in snippet * Add redirect for old xrp.html URL * Small edits to 'What is XRP?' article * Add missing imgs * XRP - copy edit per @DennisDawson * restructure tutorials nav and pages * fix broken links * more broken link fixes * Algo trading: 1st draft * Algo trading: notes on taxes * Algo trading: edits per review * algo trading: fix broken link * Ledger structure: rewrite for accuracy and clarity * Update links to removed 'tree format' header * Ledger Structure: Update diagrams * Re-gen CSS for ledger structure changes * Ledger structure: edits per review * IA.v3: fix broken NFT links introduced by rebase * Desktop Wallet (py): update little stuff * Update some capacity/storage details * contribute doc nav update * fix image link in create diagram page * IAv3: Fix 'Ledgers' blurb * Update full history requirements with details from community members * add reviewer suggestions * Edits per @trippled review * Apply suggestions from peer review Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com> * FH: reword file size limit note per review * Update software ecosystem * updates per review * Minor tweaks to graphics * fixTypos * Update content/concepts/introduction/software-ecosystem.md Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * Update content/concepts/introduction/software-ecosystem.md Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * [JA] update AccountDelete cost * custom transactors doc * add doc to dactyl config * [JA] fix NonFungibleTokensV1_1 amendment status * [JA] update NFTokenOffer page * Remove old, unused XRP article (#2039) * add reviewer suggestions * Add tooling to check for file/nav consistency - From the repo top, run tool/check_file_consistency.py to look for Markdown files that exist in the "content/" directory but aren't used in the documentation. - New "enforce_filenames" filter prints a warning to console when building, if a file's path and filename don't match expectations based on its place in the nav and top heading. * File consistency checker: correctly handle filenames starting in _ * Remove unused old 'get started' and associated code * Create Resources section & reorg some files - Rename some files/folders based on their place in the nav - Move a bunch of non-documentation stuff, and docs on contributing code and/or docs to the new "Resources" section. - Known issue: nav spills into a second row on page widths between 993px-1110px. To be fixed in a later CSS update, maybe along with making the Resources dropdown multi-column. * Fix #2078 code tab bug CSS not built yet, to reduce merge conflicts. Won't have any effect until that happens. * fix Transaction JSON * [JA] translate contributing contents * fix contributing-to-documentation parent * fix contribute-code blurb * Top nav: add cols for Resources, fix broken links * CSS: fix top nav overflows * Fix broken link from redirect not in JA target * Top nav: add Infra to article types * Update contrib info & rename intro file * [ja] Update link to suggested first page to translate * [ja] fix contribute docs organization * Run private network with docker tutorial (#2065) * [NO-ISSUE] Run private network with docker tutorial Adds a tutorial page in the Infrastructure section on how to run a private XRPL network with Docker. Please let me know if you think this is a useful page to include for developers, whether the steps are clear or not, and if you have suggestions on what can be added to it. * Add minor link fixes and Japanese target * Apply suggestions from code review Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * Add link to ripple-docker-testnet setup scripts in See Also section * Update repo URL --------- Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * add intro gfx (#2036) * add intro gfx * Move graphic up * Update some graphics with their revised versions * Add updated version of the custodial vs non-custodial graphic --------- Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com> * Update to reflect current UNL publishers * [ja] update contributing Co-authored-by: tequ <git@tequ.dev> * Incorporate feedback on "What is XRP" page. (#2099) * Add trademark info for XRP * Revert section to previous state * Fix broken link (#2101) --------- Co-authored-by: Oliver Eggert <oeggert@ripple.com> Co-authored-by: ddawson <dennis.s.dawson@gmail.com> Co-authored-by: Maria Shodunke <mshodunke@ripple.com> Co-authored-by: tequ <git@tequ.dev> Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com> Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> Co-authored-by: develoQ <develoQ.jp@gmail.com> Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com> Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com>
714 lines
28 KiB
Markdown
714 lines
28 KiB
Markdown
---
|
|
html: assign-a-regular-key-pair.html
|
|
parent: manage-account-settings.html
|
|
blurb: Authorize a second key pair to sign transactions from your account. This key pair can be changed or removed later.
|
|
labels:
|
|
- Security
|
|
- Accounts
|
|
---
|
|
# Assign a Regular Key Pair
|
|
|
|
The XRP Ledger allows an account to authorize a secondary key pair, called a _[regular key pair](cryptographic-keys.html)_, to sign future transactions. If the private key of a regular key pair is compromised, you can remove or replace it without changing the rest of your [account](accounts.html) and re-establishing its relationships to other accounts. You can also rotate a regular key pair proactively. (Neither of those things is possible for the master key pair of an account, which is intrinsically linked to the account's address.)
|
|
|
|
For more information about master and regular key pairs, see [Cryptographic Keys](cryptographic-keys.html).
|
|
|
|
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)
|
|
3. [Verify the regular key pair](#3-verify-the-regular-key-pair)
|
|
4. [Explore next steps](#see-also)
|
|
|
|
|
|
## 1. Generate a Key Pair
|
|
|
|
Generate a key pair that you'll assign to your account as a regular key pair.
|
|
|
|
This key pair is the same data type as a master key pair, so you can generate it the same way: you can use the client library of your choice or use the [wallet_propose method][] of a server you run. This might look as follows:
|
|
|
|
|
|
<!-- MULTICODE_BLOCK_START -->
|
|
|
|
_WebSocket_
|
|
|
|
```json
|
|
// Request:
|
|
|
|
{
|
|
"command": "wallet_propose"
|
|
}
|
|
|
|
// Response:
|
|
|
|
{
|
|
"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",
|
|
"type": "response"
|
|
}
|
|
```
|
|
|
|
_JSON-RPC_
|
|
|
|
```json
|
|
// Request:
|
|
|
|
{
|
|
"method": "wallet_propose"
|
|
}
|
|
|
|
// Response:
|
|
|
|
{
|
|
"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_
|
|
|
|
```sh
|
|
$ rippled wallet_propose
|
|
|
|
{
|
|
"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"
|
|
}
|
|
}
|
|
```
|
|
|
|
_Python_
|
|
|
|
```py
|
|
keypair = xrpl.wallet.Wallet.create()
|
|
print("seed:", keypair.seed)
|
|
print("classic address:", keypair.address)
|
|
```
|
|
|
|
_JavaScript_
|
|
|
|
```js
|
|
const keypair = new xrpl.Wallet()
|
|
console.log("seed:", keypair.seed)
|
|
console.log("classic address:", keypair.classicAddress)
|
|
```
|
|
|
|
_Java_
|
|
|
|
```java
|
|
WalletFactory walletFactory = DefaultWalletFactory.getInstance();
|
|
Wallet keypair = walletFactory.randomWallet(true).wallet();
|
|
System.out.println(keypair);
|
|
System.out.println(keypair.privateKey().get());
|
|
```
|
|
|
|
<!-- MULTICODE_BLOCK_END -->
|
|
|
|
In the next step, you'll use the address from this response (`account_id` in the API response) to assign the key pair as a regular key pair to your account. Also, save the seed value from this key pair (`master_seed` in the API response) somewhere securely; you'll use that key to sign transactions later. (Everything else, you can forget about.)
|
|
|
|
|
|
## 2. Assign the Key Pair to Your Account as a Regular Key Pair
|
|
|
|
Use a [SetRegularKey transaction][] to assign the key pair you generated in step 1 to your account as a regular key pair.
|
|
|
|
When assigning a regular key pair to your account for the first time, the SetRegularKey transaction requires signing with your account's master private key (secret). There are [several ways of securely signing transactions](secure-signing.html), but this tutorial uses a local `rippled` server.
|
|
|
|
When you send later SetRegularKey transactions, you can sign using the existing regular private key to replace or [remove itself](change-or-remove-a-regular-key-pair.html). Note that you should still not submit your regular private key across the network.
|
|
|
|
|
|
### Sign Your Transaction
|
|
|
|
{% include '_snippets/tutorial-sign-step.md' %}
|
|
<!--{#_ #}-->
|
|
|
|
Populate the request fields with the following values:
|
|
|
|
| Request Field | Value |
|
|
|:--------------|:-------------------------------------------------------------|
|
|
| `Account` | The address of your account. |
|
|
| `RegularKey` | `account_id` generated in step 1. |
|
|
| `secret` | `master_key`, `master_seed`, or `master_seed_hex` (master private key) for your account. |
|
|
|
|
|
|
#### Request Format
|
|
|
|
An example of the request format:
|
|
|
|
<!-- MULTICODE_BLOCK_START -->
|
|
|
|
*WebSocket*
|
|
|
|
```json
|
|
{
|
|
"command": "sign",
|
|
"tx_json": {
|
|
"TransactionType": "SetRegularKey",
|
|
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
|
"RegularKey": "rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7"
|
|
},
|
|
"secret": "ssCATR7CBvn4GLd1UuU2bqqQffHki"
|
|
}
|
|
```
|
|
|
|
*JSON-RPC*
|
|
|
|
```json
|
|
{
|
|
"method": "sign",
|
|
"params": [
|
|
{
|
|
"tx_json": {
|
|
"TransactionType": "SetRegularKey",
|
|
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
|
"RegularKey": "rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7"
|
|
},
|
|
"secret": "ssCATR7CBvn4GLd1UuU2bqqQffHki"
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
*Commandline*
|
|
|
|
```sh
|
|
#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*
|
|
|
|
```json
|
|
{
|
|
"result": {
|
|
"tx_blob": "1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540",
|
|
"tx_json": {
|
|
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
|
"Fee": "10",
|
|
"Flags": 2147483648,
|
|
"RegularKey": "rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
|
|
"Sequence": 4,
|
|
"SigningPubKey": "0384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A",
|
|
"TransactionType": "SetRegularKey",
|
|
"TxnSignature": "304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C26",
|
|
"hash": "AB73BBF7C99061678B59FB48D72CA0F5FC6DD2815B6736C6E9EB94439EC236CE"
|
|
}
|
|
},
|
|
"status": "success",
|
|
"type": "response"
|
|
}
|
|
```
|
|
|
|
*JSON-RPC*
|
|
|
|
```json
|
|
{
|
|
"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*
|
|
|
|
```json
|
|
{
|
|
"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 send 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 method][].
|
|
|
|
#### Request Format
|
|
|
|
An example of the request format:
|
|
|
|
<!-- MULTICODE_BLOCK_START -->
|
|
|
|
*WebSocket*
|
|
|
|
```json
|
|
{
|
|
"command": "submit",
|
|
"tx_blob": "1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540"
|
|
}
|
|
```
|
|
|
|
*JSON-RPC*
|
|
|
|
```json
|
|
{
|
|
"method":"submit",
|
|
"params": [
|
|
{
|
|
"tx_blob": "1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540"
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
*Commandline*
|
|
|
|
```sh
|
|
#Syntax: submit tx_blob
|
|
rippled submit 1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540
|
|
```
|
|
|
|
<!-- MULTICODE_BLOCK_END -->
|
|
|
|
|
|
#### Response Format
|
|
|
|
An example of a successful response:
|
|
|
|
<!-- MULTICODE_BLOCK_START -->
|
|
|
|
*WebSocket*
|
|
|
|
```json
|
|
{
|
|
"result": {
|
|
"engine_result": "tesSUCCESS",
|
|
"engine_result_code": 0,
|
|
"engine_result_message": "The transaction was applied. Only final in a validated ledger.",
|
|
"tx_blob": "1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540",
|
|
"tx_json": {
|
|
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
|
"Fee": "10",
|
|
"Flags": 2147483648,
|
|
"RegularKey": "rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
|
|
"Sequence": 4,
|
|
"SigningPubKey": "0384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A",
|
|
"TransactionType": "SetRegularKey",
|
|
"TxnSignature": "304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C26",
|
|
"hash": "AB73BBF7C99061678B59FB48D72CA0F5FC6DD2815B6736C6E9EB94439EC236CE"
|
|
}
|
|
},
|
|
"status": "success",
|
|
"type": "response"
|
|
}
|
|
```
|
|
|
|
*JSON-RPC*
|
|
|
|
```json
|
|
{
|
|
"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*
|
|
|
|
```json
|
|
{
|
|
"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](tx.html).
|
|
|
|
|
|
## 3. Verify the Regular Key Pair
|
|
|
|
At this point, the regular key pair is assigned to your account and you should be able to send transactions using the regular key pair. **To avoid losing control of your account,** it is important that you test your regular key before you take any additional steps such as [disabling the master key pair](disable-master-key-pair.html). If you make a mistake and lose access to your account, no one can restore it for you.
|
|
|
|
To verify that your account has the regular key pair set correctly, submit an [AccountSet transaction][] from your account, signing it with the regular private key you assigned to your account in step 2. As in step 1, this tutorial uses a local `rippled` server as a [way of securely signing transactions](secure-signing.html).
|
|
|
|
|
|
### Sign Your Transaction
|
|
|
|
{% include '_snippets/tutorial-sign-step.md' %}
|
|
<!--{#_ #}-->
|
|
|
|
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` (regular private key) generated in step 1 and assigned to your account in step 2. |
|
|
|
|
|
|
#### 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).
|
|
|
|
|
|
<!-- MULTICODE_BLOCK_START -->
|
|
|
|
*WebSocket*
|
|
|
|
```json
|
|
{
|
|
"command": "sign",
|
|
"tx_json": {
|
|
"TransactionType": "AccountSet",
|
|
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"
|
|
},
|
|
"secret": "sh8i92YRnEjJy3fpFkL8txQSCVo79"
|
|
}
|
|
```
|
|
|
|
*JSON-RPC*
|
|
|
|
```json
|
|
{
|
|
"method": "sign",
|
|
"params": [
|
|
{
|
|
"tx_json": {
|
|
"TransactionType": "AccountSet",
|
|
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"
|
|
},
|
|
"secret": "sh8i92YRnEjJy3fpFkL8txQSCVo79"
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
*Commandline*
|
|
|
|
```sh
|
|
#Syntax: sign secret tx_json
|
|
rippled sign sh8i92YRnEjJy3fpFkL8txQSCVo79 '{"TransactionType": "AccountSet", "Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"}'
|
|
```
|
|
|
|
<!-- MULTICODE_BLOCK_END -->
|
|
|
|
|
|
#### Response Format
|
|
|
|
An example of a successful response:
|
|
|
|
<!-- MULTICODE_BLOCK_START -->
|
|
|
|
*WebSocket*
|
|
|
|
```json
|
|
{
|
|
"result": {
|
|
"tx_blob": "1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
|
"tx_json": {
|
|
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
|
"Fee": "10",
|
|
"Flags": 2147483648,
|
|
"Sequence": 4,
|
|
"SigningPubKey": "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
|
"TransactionType": "AccountSet",
|
|
"TxnSignature": "3045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB8",
|
|
"hash": "D9B305CB6E861D0994A5CDD4726129D91AC4277111DC444DE4CEE44AD4674A9F"
|
|
}
|
|
},
|
|
"status": "success",
|
|
"type": "response"
|
|
}
|
|
```
|
|
|
|
*JSON-RPC*
|
|
|
|
```json
|
|
{
|
|
"result": {
|
|
"status": "success",
|
|
"tx_blob": "1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
|
"tx_json": {
|
|
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
|
"Fee": "10",
|
|
"Flags": 2147483648,
|
|
"Sequence": 4,
|
|
"SigningPubKey": "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
|
"TransactionType": "AccountSet",
|
|
"TxnSignature": "3045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB8",
|
|
"hash": "D9B305CB6E861D0994A5CDD4726129D91AC4277111DC444DE4CEE44AD4674A9F"
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
*Commandline*
|
|
|
|
```json
|
|
{
|
|
"result" : {
|
|
"status" : "success",
|
|
"tx_blob" : "1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
|
"tx_json" : {
|
|
"Account" : "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
|
"Fee" : "10",
|
|
"Flags" : 2147483648,
|
|
"Sequence" : 4,
|
|
"SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
|
"TransactionType" : "AccountSet",
|
|
"TxnSignature" : "3045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB8",
|
|
"hash" : "D9B305CB6E861D0994A5CDD4726129D91AC4277111DC444DE4CEE44AD4674A9F"
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
<!-- 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 send 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 method][].
|
|
|
|
#### Request Format
|
|
|
|
An example of the request format:
|
|
|
|
<!-- MULTICODE_BLOCK_START -->
|
|
|
|
*WebSocket*
|
|
|
|
```json
|
|
{
|
|
"command": "submit",
|
|
"tx_blob": "1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E"
|
|
}
|
|
```
|
|
|
|
*JSON-RPC*
|
|
|
|
```json
|
|
{
|
|
"method":"submit",
|
|
"params": [
|
|
{
|
|
"tx_blob": "1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E"
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
*Commandline*
|
|
|
|
```sh
|
|
#Syntax: submit tx_blob
|
|
rippled submit 1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E
|
|
```
|
|
|
|
<!-- MULTICODE_BLOCK_END -->
|
|
|
|
|
|
#### Response Format
|
|
|
|
An example of a successful response:
|
|
|
|
<!-- MULTICODE_BLOCK_START -->
|
|
|
|
*WebSocket*
|
|
|
|
```json
|
|
{
|
|
"result": {
|
|
"engine_result": "tesSUCCESS",
|
|
"engine_result_code": 0,
|
|
"engine_result_message": "The transaction was applied. Only final in a validated ledger.",
|
|
"tx_blob": "1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
|
"tx_json": {
|
|
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
|
"Fee": "10",
|
|
"Flags": 2147483648,
|
|
"Sequence": 4,
|
|
"SigningPubKey": "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
|
"TransactionType": "AccountSet",
|
|
"TxnSignature": "3045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB8",
|
|
"hash": "D9B305CB6E861D0994A5CDD4726129D91AC4277111DC444DE4CEE44AD4674A9F"
|
|
}
|
|
},
|
|
"status": "success",
|
|
"type": "response"
|
|
}
|
|
```
|
|
|
|
*JSON-RPC*
|
|
|
|
```json
|
|
{
|
|
"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": "1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
|
"tx_json": {
|
|
"Account": "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
|
"Fee": "10",
|
|
"Flags": 2147483648,
|
|
"Sequence": 4,
|
|
"SigningPubKey": "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
|
"TransactionType": "AccountSet",
|
|
"TxnSignature": "3045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB8",
|
|
"hash": "D9B305CB6E861D0994A5CDD4726129D91AC4277111DC444DE4CEE44AD4674A9F"
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
*Commandline*
|
|
|
|
```json
|
|
{
|
|
"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" : "1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
|
"tx_json" : {
|
|
"Account" : "rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
|
"Fee" : "10",
|
|
"Flags" : 2147483648,
|
|
"Sequence" : 4,
|
|
"SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
|
"TransactionType" : "AccountSet",
|
|
"TxnSignature" : "3045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB8",
|
|
"hash" : "D9B305CB6E861D0994A5CDD4726129D91AC4277111DC444DE4CEE44AD4674A9F"
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
<!-- MULTICODE_BLOCK_END -->
|
|
|
|
If the transaction fails with the following [result codes](transaction-results.html), here are some things to check:
|
|
|
|
- **`tefBAD_AUTH`**: The regular key you signed your test transaction with doesn't match the regular key you set in the previous step. Check that the secret and address for your regular key pair match and double-check which values you used in each step.
|
|
- **`tefBAD_AUTH_MASTER`** or **`temBAD_AUTH_MASTER`**: Your account doesn't have a regular key assigned. Check that the SetRegularKey transaction executed successfully. You can also use the [account_info method][] to confirm that your regular key is set in the `RegularKey` field as expected.
|
|
|
|
For possible causes of other result codes, see [Transaction Results](transaction-results.html).
|
|
|
|
|
|
## See Also
|
|
|
|
Now that you're familiar with the benefits of assigning a regular key pair to an account, consider taking a look at these related topics and tutorials:
|
|
|
|
- **Concepts:**
|
|
- [Cryptographic Keys](cryptographic-keys.html)
|
|
- [Multi-Signing](multi-signing.html)
|
|
- [Issuing and Operational Addresses](account-types.html)
|
|
- **Tutorials:**
|
|
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
|
|
- [Set Up Multi-Signing](set-up-multi-signing.html)
|
|
- [List XRP as an Exchange](list-xrp-as-an-exchange.html)
|
|
- **References:**
|
|
- [wallet_propose method][]
|
|
- [sign method][]
|
|
- [SetRegularKey transaction][]
|
|
- [AccountRoot object](accountroot.html) where the regular key is stored in the field `RegularKey`
|
|
|
|
|
|
|
|
|
|
|
|
<!--{# common link defs #}-->
|
|
{% include '_snippets/rippled-api-links.md' %}
|
|
{% include '_snippets/tx-type-links.md' %}
|
|
{% include '_snippets/rippled_versions.md' %}
|