From b5a7a4870e3a454b557683af6a6ea8101c0506c6 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Fri, 28 May 2021 16:45:42 -0700 Subject: [PATCH] Edits for style --- .../about-canceling-a-transaction.md | 2 +- .../amendments/known-amendments.ja.md | 2 +- .../amendments/known-amendments.md | 4 ++-- .../consensus-network/consensus-protections.md | 6 +++--- content/concepts/consensus-network/consensus.md | 4 ++-- .../concepts/consensus-network/negative-unl.md | 16 ++++++++-------- .../transaction-malleability.md | 8 ++++---- content/concepts/introduction/technical-faq.md | 2 +- content/concepts/issued-currencies/freezes.md | 6 ++++-- .../issued-currencies-overview.md | 2 +- .../accounts/cryptographic-keys.md | 6 +++--- .../accounts/depositauth.md | 8 ++++---- .../payment-system-basics/accounts/tickets.md | 4 ++-- .../concepts/payment-system-basics/ledgers.md | 2 +- .../transaction-basics/transaction-basics.md | 2 +- content/concepts/payment-types/checks.md | 10 +++++----- .../concepts/payment-types/payment-channels.md | 2 +- .../ledger-history/ledger-history.md | 2 +- .../ledger-history/online-deletion.md | 2 +- .../the-rippled-server/rippled-server-modes.md | 4 ++-- .../ledger-object-types/ledgerhashes.md | 4 ++-- .../protocol-reference/serialization.md | 2 +- .../pseudo-transaction-types.md | 2 +- .../logrotate.md | 6 +++--- .../api-conventions/api-conventions.md | 2 +- .../api-conventions/response-formatting.md | 4 ++-- .../health-check-interventions.md | 2 +- .../troubleshooting/server-doesnt-sync.md | 2 +- dactyl-config.yml | 2 -- tool/phrase_substitutions.yaml | 4 ++-- tool/word_substitutions.yaml | 4 ++-- 31 files changed, 64 insertions(+), 64 deletions(-) diff --git a/content/concepts/consensus-network/about-canceling-a-transaction.md b/content/concepts/consensus-network/about-canceling-a-transaction.md index 902b6e1841..9ed3ee24d7 100644 --- a/content/concepts/consensus-network/about-canceling-a-transaction.md +++ b/content/concepts/consensus-network/about-canceling-a-transaction.md @@ -9,7 +9,7 @@ An important and intentional feature of the XRP Ledger is that a [transaction](t If a transaction has _not_ yet been included in a validated ledger, it may be possible to effectively cancel it by sending another transaction from the same sending address with the same `Sequence` value. If you do not want the replacement transaction to do anything, send an [AccountSet transaction][] with no options. -**Caution:** There is no guaranteed way to cancel a valid transaction after it has been distributed to the network. The process described here may or may not work depending on a number of factors including how busy the network is, the network topology, and the [transaction cost](transaction-cost.html) of the proposed transaction. +**Caution:** There is no guaranteed way to cancel a valid transaction after it has been distributed to the network. The process described here may or may not work depending on factors including how busy the network is, the network topology, and the [transaction cost](transaction-cost.html) of the proposed transaction. If the transaction has already been distributed to the network and proposed as a [candidate transaction](consensus.html#consensus-1) in servers' consensus proposals, it may be too late to cancel. It is more likely that you can successfully cancel a transaction that is [queued](transaction-queue.html) or is stuck "in limbo" because its [transaction cost](transaction-cost.html) is not high enough to meet the network's current requirements. In this case, the replacement transaction can either do nothing, or do the same thing as the transaction to be canceled. The replacement transaction is more likely to succeed if its transaction cost is higher. diff --git a/content/concepts/consensus-network/amendments/known-amendments.ja.md b/content/concepts/consensus-network/amendments/known-amendments.ja.md index a61c042fe8..d686427ec2 100644 --- a/content/concepts/consensus-network/amendments/known-amendments.ja.md +++ b/content/concepts/consensus-network/amendments/known-amendments.ja.md @@ -592,7 +592,7 @@ XRPの「Payment Channel」を作成します。Payment Channelは、2名の当 | 00C1FC4A53E60AB02C864641002B3172F38677E29C26C5406685179B37E1EDAC | 有効 | -Changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid in any case. This protects against [transaction malleability](transaction-malleability.html) on _all_ transactions, instead of just transactions with the [tfFullyCanonicalSig flag](transaction-common-fields.html#グローバルフラグ) enabled. +Changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid in any case. This protects against [transaction malleability](transaction-malleability.html) on _all_ transactions, instead of only protecting transactions with the [tfFullyCanonicalSig flag](transaction-common-fields.html#グローバルフラグ) enabled. Without this amendment, a transaction is malleable if it uses a secp256k1 signature and does not have tfFullyCanonicalSig enabled. Most signing utilities enable tfFullyCanonicalSig by default, but there are exceptions. diff --git a/content/concepts/consensus-network/amendments/known-amendments.md b/content/concepts/consensus-network/amendments/known-amendments.md index 260eacdccc..baae44a88c 100644 --- a/content/concepts/consensus-network/amendments/known-amendments.md +++ b/content/concepts/consensus-network/amendments/known-amendments.md @@ -140,7 +140,7 @@ Also fixes a bug in the EscrowCreate and PaymentChannelCreate transactions where Provides users of [deposit authorization](depositauth.html) with a way to preauthorize specific senders so those senders are allowed to send payments directly. -Adds a new transaction type, DepositPreauth for adding or removing preauthorization, and a DepositPreauth ledger object type for tracking preauthorizations from one account to another. Adds a JSON-RPC command, `deposit_authorized`, to query whether an account is authorized to send payments directly to another. +Adds a new transaction type, DepositPreauth for adding or removing preauthorization, and a DepositPreauth ledger object type for tracking preauthorizations from one account to another. Adds a JSON-RPC command, `deposit_authorized`, to query whether an account is authorized to send payments directly to another. Also changes the behavior of cross-currency Payments from an account to itself when that account requires deposit authorization. Without this amendment, those payments always fail with the code `tecNO_PERMISSION`. With this amendment, those payments succeed as they would with Deposit Authorization disabled. @@ -560,7 +560,7 @@ Reduces the [owner reserve](reserves.html#owner-reserves) counted against your X Without this amendment, the owner reserve for a SignerList ranges from 15 to 50 XRP, depending on the number of signers in the list. -With this amendment enabled, the owner reserve for a new SignerList is 5 XRP, regardless of the number of signers. The reserve requirement for previously-created SignerList objects remains unchanged. To reduce the reserve requirement of SignerList objects created before this amendment was enabled, use a [SignerListSet transaction](signerlistset.html) to replace the SignerList after this amendment has been enabled. (The replacement can be identical to the previous version.) +With this amendment enabled, the owner reserve for a new SignerList is 5 XRP, regardless of the number of signers. The reserve requirement for previously-created SignerList objects remains unchanged. To reduce the reserve requirement of SignerList objects created before this amendment was enabled, use a [SignerListSet transaction](signerlistset.html) to replace the SignerList after this amendment has been enabled. (The replacement can be the same as the previous version.) ## NegativeUNL diff --git a/content/concepts/consensus-network/consensus-protections.md b/content/concepts/consensus-network/consensus-protections.md index bfc2c94c5b..089ae7787d 100644 --- a/content/concepts/consensus-network/consensus-protections.md +++ b/content/concepts/consensus-network/consensus-protections.md @@ -7,7 +7,7 @@ blurb: Learn how the XRP Ledger Consensus Protocol is protected against various The XRP Ledger Consensus Protocol is a _byzantine fault tolerant_ consensus mechanism, which means it's designed to work even if all kinds of things can go wrong: participants depend on an unreliable open network to communicate, and malicious actors may be attempting to control or interrupt the system at any given time. On top of that, the set of participants in the XRP Ledger Consensus Protocol isn't known in advance and can change over time. -Confirming transactions in a timely manner while maintaining [the desired properties of the network](intro-to-consensus.html#consensus-protocol-properties) is a complex challenge, and it's impossible to build a perfect system. The XRP Ledger Consensus Protocol is designed to work as well as it can in most situations, and to fail as gracefully as possible in the situations where it can't. +Confirming transactions quickly while maintaining [the desired properties of the network](intro-to-consensus.html#consensus-protocol-properties) is a complex challenge, and it's impossible to build a perfect system. The XRP Ledger Consensus Protocol is designed to work as well as it can in most situations, and to fail as gracefully as possible in the situations where it can't. This page describes some of the types of challenges that the XRP Ledger Consensus Protocol faces and how it handles them. @@ -41,7 +41,7 @@ As with any software system, bugs (or intentionally malicious code) in the imple ## Sybil Attacks -A _[Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack)_ is an attempt to take control of a network using a large number of fake identities. In the XRP Ledger, a Sybil attack would take the form of running a large number of validators, then convincing others to trust those validators. This sort of attack is theoretically possible, but would be very difficult to accomplish because human intervention is necessary for validators to become trusted. +A _[Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack)_ is an attempt to take control of a network using a large number of fake identities. In the XRP Ledger, a Sybil attack would take the form of running a large number of validators, then convincing others to trust those validators. This sort of attack is theoretically possible, but would be very difficult to do because human intervention is necessary for validators to become trusted. No matter how many validating servers a would-be attacker runs, those servers have no say on what the existing participants consider validated unless those participants choose to trust the attacker's validators. Other servers only listen to the validators they are configured to trust, either through a validator list or explicit configuration. (See [validator overlap requirements](#validator-overlap-requirements) for a summary of how the default validator list works.) @@ -50,7 +50,7 @@ This trust does not happen automatically, so performing a successful Sybil attac ## 51% Attack -A "51% attack" is an attack on a blockchain system where one party controls more than 50% of all mining or voting power. (Technically, the attack is slightly misnamed because _any_ amount over 50% is enough.) The XRP Ledger is not vulnerable to a 51% attack because it does not use mining in its consensus mechanism. The next closest analogue for the XRP Ledger is a [Sybil attack](#sybil-attacks), which would also be difficult to accomplish. +A "51% attack" is an attack on a blockchain system where one party controls more than 50% of all mining or voting power. (Technically, the attack is slightly misnamed because _any_ amount over 50% is enough.) The XRP Ledger is not vulnerable to a 51% attack because it does not use mining in its consensus mechanism. The next closest analogue for the XRP Ledger is a [Sybil attack](#sybil-attacks), which would also be difficult. ## Validator Overlap Requirements diff --git a/content/concepts/consensus-network/consensus.md b/content/concepts/consensus-network/consensus.md index 917b109d08..c62fa681b2 100644 --- a/content/concepts/consensus-network/consensus.md +++ b/content/concepts/consensus-network/consensus.md @@ -52,9 +52,9 @@ Transactions that appear in a validated ledger may have succeeded in changing th All transactions included in a ledger destroy some XRP as a [transaction cost](transaction-cost.html), regardless of whether they had a **`tes`** or **`tec`** code. The exact amount of XRP to destroy is defined by the signed transaction instructions. -In addition to the **`tes`** and **`tec`** class result codes, there are **`ter`**, **`tef`** and **`tem`** class codes. The latter three indicate provisional failures returned by API calls. Only **`tes`** and **`tec`** codes appear in ledgers. Transactions that are not included in ledgers cannot have any effect on the ledger state (including XRP balances), but transitions that provisionally failed may still end up succeeding. +There are other classes of result codes besides **`tes`** and **`tec`**. Any other classes of result code indicate provisional failures returned by API calls. Only **`tes`** and **`tec`** codes appear in ledgers. Transactions that are not included in ledgers cannot have any effect on the ledger state (including XRP balances), but transitions that provisionally failed may still end up succeeding. -When working with [`rippled` APIs](rippled-api.html), applications must distinguish between candidate transactions proposed for inclusion in a ledger versus validated transactions which are included in a validated ledger. Only transaction results found in a validated ledger are immutable. A candidate transaction may or may not ever be included in a validated ledger. +When working with [XRP Ledger APIs](rippled-api.html), applications must distinguish between candidate transactions proposed for inclusion in a ledger versus validated transactions which are included in a validated ledger. Only transaction results found in a validated ledger are immutable. A candidate transaction may eventually be included in a validated ledger, or it may not. Important: Some [`rippled` APIs](rippled-api.html) provide provisional results, based on candidate transactions 2. Applications should never rely on provisional results to determine the final outcome of a transaction. The only way to know with certainty that a transaction finally succeeded is to check the status of the transaction until it is both in a validated ledger and has result code `tesSUCCESS`. If the transaction is in a validated ledger with any other result code, it has failed. If the ledger specified in a transaction’s [`LastLedgerSequence`](transaction-common-fields.html) has been validated, yet the transaction does not appear in that ledger or any before it, then that transaction has failed and can never appear in any ledger. An outcome is final only for transactions that appear in a validated ledger or can never appear because of `LastLedgerSequence` restrictions as explained later in this document. diff --git a/content/concepts/consensus-network/negative-unl.md b/content/concepts/consensus-network/negative-unl.md index 745fdf6711..f6b0958a52 100644 --- a/content/concepts/consensus-network/negative-unl.md +++ b/content/concepts/consensus-network/negative-unl.md @@ -16,7 +16,7 @@ The Negative UNL has no impact on how the network processes transactions or what Each server in the XRP Ledger protocol has its own UNL (Unique Node List), a list of validators it trusts not to collude, and each server independently decides when a ledger version is validated based on the consensus when enough of its trusted validators agree on a new ledger version. (The default configuration uses a recommended UNL, signed by Ripple, consisting of validators Ripple considers to be sufficiently unique, reliable, and independent.) The standard quorum requirement is at least 80% of trusted validators must agree. -Therefore, if more than 20% of trusted validators go offline or become unable to communicate with the rest of the network, the network stops validating new ledgers because it cannot reach a quorum. This is a design choice to ensure that no transactions' outcomes can be changed after they are declared final. During such a situation, the remaining servers would still be online and could provide past and tentative transaction data, but could not confirm the final, immutable outcome of new transactions. +If more than 20% of trusted validators go offline or become unable to communicate with the rest of the network, the network stops validating new ledgers because it cannot reach a quorum. This is a design choice to ensure that no transactions' outcomes can be changed after they are declared final. During such a situation, the remaining servers would still be online and could provide past and tentative transaction data, but could not confirm the final, immutable outcome of new transactions. However, this means that the network could stop making forward progress if a few widely-trusted validators went offline. As of 2020-10-06, there are 34 validators in Ripple's recommended UNL, so the network would stop making forward progress if 7 or more of them were offline. Furthermore, if one or two validators are out for an extended period of time, the network has less room for disagreement between the remaining validators, which can make it take longer to achieve a consensus. @@ -50,11 +50,11 @@ The Negative UNL is intentionally designed to change at a slow rate, to avoid an ### Reliability Measurement -Each server in the network has a UNL, the list of validators it trusts not to collude. (By default, a server's exact UNL is configured implicitly based on the recommended validator list Ripple publishes.) Each server tracks the _reliability_ of its trusted validators using a simple metric: the percentage of the last 256 ledgers where the validator's validation vote matched the server's view of consensus. In other words: +Each server in the network has a UNL, the list of validators it trusts not to collude. (By default, a server's exact UNL is configured implicitly based on the recommended validator list Ripple publishes.) Each server tracks the _reliability_ of its trusted validators using a single metric: the percentage of the last 256 ledgers where the validator's validation vote matched the server's view of consensus. In other words: > Reliability = Va ÷ 256 -Va is the total number of validation votes received for the last 256 ledgers that matched the server's own view of consensus. +Va is the total number of validation votes received from one validator for the last 256 ledgers that matched the server's own view of consensus. This metric of reliability measures the availability of a validator _and_ the behavior of that validator. A validator should have a high reliability score if it is in sync with the rest of the network and following the same protocol rules as the server scoring it. A validator's reliability score can suffer for any of the following reasons: @@ -110,17 +110,17 @@ If there are multiple candidates to be removed from the Negative UNL in a given This mechanism has several useful properties: - It uses information that is readily available to all servers and can be calculated quickly. -- Most servers will chose the same result even if they calculated slightly different scores for their trusted validators. This holds even if those servers disagree on which validator is _least_ or _most_ reliable. This even holds in many cases where the servers disagree on whether some validators are above or below the reliability thresholds. Therefore, the network is likely to achieve a consensus on which validator to add or remove. -- It does not always give the same results each ledger version. Therefore, if one proposed change to the Negative UNL fails to achieve a consensus, the network does not get stuck with some servers trying and failing to add or remove that one validator every time. The network can attempt to add or remove a different candidate to the Negative UNL in a later flag ledger. +- Most servers choose the same candidate even if they calculated slightly different scores for their trusted validators. This holds even if those servers disagree on which validator is _least_ or _most_ reliable. This even holds in many cases where the servers disagree on whether some validators are above or below the reliability thresholds. So, the network is likely to achieve a consensus on which validator to add or remove. +- It does not always give the same results each ledger version. If one proposed change to the Negative UNL fails to achieve a consensus, the network does not get stuck with some servers trying and failing to add or remove that one validator every time. The network can attempt to add or remove a different candidate to the Negative UNL in a later flag ledger. ### Filtering Validations -During [the validation step of the consensus process](consensus.html#validation), validators in the parent ledger's Negative UNL are disabled. Each server calculates an "effective UNL" consisting of its configured UNL with the disabled validators removed, and recalculates its quorum accordingly. (The quorum is always at least 80% of the effective UNL and at least 60% of the configured UNL.) If a disabled validator sends validation votes, servers track those votes for purposes of calculating the disabled validator's reliability measurement, but they do not use those votes towards determining whether a ledger version has achieved a consensus. +During [the validation step of the consensus process](consensus.html#validation), validators in the parent ledger's Negative UNL are disabled. Each server calculates an "effective UNL" consisting of its configured UNL with the disabled validators removed, and recalculates its quorum. (The quorum is always at least 80% of the effective UNL and at least 60% of the configured UNL.) If a disabled validator sends validation votes, servers track those votes for purposes of calculating the disabled validator's reliability measurement, but they do not use those votes towards determining whether a ledger version has achieved a consensus. -**Note:** The Negative UNL adjusts the _total_ trusted validators that the quorum is calculated from, not the quorum directly. The quorum is a percentage but the number of votes is a whole number, so in some cases, reducing the total trusted validators may not change the number of votes required to reach a quorum. For example, if there are 15 total validators, 80% is 12 validators exactly. If you reduce the total to 14 validators, 80% is 11.2 validators, which means that it still requires 12 validators to reach a quorum. +**Note:** The Negative UNL adjusts the _total_ trusted validators that the quorum is calculated from, not the quorum directly. The quorum is a percentage but the number of votes is a whole number, so reducing the total trusted validators does not always change the number of votes required to reach a quorum. For example, if there are 15 total validators, 80% is 12 validators exactly. If you reduce the total to 14 validators, 80% is 11.2 validators, which means that it still requires 12 validators to reach a quorum. -The Negative UNL has no impact on the other parts of the consensus process, such as choosing which transactions to include in the proposed transaction set. Those steps always rely on configured UNL, and the thresholds are based on how many trusted validators are actively participating in the consensus round. Therefore, even a validator that is in the Negative UNL can participate in the consensus process. +The Negative UNL has no impact on the other parts of the consensus process, such as choosing which transactions to include in the proposed transaction set. Those steps always rely on the configured UNL, and the thresholds are based on how many trusted validators are actively participating in the consensus round. Even a validator that is in the Negative UNL can participate in the consensus process. ### Example diff --git a/content/concepts/consensus-network/transaction-malleability.md b/content/concepts/consensus-network/transaction-malleability.md index e4b6df80c5..9e0044b191 100644 --- a/content/concepts/consensus-network/transaction-malleability.md +++ b/content/concepts/consensus-network/transaction-malleability.md @@ -33,7 +33,7 @@ To be "canonical", signatures created with the ECDSA algorithm and secp256k1 cur - The signature must be properly [DER-encoded data](https://en.wikipedia.org/wiki/X.690#DER_encoding). - The signature must not have any padding bytes outside the DER-encoded data. -- The signature's component integers must not be negative, and they must not be larger than the secp256k1 group order. +- The signature's component integers must not be negative, and they must not be larger than the secp256k1 group order. Generally speaking, any standard ECDSA implementation handles these requirements automatically. However, with secp256k1, those requirements are insufficient to prevent malleability. Thus, the XRP Ledger has a concept of "fully canonical" signatures which do not have the same problem. @@ -48,7 +48,7 @@ Between 2014 and 2020, the XRP Ledger was compatible with legacy software that d ### Malleability with Multi-Signatures -An important, explicit feature of multi-signing is that multiple different possible configurations can render a transaction valid. For example, an account can be configured so that signatures from any three of five signers could authorize a transaction. However, this inherently means that there can be several different variations of a valid transaction, each with a different identifying hash. +An important, explicit feature of multi-signing is that multiple different possible configurations can make a transaction valid. For example, an account can be configured so that signatures from any three of five signers could authorize a transaction. However, this inherently means that there can be several different variations of a valid transaction, each with a different identifying hash. All of the following cases can lead to transaction malleability: @@ -63,7 +63,7 @@ Even if your authorized signers are not intentionally malicious, confusion or po **Good operational security can protect against these problems.** Generally, you can avoid transaction malleability problems when multi-signing if you follow good operational security practices, including the following: - Do not collect more signatures than necessary. -- Either designate one party to assemble a transaction after collecting the necessary number of signatures, or designate a "chain" where signers pass the transaction instructions forward to be signed in a predefined order. +- Either appoint one party to assemble a transaction after collecting the necessary number of signatures, or instruct signers pass the transaction instructions forward to be signed in a set order. - Do not add unnecessary or untrusted signers to your multi-signing lists, even if the `weight` values associated with their keys are insufficient to authorize a transaction. - Be prepared for the possibility that a transaction executes with a different hash and set of signatures than you expected. Carefully monitor your account's sent transactions (for example, using the [account_tx method][]). - Monitor the `Sequence` number of your account (for example, using the [account_info method][]). This number always increases by exactly one when your account sends a transaction successfully, and never any other way. If the number does not match what you expect, you should check your recent transactions to confirm why. (Aside from malleable transactions, there are other ways this could happen, too. Perhaps you configured another application to send transactions for you. Maybe a malicious user gained access to your secret key. Or perhaps your application lost data and forgot about a transaction you sent already.) @@ -81,7 +81,7 @@ If you use single-signatures only, you are not vulnerable to this exploit. If yo ### Exploit Scenario Steps -The process to exploit a vulnerable system follows a series of steps similar to the following: +The process to exploit a vulnerable system follows a series of steps like the following: 1. The vulnerable system constructs a multi-signed transaction and collects more than the necessary number of signatures. diff --git a/content/concepts/introduction/technical-faq.md b/content/concepts/introduction/technical-faq.md index 69fff2618f..80ecbbdc2b 100644 --- a/content/concepts/introduction/technical-faq.md +++ b/content/concepts/introduction/technical-faq.md @@ -51,7 +51,7 @@ No, institutions cannot set up customized validator policies for choosing to all The network may temporarily halt to reconfigure itself to continue with the new UNL list based on those that want to reach consensus. This temporary processing delay is desired rather than double spending. -In the process of determining the final, authoritative version of the ledger, there may be multiple temporary internal versions. Such internal versions naturally happen in distributed systems because not all nodes receive transactions in the same order. The analogous behavior in Bitcoin is where two servers each see a different longest chain because two blocks were mined at about the same time. +While determining the final, authoritative version of the ledger, there may be multiple temporary internal versions. Such internal versions naturally happen in distributed systems because not all nodes receive transactions in the same order. The analogous behavior in Bitcoin is where two servers each see a different longest chain because two blocks were mined at about the same time. However, there can be only one latest _validated_ ledger version at any given time; other versions are irrelevant and harmless. diff --git a/content/concepts/issued-currencies/freezes.md b/content/concepts/issued-currencies/freezes.md index cc12daff40..85a339a35e 100644 --- a/content/concepts/issued-currencies/freezes.md +++ b/content/concepts/issued-currencies/freezes.md @@ -5,9 +5,11 @@ blurb: Freezes can suspend trading of issued currencies for compliance purposes. --- # Freezing Issued Currencies -XRP is not an issued currency. XRP is the only native asset on the XRP Ledger and is required in order to conduct transactions on the XRP Ledger. XRP is counterparty free, meaning that when someone holds XRP, they are not holding a liability, they are holding the actual currency, XRP. Due to this fact, _**XRP CANNOT be frozen by any entity or individual**_. +Issuers can freeze the tokens they issue in the XRP Ledger. -All non-XRP currencies can be represented in the XRP Ledger as issued currencies. These issued currencies (sometimes called "IOUs") are tracked in accounting relationships, called "trust lines," between addresses. Issued currencies are typically considered as liabilities from one perspective and assets from the other, so the balance of a trust line is negative or positive depending on which side you view it from. Any address may freely issue (non-XRP) currencies, limited only by how much other addresses are willing to hold. +XRP is not an issued currency. XRP is the only native asset on the XRP Ledger and is required to conduct transactions on the XRP Ledger. XRP has no counterparty, meaning that when someone holds XRP, they are not holding a liability, they are holding the actual currency, XRP. Due to this fact, _**XRP CANNOT be frozen by any entity or individual**_. + +All non-XRP currencies can be represented in the XRP Ledger as issued currencies. These issued currencies (sometimes called "IOUs") are tracked in accounting relationships, called "trust lines," between addresses. Issued currencies are typically considered as liabilities from one perspective and assets from the other, so the balance of a trust line is negative or positive depending on which side you view it from. Any address may freely issue (non-XRP) currencies, limited only by how much other addresses are willing to hold. In certain cases, to meet regulatory requirements, or while investigating suspicious activity, an exchange or gateway may want to quickly freeze non-XRP issued currency balances. diff --git a/content/concepts/issued-currencies/issued-currencies-overview.md b/content/concepts/issued-currencies/issued-currencies-overview.md index 44bc92bc69..b438f19d5d 100644 --- a/content/concepts/issued-currencies/issued-currencies-overview.md +++ b/content/concepts/issued-currencies/issued-currencies-overview.md @@ -5,7 +5,7 @@ blurb: Get an overview of issued currencies and their properties in the XRP Ledg --- # Issued Currencies Overview -All currencies other than XRP can be represented in the XRP Ledger as **issued currencies**. These digital assets (sometimes called "IOUs") are tracked in accounting relationships, called "trust lines," between addresses. Issued currencies are typically considered as liabilities from one perspective and assets from the other, so the balance of a trust line is negative or positive depending on which side you view it from. Any address may freely issue (non-XRP) currencies, limited only by how much other addresses are willing to hold. +All currencies other than XRP can be represented in the XRP Ledger as **issued currencies**. These digital assets (sometimes called "IOUs") are tracked in accounting relationships, called "trust lines," between addresses. Issued currencies are typically considered as liabilities from one perspective and assets from the other, so the balance of a trust line is negative or positive depending on which side you view it from. Any address may freely issue (non-XRP) currencies, limited only by how much other addresses are willing to hold. Issued currencies can "ripple" through multiple issuers and holders if they use the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [No Ripple flag](rippling.html) on trust lines to prevent those trust lines from rippling. diff --git a/content/concepts/payment-system-basics/accounts/cryptographic-keys.md b/content/concepts/payment-system-basics/accounts/cryptographic-keys.md index da021f3de3..9ef5d04d53 100644 --- a/content/concepts/payment-system-basics/accounts/cryptographic-keys.md +++ b/content/concepts/payment-system-basics/accounts/cryptographic-keys.md @@ -17,7 +17,7 @@ There are several ways to create a key pair: - The [wallet_propose method][] in [the `rippled` server](the-rippled-server.html). - The [`generateAddress()` method of ripple-lib](rippleapi-reference.html#generateaddress). -- Other [tools or wallet applications](software-ecosystem.html). +- Other [tools or wallet applications](software-ecosystem.html). ## Key Components @@ -51,7 +51,7 @@ The seed value is secret information, so you must protect it very carefully. Any The _private key_ is the value that is used to create a digital signature. Most XRP Ledger software does not explicitly show the private key, and [derives the private key](#key-derivation) from the seed value when necessary. It is technically possible to save the private key instead of the seed and use that to sign transactions directly, but this usage is rare. -Just like the seed, the private key is secret information, so you must protect it very carefully. Anyone who has knows an address's private key has effectively full control over that address. +Like the seed, the private key is secret information, so you must protect it very carefully. Anyone who has knows an address's private key has effectively full control over that address. ### Public Key @@ -145,7 +145,7 @@ In the future, it is likely that the XRP Ledger will need new cryptographic sign ## Key Derivation -The process of deriving a key pair depends on the signing algorithm. In all cases, keys are generated from a _seed_ value that is 16 bytes (128 bits) in length. The seed value can be completely random (recommended) or it can be derived from a specific passphrase by taking the [SHA-512 hash][Hash] and keeping the first 16 bytes (similar to [SHA-512Half][], but keeping only 128 bits instead of 256 bits of the output). +The process of deriving a key pair depends on the signing algorithm. In all cases, keys are generated from a _seed_ value that is 16 bytes (128 bits) in length. The seed value can be completely random (recommended) or it can be derived from a specific passphrase by taking the [SHA-512 hash][Hash] and keeping the first 16 bytes (like [SHA-512Half][], but keeping only 128 bits instead of 256 bits of the output). ### Sample Code diff --git a/content/concepts/payment-system-basics/accounts/depositauth.md b/content/concepts/payment-system-basics/accounts/depositauth.md index 973f8dbd91..37f14f22d5 100644 --- a/content/concepts/payment-system-basics/accounts/depositauth.md +++ b/content/concepts/payment-system-basics/accounts/depositauth.md @@ -30,7 +30,7 @@ To get the full effect of Deposit Authorization, Ripple recommends also doing th - Always maintain an XRP balance higher than the minimum [reserve requirement](reserves.html). - Keep the Default Ripple flag in its default (disabled) state. Do not enable [rippling](rippling.html) on any trust lines. When sending [TrustSet transactions][], always use the [`tfSetNoRipple` flag](trustset.html). -- Do not place [Offers](offercreate.html). It is impossible to know in advance which matching offers will be consumed to execute such a trade. +- Do not place [Offers](offercreate.html). It is impossible to know in advance which matching offers will be consumed to execute such a trade. ## Precise Semantics @@ -47,7 +47,7 @@ An account with Deposit Authorization enabled: - The destination of the EscrowFinish transaction has [preauthorized](#preauthorization) the sender of the EscrowFinish. _(Added by the [DepositPreauth amendment][])_ - **Can** receive XRP or issued currencies by sending a [CheckCash][] transaction. _(Added by the [Checks amendment][].)_ - **Can** receive XRP or issued currencies by sending [OfferCreate transactions][]. - - If the account sends an OfferCreate transaction that is not fully executed immediately, it **can** receive the remainder of the ordered XRP or issued currency later when the offer is consumed by other accounts' [Payment][] and [OfferCreate][] transactions. + - If the account sends an OfferCreate transaction that is not fully executed immediately, it **can** receive the rest of the ordered XRP or issued currency later when the offer is consumed by other accounts' [Payment][] and [OfferCreate][] transactions. - If the account has created any trust lines without the [No Ripple flag](rippling.html) enabled, or has enabled the Default Ripple flag and issued any currency, the account **can** receive the issued currencies of those trust lines in [Payment transactions][] as a result of rippling. It cannot be the destination of those transactions. - In general, an account in the XRP Ledger **cannot** receive any non-XRP currencies in the XRP Ledger as long as all of the following are true. (This rule is not specific to the DepositAuth flag.) - The account has not created any trust lines with a nonzero limit. @@ -80,7 +80,7 @@ Preauthorization is currency-agnostic. You cannot preauthorize accounts for spec To preauthorize a particular sender, send a [DepositPreauth transaction][] with the address of another account to preauthorize in the `Authorize` field. To revoke preauthorization, provide the other account's address in the `Unauthorize` field instead. Specify your own address in the `Account` field as usual. You can preauthorize or unauthorize accounts even if you do not currently have DepositAuth enabled; the preauthorization status you set for other accounts is saved, but has no effect unless you enable DepositAuth. An account cannot preauthorize itself. Preauthorizations are one-directional, and have no effect on payments going the opposite direction. -Preauthorizing another account adds a [DepositPreauth object](depositpreauth-object.html) to the ledger, which increases the [owner reserve](reserves.html#owner-reserves) of the account providing the authorization. If the account revokes this preauthorization, doing so removes the object and the reserve decreases accordingly. +Preauthorizing another account adds a [DepositPreauth object](depositpreauth-object.html) to the ledger, which increases the [owner reserve](reserves.html#owner-reserves) of the account providing the authorization. If the account revokes this preauthorization, doing so removes the object and decreases the owner reserve. After the DepositPreauth transaction has been processed, the authorized account can send funds to your account, even if you have DepositAuth enabled, using any of the following transaction types: @@ -92,7 +92,7 @@ Preauthorization has no effect on the other ways to send money to an account wit ### Checking for Authorization -You can use the [deposit_authorized method][] to see if an account is authorized to deposit to another account. This method checks two things: +You can use the [deposit_authorized method][] to see if an account is authorized to deposit to another account. This method checks two things: - Whether the destination account requires Deposit Authorization. (If it does not require authorization, then all source accounts are considered authorized.) - Whether the source account is preauthorized to send money to the destination. diff --git a/content/concepts/payment-system-basics/accounts/tickets.md b/content/concepts/payment-system-basics/accounts/tickets.md index ba77ecd9f1..ba6f7753fb 100644 --- a/content/concepts/payment-system-basics/accounts/tickets.md +++ b/content/concepts/payment-system-basics/accounts/tickets.md @@ -17,7 +17,7 @@ A Ticket in the XRP Ledger is a way of setting aside a [sequence number][Sequenc However, there are some situations where sequence numbers are too limiting. For example: - Two or more users share access to an account, each with the ability to send transactions independently. If these users try to send transactions around the same time without coordinating first, they may each try to use the same Sequence number for different transactions, and only one can succeed. -- You may want to prepare and sign a transaction in advance, then save it in some secure storage so that it can be executed at any future point if certain events occur. However, if you want to continue using your account as normal in the meantime, you don't know what Sequence number the set-aside transaction will need. +- You may want to prepare and sign a transaction in advance, then save it in some secure storage so that it can be executed at any future point if certain events occur. However, if you want to continue using your account as normal in the meantime, you don't know what Sequence number the set-aside transaction will need. - When [multiple people must sign a transaction](multi-signing.html) to make it valid, it can be difficult to plan more than one transaction at a time. If you number the transactions with separate sequence numbers, you can't send the later-numbered transactions until everyone has signed the previous transactions; but if you use the same sequence number for each pending transactions, only one of them can succeed. Tickets provide a solution to all of these problems by setting aside sequence numbers that can be used later, outside of their usual order, but still no more than once each. @@ -48,7 +48,7 @@ To look up what Tickets an account has available, use the [account_objects metho Any account can create and use Tickets on any type of transaction. However, some restrictions apply: - Each Ticket can only be used once. It is possible to have multiple different candidate transactions that would use the same Ticket Sequence, but only one of those candidates can be validated by consensus. -- Each account cannot have more than 250 Tickets in the ledger at a time. Therefore, you cannot create more than 250 Tickets at a time, either. +- Each account cannot have more than 250 Tickets in the ledger at a time. You cannot create more than 250 Tickets at a time, either. - You _can_ use a Ticket to create more Tickets. If you do, the Ticket you used does not count towards the total number of Tickets you can have at once. - Each Ticket counts toward the [owner reserve](reserves.html), so you must set aside 5 XRP for each Ticket you have not used yet. The XRP becomes available for you to use again after the Ticket is used. - Within an individual ledger, transactions that use Tickets execute after other transactions from the same sender. If an account has multiple transactions using Tickets in the same ledger version, those Tickets execute in order from lowest Ticket Sequence to highest. (For more information, see the documentation on consensus's [canonical order](consensus.html#calculate-and-share-validations).) diff --git a/content/concepts/payment-system-basics/ledgers.md b/content/concepts/payment-system-basics/ledgers.md index 02dd7766f1..8e01c5179f 100644 --- a/content/concepts/payment-system-basics/ledgers.md +++ b/content/concepts/payment-system-basics/ledgers.md @@ -47,7 +47,7 @@ Thus, an open ledger is only ever used as a temporary workspace, which is a majo ## Ledger Close Times -The time that a ledger version closed is recorded at the `close_time` field of the [ledger header](ledger-header.html). To make it easier for the network to reach a consensus on an exact close time, this value is rounded to a number of seconds based on the close time resolution, currently 10 seconds. If rounding would cause a ledger's close time to be the same as (or earlier than) its parent ledger's, the child ledger has its close time set to the parent's close time plus 1. This guarantees that the close times of validated ledgers are strictly increasing. +The time that a ledger version closed is recorded at the `close_time` field of the [ledger header](ledger-header.html). To make it easier for the network to reach a consensus on an exact close time, this value is rounded to a number of seconds based on the close time resolution, currently 10 seconds. If rounding would cause a ledger's close time to be the same as (or earlier than) its parent ledger's, the child ledger has its close time set to the parent's close time plus 1. This guarantees that the close times of validated ledgers are strictly increasing. Since new ledger versions usually close about every 3 to 5 seconds, these rules result in a loose pattern where ledgers' close times end in :00, :01, :02, :10, :11, :20, :21, and so on. Times ending in 2 are less common and times ending in 3 are very rare, but both occur randomly when more ledgers randomly happen to close within a 10-second window. diff --git a/content/concepts/payment-system-basics/transaction-basics/transaction-basics.md b/content/concepts/payment-system-basics/transaction-basics/transaction-basics.md index b5e8e88464..22dbf34295 100644 --- a/content/concepts/payment-system-basics/transaction-basics/transaction-basics.md +++ b/content/concepts/payment-system-basics/transaction-basics/transaction-basics.md @@ -105,7 +105,7 @@ Signing a transaction generates a binary blob that can be submitted to the netwo ## Example Executed Transaction with Metadata -After a transaction has been submitted, you can check its status using the API, for example using the [tx command](tx.html). This shows the transaction instructions, its outcome, and the [metadata](transaction-metadata.html) of all changes that were made in the process of executing it. +After a transaction has been submitted, you can check its status using the API, for example using the [tx command](tx.html). This shows the transaction instructions, its outcome, and the [metadata](transaction-metadata.html) of all changes that were made by executing it. **Caution:** The success of a transaction is not final unless the transaction appears in a **validated** ledger with the result code `tesSUCCESS`. See also: [Finality of Results](finality-of-results.html). diff --git a/content/concepts/payment-types/checks.md b/content/concepts/payment-types/checks.md index c959de0543..00d28760f1 100644 --- a/content/concepts/payment-types/checks.md +++ b/content/concepts/payment-types/checks.md @@ -11,11 +11,11 @@ The Checks feature in the XRP Ledger allows users to create deferred payments th XRP Ledger Checks have expiration times after which they may no longer be cashed. If the recipient doesn't successfully cash the Check before it expires, the Check object remains in the XRP Ledger until someone cancels it. Anyone may cancel the Check after it expires. Only the sender and recipient can cancel the Check before it expires or is cashed. The Check object is removed from the Ledger when the sender successfully cashes the check or someone cancels it. -Checks are similar to [Escrow](escrow.html) and [Payment Channels](use-payment-channels.html), but there are some important differences between those features and Checks: +Checks have some similarities to [Escrow](escrow.html) and [Payment Channels](use-payment-channels.html), but there are some important differences between those features and Checks: * You can send issued currency with Checks. With Payment Channels and Escrow, you can only send XRP. -* Checks do not tie up any funds. The XRP involved in Payment Channels and Escrow cannot be spent until it is redeemed with a claim provided by the sender (Payment Channels), or released by an expiration or crypto-condition (Escrow). +* Checks do not lock up or set aside any funds. The XRP involved in Payment Channels and Escrow cannot be spent until it is redeemed with a claim provided by the sender (Payment Channels), or released by an expiration or crypto-condition (Escrow). * You can send XRP to yourself through Escrow. You cannot use Checks or Payment Channels to send XRP (or, in the case of Checks, issued currencies) to yourself. @@ -27,14 +27,14 @@ Checks are similar to [Escrow](escrow.html) and [Payment Channels](use-payment-c Traditional paper checks allow people to transfer balances without immediately exchanging physical currency. XRP Ledger Checks allow people to exchange funds asynchronously using a process that is familiar to and accepted by the banking industry. -XRP Ledger Checks also solve a problem that is unique to the XRP Ledger: they allow users to reject unwanted payments or accept only a portion of a payment. This is useful for institutions that need to be careful about accepting payments for compliance reasons. +XRP Ledger Checks also solve a problem that is unique to the XRP Ledger: they allow users to reject unwanted payments or accept only part of a payment. This is useful for institutions that need to be careful about accepting payments for compliance reasons. Checks potentially enable many other use cases. Ripple encourages the community to find new and creative applications for Checks. ### Use Case: Payment Authorization -**Problem:** To comply with regulations like [BSA, KYC, AML, and CFT](become-an-xrp-ledger-gateway.html#gateway-compliance), financial institutions must provide documentation about the source of funds they receive. Such regulations seek to prevent the illicit transfer of funds by requiring institutions to disclose the source and destination of all payments processed by the institution. Because of the nature of the XRP Ledger, anyone could potentially send XRP (and, under the right circumstances, issued currencies) to an institution's account on the XRP Ledger. Dealing with such unwanted payments adds significant cost and time delays to these institutions' compliance departments, including potential fines or penalties. +**Problem:** To comply with regulations like [BSA, KYC, AML, and CFT](become-an-xrp-ledger-gateway.html#gateway-compliance), financial institutions must provide documentation about the source of funds they receive. Such regulations seek to prevent the illicit transfer of funds by requiring institutions to know the source and destination of all payments processed by the institution. Because of the nature of the XRP Ledger, anyone could potentially send XRP (and, under the right circumstances, issued currencies) to an institution's account on the XRP Ledger. Dealing with such unwanted payments adds significant cost and time delays to these institutions' compliance departments, including potential fines or penalties. **Solution:** Institutions can enable [Deposit Authorization](depositauth.html) on their XRP Ledger accounts by [setting the `asfDepositAuth` flag in an `AccountSet` transaction](accountset.html). This makes the account unable to receive Payment transactions. Accounts with Deposit Authorization enabled can only receive funds through Escrow, Payment Channels, or Checks. Checks are the most straightforward, familiar, and flexible way to transfer funds if Deposit Authorization is enabled. @@ -56,7 +56,7 @@ Checks typically have the lifecycle described below. * `Amount` — The recipient can use this option to specify an exact amount to cash. This may be useful for cases where the sender has padded the check to cover possible [transfer fees](transfer-fees.html) and the recipient wants to accept the exact amount on an invoice or other contract. -* `DeliverMin` — The recipient can use this option to specify the minimum amount they are willing to receive from the Check. If the recipient uses this option, the XRP Ledger attempts to deliver as much as possible and will deliver at least this amount. The transaction fails if the amount that can be credited to the recipient is not at least the requested amount. +* `DeliverMin` — The recipient can use this option to specify the minimum amount they are willing to receive from the Check. If the recipient uses this option, the XRP Ledger attempts to deliver as much as possible and always delivers at least this amount. The transaction fails if the amount that can be credited to the recipient is not at least the requested amount. If the sender has enough funds to cover the Check and the expiration time has not passed, the funds are debited from the sender's account and credited to the recipient's account, and the Check object is destroyed. diff --git a/content/concepts/payment-types/payment-channels.md b/content/concepts/payment-types/payment-channels.md index cd91af8364..9dcdb7eb49 100644 --- a/content/concepts/payment-types/payment-channels.md +++ b/content/concepts/payment-types/payment-channels.md @@ -7,7 +7,7 @@ blurb: Payment Channels enable fast, asynchronous XRP payments that can be divid Payment Channels are an advanced feature for sending "asynchronous" XRP payments that can be divided into very small increments and settled later. -The XRP for a payment channel is set aside for a given time period. The sender creates _Claims_ against the channel, which the recipient verifies without sending an XRP Ledger transaction or waiting for a new ledger version to be approved by [consensus](consensus.html). (This is an _asynchronous_ process because it happens separate from the usual pattern of getting transactions approved by consensus.) At any time, the recipient can _redeem_ a Claim to receive an amount of XRP authorized by that Claim. Settling a Claim like this uses a standard XRP Ledger transaction, as part of the usual consensus process. This single transaction can encompass any number of transactions guaranteed by smaller Claims. +The XRP for a payment channel is set aside temporarily. The sender creates _Claims_ against the channel, which the recipient verifies without sending an XRP Ledger transaction or waiting for a new ledger version to be approved by [consensus](consensus.html). (This is an _asynchronous_ process because it happens separate from the usual pattern of getting transactions approved by consensus.) At any time, the recipient can _redeem_ a Claim to receive an amount of XRP authorized by that Claim. Settling a Claim like this uses a standard XRP Ledger transaction, as part of the usual consensus process. This single transaction can encompass any number of transactions guaranteed by smaller Claims. Because Claims can be verified individually but settled in bulk later, payment channels make it possible to conduct transactions at a rate only limited by the participants' ability to create and verify the digital signatures of those Claims. This limit is primarily based the speed of the participants' hardware and the complexity of the signature algorithms. For maximum speed, use Ed25519 signatures, which are faster than the XRP Ledger's default secp256k1 ECDSA signatures. Research has [demonstrated the ability to create over Ed25519 100,000 signatures per second and to verify over 70,000 per second](https://ed25519.cr.yp.to/ed25519-20110926.pdf) on commodity hardware in 2011. diff --git a/content/concepts/the-rippled-server/ledger-history/ledger-history.md b/content/concepts/the-rippled-server/ledger-history/ledger-history.md index 9fac0c11c1..e0d54a8c62 100644 --- a/content/concepts/the-rippled-server/ledger-history/ledger-history.md +++ b/content/concepts/the-rippled-server/ledger-history/ledger-history.md @@ -36,7 +36,7 @@ The XRP Ledger identifies data (on several different levels) by a unique hash of The amount of history a server attempts to download depends on its configuration. The server automatically tries to fill gaps by downloading history up to **the oldest ledger it already has available**. You can use the `[ledger_history]` setting to make the server backfill history beyond that point. However, the server never downloads ledgers that would be scheduled for [deletion](online-deletion.html). -The `[ledger_history]` setting defines a minimum number of ledgers to accumulate from before the current validated ledger. Use the special value `full` to download the [full history](#full-history) of the network. If you specify a number of ledgers, it must be equal to or more than the `online_deletion` setting; you cannot use `[ledger_history]` to make the server download _less_ history. To reduce the amount of history a server stores, change the [online deletion](online-deletion.html) settings instead. +The `[ledger_history]` setting defines a minimum number of ledgers to accumulate from before the current validated ledger. Use the special value `full` to download the [full history](#full-history) of the network. If you specify a number of ledgers, it must be equal to or more than the `online_deletion` setting; you cannot use `[ledger_history]` to make the server download _less_ history. To reduce the amount of history a server stores, change the [online deletion](online-deletion.html) settings instead. diff --git a/content/concepts/the-rippled-server/ledger-history/online-deletion.md b/content/concepts/the-rippled-server/ledger-history/online-deletion.md index 73903ba972..0c090cbb49 100644 --- a/content/concepts/the-rippled-server/ledger-history/online-deletion.md +++ b/content/concepts/the-rippled-server/ledger-history/online-deletion.md @@ -35,7 +35,7 @@ The online deletion settings configure how many ledger versions the `rippled` se The amount of data the server stores depends on how often you call [can_delete][can_delete method] and how big an interval of time your `online_delete` setting represents: - - If you call `can_delete` _more often_ than your `online_delete` interval, the server stores at most a number of ledger versions approximately equal to **twice the `online_delete` value**. (After deletion, this is reduced to approximately the `online_delete` value.) + - If you call `can_delete` _more often_ than your `online_delete` interval, the server stores at most a number of ledger versions approximately equal to **twice the `online_delete` value**. (After deletion, this is reduced to approximately the `online_delete` value.) For example, if you call `can_delete` with a value of `now` once per day and an `online_delete` value of 50,000, the server typically stores up to 100,000 ledger versions before running deletion. After running deletion, the server keeps at least 50,000 ledger versions (about two days' worth). With this configuration, approximately every other `can_delete` call results in no change because the server does not have enough ledger versions to delete. diff --git a/content/concepts/the-rippled-server/rippled-server-modes.md b/content/concepts/the-rippled-server/rippled-server-modes.md index 4bfbc5dac7..ac886621e5 100644 --- a/content/concepts/the-rippled-server/rippled-server-modes.md +++ b/content/concepts/the-rippled-server/rippled-server-modes.md @@ -38,7 +38,7 @@ All P2P Mode servers provide [APIs](rippled-api.html) for purposes like submitti #### Full History Servers -Unlike some other blockchains, the XRP Ledger does not require servers to have a complete transaction history to know the current state and process new transactions. As a server operator, you decide how much [ledger history](ledger-history.html) to store at a time. However, a P2P Mode server can only answer API requests using the ledger history it has locally available. For example, if you keep six months of history, your server can't describe the outcome of a transaction from a year ago. API servers with [full history](ledger-history.html#full-history) can report all transactions and balances since the inception of the XRP Ledger. +Unlike some other blockchains, the XRP Ledger does not require servers to have a complete transaction history to know the current state and process new transactions. As a server operator, you decide how much [ledger history](ledger-history.html) to store at a time. However, a P2P Mode server can only answer API requests using the ledger history it has locally available. For example, if you keep six months of history, your server can't describe the outcome of a transaction from a year ago. API servers with [full history](ledger-history.html#full-history) can report all transactions and balances since the start of the XRP Ledger. ### Public Hubs @@ -56,7 +56,7 @@ To configure your server as a hub, increase the maximum number of peers allowed ### Validators -The robustness of the XRP Ledger depends on an interconnected web of _validators_ who each trust some other validators _not to collude_. In addition to processing each transaction and calculating ledger state just like other P2P Mode servers, validators participate actively in the [consensus protocol](consensus.html). If you or your organization relies on the XRP Ledger, it is in your interest to contribute to the consensus process by running _one_ server as a validator. +The robustness of the XRP Ledger depends on an interconnected web of _validators_ who each trust some other validators _not to collude_. In addition to processing each transaction and calculating ledger state exactly like other P2P Mode servers, validators participate actively in the [consensus protocol](consensus.html). If you or your organization relies on the XRP Ledger, it is in your interest to contribute to the consensus process by running _one_ server as a validator. Validation uses only a small amount of computing resources, but there is not much benefit to a single entity or organization running multiple validators because doing so does not provide more protections against collusion. Each validator identifies itself with a unique cryptographic key pair that must be carefully managed; multiple validators must not share a key pair. For these reasons, validation is disabled by default. diff --git a/content/references/protocol-reference/ledger-data/ledger-object-types/ledgerhashes.md b/content/references/protocol-reference/ledger-data/ledger-object-types/ledgerhashes.md index 04172e7cb7..78fd8343d0 100644 --- a/content/references/protocol-reference/ledger-data/ledger-object-types/ledgerhashes.md +++ b/content/references/protocol-reference/ledger-data/ledger-object-types/ledgerhashes.md @@ -8,12 +8,12 @@ blurb: Lists of prior ledger versions' hashes for history lookup. (Not to be confused with the ["ledger hash" string data type][Hash], which uniquely identifies a ledger version. This section describes the `LedgerHashes` ledger object type.) -The `LedgerHashes` object type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Objects of this ledger type are modified automatically in the process of closing a ledger. (This is one of the only times a ledger's state data is modified without a [transaction](transaction-basics.html) or [pseudo-transaction](pseudo-transaction-types.html).) The `LedgerHashes` objects exist to make it possible to look up a previous ledger's hash with only the current ledger version and at most one lookup of a previous ledger version. +The `LedgerHashes` object type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Objects of this ledger type are modified automatically when closing a ledger. (This is one of the only times a ledger's state data is modified without a [transaction](transaction-basics.html) or [pseudo-transaction](pseudo-transaction-types.html).) The `LedgerHashes` objects exist to make it possible to look up a previous ledger's hash with only the current ledger version and at most one lookup of a previous ledger version. There are two kinds of `LedgerHashes` object. Both types have the same fields. Each ledger version contains: - Exactly one "recent history" `LedgerHashes` object -- A number of "previous history" `LedgerHashes` objects based on the current ledger index (that is, the length of the ledger history). Specifically, the XRP Ledger adds a new "previous history" object every 65536 ledger versions. +- A number of "previous history" `LedgerHashes` objects based on the current ledger index (that is, the length of the ledger history). Specifically, the XRP Ledger adds a new "previous history" object every 65536 ledger versions. **Note:** As an exception, a new genesis ledger has no `LedgerHashes` objects at all, because it has no ledger history. diff --git a/content/references/protocol-reference/serialization.md b/content/references/protocol-reference/serialization.md index 20bd019b1c..f98821bb37 100644 --- a/content/references/protocol-reference/serialization.md +++ b/content/references/protocol-reference/serialization.md @@ -56,7 +56,7 @@ Additionally, the following libraries also provide serialization support: {% include '_snippets/libs-snippet.md' %} -These implementations are all provided with permissive open-source licenses, so you can import, use, or adapt the code for your needs in addition to using it alongside these documents for learning purposes. +These implementations are all provided with permissive open-source licenses, so you can import, use, or adapt the code for your needs. diff --git a/content/references/protocol-reference/transactions/pseudo-transaction-types/pseudo-transaction-types.md b/content/references/protocol-reference/transactions/pseudo-transaction-types/pseudo-transaction-types.md index 907299eb59..5fb8f9d443 100644 --- a/content/references/protocol-reference/transactions/pseudo-transaction-types/pseudo-transaction-types.md +++ b/content/references/protocol-reference/transactions/pseudo-transaction-types/pseudo-transaction-types.md @@ -6,7 +6,7 @@ template: template-landing-children.html --- # Pseudo-Transactions -Pseudo-transactions are never submitted by users, nor [propagated through the network](peer-protocol.html). Instead, a server may choose to inject pseudo-transactions in a proposed ledger directly according to specific protocol rules. If enough servers inject an identical pseudo-transaction for it to be approved by the [consensus process](consensus.html), then the pseudo-transaction becomes included in the ledger, and appears in ledger data thereafter. +Pseudo-transactions are never submitted by users, nor [propagated through the network](peer-protocol.html). Instead, a server may choose to inject pseudo-transactions in a proposed ledger directly according to specific protocol rules. If enough servers propose the exact same pseudo-transaction, the [consensus process](consensus.html) approves it, and the pseudo-transaction is included in that ledger's transaction data. ## Special Values for Common Fields diff --git a/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/logrotate.md b/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/logrotate.md index 63745826ec..20afd2482b 100644 --- a/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/logrotate.md +++ b/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/logrotate.md @@ -30,11 +30,11 @@ The following script is a sample that can be created as `/etc/logrotate.d/ripple } ``` -You can configure parameters such as `minsize` and `rotate` depending on the amount of logs you keep. Use the `log_level` setting in your `rippled.cfg` file to configure how verbose your server's logs are. This sample script is based on standard `log_level` and will store approximately 2 weeks worth of logs in a compressed format. +You can configure parameters such as `minsize` and `rotate` depending on the amount of logs you keep. Use the `log_level` setting in your `rippled.cfg` file to configure how verbose your server's logs are. This sample script is based on standard `log_level` and stores approximately 2 weeks worth of logs in a compressed format. -Starting with `rippled` 1.3, the script `/etc/logrotate.d/rippled` will be automatically installed by the DEB and RPM packages. You can make modifications to this as required. Your modifications will not be overwritten on package upgrades. +The official packages [for CentOS/Red Hat](install-rippled-on-centos-rhel-with-yum.html) and [Ubuntu or Debian](install-rippled-on-ubuntu.html) provide the script `/etc/logrotate.d/rippled` by default. You can make modifications to this as required. Your modifications will not be overwritten on package upgrades. -**Note:** You should have only one system logrotate script per application. Please ensure that you do not have any other log rotation that handles the same directory. +**Note:** You should have only one system log rotation script per application. Please ensure that you do not have any other log rotation that handles the same directory. _The `logrotate` method is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users._ diff --git a/content/references/rippled-api/api-conventions/api-conventions.md b/content/references/rippled-api/api-conventions/api-conventions.md index 7ee45ee479..a6dcac344b 100644 --- a/content/references/rippled-api/api-conventions/api-conventions.md +++ b/content/references/rippled-api/api-conventions/api-conventions.md @@ -8,4 +8,4 @@ template: template-landing-children.html This section describes data types and formats of the HTTP APIs (JSON-RPC and WebSocket) as implemented in [the `rippled` server](the-rippled-server.html). -For information regarding the XRP Ledger protocol regardless of interface, see [Protocol Reference](protocol-reference.html). +For information on the XRP Ledger protocol that applies to all APIs, see [Protocol Reference](protocol-reference.html). diff --git a/content/references/rippled-api/api-conventions/response-formatting.md b/content/references/rippled-api/api-conventions/response-formatting.md index a34f3520e8..825237979b 100644 --- a/content/references/rippled-api/api-conventions/response-formatting.md +++ b/content/references/rippled-api/api-conventions/response-formatting.md @@ -16,7 +16,7 @@ The fields of a successful response include: | `result.status` | String | (JSON-RPC and Commandline) The value `success` indicates the request was successfully received and understood by the server. | | `type` | String | (WebSocket only) The value `response` indicates a successful response to a command. [Asynchronous notifications](subscribe.html) use a different value such as `ledgerClosed` or `transaction`. | | `result` | Object | The result of the query; contents vary depending on the command. | -| `warning` | String | _(May be omitted)_ If this field is provided, the value is the string `load`. This means the client is approaching the [rate limiting](rate-limiting.html) threshold where the server will disconnect this client. | +| `warning` | String | _(May be omitted)_ If this field is provided, the value is the string `load`. This means the client is approaching the [rate limiting](rate-limiting.html) threshold where the server will disconnect this client. | | `warnings` | Array | _(May be omitted)_ If this field is provided, it contains one or more **Warnings Objects** with important warnings. For details, see [API Warnings](#api-warnings). [New in: rippled 1.5.0][] | | `forwarded` | Boolean | _(May be omitted)_ If `true`, this request and response have been forwarded from a [Reporting Mode][] server to a P2P Mode server (and back) because the request requires data that is not available in Reporting Mode. The default is `false`. | @@ -126,7 +126,7 @@ Example warning: ] ``` -This warning indicates that the one or more [amendments](amendments.html) to the XRP Ledger protocol are scheduled to become enabled, but the current server does not have an implementation for those amendments. If those amendments become enabled, the current server will become [amendment blocked](amendments.html#amendment-blocked), so you should [upgrade to the latest `rippled` version](install-rippled.html) as soon as possible. +This warning indicates that the one or more [amendments](amendments.html) to the XRP Ledger protocol are scheduled to become enabled, but the current server does not have an implementation for those amendments. If those amendments become enabled, the current server will become [amendment blocked](amendments.html#amendment-blocked), so you should [upgrade to the latest `rippled` version](install-rippled.html) as soon as possible. The server only sends this warning if the client is [connected as an admin](get-started-using-http-websocket-apis.html#admin-access). diff --git a/content/tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md b/content/tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md index 71ff334069..11f38533d6 100644 --- a/content/tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md +++ b/content/tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md @@ -28,7 +28,7 @@ Some examples of special cases that may occur include: ## Suggested Interventions -When a health check fails, and it's not just a [momentary failure](#momentary-failures), the action to take to recover from the outage varies based on the cause. You may be able to configure your infrastructure to fix some types of failures automatically. Other failures require the intervention of a human administrator who can investigate and take the necessary steps to resolve more complex or critical failures; depending on the structure of your organization, you may have different levels of human administrator so that less skilled, lower level administrators can fix certain issues independently, but need to escalate to higher level administrators to fix larger or more complex issues. How and when you respond is likely to depend on your unique situation, but the metrics reported in the health check result can be a factor in these decisions. +When a health check fails, and it's not just a [momentary failure](#momentary-failures), the action to take to recover from the outage varies based on the cause. You may be able to configure your infrastructure to fix some types of failures automatically. Other failures require the intervention of a human administrator who can investigate and take the necessary steps to resolve more complex or critical failures; depending on the structure of your organization, you may have different levels of human administrator so that less skilled, lower level administrators can fix certain issues independently, but need to escalate to higher level administrators to fix larger or more complex issues. How and when you respond is likely to depend on your unique situation, but the metrics reported in the health check result can be a factor in these decisions. The following sections suggest some common interventions you may want to attempt and the health check statuses most likely to prompt those interventions. Automated systems and human administrators may selectively escalate through these and other interventions: diff --git a/content/tutorials/manage-the-rippled-server/troubleshooting/server-doesnt-sync.md b/content/tutorials/manage-the-rippled-server/troubleshooting/server-doesnt-sync.md index 7bb04d456a..99c0a2c8f7 100644 --- a/content/tutorials/manage-the-rippled-server/troubleshooting/server-doesnt-sync.md +++ b/content/tutorials/manage-the-rippled-server/troubleshooting/server-doesnt-sync.md @@ -40,7 +40,7 @@ The most common cause of syncing issues is not meeting the [system requirements] - **Insufficient RAM.** The memory requirements vary depending on several factors including ones that are hard to predict like network load and how people use the XRP Ledger, so it's good to have more than the minimum system requirements. - **Poor network connection.** Network requirements vary the most based on how people use the XRP Ledger, but a slow or unstable connection can make it impossible to keep up with new transactions and data added to the XRP Ledger. -If you are having trouble remaining synced, double-check that your server meets the system requirements. Depending on how you use your server, you may need to meet the higher "Recommended" requirements instead of just the "Minimum" requirements. If you meet the "Recommended" requirements and still cannot sync, try the other possibilities on this page. +If you are having trouble remaining synced, double-check that your server meets the system requirements. Depending on how you use your server, you may need to meet the higher "Recommended" requirements. If you meet the "Recommended" requirements and still cannot sync, try the other possibilities on this page. ## Couldn't Load Validator List diff --git a/dactyl-config.yml b/dactyl-config.yml index b50659c9ca..3794f39d53 100644 --- a/dactyl-config.yml +++ b/dactyl-config.yml @@ -79,8 +79,6 @@ targets: display_name: XRPL.org <<: *defaults prefix: "" - readability_goals: - flesch_reading_ease: 50 # or higher blurb: XRPL.org is a community-driven resource for all things XRP and the XRP Ledger—your source for technical information, reference materials and tools. - name: ja diff --git a/tool/phrase_substitutions.yaml b/tool/phrase_substitutions.yaml index c28733d0a3..b9a64ead28 100644 --- a/tool/phrase_substitutions.yaml +++ b/tool/phrase_substitutions.yaml @@ -20,7 +20,7 @@ be advised: (omit) by means of: by, with close proximity: near combat environment: combat -comply with: follow +# comply with: follow due to the fact that: due to, since during the period: during effect modifications: make changes @@ -63,7 +63,7 @@ provided that: if provides guidance for: guides pursuant to: by, following, per, under set forth in: in -similar to: like +# similar to: like successfully complete: complete, pass take action to: (omit) the month of: (omit) diff --git a/tool/word_substitutions.yaml b/tool/word_substitutions.yaml index 36a08b4df5..8dda6580de 100644 --- a/tool/word_substitutions.yaml +++ b/tool/word_substitutions.yaml @@ -10,7 +10,7 @@ will: (avoid future tense) accompany: go with accomplish: carry out, do accorded: given -accordingly: so +# accordingly: so accrue: add, gain accurate: correct, exact, right #additional: added, more, other @@ -50,7 +50,7 @@ depart: leave designate: appoint, choose, name desire: want, wish #determine: decide, figure, find -disclose: show +# disclose: show discontinue: drop, stop disseminate: give, issue, pass, send easy: (omit)