mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 11:45:50 +00:00
drop concept prefix; referencify paychan tut links
This commit is contained in:
mDuo13
@@ -4,7 +4,7 @@ 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 receiver 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 receiver 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](concept-escrow.html) and [Payment Channels](tutorial-paychan.html), but there are some important differences between those features and Checks:
|
||||
Checks are similar to [Escrow](escrow.html) and [Payment Channels](tutorial-paychan.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.
|
||||
|
||||
@@ -29,7 +29,7 @@ Checks potentially enable many other use cases. Ripple encourages the community
|
||||
|
||||
**Problem:** To comply with regulations like [BSA, KYC, AML, and CFT](tutorial-gateway-guide.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.
|
||||
|
||||
**Solution:** Institutions can enable [Deposit Authorization](concept-depositauth.html) on their XRP Ledger accounts by [setting the `asfDepositAuth` flag in an `AccountSet` transaction](reference-transaction-format.html#accountset-flags). 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.
|
||||
**Solution:** Institutions can enable [Deposit Authorization](depositauth.html) on their XRP Ledger accounts by [setting the `asfDepositAuth` flag in an `AccountSet` transaction](reference-transaction-format.html#accountset-flags). 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.
|
||||
|
||||
|
||||
## Usage
|
||||
@@ -48,7 +48,7 @@ Checks typically have the lifecycle described below.
|
||||
|
||||
**Step 3:** To cash the check, the receiver submits a [CheckCash][] transaction. The receiver has two options for cashing the check:
|
||||
|
||||
* `Amount` — The receiver 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](concept-transfer-fees.html) and the receiver can only accept the exact amount on an invoice or other contract.
|
||||
* `Amount` — The receiver 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 receiver can only accept the exact amount on an invoice or other contract.
|
||||
|
||||
* `DeliverMin` — The receiver can use this option to specify the minimum amount they are willing to receive from the Check. If the receiver uses this option, `rippled` 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 receiver is not at least this amount.
|
||||
|
||||
@@ -76,7 +76,7 @@ All Checks start the same way, so **Steps 1 and 2** are the same.
|
||||
|
||||
## Availability of Checks
|
||||
|
||||
Checks require `rippled` v0.90.0 or later. The Checks amendment gained support of a majority of validators on the production XRP Ledger on 2018-03-22 in this [EnableAmendment pseudo-transaction](https://ripple.com/build/transactions/#enableamendment): [`EC0D90F114D4F3C599FEABCAF47DCF0CAC29A272D1EF6C9BEF7F420819540F04`](https://xrpcharts.ripple.com/#/transactions/EC0D90F114D4F3C599FEABCAF47DCF0CAC29A272D1EF6C9BEF7F420819540F04). For more information about how amendments are enabled and voted on, see [Amendment Process](concept-amendments.html#amendment-process).
|
||||
Checks require `rippled` v0.90.0 or later. The Checks amendment gained support of a majority of validators on the production XRP Ledger on 2018-03-22 in this [EnableAmendment pseudo-transaction](https://ripple.com/build/transactions/#enableamendment): [`EC0D90F114D4F3C599FEABCAF47DCF0CAC29A272D1EF6C9BEF7F420819540F04`](https://xrpcharts.ripple.com/#/transactions/EC0D90F114D4F3C599FEABCAF47DCF0CAC29A272D1EF6C9BEF7F420819540F04). For more information about how amendments are enabled and voted on, see [Amendment Process](amendments.html#amendment-process).
|
||||
|
||||
<!-- {***TODO:*** update this with the...other pseudo-transaction that will enable this amendment after two weeks with majority support? } -->
|
||||
|
||||
@@ -103,8 +103,8 @@ For more information about Checks in the XRP Ledger, see:
|
||||
|
||||
For more information about related features, see:
|
||||
|
||||
* [Deposit Authorization](concept-depositauth.html)
|
||||
* [Escrow](concept-escrow.html)
|
||||
* [Deposit Authorization](depositauth.html)
|
||||
* [Escrow](escrow.html)
|
||||
* [Payment Channels Tutorial](tutorial-paychan.html)
|
||||
|
||||
|
||||
|
||||
@@ -31,7 +31,7 @@ All escrows start the same way, so **Steps 1 and 2** are the same as in the succ
|
||||
Escrow is designed as a feature to enable the XRP Ledger to be used in the [Interledger Protocol][] and with other smart contracts. The current version has a modest scope to avoid complexity.
|
||||
|
||||
- Escrow only works with XRP, not issued currencies.
|
||||
- Escrow requires sending at least two transactions: one to create the escrow, and one to finish or cancel it. Thus, it may not be financially sensible to escrow payments for very small amounts, because the participants must destroy the [transaction cost](concept-transaction-cost.html) of the two transactions.
|
||||
- Escrow requires sending at least two transactions: one to create the escrow, and one to finish or cancel it. Thus, it may not be financially sensible to escrow payments for very small amounts, because the participants must destroy the [transaction cost](transaction-cost.html) of the two transactions.
|
||||
- When using Crypto-Conditions, the [cost of the transaction to finish the escrow](#escrowfinish-transaction-cost) is higher than usual.
|
||||
- All escrows must have a "finish-after" time, an expiration time, or both. Neither time can be in the past when the transaction to create the escrow executes.
|
||||
- Timed releases and expirations are limited to the resolution of XRP Ledger closes. This means that, in practice, times may be rounded to approximately 5 second intervals, depending on exactly when the ledgers close.
|
||||
@@ -43,7 +43,7 @@ Escrow provides strong guarantees that are best suited for high-value, low-quant
|
||||
|
||||
Conditional payments have been enabled by the ["Escrow" Amendment](reference-amendments.html#escrow) to the XRP Ledger Consensus Protocol since 2017-03-31. A previous version of the same functionality was available on the [Ripple Test Net](https://ripple.com/build/ripple-test-net/) by the name "Suspended Payments" (SusPay) in 2016.
|
||||
|
||||
When testing in [stand-alone mode](concept-stand-alone-mode.html), you can force the Escrow feature to be enabled locally regardless of the amendment status. Add the following stanza to your `rippled.cfg`:
|
||||
When testing in [stand-alone mode](stand-alone-mode.html), you can force the Escrow feature to be enabled locally regardless of the amendment status. Add the following stanza to your `rippled.cfg`:
|
||||
|
||||
[features]
|
||||
Escrow
|
||||
@@ -52,15 +52,15 @@ You can check the status of the Escrow amendment using the [feature method][].
|
||||
|
||||
## EscrowFinish Transaction Cost
|
||||
|
||||
When using [crypto-conditions][], the EscrowFinish transaction must pay a [higher transaction cost](concept-transaction-cost.html#special-transaction-costs) because of the higher processing load involved in verifying the crypto-condition fulfillment.
|
||||
When using [crypto-conditions][], the EscrowFinish transaction must pay a [higher transaction cost](transaction-cost.html#special-transaction-costs) because of the higher processing load involved in verifying the crypto-condition fulfillment.
|
||||
|
||||
If the escrow is purely time-locked with no crypto-condition, the EscrowFinish costs only the standard [transaction cost](concept-transaction-cost.html) for a reference transaction.
|
||||
If the escrow is purely time-locked with no crypto-condition, the EscrowFinish costs only the standard [transaction cost](transaction-cost.html) for a reference transaction.
|
||||
|
||||
The additional transaction cost required is proportional to the size of the fulfillment. Currently, an EscrowFinish with a fulfillment requires a minimum transaction cost of **330 [drops of XRP](reference-rippled.html#specifying-currency-amounts) plus 10 drops per 16 bytes in the size of the fulfillment**. If the transaction is [multi-signed](reference-transaction-format.html#multi-signing), the cost of multi-signing is added to the cost of the fulfillment.
|
||||
|
||||
**Note:** The above formula is based on the assumption that the reference cost of a transaction is 10 drops of XRP.
|
||||
|
||||
If [Fee Voting](concept-fee-voting.html) changes the `reference_fee` value, the formula scales based on the new reference cost. The generalized formula for an EscrowFinish transaction with a fulfillment is as follows:
|
||||
If [Fee Voting](fee-voting.html) changes the `reference_fee` value, the formula scales based on the new reference cost. The generalized formula for an EscrowFinish transaction with a fulfillment is as follows:
|
||||
|
||||
```
|
||||
reference_fee * (signer_count + 33 + (fulfillment_bytes / 16))
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Partial Payments
|
||||
|
||||
In the default case, the `Amount` field of a [Payment transaction][] in the XRP Ledger specifies the exact amount to deliver, after charging for exchange rates and [transfer fees](concept-transfer-fees.html). The "Partial Payment" flag ([**tfPartialPayment**](reference-transaction-format.html#payment-flags)) allows a payment to succeed by reducing the amount received instead of increasing the amount sent. Partial payments are useful for [returning payments](tutorial-gateway-guide.html#bouncing-payments) without incurring additional costs to oneself.
|
||||
In the default case, the `Amount` field of a [Payment transaction][] in the XRP Ledger specifies the exact amount to deliver, after charging for exchange rates and [transfer fees](transfer-fees.html). The "Partial Payment" flag ([**tfPartialPayment**](reference-transaction-format.html#payment-flags)) allows a payment to succeed by reducing the amount received instead of increasing the amount sent. Partial payments are useful for [returning payments](tutorial-gateway-guide.html#bouncing-payments) without incurring additional costs to oneself.
|
||||
|
||||
The amount of XRP used for the [transaction cost](concept-transaction-cost.html) is always deducted from the sender’s account, regardless of the type of transaction.
|
||||
The amount of XRP used for the [transaction cost](transaction-cost.html) is always deducted from the sender’s account, regardless of the type of transaction.
|
||||
|
||||
Partial payments can be used to exploit naive integrations with the XRP Ledger to steal money from exchanges and gateways. The [Partial Payments Exploit](#partial-payments-exploit) section of this document describes how this exploit works and how you can avoid it.
|
||||
|
||||
@@ -16,9 +16,9 @@ In other words:
|
||||
|
||||
Amount + (fees) = (sent amount) ≤ SendMax
|
||||
|
||||
In this formula, "fees" refers to [transfer fees](concept-transfer-fees.html) and currency exchange rates. The "sent amount" and the delivered amount (`Amount`) may be denominated in different currencies and converted by consuming Offers in the XRP Ledger's decentralized exchange.
|
||||
In this formula, "fees" refers to [transfer fees](transfer-fees.html) and currency exchange rates. The "sent amount" and the delivered amount (`Amount`) may be denominated in different currencies and converted by consuming Offers in the XRP Ledger's decentralized exchange.
|
||||
|
||||
**Note:** The `Fee` field of the transaction refers to the XRP [transaction cost](concept-transaction-cost.html), which is destroyed to relay the transaction to the network. The exact transaction cost specified is always debited from the sender and is completely separate from the fee calculations for any type of payment.
|
||||
**Note:** The `Fee` field of the transaction refers to the XRP [transaction cost](transaction-cost.html), which is destroyed to relay the transaction to the network. The exact transaction cost specified is always debited from the sender and is completely separate from the fee calculations for any type of payment.
|
||||
|
||||
### With Partial Payments
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ Amendments solve this problem, so that new features can be enabled only when eno
|
||||
|
||||
Users and businesses who rely on the XRP Ledger can also use Amendments to provide advance notice of changes in transaction processing that might affect their business. However, API changes that do not impact transaction processing or [the consensus process][] do not need Amendments.
|
||||
|
||||
[the consensus process]: concept-consensus.html
|
||||
[the consensus process]: consensus.html
|
||||
|
||||
|
||||
## About Amendments
|
||||
@@ -30,7 +30,7 @@ By convention, Ripple's developers use the SHA-512Half hash of the amendment nam
|
||||
|
||||
## Amendment Process
|
||||
|
||||
Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger. When `rippled` validator servers send validation messages for that ledger, those servers also submit votes in favor of specific amendments. If a validator does not vote in favor of an amendment, that is the same as voting against the amendment. ([Fee Voting](concept-fee-voting.html) also occurs around flag ledgers.)
|
||||
Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger. When `rippled` validator servers send validation messages for that ledger, those servers also submit votes in favor of specific amendments. If a validator does not vote in favor of an amendment, that is the same as voting against the amendment. ([Fee Voting](fee-voting.html) also occurs around flag ledgers.)
|
||||
|
||||
The flag ledger itself has no special contents. However, during that time, the servers look at the votes of the validators they trust, and decide whether to insert an [`EnableAmendment` pseudo-transaction](reference-transaction-format.html#enableamendment) into the following ledger. The flags of an EnableAmendment pseudo-transaction show what the server thinks happened:
|
||||
|
||||
@@ -221,7 +221,7 @@ To look up which `rippled` version supports these features, see [Known Amendment
|
||||
|
||||
If you want to see how `rippled` behaves with an amendment enabled, before that amendment gets enabled on the production network, you can run use `rippled`'s configuration file to forcibly enable a feature. This is intended for development purposes only.
|
||||
|
||||
Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run `rippled` in [Stand-Alone Mode](concept-stand-alone-mode.html).
|
||||
Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run `rippled` in [Stand-Alone Mode](stand-alone-mode.html).
|
||||
|
||||
To forcibly enable a feature, add a `[features]` stanza to your `rippled.cfg` file. In this stanza, add the short names of the features to enable, one per line. For example:
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Fee Voting
|
||||
|
||||
Validators can vote for changes to basic [transaction cost](concept-transaction-cost.html) as well as [reserve requirements](concept-reserves.html). If the preferences in a validator's configuration are different than the network's current settings, the validator expresses its preferences to the network periodically. If a quorum of validators agrees on a change, they can apply a change that takes effect thereafter. Validators may do this for various reasons, especially to adjust to long-term changes in the value of XRP.
|
||||
Validators can vote for changes to basic [transaction cost](transaction-cost.html) as well as [reserve requirements](reserves.html). If the preferences in a validator's configuration are different than the network's current settings, the validator expresses its preferences to the network periodically. If a quorum of validators agrees on a change, they can apply a change that takes effect thereafter. Validators may do this for various reasons, especially to adjust to long-term changes in the value of XRP.
|
||||
|
||||
Operators of [`rippled` validators](tutorial-rippled-setup.html#running-a-validator) can set their preferences for the transaction cost and reserve requirements in the `[voting]` stanza of the `rippled.cfg` file.
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ It is possible for an offer to become temporarily or permanently _unfunded_:
|
||||
|
||||
* If the creator no longer has any of the `TakerGets` currency.
|
||||
* The offer becomes funded again when the creator obtains more of that currency.
|
||||
* If the currency required to fund the offer is held in a [frozen trust line](concept-freeze.html).
|
||||
* If the currency required to fund the offer is held in a [frozen trust line](freeze.html).
|
||||
* The offer becomes funded again when the trust line is no longer frozen.
|
||||
* If the creator does not have enough XRP for the reserve amount of a new trust line required by the offer. (See [Offers and Trust](#offers-and-trust).)
|
||||
* The offer becomes funded again when the creator obtains more XRP, or the reserve requirements decrease.
|
||||
@@ -44,7 +44,7 @@ A client application can locally track the funding status of offers. To do this,
|
||||
|
||||
The limit values of trust lines (See [TrustSet](#trustset)) do not affect offers. In other words, you can use an offer to acquire more than the maximum amount you trust an issuer to redeem.
|
||||
|
||||
However, holding non-XRP balances still requires a trust line to the address issuing those balances. When an offer is taken, it automatically creates any necessary trust lines, setting their limits to 0. Because [trust lines increase the reserve an account must hold](concept-reserves.html), any offers that would require a new trust line also require the address to have enough XRP to meet the reserve for that trust line.
|
||||
However, holding non-XRP balances still requires a trust line to the address issuing those balances. When an offer is taken, it automatically creates any necessary trust lines, setting their limits to 0. Because [trust lines increase the reserve an account must hold](reserves.html), any offers that would require a new trust line also require the address to have enough XRP to meet the reserve for that trust line.
|
||||
|
||||
A trust line indicates an issuer you trust enough to accept their issuances as payment, within limits. Offers are explicit instructions to acquire certain issuances, so they are allowed to go beyond those limits.
|
||||
|
||||
@@ -64,7 +64,7 @@ You can determine the final disposition of an offer with an `Expiration` as soon
|
||||
|
||||
**Note:** Since only new transactions can modify the ledger, an expired offer can stay on the ledger after it becomes inactive. The offer is treated as unfunded and has no effect, but it can continue to appear in results (for example, from the [ledger_entry](reference-rippled.html#ledger-entry) command). Later on, the expired offer can get finally deleted as a result of another transaction (such as another OfferCreate) if the server finds it while processing.
|
||||
|
||||
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](reference-amendments.html#checks) 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](concept-transaction-cost.html).
|
||||
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](reference-amendments.html#checks) 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).
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
|
||||
@@ -12,10 +12,10 @@ When building applications on the XRP Ledger, it is important to understand this
|
||||
|
||||
The peer-to-peer XRP Ledger network provides a worldwide, shared ledger, which gives applications authoritative information about the state of its contents. This state information includes:
|
||||
|
||||
- settings for each [account](concept-accounts.html)
|
||||
- settings for each [account](accounts.html)
|
||||
- balances between accounts (trust lines)
|
||||
- offers in the distributed exchange
|
||||
- network settings, such as [transaction costs](concept-transaction-cost.html) and [reserve](concept-reserves.html) amounts
|
||||
- network settings, such as [transaction costs](transaction-cost.html) and [reserve](reserves.html) amounts
|
||||
- a time stamp
|
||||
|
||||
For a full, technical description of which data is included in a ledger version, see the [Ledger Format Reference](reference-ledger-format.html).
|
||||
@@ -102,7 +102,7 @@ Nodes of the network recognize a ledger instance as validated when a supermajori
|
||||
|
||||
In cases where a node is in the minority, having computed a ledger that differs from its peers, the node disregards the ledger it computed <a href="#footnote_9" id="footnote_from_9"><sup>9</sup></a>. It recomputes the correct ledger, or retrieves the correct ledger as needed.
|
||||
|
||||
If the network fails to achieve supermajority agreement on validations, this implies that transaction volume was too high or network latency too great for the consensus process to produce consistent proposals. In this case, the nodes repeat the consensus process. As time passes since consensus began, it becomes increasingly likely that a majority of the nodes have received the same set of candidate transactions, as each consensus round reduces disagreement. The XRP Ledger dynamically adjusts [transaction costs](concept-transaction-cost.html) and the time to wait for consensus in response to these conditions.
|
||||
If the network fails to achieve supermajority agreement on validations, this implies that transaction volume was too high or network latency too great for the consensus process to produce consistent proposals. In this case, the nodes repeat the consensus process. As time passes since consensus began, it becomes increasingly likely that a majority of the nodes have received the same set of candidate transactions, as each consensus round reduces disagreement. The XRP Ledger dynamically adjusts [transaction costs](transaction-cost.html) and the time to wait for consensus in response to these conditions.
|
||||
|
||||
[](img/consensus-validated-ledger.png)
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ This combines qualities of physical and centralized digital money. Prior to the
|
||||
- **Physical coins and paper money**, which individuals can use to do business without going through a central party. As physical objects, they cannot be used online, and doing business long-distance is slow and inconvenient.
|
||||
- **Centralized digital currencies**, which need an administrator to confirm transactions. The administrator also has the power to censor or roll back transactions, or disallow some individuals from using the digital currency. If the operator of a digital currency decides someone has violated its terms of service, it can freeze or even confiscate that person's money. However, as digital balances, these currencies can be used online and are convenient across long distances.
|
||||
|
||||
**Note:** Users of the XRP Ledger _can_ freeze non-XRP currencies issued in the XRP Ledger. For more information, see the [Freeze documentation](concept-freeze.html).
|
||||
**Note:** Users of the XRP Ledger _can_ freeze non-XRP currencies issued in the XRP Ledger. For more information, see the [Freeze documentation](freeze.html).
|
||||
|
||||
The XRP Ledger's system of trusted validators uses a small amount of human interaction to achieve better distribution of authority than other decentralized systems. Fully-automated systems for reaching consensus from an unknown set of participants are vulnerable to concentrations of voting power. For example, Bitcoin mining is disproportionately concentrated in places with cheap electricity. As Ripple curates a list of distinct validators operated by different entities in different jurisdictions, the XRP Ledger can become more resistant to censorship and outside pressures than proof-of-work mining. For more information on Ripple's plan to decentralize the recommended set of validators, see the [Decentralization Strategy Update](https://ripple.com/dev-blog/decentralization-strategy-update/).
|
||||
|
||||
@@ -38,7 +38,7 @@ The XRP Ledger's biggest difference from most cryptocurrencies is that it uses a
|
||||
|
||||
Furthermore, each new "ledger version" in the XRP Ledger (the equivalent of a "block") contains the full current state of all balances, so a server can synchronize with the network in minutes instead of spending hours downloading and re-processing the full transaction history.
|
||||
|
||||
For more information on how the XRP Ledger's consensus algorithm works, see [The XRP Ledger Consensus Process](concept-consensus.html). For background on why the XRP Ledger uses this consensus algorithm, see [Reaching Consensus In the XRP Ledger](concept-reaching-consensus.html).
|
||||
For more information on how the XRP Ledger's consensus algorithm works, see [The XRP Ledger Consensus Process](consensus.html). For background on why the XRP Ledger uses this consensus algorithm, see [Reaching Consensus In the XRP Ledger](reaching-consensus.html).
|
||||
|
||||
|
||||
## Finite XRP Supply
|
||||
@@ -48,9 +48,9 @@ Alongside war and political turmoil, hyperinflation is one of the leading causes
|
||||
|
||||
The supply of XRP available to the general public _does_ change due to a few factors:
|
||||
|
||||
- Sending transactions in the XRP Ledger destroys a small amount of XRP. Senders choose how much to destroy, with certain minimums based on the expected work of processing the transaction and how busy the network is. If the network is busy, potential transactions that promise to destroy more XRP can cut in front of the transaction queue. This is an anti-spam measure to make it prohibitively expensive to [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) the XRP Ledger network. For more information, see [Transaction Cost](concept-transaction-cost.html).
|
||||
- Sending transactions in the XRP Ledger destroys a small amount of XRP. Senders choose how much to destroy, with certain minimums based on the expected work of processing the transaction and how busy the network is. If the network is busy, potential transactions that promise to destroy more XRP can cut in front of the transaction queue. This is an anti-spam measure to make it prohibitively expensive to [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) the XRP Ledger network. For more information, see [Transaction Cost](transaction-cost.html).
|
||||
- Each account in the XRP Ledger must hold a small amount of XRP in reserve. This is an anti-spam measure to disincentivize making the ledger data occupy too much space. XRP Ledger validators can vote to change the amount of XRP required as a reserve, to compensate for changes in XRP's real-world value. (The last time this happened was in December 2013, when [the reserve requirement decreased from 50 XRP to 20 XRP](https://ripple.com/insights/proposed-change-to-ripple-reserve-requirement-2/).) If the reserve requirement decreases, XRP that was previously locked up by the reserve becomes available again.
|
||||
- Ripple (the company) holds a large reserve of XRP in escrow. At the start of each month, 1 billion XRP is released from escrow for Ripple to use. (Ripple uses XRP to incentivize growth in the XRP Ledger ecosystem and sells XRP to institutional investors.) At the end of each month, any remaining XRP the company does not sell or give away is stored into escrow for a 54-month period. For more information on Ripple's escrow policy, see [Ripple Escrows 55 Billion XRP for Supply Predictability](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/). For more information on the technical capabilities of the Escrow feature, see [Escrow](concept-escrow.html).
|
||||
- Ripple (the company) holds a large reserve of XRP in escrow. At the start of each month, 1 billion XRP is released from escrow for Ripple to use. (Ripple uses XRP to incentivize growth in the XRP Ledger ecosystem and sells XRP to institutional investors.) At the end of each month, any remaining XRP the company does not sell or give away is stored into escrow for a 54-month period. For more information on Ripple's escrow policy, see [Ripple Escrows 55 Billion XRP for Supply Predictability](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/). For more information on the technical capabilities of the Escrow feature, see [Escrow](escrow.html).
|
||||
|
||||
|
||||
## Responsible Software Governance
|
||||
@@ -71,7 +71,7 @@ As an entity that is obligated to hold large amounts of XRP for the long term, R
|
||||
|
||||
Cryptography is one of the hardest parts of any distributed system, and a mistake can lead to money stolen by malicious actors anywhere in the world. The XRP Ledger uses industry-standard schemes for signing and verifying transactions, algorithms that have successfully protected hundreds of billions of US dollars' worth of value for many years. The XRP Ledger also layers multi-signing functionality so you can use multi-factor authorization or split keys across multiple people as a backup, and provides new algorithms with a path to migrate the keys you use if a breakthrough in cryptography makes the old algorithms obsolete.
|
||||
|
||||
For more information, see [Cryptographic Keys](concept-cryptographic-keys.html) and [Multi-signing](reference-transaction-format.html#multi-signing).
|
||||
For more information, see [Cryptographic Keys](cryptographic-keys.html) and [Multi-signing](reference-transaction-format.html#multi-signing).
|
||||
|
||||
|
||||
## Modern Features for Smart Contracts
|
||||
@@ -82,11 +82,11 @@ Besides simple value transfer with XRP payments, the XRP Ledger has several adva
|
||||
A sample of advanced features in the XRP Ledger:
|
||||
|
||||
- [Payment Channels](tutorial-paychan.html) allow asynchronous balance changes as fast as you can create and validate signatures.
|
||||
- [Escrow](concept-escrow.html) locks up XRP until a declared time passes or cryptographic condition is met.
|
||||
- [DepositAuth](concept-depositauth.html) lets users decide who can send them money and who can't.
|
||||
- [Escrow](escrow.html) locks up XRP until a declared time passes or cryptographic condition is met.
|
||||
- [DepositAuth](depositauth.html) lets users decide who can send them money and who can't.
|
||||
- A [Decentralized Exchange](#on-ledger-decentralized-exchange) lets users trade obligations and XRP on-ledger.
|
||||
- [Invariant Checking](https://ripple.com/dev-blog/protecting-ledger-invariant-checking/) provides an independent layer of protections against bugs in transaction execution.
|
||||
- [Amendments](concept-amendments.html) provide smooth upgrades to the existing feature set, so the technology can continue to evolve without fracturing the ecosystem or causing uncertainty around times of transition.
|
||||
- [Amendments](amendments.html) provide smooth upgrades to the existing feature set, so the technology can continue to evolve without fracturing the ecosystem or causing uncertainty around times of transition.
|
||||
|
||||
|
||||
## On-Ledger Decentralized Exchange
|
||||
@@ -94,4 +94,4 @@ A sample of advanced features in the XRP Ledger:
|
||||
|
||||
One of the biggest features that sets the XRP Ledger apart from other cryptocurrency networks is that it also contains a full currency exchange that runs on the XRP Ledger. Within this system, businesses (typically called "gateways") can freely issue any currency they want to customers, and those customers can freely trade issued currencies for XRP or other issued currencies issued by any gateway. The XRP Ledger can execute atomic cross-currency transactions this way, using orders in the exchange to provide liquidity.
|
||||
|
||||
For more information on how the decentralized exchange works, see [Money in the XRP Ledger](concept-money.html) and [Lifecycle of an Offer](reference-transaction-format.html#lifecycle-of-an-offer). For more information on the gateway business model, see the [Gateway Guide](tutorial-gateway-guide.html).
|
||||
For more information on how the decentralized exchange works, see [Money in the XRP Ledger](money.html) and [Lifecycle of an Offer](reference-transaction-format.html#lifecycle-of-an-offer). For more information on the gateway business model, see the [Gateway Guide](tutorial-gateway-guide.html).
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
# XRP
|
||||
|
||||
**XRP** is the native cryptocurrency of the XRP Ledger. All [accounts](concept-accounts.html) in the XRP Ledger can send XRP among one another and must hold a minimum amount of XRP as a [reserve](concept-reserves.html). XRP can be sent directly from any XRP Ledger address to any other, without needing a gateway or liquidity provider. This helps make XRP a convenient bridge currency.
|
||||
**XRP** is the native cryptocurrency of the XRP Ledger. All [accounts](accounts.html) in the XRP Ledger can send XRP among one another and must hold a minimum amount of XRP as a [reserve](reserves.html). XRP can be sent directly from any XRP Ledger address to any other, without needing a gateway or liquidity provider. This helps make XRP a convenient bridge currency.
|
||||
|
||||
Some advanced features of the XRP Ledger, such as [Escrow](concept-escrow.html) and [Payment Channels](tutorial-paychan.html), only work with XRP. Order book [autobridging](https://ripple.com/dev-blog/introducing-offer-autobridging/) uses XRP to deepen liquidity in the decentralized exchange by merging order books of two issued currencies with XRP order books to create synthetic combined order books. (For example, autobridging matches USD:XRP and XRP:EUR orders to augment USD:EUR order books.)
|
||||
Some advanced features of the XRP Ledger, such as [Escrow](escrow.html) and [Payment Channels](tutorial-paychan.html), only work with XRP. Order book [autobridging](https://ripple.com/dev-blog/introducing-offer-autobridging/) uses XRP to deepen liquidity in the decentralized exchange by merging order books of two issued currencies with XRP order books to create synthetic combined order books. (For example, autobridging matches USD:XRP and XRP:EUR orders to augment USD:EUR order books.)
|
||||
|
||||
XRP also serves as a protective measure against spamming the network. All XRP Ledger addresses need a small amount of XRP to pay the costs of maintaining the XRP Ledger. The [transaction cost](concept-transaction-cost.html) and [reserve](concept-reserves.html) are neutral fees denominated in XRP and not paid to any party. In the ledger's data format, XRP is stored in [AccountRoot objects](reference-ledger-format.html#accountroot).
|
||||
XRP also serves as a protective measure against spamming the network. All XRP Ledger addresses need a small amount of XRP to pay the costs of maintaining the XRP Ledger. The [transaction cost](transaction-cost.html) and [reserve](reserves.html) are neutral fees denominated in XRP and not paid to any party. In the ledger's data format, XRP is stored in [AccountRoot objects](reference-ledger-format.html#accountroot).
|
||||
|
||||
For more information on XRP's use cases, benefits, and news, see the [XRP Portal](https://ripple.com/xrp-portal/).
|
||||
|
||||
## XRP Properties
|
||||
|
||||
The very first ledger contained 100 billion XRP, and no new XRP can be created. XRP can be destroyed by [transaction costs](concept-transaction-cost.html) or lost by sending it to addresses for which no one holds a key, so XRP is slightly [deflationary](https://en.wikipedia.org/wiki/Deflation) by nature. No need to worry about running out, though: at the current rate of destruction, it would take at least 70,000 years to destroy all XRP, and XRP [prices and fees can be adjusted](concept-fee-voting.html) as the total supply of XRP changes.
|
||||
The very first ledger contained 100 billion XRP, and no new XRP can be created. XRP can be destroyed by [transaction costs](transaction-cost.html) or lost by sending it to addresses for which no one holds a key, so XRP is slightly [deflationary](https://en.wikipedia.org/wiki/Deflation) by nature. No need to worry about running out, though: at the current rate of destruction, it would take at least 70,000 years to destroy all XRP, and XRP [prices and fees can be adjusted](fee-voting.html) as the total supply of XRP changes.
|
||||
|
||||
In technical contexts, XRP is measured precisely to the nearest 0.000001 XRP, called a "drop" of XRP. The [`rippled` APIs](reference-rippled.html) require all XRP amounts to be specified in drops of XRP. For example, 1 XRP is represented as `1000000` drops. For more detailed information, see the [currency format reference](reference-currency.html).
|
||||
|
||||
@@ -16,7 +16,7 @@ The transaction to authorize a trust line must be signed by the issuing address,
|
||||
|
||||
The `RequireAuth` setting (`requireAuthorization` in [RippleAPI](reference-rippleapi.html)) prevents all counterparties from holding balances issued by an address unless the issuing address has specifically approved a trust line with that counterparty for the currency in question.
|
||||
|
||||
As a precaution, Ripple recommends that issuing gateways always enable `RequireAuth` on [operational addresses and standby addresses](concept-issuing-and-operational-addresses.html), and then never approve any trust lines to those addresses. This prevents operational addresses and standby addresses from issuing currency in the XRP Ledger even by accident. This is a purely precautionary measure, and does not stop those addresses from transferring issued currency balances created by the issuing address, as they are intended to do.
|
||||
As a precaution, Ripple recommends that issuing gateways always enable `RequireAuth` on [operational addresses and standby addresses](issuing-and-operational-addresses.html), and then never approve any trust lines to those addresses. This prevents operational addresses and standby addresses from issuing currency in the XRP Ledger even by accident. This is a purely precautionary measure, and does not stop those addresses from transferring issued currency balances created by the issuing address, as they are intended to do.
|
||||
|
||||
To use the Authorized Trust Lines feature, an issuer must also enable `RequireAuth` on its issuing address. After doing so, the issuing address must [submit a `TrustSet` transaction to approve each trust line](#authorizing-trust-lines) from a customer.
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ The **Individual Freeze** feature is a setting on a trust line. When an issuing
|
||||
|
||||
A financial institution can freeze the trust line linking it to a counterparty if that counterparty shows suspicious activity or violates the financial institution's terms of use. The financial institution should also freeze the counterparty in any other systems the financial institution operates that are connected to the XRP Ledger. (Otherwise, an address might still be able to engage in undesired activity by sending payments through the financial institution.)
|
||||
|
||||
An individual address can freeze its trust line to a financial institution. This has no effect on transactions between the institution and other users. It does, however, prevent other addresses, including [operational addresses](concept-issuing-and-operational-addresses.html), from sending that financial institution's issuances to the individual address. This type of individual freeze has no effect on offers.
|
||||
An individual address can freeze its trust line to a financial institution. This has no effect on transactions between the institution and other users. It does, however, prevent other addresses, including [operational addresses](issuing-and-operational-addresses.html), from sending that financial institution's issuances to the individual address. This type of individual freeze has no effect on offers.
|
||||
|
||||
The Individual Freeze applies to a single currency only. To freeze multiple currencies with a particular counterparty, the address must enable Individual Freeze on the trust lines for each currency individually.
|
||||
|
||||
@@ -35,13 +35,13 @@ An address cannot enable the Individual Freeze setting if it has enabled the [No
|
||||
|
||||
The **Global Freeze** feature is a setting on an address. When an issuing address enables the Global Freeze feature, the following rules apply:
|
||||
|
||||
* All counterparties of the frozen issuing address can no longer decrease the balances in their trust lines to the frozen address, except in direct payments to the issuer. (This also affects any [operational addresses](concept-issuing-and-operational-addresses.html).)
|
||||
* All counterparties of the frozen issuing address can no longer decrease the balances in their trust lines to the frozen address, except in direct payments to the issuer. (This also affects any [operational addresses](issuing-and-operational-addresses.html).)
|
||||
* Counterparties of the frozen issuing address can still send and receive payments directly to and from the issuing address.
|
||||
* All offers to sell currencies issued by the frozen address are [considered unfunded](reference-transaction-format.html#lifecycle-of-an-offer).
|
||||
|
||||
It can be useful to enable Global Freeze on a financial institution's [issuing address](concept-issuing-and-operational-addresses.html) if the secret key to an operational address is compromised, even after regaining control of a such an address. This stops the flow of funds, preventing attackers from getting away with any more money or at least making it easier to track what happened. Besides enacting a Global Freeze in the XRP Ledger, a financial institution should also suspend activities in its connectors to outside systems.
|
||||
It can be useful to enable Global Freeze on a financial institution's [issuing address](issuing-and-operational-addresses.html) if the secret key to an operational address is compromised, even after regaining control of a such an address. This stops the flow of funds, preventing attackers from getting away with any more money or at least making it easier to track what happened. Besides enacting a Global Freeze in the XRP Ledger, a financial institution should also suspend activities in its connectors to outside systems.
|
||||
|
||||
It can also be useful to enable Global Freeze if a financial institution intends to migrate to a new [issuing address](concept-issuing-and-operational-addresses.html), or if the financial institution intends to cease doing business. This locks the funds at a specific point in time, so users cannot trade them away for other currencies.
|
||||
It can also be useful to enable Global Freeze if a financial institution intends to migrate to a new [issuing address](issuing-and-operational-addresses.html), or if the financial institution intends to cease doing business. This locks the funds at a specific point in time, so users cannot trade them away for other currencies.
|
||||
|
||||
Global Freeze applies to _all_ currencies issued and held by the address. You cannot enable Global Freeze for only one currency. If you want to have the ability to freeze some currencies and not others, you should use different addresses for each currency.
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
All currencies other than XRP can be represented in the XRP Ledger as **issued currencies**. These digital assets (sometimes called "issuances" or "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 [NoRipple flag](concept-noripple.html) on trust lines to prevent those trust lines from rippling.
|
||||
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 [NoRipple flag](noripple.html) on trust lines to prevent those trust lines from rippling.
|
||||
|
||||
Issued currencies can be traded with XRP or each other in the XRP Ledger's decentralized exchange.
|
||||
|
||||
@@ -18,9 +18,9 @@ Ripple strongly recommends researching the relevant regulations before engaging
|
||||
|
||||
All issued currencies in the XRP Ledger exist in trust lines, represented in the ledger's data as [RippleState objects](reference-ledger-format.html#ripplestate). To create an issued currency, the issuing address sends a [Payment transaction][] to an address which has a trust line to the issuer with a nonzero limit for that currency. (You can also create issued currency by rippling "through" such a trust line.) You can erase issued currency by sending it back to the issuer.
|
||||
|
||||
The issuer of a currency can define a percentage [transfer fee](concept-transfer-fees.html) to deduct when two parties transact in its issued currencies.
|
||||
The issuer of a currency can define a percentage [transfer fee](transfer-fees.html) to deduct when two parties transact in its issued currencies.
|
||||
|
||||
Addresses can also [freeze](concept-freeze.html) issued currencies, which may be useful for businesses to comply with financial regulations in their jurisdiction. If you do not need this feature and do not want to freeze currencies, you can give up your address's ability to freeze individual trust lines and to undo a global freeze. XRP cannot be frozen.
|
||||
Addresses can also [freeze](freeze.html) issued currencies, which may be useful for businesses to comply with financial regulations in their jurisdiction. If you do not need this feature and do not want to freeze currencies, you can give up your address's ability to freeze individual trust lines and to undo a global freeze. XRP cannot be frozen.
|
||||
|
||||
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](reference-currency.html).
|
||||
|
||||
|
||||
@@ -13,11 +13,11 @@ A path is made of steps that connect the sender to the receiver of the payment.
|
||||
* Rippling through another address with the same currency
|
||||
* Exchanging currency at an order book
|
||||
|
||||
Rippling through another address is the process of moving debt around. In the typical case, this involves reducing an issuer's obligation to one party and increasing the obligation to another party. Rippling can occur between any addresses that are connected by trust lines. See [Understanding the NoRipple Flag](concept-noripple.html) for more examples of rippling.
|
||||
Rippling through another address is the process of moving debt around. In the typical case, this involves reducing an issuer's obligation to one party and increasing the obligation to another party. Rippling can occur between any addresses that are connected by trust lines. See [Understanding the NoRipple Flag](noripple.html) for more examples of rippling.
|
||||
|
||||
In the case of a currency exchange step, the path step specifies which currency to change to, but does not record the state of the Offers in the order book. The canonical order of transactions is not final until a ledger is validated, so you cannot know for certain which Offers a transaction will take, until after the transaction has been validated. (You can make an educated guess, since each transaction takes the best available Offers at the time it executes in the final ledger.) <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
In both types of steps, each intermediate address gains and loses approximately equal value: either a balance ripples from a trust line to another trust line in the same currency, or they exchange currencies according to a previously-placed order. In some cases, the amounts gained and lost may not be exactly equivalent, due to [transfer fees](concept-transfer-fees.html), trust line quality, or rounding.
|
||||
In both types of steps, each intermediate address gains and loses approximately equal value: either a balance ripples from a trust line to another trust line in the same currency, or they exchange currencies according to a previously-placed order. In some cases, the amounts gained and lost may not be exactly equivalent, due to [transfer fees](transfer-fees.html), trust line quality, or rounding.
|
||||
|
||||
[](img/paths-examples.png)
|
||||
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
|
||||
The `TransferRate` setting in the XRP Ledger allows [financial institutions that issue currency in the XRP Ledger](tutorial-gateway-guide.html) to charge users a _transfer fee_ for sending the currencies issued by that financial institution. The sender of the transfer is debited an extra percentage based on the transfer fee, while the recipient of the transfer is credited the intended amount. The difference is the transfer fee, which becomes the property of the issuing address, and is no longer tracked in the XRP Ledger. The transfer fee does not apply when sending or receiving _directly_ to and from the issuing account, but it does apply when transferring from an [operational address][] to another user.
|
||||
|
||||
[operational address]: concept-issuing-and-operational-addresses.html
|
||||
[issuing address]: concept-issuing-and-operational-addresses.html
|
||||
[operational address]: issuing-and-operational-addresses.html
|
||||
[issuing address]: issuing-and-operational-addresses.html
|
||||
|
||||
XRP never has a transfer fee, because it never has an issuer.
|
||||
|
||||
@@ -31,7 +31,7 @@ In this scenario, Salazar (the sender) holds EUR issued by ACME, and wants to de
|
||||
|
||||
The transfer fee is represented by a setting on the [issuing address][]. The transfer fee cannot be less than 0% or more than 100% and is rounded down to the nearest 0.0000001%. The TransferRate setting applies to all currencies issued by the same account. If you want to have different transfer fee percentages for different currencies, use different [issuing addresses][issuing address] for each currency.
|
||||
|
||||
**Note:** The [fix1201 amendment](concept-amendments.html), introduced in `rippled` v0.80.0 and enabled on 2017-11-14, lowered the maximum transfer fee to 100% from an effective limit of approximately 329% (based on the maximum size of a 32-bit integer). The ledger may still contain accounts with a transfer fee setting higher than 100% (a `TransferRate` of `2000000000`). Any transfer fees already set continue to operate at their stated rate.
|
||||
**Note:** The [fix1201 amendment](amendments.html), introduced in `rippled` v0.80.0 and enabled on 2017-11-14, lowered the maximum transfer fee to 100% from an effective limit of approximately 329% (based on the maximum size of a 32-bit integer). The ledger may still contain accounts with a transfer fee setting higher than 100% (a `TransferRate` of `2000000000`). Any transfer fees already set continue to operate at their stated rate.
|
||||
|
||||
## RippleAPI
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
An "Account" in the XRP Ledger represents a holder of XRP and a sender of [transactions](reference-transaction-format.html). The core elements of an account are:
|
||||
|
||||
- An identifying **address**, such as `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`
|
||||
- An **XRP balance**. Some of this XRP is set aside for the [Reserve](concept-reserves.html).
|
||||
- An **XRP balance**. Some of this XRP is set aside for the [Reserve](reserves.html).
|
||||
- A **sequence number**, starting at 1 and increasing with each transaction sent from this account. No transaction can be included in a ledger unless the transaction's sequence number matches its sender's next sequence number.
|
||||
- A **history of transactions** that affected this account and its balances.
|
||||
- One or more ways to [authorize transactions](reference-transaction-format.html#authorizing-transactions), possibly including:
|
||||
@@ -17,7 +17,7 @@ In the ledger's data tree, an account's core data is stored in the [AccountRoot]
|
||||
|
||||
### Creating Accounts
|
||||
|
||||
There is not a dedicated "create account" transaction. The [Payment transaction][] automatically creates a new account if the payment sends XRP equal to or greater than the [account reserve](concept-reserves.html) to a mathematically-valid address that does not already have an account. This is called _funding_ an account, and creates an [AccountRoot object](reference-ledger-format.html#accountroot) in the ledger. No other transaction can create an account.
|
||||
There is not a dedicated "create account" transaction. The [Payment transaction][] automatically creates a new account if the payment sends XRP equal to or greater than the [account reserve](reserves.html) to a mathematically-valid address that does not already have an account. This is called _funding_ an account, and creates an [AccountRoot object](reference-ledger-format.html#accountroot) in the ledger. No other transaction can create an account.
|
||||
|
||||
**Caution:** Funding an account **does not** give you any special privileges over that account. Whoever has the secret key corresponding to the account's address has full control over the account and all XRP it contains. For some addresses, it's possible that no one has the secret key, in which case the account is a [black hole](#special-addresses) and the XRP is lost forever.
|
||||
|
||||
@@ -29,7 +29,7 @@ The typical way to get an account in the XRP Ledger is as follows:
|
||||
|
||||
- For example, you can purchase XRP in a private exchange, then withdraw XRP from the exchange to the address you specified.
|
||||
|
||||
**Caution:** The first time you receive XRP at your own XRP Ledger address, you must pay the [account reserve](concept-reserves.html) (currently 20 XRP), which locks up that amount of XRP indefinitely. In contrast, private exchanges usually hold all their customers' XRP in a few shared XRP Ledger accounts, so customers don't have to pay the reserve for individual accounts at the exchange. Before withdrawing, consider whether having your own account directly on the XRP Ledger is worth the price.
|
||||
**Caution:** The first time you receive XRP at your own XRP Ledger address, you must pay the [account reserve](reserves.html) (currently 20 XRP), which locks up that amount of XRP indefinitely. In contrast, private exchanges usually hold all their customers' XRP in a few shared XRP Ledger accounts, so customers don't have to pay the reserve for individual accounts at the exchange. Before withdrawing, consider whether having your own account directly on the XRP Ledger is worth the price.
|
||||
|
||||
## Addresses
|
||||
|
||||
@@ -66,7 +66,7 @@ Unlike Bitcoin and many other crypto-currencies, each new version of the XRP Led
|
||||
|
||||
In the XRP Ledger, transaction history is tracked by a "thread" of transactions linked by a transaction's identifying hash and the ledger index. The `AccountRoot` ledger object has the identifying hash and ledger of the transaction that most recently modified it; the metadata of that transaction includes the previous state of the `AccountRoot` node, so it is possible to iterate through the history of a single account this way. This transaction history includes any transactions that modify the `AccountRoot` node directly, including:
|
||||
|
||||
- Transactions sent by the account, because they modify the account's `Sequence` number. These transactions also modify the account's XRP balance because of the [transaction cost](concept-transaction-cost.html).
|
||||
- Transactions sent by the account, because they modify the account's `Sequence` number. These transactions also modify the account's XRP balance because of the [transaction cost](transaction-cost.html).
|
||||
- Transactions that modified the account's XRP balance, including incoming [Payment transactions][] and other types of transactions such as [PaymentChannelClaim][] and [EscrowFinish][].
|
||||
|
||||
The _conceptual_ transaction history of an account also includes transactions that modified the account's owned objects and non-XRP balances. These objects are separate ledger objects, each with their own thread of transactions that affected them. If you have an account's full ledger history, you can follow it forward to find the ledger objects created or modified by it. A "complete" transaction history includes the history of objects owned by a transaction, such as:
|
||||
|
||||
@@ -38,11 +38,11 @@ The `public_key` and `public_key_hex` are the public key in various formats, wit
|
||||
|
||||
**account_id**
|
||||
|
||||
The `account_id` is [derived from the public key](concept-accounts.html#address-encoding) and designates the *potential* for an account to be created in the XRP Ledger. It is important to know that while an `account_id` exists, no actual account exists in the XRP Ledger until the `account_id` receives its first XRP payment. In addition, the `account_id` can't send any transactions until after it's received a transaction that funds and creates the account.
|
||||
The `account_id` is [derived from the public key](accounts.html#address-encoding) and designates the *potential* for an account to be created in the XRP Ledger. It is important to know that while an `account_id` exists, no actual account exists in the XRP Ledger until the `account_id` receives its first XRP payment. In addition, the `account_id` can't send any transactions until after it's received a transaction that funds and creates the account.
|
||||
|
||||
The `account_id` (without a funded account) can, however, be used as a [regular key](#regular-key-pair) or a [member of a signer list](reference-transaction-format.html#multi-signing) to authorize transactions for another account that does exist.
|
||||
|
||||
To create a funded account stored in the ledger, the `account_id` must [receive a `Payment` transaction](reference-transaction-format.html#creating-accounts) that provides enough XRP to meet the [reserve requirement](concept-reserves.html).
|
||||
To create a funded account stored in the ledger, the `account_id` must [receive a `Payment` transaction](reference-transaction-format.html#creating-accounts) that provides enough XRP to meet the [reserve requirement](reserves.html).
|
||||
|
||||
For more information about the `wallet_propose` response, see [`wallet_propose`](reference-rippled.html#wallet-propose).
|
||||
|
||||
@@ -59,11 +59,11 @@ The master key pair is composed of a private key and a public key. In addition t
|
||||
|
||||
* [Disable the master public key](reference-transaction-format.html#accountset-flags).
|
||||
|
||||
* Permanently give up the ability to [freeze](concept-freeze.html#no-freeze).
|
||||
* Permanently give up the ability to [freeze](freeze.html#no-freeze).
|
||||
|
||||
* Send a cost-0 [key reset transaction](concept-transaction-cost.html#key-reset-transaction).
|
||||
* Send a cost-0 [key reset transaction](transaction-cost.html#key-reset-transaction).
|
||||
|
||||
The master key pair for an account is generated in the same [`wallet_propose`](reference-rippled.html#wallet-propose) response as the `account_id` of the account the master key pair is authorized to sign transactions for. Because the master key pair is generated in the same response, it is [intrinsically related](concept-accounts.html#address-encoding) to the `account_id`, which is derived from the `public_key_hex`.
|
||||
The master key pair for an account is generated in the same [`wallet_propose`](reference-rippled.html#wallet-propose) response as the `account_id` of the account the master key pair is authorized to sign transactions for. Because the master key pair is generated in the same response, it is [intrinsically related](accounts.html#address-encoding) to the `account_id`, which is derived from the `public_key_hex`.
|
||||
|
||||
This is as opposed to a regular key pair, which is also generated using the `wallet_propose` method, but which must be explicitly assigned as a regular key pair to an account. Because a regular key pair is explicitly assigned, it is not intrinsically related to the `account_id` of the account it is authorized to sign transactions for. For more information, see [Regular Key Pair](#regular-key-pair).
|
||||
|
||||
@@ -107,7 +107,7 @@ The XRP Ledger supports the following cryptographic signing algorithms:
|
||||
|
||||
When you generate a key pair with the [wallet_propose method][], you can specify the `key_type` to choose which cryptographic signing algorithm to use to derive the keys. If you generated a key type other than the default, you must also specify the `key_type` when signing transactions.
|
||||
|
||||
The supported types of key pairs can be used interchangeably throughout the XRP Ledger as master key pairs, regular key pairs, and members of signer lists. The process of [deriving an address](concept-accounts.html#address-encoding) is the same for secp256k1 and Ed25519 key pairs.
|
||||
The supported types of key pairs can be used interchangeably throughout the XRP Ledger as master key pairs, regular key pairs, and members of signer lists. The process of [deriving an address](accounts.html#address-encoding) is the same for secp256k1 and Ed25519 key pairs.
|
||||
|
||||
**Note:** Currently, you cannot sign [payment channel claims](tutorial-paychan.html) with Ed25519 keys. This is a bug.
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
_(Requires the [DepositAuth amendment](reference-amendments.html#depositauth).)_
|
||||
|
||||
Deposit Authorization is an optional feature of an [account](concept-accounts.html) in the XRP Ledger. With Deposit Authorization enabled, transactions cannot send value of any kind to the account unless the sender of those transactions is the account itself. This includes transfers of XRP and issued currencies.
|
||||
Deposit Authorization is an optional feature of an [account](accounts.html) in the XRP Ledger. With Deposit Authorization enabled, transactions cannot send value of any kind to the account unless the sender of those transactions is the account itself. This includes transfers of XRP and issued currencies.
|
||||
|
||||
By default, new accounts have DepositAuth disabled.
|
||||
|
||||
@@ -12,14 +12,14 @@ Financial services regulations and licenses may require that a business or entit
|
||||
|
||||
The Deposit Authorization flag introduces an option for those using the XRP Ledger to comply with such regulations without changing the fundamental nature of the decentralized ledger. With Deposit Authorization enabled, an account can only receive funds it explicitly approves by sending a transaction. The owner of an account using Deposit Authorization can perform the due diligence necessary to identify the sender of any funds _before_ sending the transaction that causes the account to receive the money.
|
||||
|
||||
Deposit Authorization is intended to be used with [Checks](reference-amendments.html#checks), [Escrow](concept-escrow.html), and [Payment Channels](reference-amendments.html#paychan). In this "two-step" model, first the source sends a transaction to authorize sending funds, then the destination sends a transaction to authorize receiving those funds. Deposit Authorization cannot be used with [Payment transactions][].
|
||||
Deposit Authorization is intended to be used with [Checks](reference-amendments.html#checks), [Escrow](escrow.html), and [Payment Channels](reference-amendments.html#paychan). In this "two-step" model, first the source sends a transaction to authorize sending funds, then the destination sends a transaction to authorize receiving those funds. Deposit Authorization cannot be used with [Payment transactions][].
|
||||
|
||||
## Recommended Usage
|
||||
|
||||
To get the full effect of Deposit Authorization, Ripple recommends also doing the following:
|
||||
|
||||
- Always maintain an XRP balance higher than the minimum [reserve requirement](concept-reserves.html).
|
||||
- Keep the DefaultRipple flag in its default (disabled) state. Do not enable [rippling](concept-noripple.html) on any trust lines. When sending TrustSet transactions, always use the [`tfSetNoRipple` flag](reference-transaction-format.html#trustset-flags).
|
||||
- Always maintain an XRP balance higher than the minimum [reserve requirement](reserves.html).
|
||||
- Keep the DefaultRipple flag in its default (disabled) state. Do not enable [rippling](noripple.html) on any trust lines. When sending TrustSet transactions, always use the [`tfSetNoRipple` flag](reference-transaction-format.html#trustset-flags).
|
||||
- Do not place [Offers](reference-transaction-format.html#offercreate). It is impossible to know in advance which matching offers will be consumed to execute such a trade.
|
||||
|
||||
## Precise Semantics
|
||||
@@ -27,13 +27,13 @@ To get the full effect of Deposit Authorization, Ripple recommends also doing th
|
||||
An account with Deposit Authorization enabled:
|
||||
|
||||
- **Cannot** be the destination of [Payment transactions][], with **one exception**:
|
||||
- If the account's XRP balance is equal to or below the minimum account [reserve requirement](concept-reserves.html), it can be the destination of an XRP Payment whose `Amount` is equal or less than the minimum account reserve (currently 20 XRP). This is to prevent an account from becoming "stuck" by being unable to send transactions but also unable to receive XRP. The account's owner reserve does not matter for this case.
|
||||
- If the account's XRP balance is equal to or below the minimum account [reserve requirement](reserves.html), it can be the destination of an XRP Payment whose `Amount` is equal or less than the minimum account reserve (currently 20 XRP). This is to prevent an account from becoming "stuck" by being unable to send transactions but also unable to receive XRP. The account's owner reserve does not matter for this case.
|
||||
- Can receive XRP from [PaymentChannelClaim transactions][] **only if** the sender of the PaymentChannelClaim transaction is the destination of the payment channel.
|
||||
- Can receive XRP from [EscrowFinish transactions][] **only if** the sender of the EscrowFinish transaction is the destination of the escrow.
|
||||
- **Can** receive XRP or issued currencies by sending a [CheckCash][] transaction. _(Requires the [Checks amendment](reference-amendments.html#checks).)_
|
||||
- **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 has created any trust lines without the [NoRipple flag](concept-noripple.html) enabled, or has enabled the DefaultRipple 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.
|
||||
- If the account has created any trust lines without the [NoRipple flag](noripple.html) enabled, or has enabled the DefaultRipple 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.
|
||||
- The account has not issued currency on trust lines created by others
|
||||
@@ -56,9 +56,9 @@ If the result of the `Flags` value bitwise-AND the `lsfDepositAuth` flag value (
|
||||
|
||||
## See Also
|
||||
|
||||
- The [Authorized Trust Lines](concept-authorized-trust-lines.html) feature (`RequireAuth` flag) limits which counterparties can hold non-XRP currencies issued by an account.
|
||||
- The [Authorized Trust Lines](authorized-trust-lines.html) feature (`RequireAuth` flag) limits which counterparties can hold non-XRP currencies issued by an account.
|
||||
- The `DisallowXRP` flag indicates that an account should not receive XRP. This is a softer protection than Deposit Authorization, and is not enforced by the XRP Ledger. (Client applications should honor this flag or at least warn about it.)
|
||||
- The `RequireDest` flag indicates that an account can only receive currency amounts if the sending transaction specifies a [Destination Tag](tutorial-gateway-guide.html#source-and-destination-tags). This protects users from forgetting to indicate the purpose of a payment, but does not protect recipients from unknown senders, who can make up arbitrary destination tags.
|
||||
- [Partial Payments](concept-partial-payments.html) provide a way for accounts to return unwanted payments while subtracting [transfer fees](concept-transfer-fees.html) and exchange rates from the amount delivered instead of adding them to the amount sent.
|
||||
- [Partial Payments](partial-payments.html) provide a way for accounts to return unwanted payments while subtracting [transfer fees](transfer-fees.html) and exchange rates from the amount delivered instead of adding them to the amount sent.
|
||||
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -25,7 +25,7 @@ Many objects in the ledger are owned by a particular address, and count toward t
|
||||
- [Held Payments (Escrow)](reference-ledger-format.html#escrow) are owned by the address that placed them.
|
||||
- [Payment Channels](tutorial-paychan.html) are owned by the address that created them.
|
||||
- [Owner directories](reference-ledger-format.html#directorynode) list all the ledger objects that contribute to an address's owner reserve. However, the owner directory itself does not count towards the reserve.
|
||||
- [Checks](concept-checks.html) are owned by the address that created them (the sender, not the destination).
|
||||
- [Checks](checks.html) are owned by the address that created them (the sender, not the destination).
|
||||
|
||||
#### Owner Reserve Edge Cases
|
||||
|
||||
@@ -35,7 +35,7 @@ The XRP Ledger considers an [OfferCreate transaction][] to be an explicit statem
|
||||
|
||||
## Going Below the Reserve Requirement
|
||||
|
||||
During transaction processing, the [transaction cost](concept-transaction-cost.html) destroys some of the sending address's XRP balance. This can cause an address's XRP to go below the reserve requirement.
|
||||
During transaction processing, the [transaction cost](transaction-cost.html) destroys some of the sending address's XRP balance. This can cause an address's XRP to go below the reserve requirement.
|
||||
|
||||
When an address holds less XRP than its current reserve requirement, it cannot send new transactions that would transfer XRP to others, or increase its own reserve. Even so, the address continues to exist in the ledger and can send other transactions as long as it has enough XRP to pay the transaction cost. The address can become able to send all types of transactions again if it receives enough XRP to meet its reserve requirement again, or if the [reserve requirement decreases](#changing-the-reserve-requirements) to less than the address's XRP holdings.
|
||||
|
||||
@@ -43,6 +43,6 @@ When an address holds less XRP than its current reserve requirement, it cannot s
|
||||
|
||||
## Changing the Reserve Requirements
|
||||
|
||||
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](concept-fee-voting.html) for more information.
|
||||
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.
|
||||
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -9,13 +9,13 @@ However, the rules of the XRP Ledger include several types of fees, including ne
|
||||
|
||||
### Neutral Fees
|
||||
|
||||
The _**transaction cost**_ (sometimes called the transaction fee) is a miniscule amount of XRP destroyed to send a transaction. This cost scales with the load of the network, which protects the peer-to-peer network from spam. See [Transaction Cost](concept-transaction-cost.html) for more information.
|
||||
The _**transaction cost**_ (sometimes called the transaction fee) is a miniscule amount of XRP destroyed to send a transaction. This cost scales with the load of the network, which protects the peer-to-peer network from spam. See [Transaction Cost](transaction-cost.html) for more information.
|
||||
|
||||
The _**reserve requirement**_ is a minimum amount of XRP that an account must hold. It increases with the number of objects the account owns in the ledger. This disincentivizes users from increasing the size of the ledger carelessly or maliciously. See [Reserves](concept-reserves.html) for more information.
|
||||
The _**reserve requirement**_ is a minimum amount of XRP that an account must hold. It increases with the number of objects the account owns in the ledger. This disincentivizes users from increasing the size of the ledger carelessly or maliciously. See [Reserves](reserves.html) for more information.
|
||||
|
||||
### Optional Fees
|
||||
|
||||
_**Transfer fees**_ are optional percentage fees that issuers can charge to transfer the currencies they issue to other addresses within the XRP Ledger. See [Transfer Fees](concept-transfer-fees.html) for more information.
|
||||
_**Transfer fees**_ are optional percentage fees that issuers can charge to transfer the currencies they issue to other addresses within the XRP Ledger. See [Transfer Fees](transfer-fees.html) for more information.
|
||||
|
||||
_**Trust line quality**_ is a setting that allows an account to value balances on a trust line at higher or lower than face value. This can lead to situations that are like charging a fee. Trust line quality does not apply to XRP, which is not tied to a trust line.
|
||||
|
||||
|
||||
@@ -91,7 +91,7 @@ If none of the above occur, transactions can stay in the queue for a theoretical
|
||||
|
||||
## Reference Transaction Cost
|
||||
|
||||
The "Reference Transaction" is the cheapest (non-free) transaction, in terms of the necessary [transaction cost](concept-transaction-cost.html) before load scaling. Most transactions have the same cost as the reference transaction. Some transactions, such as [multi-signed transactions](reference-transaction-format.html#multi-signing), require a multiple of this cost instead. When the open ledger cost escalates, the requirement is proportional to the basic cost of the transaction.
|
||||
The "Reference Transaction" is the cheapest (non-free) transaction, in terms of the necessary [transaction cost](transaction-cost.html) before load scaling. Most transactions have the same cost as the reference transaction. Some transactions, such as [multi-signed transactions](reference-transaction-format.html#multi-signing), require a multiple of this cost instead. When the open ledger cost escalates, the requirement is proportional to the basic cost of the transaction.
|
||||
|
||||
### Fee Levels
|
||||
|
||||
@@ -101,7 +101,7 @@ _Fee levels_ represent the proportional difference between the minimum cost and
|
||||
|-------------|-----------------------|----------------------------|----------------------|---------------------------|
|
||||
| Reference transaction (most transactions) | 10 | 256 | 20 | 512 |
|
||||
| [Multi-signed transaction](reference-transaction-format.html#multi-signing) with 4 signatures | 50 | 256 | 100 | 512 |
|
||||
| [Key reset transaction](concept-transaction-cost.html#key-reset-transaction) | 0 | (Effectively infinite) | N/A | (Effectively infinite) |
|
||||
| [Key reset transaction](transaction-cost.html#key-reset-transaction) | 0 | (Effectively infinite) | N/A | (Effectively infinite) |
|
||||
| [EscrowFinish transaction](reference-transaction-format.html#escrowfinish) with 32-byte preimage. | 350 | 256 | 700 | 512 |
|
||||
|
||||
|
||||
@@ -130,7 +130,7 @@ The [server_state method][] returns a direct representation of `rippled`'s inter
|
||||
|
||||
Every signed transaction must include the transaction cost in the [`Fee` field](reference-transaction-format.html#common-fields). Like all fields of a signed transaction, this field cannot be changed without invalidating the signature.
|
||||
|
||||
As a rule, the XRP Ledger executes transactions _exactly_ as they are signed. (To do anything else would be difficult to coordinate across a decentralized consensus network, at the least.) As a consequence of this, every transaction destroys the exact amount of XRP specified by the `Fee` field, even if the specified amount is much more than the current minimum transaction cost for any part of the network. The transaction cost can even destroy XRP that would otherwise be set aside for an account's [reserve requirement](concept-reserves.html).
|
||||
As a rule, the XRP Ledger executes transactions _exactly_ as they are signed. (To do anything else would be difficult to coordinate across a decentralized consensus network, at the least.) As a consequence of this, every transaction destroys the exact amount of XRP specified by the `Fee` field, even if the specified amount is much more than the current minimum transaction cost for any part of the network. The transaction cost can even destroy XRP that would otherwise be set aside for an account's [reserve requirement](reserves.html).
|
||||
|
||||
Before signing a transaction, we recommend [looking up the current load-based transaction cost](#querying-the-transaction-cost). If the transaction cost is high due to load scaling, you may want to wait for it to decrease. If you do not plan on submitting the transaction immediately, we recommend specifying a slightly higher transaction cost to account for future load-based fluctuations in the transaction cost.
|
||||
|
||||
@@ -176,6 +176,6 @@ When the [FeeEscalation amendment](reference-amendments.html#feeescalation) is e
|
||||
|
||||
## Changing the Transaction Cost
|
||||
|
||||
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](concept-fee-voting.html) for more information.
|
||||
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.
|
||||
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
***TODO: Question: Added this concept section based on fantastic source material from Rome -- thought we should publish it. Useful? May be good to associate it with a flow diagram - like the one for address encoding: https://ripple.com/build/accounts/#address-encoding. Address both single and multi-sign flows.***
|
||||
|
||||
In the XRP Ledger, a digital signature proves that a transaction is authorized to do a specific set of actions. A digital signature is created based on a [key pair](concept-cryptographic-keys.html) associated with the transaction's sending account.
|
||||
In the XRP Ledger, a digital signature proves that a transaction is authorized to do a specific set of actions. A digital signature is created based on a [key pair](cryptographic-keys.html) associated with the transaction's sending account.
|
||||
|
||||
Here's an overview of some of the more common signature-related fields used in the XRP Ledger.
|
||||
|
||||
@@ -20,7 +20,7 @@ To verify whether a single-signed transaction is valid, a `rippled` server check
|
||||
|
||||
1. This key hashes to an address that's authorized by the transaction's sender.
|
||||
|
||||
The default is that only the address of an account is authorized to send all transactions for that account. That address is [derived from](concept-accounts.html#address-encoding) the public key from the master key pair that was generated during address creation. Regular keys add a different address (derived from a different key pair) that's authorized to send most transactions. And of course, you can also disable the [master key](concept-cryptographic-keys.html) or add a [multi-signing list](reference-transaction-format.html#multi-signing). ***TODO: address from Ryan: "And of course" - Nit: this seems a little informal. Maybe just drop it and go into the next sentence? JHA take a closer look at what this sentence is trying to say.***
|
||||
The default is that only the address of an account is authorized to send all transactions for that account. That address is [derived from](accounts.html#address-encoding) the public key from the master key pair that was generated during address creation. Regular keys add a different address (derived from a different key pair) that's authorized to send most transactions. And of course, you can also disable the [master key](cryptographic-keys.html) or add a [multi-signing list](reference-transaction-format.html#multi-signing). ***TODO: address from Ryan: "And of course" - Nit: this seems a little informal. Maybe just drop it and go into the next sentence? JHA take a closer look at what this sentence is trying to say.***
|
||||
|
||||
2. This key matches the signature on the transaction.
|
||||
|
||||
@@ -63,7 +63,7 @@ Verifying a [multi-signed transaction](reference-transaction-format.html#multi-s
|
||||
|
||||
The public key of one signer. Verifying a [multi-signed transaction](reference-transaction-format.html#multi-signing) involves making sure each such key is authorized to sign for the `AccountID` of the signer.
|
||||
|
||||
Multi-signature `AccountIDs` are a little special. If one is an address that doesn't exist in the ledger, then the `SigningPubKey` must hash to the `AccountID` value using the standard rules for [deriving an AccountID](concept-accounts.html#address-encoding) from a public key. If the address does exist in the ledger, then either:
|
||||
Multi-signature `AccountIDs` are a little special. If one is an address that doesn't exist in the ledger, then the `SigningPubKey` must hash to the `AccountID` value using the standard rules for [deriving an AccountID](accounts.html#address-encoding) from a public key. If the address does exist in the ledger, then either:
|
||||
|
||||
1. The `SigningPubKey` must hash to the `AccountID` and the address must not have the master key disabled.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Stand-Alone Mode
|
||||
|
||||
You can run `rippled` in stand-alone mode without a consensus of trusted servers. In stand-alone mode, `rippled` does not communicate with any other servers in the XRP Ledger peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing `rippled` behavior without being tied to the live network. For example, you can [test the effects of Amendments](concept-amendments.html#testing-amendments) before those Amendments have gone into effect across the decentralized network.
|
||||
You can run `rippled` in stand-alone mode without a consensus of trusted servers. In stand-alone mode, `rippled` does not communicate with any other servers in the XRP Ledger peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing `rippled` behavior without being tied to the live network. For example, you can [test the effects of Amendments](amendments.html#testing-amendments) before those Amendments have gone into effect across the decentralized network.
|
||||
|
||||
When you run `rippled` in stand-alone mode, you have to tell it what ledger version to start from:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user