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

Merge pull request #664 from mDuo13/IA-interlinking

Browse Source 
Improve interlinking of concepts section
This commit is contained in:
Rome Reginelli
2019-08-15 17:59:26 -07:00
committed by GitHub
parent f83714bf14 4af8b8daaa
commit c393431f43
40 changed files with 535 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
content/concepts/consensus-network/amendments/amendments.md
View File

@@ -232,6 +232,20 @@ TrustSetAuth
```
## See Also
- **Concepts:**
- [Known Amendments List](known-amendments.html)
- [Introduction to Consensus](intro-to-consensus.html)
- **Tutorials:**
- [Run rippled as a Validator](run-rippled-as-a-validator.html)
- [Contribute Code to rippled](contribute-code-to-rippled.html)
- **References:**
- [Amendments ledger object](amendments-object.html)
- [EnableAmendment pseudo-transaction][]
- [feature method][]
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

43
content/concepts/consensus-network/consensus-principles-and-rules.md
View File

@@ -4,16 +4,16 @@ The XRP Ledger is a universal payment system enabling users to transfer funds ac
The XRP Ledger's technology enables near real-time settlement (three to six seconds) and contains a decentralized exchange, where payments automatically use the cheapest currency trade orders available to bridge currencies.
# Background
## Background
## Mechanics
### Mechanics
At the core, the XRP Ledger is a shared database that records information such as accounts, balances, and offers to trade assets. Signed instructions called "transactions" cause changes such as creating accounts, making payments, and trading assets.
As a cryptographic system, the owners of XRP Ledger accounts are identified by _cryptographic identities_, which correspond to public/private key pairs. Transactions are authorized by cryptographic signatures matching these identities. Every server processes every transaction according to the same deterministic, known rules. Ultimately, the goal is for every server in the network to have a complete copy of the exact same ledger state, without needing a single central authority to arbitrate transactions.
## The Double Spend Problem
### The Double Spend Problem
The "double spend" problem is a fundamental challenge to operating any sort of payment system. The problem comes from the requirement that when money is spent in one place, it can't also be spent in another place. More generally, the problem occurs when you have any two transactions such that either one is valid but not both together.
@@ -26,9 +26,9 @@ Conventionally, payment systems solve the double spend problem by having a centr
Distributed ledger technologies, like the XRP Ledger, have no central authority. They must solve the double spend problem in some other way.
# How Consensus Works
## How Consensus Works
## Simplifying the Problem
### Simplifying the Problem
Much of the double spend problem can be solved by well-known rules such as prohibiting an account from spending funds it does not have. In fact, the double spend problem can be reduced to putting transactions in order.
@@ -42,7 +42,7 @@ If we could collect transactions into groups and agree on those groupings, we co
The XRP Ledger allows multiple conflicting transactions to be in the agreed group. The group of transactions is executed according to deterministic rules, so whichever transaction comes first according to the sorting rules succeeds and whichever conflicting transaction comes second fails.
## Consensus Rules
### Consensus Rules
The primary role of consensus is for participants in the process to agree on which transactions are to be processed as a group to resolve the double spend problem. There are four reasons this agreement is easier to achieve than might be expected:
@@ -53,7 +53,7 @@ The primary role of consensus is for participants in the process to agree on whi
Every participant’s top priority is correctness. They must first enforce the rules to be sure nothing violates the integrity of the shared ledger. For example, a transaction that is not properly signed must never be processed (even if other participants want to be processed). However, every honest participant’s second priority is agreement. A network with possible double spends has no utility at all. Agreement is facilitated by the fact that every honest participant values it above everything but correctness.
## Consensus Rounds
### Consensus Rounds
A consensus round is an attempt to agree on a group of transactions so they can be processed. A consensus round starts with each participant who wishes to do so taking an initial position. This is the set of valid transactions they have seen.
@@ -63,7 +63,7 @@ To prevent consensus from stalling near 50% and to reduce the overlap required f
When a participant sees a supermajority that agrees on the set of transactions to next be processed, it declares a consensus to have been reached.
## Consensus Can Fail
### Consensus Can Fail
It is not practical to develop a consensus algorithm that never fails to achieve perfect consensus. To understand why, consider how the consensus process finishes. At some point, each participant must declare that a consensus has been reached and that some set of transactions is known to be the result of the process. This declaration commits that participant irrevocably to some particular set of transactions as the result of the consensus process.
@@ -75,7 +75,7 @@ Imagine a group of people in a room trying to agree which door they should use t
The probability of this kind of failure can be made very low, but it cannot be reduced to zero. The engineering tradeoffs are such that driving this probability down below about one in a thousand makes consensus significantly slower, and less able to tolerate network and endpoint failures.
## How the XRP Ledger Handles Consensus Failure
### How the XRP Ledger Handles Consensus Failure
After a consensus round completes, each participant applies the set of transactions that they believe were agreed to. This results in constructing what they believe the next state of the ledger should be.
@@ -95,10 +95,33 @@ Case 3 results in the network losing a few seconds in which it could have made f
On rare occasions, the network as a whole fails to make forward progress for a few seconds. In exchange, average transaction confirmation times are low.
# Philosophy
## Philosophy
One form of reliability is the ability of a system to provide results even under conditions where some components have failed, some participants are malicious, and so on. While this is important, there is another form of reliability that is much more important in cryptographic payment systems — the ability of a system to produce results that can be relied upon. That is, when a system reports a result to us as reliable, we should be able to rely on that result.
Real-world systems, however, face operational conditions in which both kinds of reliability can be compromised. These include hardware failures, communication failures, and even dishonest participants. Part of the XRP Ledger's design philosophy is to detect conditions where the reliability of results are impaired and report them, rather than providing results that must not be relied on.
The XRP Ledger's consensus algorithm provides a robust alternative to proof of work systems, without consuming computational resources needlessly. Byzantine failures are possible, and do happen, but the consequence is only minor delays. In all cases, the XRP Ledger's consensus algorithm reports results as reliable only when they in fact are.
## See Also
- **Concepts:**
- [Introduction to Consensus](intro-to-consensus.html)
- [Consensus Research](consensus-research.html)
- [Ripple Consensus Video](https://www.youtube.com/watch?v=pj1QVb1vlC0)
- **Tutorials:**
- [Reliable Transaction Submission](reliable-transaction-submission.html)
- [Run `rippled` as a Validator](run-rippled-as-a-validator.html)
- **References:**
- [Ledger Format Reference](ledger-data-formats.html)
- [Transaction Format Reference](transaction-formats.html)
- [consensus_info method][]
- [validator_list_sites method][]
- [validators method][]
- [consensus_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

29
content/concepts/consensus-network/consensus.md
View File

@@ -161,16 +161,27 @@ Best practices for applications submitting transactions include:
- Take care to use a server with a continuous ledger history to detect this case <a href="#footnote_10" id="from_footnote_10"><sup>10</sup></a>.
- It may be necessary to check the status of a transaction repeatedly until the ledger identified by `LastLedgerSequence` is validated.
## Further Resources
## See Also
- [Consensus White Paper](https://ripple.com/files/ripple_consensus_whitepaper.pdf)
- [Ledger Format Reference](ledger-data-formats.html)
- [Ripple Consensus Video](https://www.youtube.com/watch?v=pj1QVb1vlC0)
- [Reliable Transaction Submission](reliable-transaction-submission.html)
- **Concepts:**
- [Introduction to Consensus](intro-to-consensus.html)
- [Consensus Research](consensus-research.html)
- [Ripple Consensus Video](https://www.youtube.com/watch?v=pj1QVb1vlC0)
- **Tutorials:**
- [Reliable Transaction Submission](reliable-transaction-submission.html)
- [Run `rippled` as a Validator](run-rippled-as-a-validator.html)
- **References:**
- [Ledger Format Reference](ledger-data-formats.html)
- [Transaction Format Reference](transaction-formats.html)
- [consensus_info method][]
- [validator_list_sites method][]
- [validators method][]
## End Notes
## Footnotes
<a href="#from_footnote_1" id="footnote_1"><sup>1</sup></a> – Transactions with **tec** result codes do not perform the requested action, but do have effects on the ledger. To prevent abuse of the network and to pay for the cost of distributing the transaction, they destroy the XRP transaction cost. To not block other transactions submitted by the same sender around the same time, they increment the sender's account sequence number. They sometimes also perform maintenance such as deleting expired objects or unfunded trade offers.
@@ -191,3 +202,9 @@ Best practices for applications submitting transactions include:
<a href="#from_footnote_9" id="footnote_9"><sup>9</sup></a> – In practice, the XRP Ledger runs more efficiently by starting a new round of consensus concurrently, before validation has completed.
<a href="#from_footnote_10" id="footnote_10"><sup>10</sup></a> – A `rippled` server can respond to API requests even without a complete ledger history. Interruptions in service or network connectivity can lead to missing ledgers, or gaps, in the server’s ledger history. Over time, if configured to, `rippled` fills in gaps in its history. When testing for missing transactions, it is important to verify against a server with continuous complete ledgers from the time the transaction was submitted until its LastLedgerSequence. Use the RPC server_state to determine which complete_ledgers are available to a particular server.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

23
content/concepts/consensus-network/fee-voting.md
View File

@@ -38,3 +38,26 @@ The maximum possible values for the fees are limited by the internal data types
| `reference_fee` | 2**64 | (More XRP than has ever existed.) |
| `account_reserve` | 2^32 drops | Approximately 4294 XRP |
| `owner_reserve` | 2^32 drops | Approximately 4294 XRP |
## See Also
- **Concepts:**
- [Amendments](amendments.html)
- [Transaction Cost](transaction-cost.html)
- [Reserves](reserves.html)
- [Transaction Queue](transaction-queue.html)
- **Tutorials:**
- [Configure `rippled`](configure-rippled.html)
- **References:**
- [fee method][]
- [server_info method][]
- [FeeSettings object](feesettings.html)
- [SetFee pseudo-transaction][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

20
content/concepts/consensus-network/parallel-networks.md
View File

@@ -11,3 +11,23 @@ Over time, there may also be smaller, temporary test networks for specific purpo
## Parallel Networks and Consensus
There is no `rippled` setting that defines which network it uses. Instead, it uses the consensus of validators it trusts to know which ledger to accept as the truth. When different consensus groups of `rippled` instances only trust other members of the same group, each group continues as a parallel network. Even if malicious or misbehaving computers connect to both networks, the consensus process overrides the confusion as long as the members of each network are not configured to trust members of another network in excess of their quorum settings.
- **Tools:**
- [XRP Test Net Faucet](xrp-test-net-faucet.html)
- **Concepts:**
- [Introduction to Consensus](intro-to-consensus.html)
- [Amendments](amendments.html)
- **Tutorials:**
- [Connect Your `rippled` to the XRP Test Net](connect-your-rippled-to-the-xrp-test-net.html)
- [Use rippled in Stand-Alone Mode](use-stand-alone-mode.html)
- **References:**
- [server_info method][]
- [consensus_info method][]
- [validator_list_sites method][]
- [validators method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

14
content/concepts/consensus-network/transaction-malleability.md
View File

@@ -141,6 +141,20 @@ The process to exploit a vulnerable system follows a series of steps similar to
Worse, the vulnerable system might construct a new transaction to replace the transaction, picking new `Sequence`, `LastLedgerSequence`, and `Fee` parameters based on the current state of the network, but keeping the rest of the transaction the same as the original. If this new transaction is also malleable, the system could be exploited in the same way an indefinite number of times.
## See Also
- **Concepts:**
- [Transaction Basics](transaction-basics.html)
- [Finality of Results](finality-of-results.html)
- **Tutorials:**
- [Look Up Transaction Results](look-up-transaction-results.html)
- [Reliable Transaction Submission](reliable-transaction-submission.html)
- **References:**
- [Basic Data Types - Hashes](basic-data-types.html#hashes)
- [Transaction Common Fields - Global Flags](transaction-common-fields.html#global-flags)
- [Transaction Results](transaction-results.html)
- [Serialization Format](serialization.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

14
content/concepts/decentralized-exchange/autobridging.md
View File

@@ -1,13 +1,21 @@
# Auto-Bridging
Any OfferCreate that would exchange two non-XRP currencies could potentially use XRP as an intermediary currency in a synthetic order book. This is because of auto-bridging, which serves to improve liquidity across all currency pairs by using XRP as a vehicle currency. This works because of XRP's nature as a native cryptocurrency to the XRP Ledger. Offer execution can use a combination of direct and auto-bridged offers to achieve the best total exchange rate.
Any [Offer](offers.html) in the XRP Ledger's [decentralized exchange](decentralized-exchange.html) that would exchange two non-XRP currencies could potentially use [XRP](xrp.html) as an intermediary currency in a synthetic order book. This is because of _auto-bridging_, which serves to improve liquidity across all currency pairs by using XRP when doing so is cheaper than trading those currencies directly. This works because of XRP's nature as a native cryptocurrency to the XRP Ledger. Offer execution can use a combination of direct and auto-bridged offers to achieve the best total exchange rate.
Example: _Anita places an offer to sell GBP and buy BRL. She might find that this uncommon currency market has few offers. There is one offer with a good rate, but it has insufficient quantity to satisfy Anita's trade. However, both GBP and BRL have active, competitive markets to XRP. Auto-bridging software finds a way to complete Anita's offer by purchasing XRP with GBP from one trader, then selling the XRP to another trader to buy BRL. Anita automatically gets the best rate possible by combining the small offer in the direct GBP:BRL market with the better composite rates created by pairing GBP:XRP and XRP:BRL offers._
Example: _Anita places an offer to sell GBP and buy BRL. She might find that this uncommon currency market has few offers. There is one offer with a good rate, but it has insufficient quantity to satisfy Anita's trade. However, both GBP and BRL have active, competitive markets to XRP. The XRP Ledger's auto-bridging system finds a way to complete Anita's offer by purchasing XRP with GBP from one trader, then selling the XRP to another trader to buy BRL. Anita automatically gets the best rate possible by combining the small offer in the direct GBP:BRL market with the better composite rates created by pairing GBP:XRP and XRP:BRL offers._
Auto-bridging happens automatically on any OfferCreate transaction. [Payment transactions](payment.html) _do not_ autobridge by default, but path-finding can find paths that have the same effect.
Auto-bridging happens automatically on any [OfferCreate transaction][]. [Payment transactions](payment.html) _do not_ autobridge by default, but path-finding can find [paths](paths.html) that have the same effect.
## See Also
- [Dev Blog: Introducing Autobridging](https://xrpl.org/blog/2014/introducing-offer-autobridging.html)
- [Offer Preference](offers.html#offer-preference)
- [Payment Paths](paths.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

12
content/concepts/decentralized-exchange/offers.md
View File

@@ -68,6 +68,18 @@ You can determine the final disposition of an offer with an `Expiration` as soon
If an OfferCreate transaction has an `Expiration` time that has already passed when the transaction first gets included in a ledger, the transaction does not execute the offer. The result code of such a transaction depends on whether the [Checks amendment][]:not_enabled: is enabled. With the Checks amendment enabled, the transaction has the `tecEXPIRED` result code. Otherwise, the transaction has the `tesSUCCESS` transaction code. In either case, the transaction has no effect except to destroy the XRP paid as a [transaction cost](transaction-cost.html).
## See Also
- **Concepts:**
- [Issued Currencies Overview](issued-currencies-overview.html)
- [Paths](paths.html)
- **Tutorials:**
- [List Your Exchange on XRP Charts](list-your-exchange-on-xrp-charts.html) - for off-ledger exchanges
- **References:**
- [account_offers method][]
- [book_offers method][]
- [OfferCreate transaction][]
- [Offer object](offer.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

5
content/concepts/decentralized-exchange/ticksize.md
View File

@@ -13,8 +13,11 @@ When an issuer enables, disables, or changes the `TickSize`, Offers that were pl
## See Also
- [Dev Blog: Introducing the TickSize Amendment](https://xrpl.org/blog/2017/ticksize-voting.html#ticksize-amendment-overview)
- **References:**
- [AccountSet transaction][]
- [book_offers method][]
- [OfferCreate transaction][]
- [AccountSet transaction][]
<!--{# common link defs #}-->

10
content/concepts/introduction/technical-faq.md
View File

@@ -32,7 +32,9 @@ No. The XRP Ledger network is opt-in. Each participant directly or indirectly ch
#### What is the validator incentive structure for validators not run by Ripple?
If the XRP Ledger becomes successful and is widely used for interbank settlement, there will be an incentive for participants to ensure the reliability and stability of the network. If this happens, institutions will run `rippled` servers to participate in the network. Once you are running a server, the additional cost and effort to operate a validator is essentially zero—it would simply involve flipping a software switch from off to on. It is the validators who decide the evolution of the XRP Ledger, so the primary incentive to run a validator is to preserve and protect the stable operation and sensible evolution of the network.
The primary incentive to run a validator is to preserve and protect the stable operation and sensible evolution of the network. It is the validators who decide the evolution of the XRP Ledger, so any business that uses or depends on the XRP Ledger has an inherent incentive to ensure the reliability and stability of the network.
If you run an XRP Ledger server to participate in the network, the additional cost and effort to operate a validator is minimal. This means that additional incentives, such as the mining rewards in Bitcoin, are not necessary. Ripple avoids paying XRP as a reward for operating a validator so that such incentives do not warp the behavior of validators.
#### Can financial institutions set up transaction validators that will help them meet specific institutional standards and requirements?
@@ -51,7 +53,9 @@ However, there will only be one authoritative ledger version at any given time;
#### Does the XRP Ledger utilize a formal validator onboarding process?
No, a formal validator onboarding process is not compatible with the XRP Ledger, as it is a system with no central authority. Rather, Ripple provides recommendations and best practices.
No, a formal validator onboarding process is not compatible with the XRP Ledger, as it is a system with no central authority.
For recommendations and best practices, see [Run `rippled` as a Validator](run-rippled-as-a-validator.html).
## Role of XRP
@@ -91,7 +95,7 @@ You don't need to use Ripple’s version of the XRP Ledger software to interact
#### Does Ripple offer a secure method to download their software?
`rippled` source code is available at <https://github.com/ripple/rippled>, where the tip of the `master`, `release` and `develop` branches always contains a version-setting commit signed by a `rippled` developer. The XRP Ledger also offers prebuilt RPM packages for CentOS, RedHat Enterprise Linux, Fedora and Ubuntu. Those packages are digitally signed by Ripple so that they are tamper-evident and their authenticity can be verified. Lastly, release bulletins are made available over a secure website, and include the commit ID of the repository, as well as the md5sum of the RPM packages that are published.
`rippled` source code is available at <https://github.com/ripple/rippled>, where the tip of the `master`, `release` and `develop` branches always contains a version-setting commit signed by a `rippled` developer. The XRP Ledger also offers prebuilt binary packages for CentOS, RedHat Enterprise Linux, Fedora, Ubuntu, and Debian Linux. Those packages are digitally signed by Ripple so that they are tamper-evident and their authenticity can be verified. Lastly, release bulletins are made available over a secure website, and include the commit ID of the repository, as well as the cryptographic hash values of the packages that are published.
#### Does Ripple distinguish between the codebase for validation and the one for user software?

2
content/concepts/introduction/xrp-ledger-overview.md
View File

@@ -79,7 +79,7 @@ For more information, see [Cryptographic Keys](cryptographic-keys.html) and [Mul
## Modern Features for Smart Contracts
[Modern Features for Smart Contracts]: #modern-features-for-smart-contracts
Besides simple value transfer with XRP payments, the XRP Ledger has several advanced features that provide useful functions for building applications that use the Internet of Value to serve previously unknown or impractical needs. Rather than running applications as "smart contracts" in the network itself, the XRP Ledger provides tools for settling contracts, while letting the applications themselves run anywhere, in whatever environment or container is appropriate. This "keep it simple" approach is flexible, scalable, and powerful.
Besides simple value transfer with [XRP payments](direct-xrp-payments.html), the XRP Ledger has advanced features specialized for the Internet of Value. This allows applications built on XRP to provide services and functionality that would have been impractical or impossible in the past. Rather than running applications as "smart contracts" in the network itself, the XRP Ledger provides tools for settling contracts, while letting the applications themselves run anywhere, in whatever environment or container is appropriate. This "keep it simple" approach is flexible, scalable, and powerful.
A sample of advanced features in the XRP Ledger:

6
content/concepts/introduction/xrp.md
View File

@@ -31,3 +31,9 @@ Originally, the XRP Ledger was called "Ripple" for the way the technology allowe
The smallest, indivisible unit of XRP was named a "drop" [at the suggestion of Ripple forum member ThePiachu](https://forum.ripple.com/viewtopic.php?f=1&t=40&p=228). An early alternative term was a "jed", after Jed McCaleb.
## See Also
- [Send XRP (Interactive Tutorial)](send-xrp.html)
- [List XRP In Your Exchange](list-xrp-in-your-exchange.html)
- [Currency Formatting in rippled APIs](currency-formats.html#)

16
content/concepts/issued-currencies/authorized-trust-lines.md
View File

@@ -98,6 +98,22 @@ To see whether a trust line has been authorized, use the [account_lines method][
In the response's `result.lines` array, find the object whose `currency` field indicates that it represents a trust line for the currency you want. If that object has a `peer_authorized` field with the value `true`, then the issuer (the address you used as the request's `peer` field) has authorized the trust line.
## See Also
- **Concepts:**
- [Deposit Authorization](depositauth.html)
- [Freezing Issued Currencies](freezes.html)
- **Tutorials:**
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
- **References:**
- [account_lines method][]
- [account_info method][]
- [AccountSet transaction][]
- [TrustSet transaction][]
- [AccountRoot Flags](accountroot.html#accountroot-flags)
- [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

11
content/concepts/issued-currencies/freezes.md
View File

@@ -420,8 +420,15 @@ Example JavaScript (ECMAScript 6) code to check whether an address has Global Fr
# See Also
* [GB-2014-02 New Feature: Balance Freeze](https://ripple.com/files/GB-2014-02.pdf)
* [Freeze Code Samples](https://github.com/ripple/ripple-dev-portal/tree/master/content/_code-samples/freeze)
- [GB-2014-02 New Feature: Balance Freeze](https://ripple.com/files/GB-2014-02.pdf)
- [Freeze Code Samples](https://github.com/ripple/ripple-dev-portal/tree/master/content/_code-samples/freeze)
- **References:**
- [account_lines method][]
- [account_info method][]
- [AccountSet transaction][]
- [TrustSet transaction][]
- [AccountRoot Flags](accountroot.html#accountroot-flags)
- [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

23
content/concepts/issued-currencies/issued-currencies-overview.md
View File

@@ -24,4 +24,25 @@ Addresses can also [freeze](freezes.html) issued currencies, which may be useful
Issued currencies are designed to be able to represent any kind of currency or asset, including those with very small or very large nominal values. For detailed technical information on the types of currency codes and the numeric limits of issued currency representation, see the [currency format reference](currency-formats.html).
{% include '_snippets/tx-type-links.md' %}
## See Also
- **Concepts:**
- [XRP](xrp.html)
- [Cross-Currency Payments](cross-currency-payments.html)
- [Decentralized Exchange](decentralized-exchange.html)
- **Tutorials:**
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
- [Look Up Transaction Results](look-up-transaction-results.html)
- [Use Specialized Payment Types](use-specialized-payment-types.html)
- **References:**
- [Payment transaction][]
- [TrustSet transaction][]
- [RippleState object](ripplestate.html)
- [account_lines method][]
- [account_currencies method][]
- [gateway_balances method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

21
content/concepts/issued-currencies/issuing-and-operational-addresses.md
View File

@@ -50,3 +50,24 @@ As with operational addresses, a standby address must have an accounting relatio
### Standby Address Compromise
If a standby address is compromised, the consequences are like an operational address being compromised. A malicious actor can steal any balances possessed by the standby address, and the financial institution can change to a new standby address with no action from customers and partners.
## See Also
- **Concepts:**
- [Accounts](accounts.html)
- [Cryptographic Keys](cryptographic-keys.html)
- **Tutorials:**
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
- [Assign a Regular Key Pair](assign-a-regular-key-pair.html)
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
- **References:**
- [account_info method][]
- [SetRegularKey transaction][]
- [AccountRoot object](accountroot.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

17
content/concepts/issued-currencies/paths.md
View File

@@ -1,10 +1,10 @@
# Paths
In the XRP Ledger, paths define a way for payments to flow through intermediary steps on their way from sender to receiver. Paths enable cross-currency payments by connecting sender and receiver through order books. Paths also enable complex settlement of offsetting debts.
In the XRP Ledger, paths define a way for [issued currency](issued-currencies-overview.html) payments to flow through intermediary steps on their way from sender to receiver. Paths enable [cross-currency payments](cross-currency-payments.html) by connecting sender and receiver through orders in the XRP Ledger's [decentralized exchange](decentralized-exchange.html). Paths also enable complex settlement of offsetting debts.
A single Payment transaction in the XRP Ledger can use multiple paths, combining liquidity from different sources to deliver the desired amount. Thus, a transaction includes a _path set_, which is a collection of possible paths to take. The paths in a path set must start and end with the same currency.
Since XRP can be sent directly to any address, an XRP-to-XRP transaction does not use any paths.
Since XRP can be sent directly to any address, an [XRP-to-XRP transaction](direct-xrp-payments.html) does not use any paths.
## Path Steps
@@ -93,6 +93,19 @@ The `type` field, used for the binary serialization of a path set, is actually c
| 0x10 | 16 | A change of currency: the `currency` field is present. |
| 0x20 | 32 | A change of issuer: the `issuer` field is present. |
## See Also
- **Concepts:**
- [Cross-Currency Payments](cross-currency-payments.html)
- [Decentralized Exchange](decentralized-exchange.html)
- [Partial Payments](partial-payments.html)
- **References:**
- [Payment transaction][]
- [path_find method][] (WebSocket only)
- [ripple_path_find method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

17
content/concepts/issued-currencies/rippling.md
View File

@@ -2,7 +2,7 @@
In the XRP Ledger, "rippling" describes a process of atomic net settlement between multiple connected parties who have [trust lines](trust-lines-and-issuing.html) for the same currency. Rippling is an essential part of issued currencies, because it allows users who trust the same issuer to send issued balances to each other with the issuer as a passive intermediary. In a sense, rippling is like a passive, two-way [currency exchange order](offers.html) with no limit and a 1:1 exchange rate for two currencies with the same currency code but different issuers.
Rippling only occurs along the [paths](paths.html) of a payment.
Rippling only occurs along the [paths](paths.html) of a payment. [Direct XRP-to-XRP payments](direct-xrp-payments.html) do not involve rippling.
For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between issuers of the same currency. Thus, the [NoRipple Flag](#the-noripple-flag) disables rippling on incoming trust lines by default, unless the account enables rippling by default by enabling the [DefaultRipple flag](#the-defaultripple-flag).
@@ -80,6 +80,21 @@ In the [`rippled` APIs](rippled-api.html), you can use the [account_lines method
In [RippleAPI](rippleapi-reference.html), you can use the [getTrustlines](rippleapi-reference.html#gettrustlines) method to look up the trust lines associated with an address. For each trust line, the `ripplingDisabled` field shows whether the current address has enabled the NoRipple flag on that trust line, and the `counterparty.ripplingDisabled` field shows whether the counterparty has enabled the NoRipple flag.
## See Also
- **Concepts:**
- [Paths](paths.html)
- **Tutorials:**
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
- **References:**
- [account_lines method][]
- [account_info method][]
- [AccountSet transaction][]
- [TrustSet transaction][]
- [AccountRoot Flags](accountroot.html#accountroot-flags)
- [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

16
content/concepts/issued-currencies/transfer-fees.md
View File

@@ -49,6 +49,22 @@ A financial institution can submit an [AccountSet transaction][] from its [issui
You can check an account's `TransferRate` with the [account_info method][]. If the `TransferRate` is omitted, then that indicates no fee.
## See Also
- **Concepts:**
- [Fees (Disambiguation)](fees.html)
- [Transaction Cost](transaction-cost.html)
- [Paths](paths.html)
- **Tutorials:**
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
- **References:**
- [account_lines method][]
- [account_info method][]
- [AccountSet transaction][]
- [AccountRoot Flags](accountroot.html#accountroot-flags)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

13
content/concepts/issued-currencies/trust-lines-and-issuing.md
View File

@@ -18,6 +18,19 @@ A trust line with settings in the default state is equivalent to no trust line.
The default state of all trust line flags is off, except for the [NoRipple flag](rippling.html), whose default state depends on the DefaultRipple flag.
## See Also
- **Concepts:**
- [Decentralized Exchange](decentralized-exchange.html)
- [Rippling](rippling.html)
- **Tutorials:**
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
- **References:**
- [account_lines method][]
- [gateway_balances method][]
- [RippleState (trust line) object](ripplestate.html)
- [TrustSet transaction][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

17
content/concepts/payment-system-basics/accounts/accounts.md
View File

@@ -137,6 +137,23 @@ The formula for calculating an XRP Ledger address is as follows. For the complet
console.log(address);
// rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
## See Also
- **Concepts:**
- [Reserves](reserves.html)
- [Cryptographic Keys](cryptographic-keys.html)
- [Issuing and Operational Addresses](issuing-and-operational-addresses.html)
- **References:**
- [account_info method][]
- [wallet_propose method][]
- [AccountSet transaction][]
- [Payment transaction][]
- [AccountRoot object](accountroot.html)
- **Tutorials:**
- [Manage Account Settings (Category)](manage-account-settings.html)
- [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

16
content/concepts/payment-system-basics/accounts/cryptographic-keys.md
View File

@@ -113,7 +113,21 @@ The supported types of key pairs can be used interchangeably throughout the XRP
### Future Algorithms
In the future, Ripple expects to add new cryptographic signing algorithms to the XRP Ledger to keep up with developments in cryptography. For example, if it seems that quantum computers using [Shor's algorithm](https://en.wikipedia.org/wiki/Shor's_algorithm) (or something similar) will soon be practical enough to break elliptic curve cryptography, Ripple can add a cryptographic signing algorithm that isn't easily broken. As of early 2018, such "quantum-resistant" signing algorithms are relatively impractical and quantum computers are even more impractical, so Ripple has no immediate plans to add any specific algorithms.
In the future, it is likely that the XRP Ledger will need new cryptographic signing algorithms to keep up with developments in cryptography. For example, if quantum computers using [Shor's algorithm](https://en.wikipedia.org/wiki/Shor's_algorithm) (or something similar) will soon be practical enough to break elliptic curve cryptography, XRP Ledger developers can add a cryptographic signing algorithm that isn't easily broken. As of mid 2019, there's no clear first choice "quantum-resistant" signing algorithm and quantum computers are not yet practical enough to be a threat, so there are no immediate plans to add any specific algorithms. <!-- STYLE_OVERRIDE: will -->
## See Also
- **Concepts:**
- [Issuing and Operational Addresses](issuing-and-operational-addresses.html)
- **Tutorials:**
- [Assign a Regular Key Pair](assign-a-regular-key-pair.html)
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
- **References:**
- [SetRegularKey transaction][]
- [AccountRoot ledger object](accountroot.html)
- [wallet_propose method][]
- [account_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

13
content/concepts/payment-system-basics/accounts/multi-signing.md
View File

@@ -28,8 +28,19 @@ To successfully submit a multi-signed transaction, you must do all of the follow
* All fields of the transaction must be defined before collecting signatures. You cannot [auto-fill](transaction-common-fields.html#auto-fillable-fields) any fields.
* If presented in binary form, the `Signers` array must be sorted based on the numeric value of the signer addresses, with the lowest value first. (If submitted as JSON, the [submit_multisigned method][] handles this automatically.)
For more information, see [Set Up Multi-Signing](set-up-multi-signing.html).
## See Also
- **Tutorials:**
- [Set Up Multi-Signing](set-up-multi-signing.html)
- [Send a Multi-Signed Transaction](send-a-multi-signed-transaction.html)
- **Concepts:**
- [Cryptographic Keys](cryptographic-keys.html)
- [Special Transaction Cost for Multi-signed transactions](transaction-cost.html#special-transaction-costs)
- **References:**
- [SignerListSet transaction][]
- [SignerList object](signerlist.html)
- [sign_for method][]
- [submit_multisigned method][]
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

7
content/concepts/payment-system-basics/accounts/reserves.md
View File

@@ -46,6 +46,13 @@ When an address holds less XRP than its current reserve requirement, it cannot s
The XRP Ledger has a mechanism to adjust the reserve requirements for long-term changes in the value of XRP. Any changes have to be approved by the consensus process. See [Fee Voting](fee-voting.html) for more information.
## See Also
- [account_objects method][]
- [AccountRoot Object][]
- [Fee Voting](fee-voting.html)
- [SetFee pseudo-transaction][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

23
content/concepts/payment-system-basics/transaction-basics/transaction-basics.md
View File

@@ -189,6 +189,29 @@ Example response from the `tx` command:
}
```
## See Also
- **Concepts:**
- [Payment Types](payment-types.html)
- [Consensus Network](consensus-network.html)
- **Tutorials:**
- [Set Up Secure Signing](set-up-secure-signing.html)
- [Send XRP](send-xrp.html)
- [Look Up Transaction Results](look-up-transaction-results.html)
- [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html)
- [Cancel or Skip a Transaction](cancel-or-skip-a-transaction.html)
- [Reliable Transaction Submission](reliable-transaction-submission.html)
- **References:**
- [Transaction Common Fields](transaction-common-fields.html)
- [Transaction Types](transaction-types.html)
- [Transaction Metadata](transaction-metadata.html)
- [account_tx method][]
- [tx method][]
- [submit method][]
- [submit_multisigned method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

15
content/concepts/payment-system-basics/transaction-basics/transaction-cost.md
View File

@@ -151,6 +151,21 @@ When the [FeeEscalation amendment][] is enabled, `rippled` prioritizes key reset
The XRP Ledger has a mechanism for changing the minimum transaction cost to account for long-term changes in the value of XRP. Any changes have to be approved by the consensus process. See [Fee Voting](fee-voting.html) for more information.
## See Also
- **Concepts:**
- [Reserves](reserves.html)
- [Fee Voting](fee-voting.html)
- [Transaction Queue](transaction-queue.html)
- **Tutorials:**
- [Reliable Transaction Submission](reliable-transaction-submission.html)
- **References:**
- [fee method][]
- [server_info method][]
- [FeeSettings object](feesettings.html)
- [SetFee pseudo-transaction][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

2
content/concepts/payment-types/checks.md
View File

@@ -81,7 +81,7 @@ Checks require `rippled` v0.90.0 or later. As of 2018-10-11, the Checks amendmen
To check the status of an amendment on a test net or private XRP Ledger network, use the [feature method][].
## Further Reading
## See Also
For more information about Checks in the XRP Ledger, see:

3
content/concepts/payment-types/complex-payment-types.md
View File

@@ -1,3 +0,0 @@
# Complex Payment Types
In addition to simple point-to-point XRP Payments, the XRP Ledger supports a number of complex payment types for a variety of use cases and situations.

12
content/concepts/payment-types/cross-currency-payments.md
View File

@@ -19,6 +19,18 @@ Cross-currency payments that exchange two issued currencies automatically use XR
For more information, see [Autobridging](autobridging.html).
## See Also
- **Concepts:**
- [Issued Currencies](issued-currencies.html)
- [Decentralized Exchange](decentralized-exchange.html)
- [Paths](paths.html)
- **References:**
- [Payment transaction type][Payment transaction]
- [path_find method][]
- [ripple_path_find method][]
- [Interpreting Metadata of Issued Currency Payments](look-up-transaction-results.html#issued-currency-payments)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

13
content/concepts/payment-types/direct-xrp-payments.md
View File

@@ -73,10 +73,15 @@ From a relatively high level, the XRP Ledger's transaction processing engine app
## See Also
- [Payment System Basics](payment-system-basics.html)
- [Payment transaction type][Payment transaction]
- [Transaction Results](transaction-results.html)
- [Send XRP (Interactive Tutorial)](send-xrp.html)
- **Concepts:**
- [Payment System Basics](payment-system-basics.html)
- **Tutorials:**
- [Send XRP (Interactive Tutorial)](send-xrp.html)
- [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html)
- **References:**
- [Payment transaction][]
- [Transaction Results](transaction-results.html)
- [account_info method][] - for checking XRP balances
<!--{# common link defs #}-->

2
content/concepts/payment-types/escrow.md
View File

@@ -116,7 +116,7 @@ The most fundamental principle of inter-ledger payments is _conditional transfer
**Solution:** The Escrow feature makes the XRP Ledger ideal for bridging multi-hop payments using the Interledger Protocol, because it natively supports transfers that deliver XRP based on PREIMAGE-SHA-256 crypto-conditions, and it executes those transfers within seconds of being presented with the matching fulfillment.
## Further Reading
## See Also
For more information about Escrow in the XRP Ledger, see the following:

18
content/concepts/payment-types/partial-payments.md
View File

@@ -105,6 +105,24 @@ Using [the `delivered_amount` field](#the-delivered-amount-field) when processin
- Add additional sanity checks to your business logic for processing withdrawals. Never process a withdrawal if the total balance you hold in the XRP Ledger does not match your expected assets and obligations.
- Follow "Know Your Customer" guidelines and strictly verify your customers' identities. You may be able to recognize and block malicious users in advance, or pursue legal action against a malicious actor who exploits your system.
## See Also
- **Tools:**
- [Transaction Sender](tx-sender.html)
- **Concepts:**
- [Transaction Basics](transaction-basics.html)
- **Tutorials:**
- [Look Up Transaction Results](look-up-transaction-results.html)
- [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html)
- [Use Specialized Payment Types](use-specialized-payment-types.html)
- [List XRP as an Exchange](list-xrp-as-an-exchange.html)
- **References:**
- [Payment transaction][]
- [Transaction Metadata](transaction-metadata.html)
- [account_tx method][]
- [tx method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

14
content/concepts/payment-types/payment-channels.md
View File

@@ -27,9 +27,19 @@ The following diagram summarizes the lifecycle of a payment channel:
## See Also
- [Use Payment Channels](use-payment-channels.html), a tutorial stepping through the process of using a payment channel.
- **Related Concepts:**
- [Escrow](escrow.html), a similar feature for higher-value, lower-speed conditional XRP payments.
- **Tutorials and Use Cases:**
- [Use Payment Channels](use-payment-channels.html), a tutorial stepping through the process of using a payment channel.
- [Open a Payment Channel to Enable an Inter-Exchange Network](open-a-payment-channel-to-enable-an-inter-exchange-network.html)
- **References:**
- [channel_authorize method][]
- [channel_verify method][]
- [PayChannel object](paychannel.html)
- [PaymentChannelClaim transaction][]
- [PaymentChannelCreate transaction][]
- [PaymentChannelFund transaction][]
- [Escrow](escrow.html), a similar feature for higher-value, lower-speed conditional XRP payments.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

11
content/concepts/the-rippled-server/clustering.md
View File

@@ -8,7 +8,16 @@ If you are running multiple `rippled` servers in a single datacenter, you can co
If you are running a validator as a [private peer](peer-protocol.html#private-peers), Ripple recommends using a cluster of `rippled` servers as proxy servers.
For a tutorial on how to set up your servers in a cluster, see [Cluster `rippled` Servers](cluster-rippled-servers.html).
## See Also
- **Tutorials:**
- [Cluster `rippled` Servers](cluster-rippled-servers.html)
- [Run rippled as a Validator](run-rippled-as-a-validator.html)
- **References:**
- [peers method][]
- [connect method][]
- [Peer Crawler](peer-crawler.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

15
content/concepts/the-rippled-server/ledger-history/history-sharding.md
View File

@@ -26,9 +26,18 @@ The history of all ledgers is shared by servers agreeing to keep particular rang
## See Also
- [Configure History Sharding](configure-history-sharding.html)
- [download_shard method][]
- [crawl_shards method][]
- **Concepts:**
- [Ledgers](ledgers.html)
- [Introduction to Consensus](intro-to-consensus.html)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Configure `rippled`](configure-rippled.html)
- [Configure History Sharding](configure-history-sharding.html)
- **References:**
- [crawl_shards method][]
- [download_shard method][]
- [Peer Crawler](peer-crawler.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

18
content/concepts/the-rippled-server/ledger-history/ledger-history.md
View File

@@ -50,6 +50,24 @@ Online deletion **does not** delete from the shard store. However, if you config
For more information, see [Configure History Sharding](configure-history-sharding.html).
## See Also
- **Concepts:**
- [Ledgers](ledgers.html)
- [Introduction to Consensus](intro-to-consensus.html)
- **Tutorials:**
- [Configure `rippled`](configure-rippled.html)
- [Configure Online Deletion](configure-online-deletion.html)
- [Configure Advisory Deletion](configure-advisory-deletion.html)
- [Configure History Sharding](configure-history-sharding.html)
- [Configure Full History](configure-full-history.html)
- **References:**
- [ledger method][]
- [server_info method][]
- [ledger_request method][]
- [can_delete method][]
- [ledger_cleaner method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

21
content/concepts/the-rippled-server/ledger-history/online-deletion.md
View File

@@ -109,11 +109,22 @@ When it comes time for online deletion, the server first walks through the oldes
## See Also
- [Capacity Planning](capacity-planning.html)
- [can_delete method][] - API reference documentation
- [Configure Online Deletion](configure-online-deletion.html)
- [Configure Advisory Deletion](configure-advisory-deletion.html)
- [Configure Full History](configure-full-history.html)
- **Concepts:**
- [Ledgers](ledgers.html)
- [Introduction to Consensus](intro-to-consensus.html)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Configure `rippled`](configure-rippled.html)
- [Configure Online Deletion](configure-online-deletion.html)
- [Configure Advisory Deletion](configure-advisory-deletion.html)
- [Configure History Sharding](configure-history-sharding.html)
- [Configure Full History](configure-full-history.html)
- **References:**
- [ledger method][]
- [server_info method][]
- [ledger_request method][]
- [can_delete method][]
- [ledger_cleaner method][]
<!--{# common link defs #}-->

14
content/concepts/the-rippled-server/peer-protocol.md
View File

@@ -69,6 +69,20 @@ Example configuration:
```
## See Also
- **Concepts:**
- [Consensus](consensus.html)
- [Parallel Networks](parallel-networks.html)
- **Tutorials:**
- [Configure the Peer Crawler](configure-the-peer-crawler.html)
- **References:**
- [peers method][]
- [connect method][]
- [fetch_info method][]
- [Peer Crawler](peer-crawler.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

17
content/concepts/the-rippled-server/rippled-server-modes.md
View File

@@ -60,8 +60,23 @@ When you run `rippled` in stand-alone mode, you have to tell it what ledger vers
**Caution:** In stand-alone mode, you must [manually advance the ledger](advance-the-ledger-in-stand-alone-mode.html).
## See Also
- [Commandline Usage Reference](commandline-usage.html) - Detailed information on command-line options for all `rippled` server modes.
- **References:**
- [Commandline Usage Reference](commandline-usage.html) - Detailed information on command-line options for all `rippled` server modes.
- [ledger_accept method][] - Manually advance the ledger in stand-alone mode.
- [feature method][] - Check [amendments](amendments.html) currently known and enabled.
- **Tutorials:**
- [Configure `rippled`](configure-rippled.html)
- [Run `rippled` as a Validator](run-rippled-as-a-validator.html)
- [Use rippled in Stand-Alone Mode](use-stand-alone-mode.html):
- [Start a New Genesis Ledger in Stand-Alone Mode](start-a-new-genesis-ledger-in-stand-alone-mode.html)
- [Load a Saved Ledger in Stand-Alone Mode](load-a-saved-ledger-in-stand-alone-mode.html)
- [Advance the Ledger in Stand-Alone Mode](advance-the-ledger-in-stand-alone-mode.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

11
content/concepts/the-rippled-server/transaction-censorship-detection.md
View File

@@ -57,5 +57,16 @@ Here are some scenarios that could cause the detector to issue false positive me
Currently, there are no known bugs that cause this unexpected behavior. However, if you see the impact of what you suspect is a bug, consider reporting it to the [Ripple Bug Bounty](https://ripple.com/bug-bounty/) program.
## See Also
- **Concepts:**
- [Consensus Principles and Rules](consensus-principles-and-rules.html)
- [Transaction Queue](transaction-queue.html)
- **Tutorials:**
- [Reliable Transaction Submission](reliable-transaction-submission.html)
- [Understanding Log Messages](understanding-log-messages.html)
- **References:**
- [Transaction Results](transaction-results.html)
{% include '_snippets/rippled_versions.md' %}