ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 19:55:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix some sign/submit links, use snippets more

Browse Source
This commit is contained in:
mDuo13
2018-05-11 19:35:48 -07:00
parent fdd3263cf8
commit 2bf70ba3f0
4 changed files with 16 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -401,7 +401,8 @@ As discussed in step 2, transmitting your master private key is dangerous. It is
### Sign Your Transaction
The most secure way to sign a transaction is to do it offline with a signing library, such as [RippleAPI](rippleapi-reference.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.
{% include '_snippets/tutorial-sign-step.md' %}
<!--{#_ #}-->
Populate the request fields with the following values:

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

@@ -14,14 +14,15 @@ For more information about master and regular key pairs, see [Cryptographic Keys
## Removing a Regular Key Pair
If you want to simply remove a compromised regular key pair from your account, you don't need to generate a key pair first. Use a [SetRegularKey transaction][], omitting the `RegularKey` field. Note that the transaction fails if you don't have another way of signing for your account currently enabled (either the master key pair or a [signer list](reference-transaction-format.html#multi-signing)).
If you want to simply remove a compromised regular key pair from your account, you don't need to generate a key pair first. Use a [SetRegularKey transaction][], omitting the `RegularKey` field. Note that the transaction fails if you don't have another way of signing for your account currently enabled (either the master key pair or a [signer list](multi-signing.html)).
When removing a regular key pair to your account, the `SetRegularKey` transaction requires signing by your account's master private key (secret) or existing regular key pair. Transmitting your master or regular private key is dangerous, so we'll complete this transaction in two steps to keep transaction signing separate from transaction submission to the network.
### Sign Your Transaction
The most secure way to sign a transaction is to do it offline with a signing library, such as [RippleAPI](rippleapi-reference.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.
{% include '_snippets/tutorial-sign-step.md' %}
<!--{#_ #}-->
Populate the request fields with the following values:

6
content/tutorials/use-complex-payment-types/use-payment-channels.md
View File

@@ -49,7 +49,7 @@ This is a [PaymentChannelCreate transaction][]. As part of this process, the pay
**Tip:** The "settlement delay" does not delay the settlement, which can happen as fast as a ledger version closes (3-5 seconds). The "settlement delay" is a forced delay on closing the channel so that the payee has a chance to finish with settlement.
The following example shows creation of a payment channel by [submitting](reference-rippled.html#sign-and-submit-mode) to a local `rippled` server with the JSON-RPC API. The payment channel allocates 100 XRP from the [example payer](#example-values) (rN7n7...) to the [example payee](#example-values) (rf1Bi...) with a settlement delay of 1 day. The public key is the example payer's master public key, in hexadecimal.
The following example shows creation of a payment channel by [submitting](submit.html#sign-and-submit-mode) to a local `rippled` server with the JSON-RPC API. The payment channel allocates 100 XRP from the [example payer](#example-values) (rN7n7...) to the [example payee](#example-values) (rf1Bi...) with a settlement delay of 1 day. The public key is the example payer's master public key, in hexadecimal.
**Note:** A payment channel counts as one object toward the payer's [owner reserve](reserves.html#owner-reserves). The owner must keep at least enough XRP to satisfy the reserve after subtracting the XRP allocated to the payment channel.
@@ -430,7 +430,7 @@ If the channel _does_ have XRP remaining, the request to close a channel acts as
The payee can also close a payment channel immediately after processing a claim _(9b in the [flow diagram][])_.
Example of [submitting a transaction](reference-rippled.html#sign-and-submit-mode) requesting a channel to close:
Example of [submitting a transaction](submit.html#sign-and-submit-mode) requesting a channel to close:
{
"method": "submit",
@@ -483,7 +483,7 @@ Ripple recommends that the payer sends a second [PaymentChannelClaim transaction
The command to submit the transaction is the same as the previous example requesting channel expiration. (However, its resulting [auto-filled](transaction-common-fields.html#auto-fillable-fields) `Sequence` number, signature, and identifying hash are unique.)
Example of [submitting](reference-rippled.html#sign-and-submit-mode) a transaction to close an expired channel:
Example of [submitting](submit.html#sign-and-submit-mode) a transaction to close an expired channel:
{
"method": "submit",

12
content/tutorials/use-simple-xrp-payments/reliable-transaction-submission.md
View File

@@ -273,7 +273,7 @@ In this example the last validated ledger sequence number is 10268596 (found und
#### Construct the Transaction
`rippled` provides the [sign method](reference-rippled.html#sign) to prepare a transaction for submission. This method requires an account secret, which should only be passed to trusted `rippled` instances. This example issues 10 FOO (a made-up currency) to another XRP Ledger address.
`rippled` provides the [sign method][] to prepare a transaction for submission. This method requires an account secret, which should only be passed to trusted `rippled` instances. This example issues 10 FOO (a made-up currency) to another XRP Ledger address.
Request:
@@ -510,8 +510,12 @@ Finally the server may show one or more gaps in the transaction history. The `co
## Additional Resources
- [Transaction Format](reference-transaction-format.html)
- [Transaction Formats](transaction-formats.html)
- [Transaction Cost](transaction-cost.html)
- [`LastLedgerSequence` field](reference-transaction-format.html#lastledgersequence)
- [Overview of XRP Ledger Consensus Process](consensus.html)
- [Reaching Consensus in the XRP Ledger](reaching-consensus.html)
- [Consensus Principles and Rules](consensus-principles-and-rules.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}