mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-04 03:45:49 +00:00
WIP - reorg accounts
This commit is contained in:
ddawson
@@ -21,11 +21,3 @@ The core elements of an account are:
|
||||
In the ledger's data tree, an account's core data is stored in the AccountRoot ledger object type. An account can also be the owner (or partial owner) of several other types of data.
|
||||
|
||||
**Tip:** An "Account" in the XRP Ledger is somewhere between the financial usage (like "bank account") and the computing usage (like "UNIX account"). Non-XRP currencies and assets are not stored in an XRP Ledger Account itself; each such asset is stored in an accounting relationship called a "Trust Line" that connects two parties.
|
||||
|
||||
## Address Encoding
|
||||
|
||||
**Tip:** These technical details are only relevant for people building low-level library software for XRP Ledger compatibility!
|
||||
|
||||
[[Source]](https://github.com/ripple/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "Source")
|
||||
|
||||
XRP Ledger addresses are encoded using `base58` with the _dictionary_ `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`. Since the XRP Ledger encodes several types of keys with base58, it prefixes the encoded data with a one-byte "type prefix" (also called a "version prefix") to distinguish them. The type prefix causes addresses to usually start with different letters in base58 format.
|
||||
|
||||
@@ -8,3 +8,24 @@ labels:
|
||||
# Accounts
|
||||
|
||||
An "Account" in the XRP Ledger represents a holder of XRP and a sender of transactions.
|
||||
|
||||
<!-- Need to document the information you need to create a tranaction from one account to another. What else do you need to know to use a basic account? -->
|
||||
|
||||
|
||||
## Creating Accounts
|
||||
|
||||
There is not a dedicated "create account" transaction. The `Payment` transaction automatically creates a new account if a payment sends XRP equal to or greater than the account reserve to a mathematically valid address that does not already have an account. This is called _funding_ an account, and creates an AccountRoot object 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 is possible that no one has the secret key, in which case the account is a black hole and the XRP is lost forever.
|
||||
|
||||
The typical way to get an account in the XRP Ledger is as follows:
|
||||
|
||||
1. Generate a key pair from a strong source of randomness and calculate the address of that key pair. (For example, you can use the `wallet_propose` method to do this.)
|
||||
|
||||
2. Have someone who already has an account in the XRP Ledger send XRP to the address you generated.
|
||||
|
||||
- For example, you can buy 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 (currently 10 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 do not 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.
|
||||
|
||||
|
||||
|
||||
@@ -39,7 +39,7 @@ For more technical details of how to calculate an XRP Ledger address, see [Addre
|
||||
XRP Ledger addresses are encoded using `base58` with the _dictionary_ `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`. Since the XRP Ledger encodes several types of keys with base58, it prefixes the encoded data with a one-byte "type prefix" (also called a "version prefix") to distinguish them. The type prefix causes addresses to usually start with different letters in base58 format.
|
||||
|
||||
|
||||
### Special Addresses
|
||||
## Special Addresses
|
||||
|
||||
Some addresses have special meaning, or historical uses, in the XRP Ledger. In many cases, these are "black hole" addresses, meaning the address is not derived from a known secret key. Since it is effectively impossible to guess a secret key from only an address, any XRP possessed by black hole addresses is lost forever.
|
||||
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
html: about-canceling-a-transaction.html
|
||||
html: canceling-a-transaction.html
|
||||
parent: transactions.html
|
||||
blurb: Before a transaction is final it might be possible to cancel it using a separate transaction.
|
||||
labels:
|
||||
- Transactions
|
||||
---
|
||||
# About Canceling a Transaction
|
||||
# Canceling a Transaction
|
||||
|
||||
An important and intentional feature of the XRP Ledger is that a [transaction](transactions.md)'s outcome is [final](finality-of-results.md) as soon as it has been incorporated in a [ledger version](../xrpl/ledgers.md) that is validated by the [consensus process](../xrpl/consensus.md).
|
||||
|
||||
@@ -7,7 +7,7 @@ labels:
|
||||
---
|
||||
# Finality of Results
|
||||
|
||||
The order in which transactions apply to the consensus [ledger](../xrpl/ledgers.md) is not final until a ledger is closed and the exact transaction set is approved by the [consensus process](../xrpl/consensus.md). A transaction that succeeded initially could still fail, and a transaction that failed initially could still succeed. Additionally, a transaction that was rejected by the consensus process in one round could achieve consensus in a later round.
|
||||
The order in which transactions apply to the consensus [ledger](ledgers.html) is not final until a ledger is closed and the exact transaction set is approved by the [consensus process](consensus.html). A transaction that succeeded initially could still fail, and a transaction that failed initially could still succeed. Additionally, a transaction that was rejected by the consensus process in one round could achieve consensus in a later round.
|
||||
|
||||
A validated ledger can include successful transactions (`tes` result codes) as well as failed transactions (`tec` result codes). No transaction with any other result is included in a ledger.
|
||||
|
||||
@@ -25,15 +25,15 @@ Any other transaction result is potentially not final. In that case, the transac
|
||||
|
||||
## How can non-final results change?
|
||||
|
||||
When you initially submit a transaction, the `rippled` server tentatively applies that transaction to its current open ledger, then returns the tentative [transaction results](../transactions/transaction-results/transaction-results.md) from doing so. However, the transaction's final result might be very different than its tentative results, for several reasons:
|
||||
When you initially submit a transaction, the `rippled` server tentatively applies that transaction to its current open ledger, then returns the tentative [transaction results](transaction-results-concepts.html) from doing so. However, the transaction's final result might be very different than its tentative results, for several reasons:
|
||||
|
||||
- The transaction might be delayed until a later ledger version, or might never be included in a validated ledger. For the most part, the XRP Ledger follows a principle that all valid transactions should be processed as soon as possible. However, there are exceptions, including:
|
||||
|
||||
- If a proposed transaction has not been relayed to a majority of validators by the time a [consensus round](../xrpl/consensus.md) begins, it might be postponed until the next ledger version, to give the remaining validators time to fetch the transaction and confirm that it is valid.
|
||||
- If a proposed transaction has not been relayed to a majority of validators by the time a [consensus round](consensus.html) begins, it might be postponed until the next ledger version, to give the remaining validators time to fetch the transaction and confirm that it is valid.
|
||||
|
||||
- If an address sends two different transactions using the same sequence number, at most one of those transactions can become validated. If those transactions are relayed through the network in different paths, a tentatively-successful transaction that some servers saw first might end up failing because the other, conflicting transaction reached a majority of servers first.
|
||||
|
||||
- To protect the network from spam, all transactions must destroy a [transaction cost](transaction-cost.md) in XRP to be relayed throughout the XRP Ledger peer-to-peer network. If heavy load on the peer-to-peer network causes the transaction cost to increase, a transaction that tentatively succeeded might not get relayed to enough servers to achieve a consensus, or might be [queued](../server/transaction-queue.md) for later.
|
||||
- To protect the network from spam, all transactions must destroy a [transaction cost](transaction-cost.md) in XRP to be relayed throughout the XRP Ledger peer-to-peer network. If heavy load on the peer-to-peer network causes the transaction cost to increase, a transaction that tentatively succeeded might not get relayed to enough servers to achieve a consensus, or might be [queued](transaction-queue.html) for later.
|
||||
|
||||
- Temporary internet outages or delays might prevent a proposed transaction from being successfully relayed before the transaction's intended expiration, as set by the `LastLedgerSequence` field. (If the transaction does not have an expiration, then it remains valid and could succeed any amount of time later, which can be undesirable in its own way.
|
||||
|
||||
@@ -41,7 +41,7 @@ When you initially submit a transaction, the `rippled` server tentatively applie
|
||||
|
||||
- Combinations of two or more of these factors can also occur.
|
||||
|
||||
- The [order transactions apply in a closed ledger](../xrpl/ledgers.md#open-closed-and-validated-ledgers) is usually different than the order those transactions were tentatively applied to a current open ledger; depending on the transactions involved, this can cause a tentatively-successful transaction to fail or a tentatively-failed transaction to succeed. Some examples include:
|
||||
- The [order transactions apply in a closed ledger](ledgers.html#open-closed-and-validated-ledgers) is usually different than the order those transactions were tentatively applied to a current open ledger; depending on the transactions involved, this can cause a tentatively-successful transaction to fail or a tentatively-failed transaction to succeed. Some examples include:
|
||||
|
||||
- If two transactions would each fully consume the same <!-- * -->offer] in the decentralized exchange, whichever one comes first succeeds, and the other fails. Since the order in which those transactions apply might change, the one that succeeded can fail and the one that failed can succeed. Since offers can be partially executed, they could also still succeed, but to a greater or lesser extent.
|
||||
|
||||
|
||||
@@ -21,6 +21,9 @@ Some fields that might appear in transaction metadata include:
|
||||
| `TransactionResult` | String | A [result code](transaction-results.html) indicating whether the transaction succeeded or how it failed. |
|
||||
| [`delivered_amount`](transaction-metadata.html#delivered_amount) | Currency Amount | _(Omitted for non-Payment transactions)_ The Currency Amount actually received by the `Destination` account. Use this field to determine how much was delivered, regardless of whether the transaction is a [partial payment](payments/partial-payments.md). See [this description](transaction-metadata.md#delivered_amount) for details. <!--[New in: rippled 0.27.0][] -->| <!--_ -->
|
||||
|
||||
|
||||
<!-- This metadata is too complex to be useful. Need a smaller example that the user can grok. -->
|
||||
|
||||
## Example Metadata
|
||||
|
||||
The following JSON object shows the metadata for [a complex cross-currency payment](https://xrpcharts.ripple.com/#/transactions/8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B):
|
||||
|
||||
@@ -628,6 +628,18 @@ pages:
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: concepts/tokens/authorized-trust-lines.md
|
||||
parent: trust-lines-and-issuing.html
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: concepts/tokens/rippling.md
|
||||
parent: trust-lines-and-issuing.html
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: concepts/transactions/transaction-cost.md
|
||||
parent: transactions.html
|
||||
@@ -652,33 +664,33 @@ pages:
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: concepts/transactions/transaction-malleability.md
|
||||
parent: transactions.html
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
|
||||
- md: concepts/transactions/finality-of-results.md
|
||||
parent: transactions.html
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: concepts/transactions/transaction-malleability.md
|
||||
parent: finality-of-results.html
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: concepts/transactions/about-canceling-a-transaction.md
|
||||
parent: transactions.html
|
||||
- md: concepts/transactions/canceling-a-transaction.md
|
||||
parent: finality-of-results.html
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: concepts/transactions/transaction-history.md
|
||||
parent: transactions.html
|
||||
parent: finality-of-results.html
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
|
||||
- md: concepts/transactions/transaction-results/transaction-results-concepts.md
|
||||
parent: transactions.html
|
||||
parent: finality-of-results.html
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
@@ -772,25 +784,13 @@ pages:
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: concepts/tokens/authorized-trust-lines.md
|
||||
parent: tokens.html
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
|
||||
- md: concepts/tokens/paths.md
|
||||
parent: tokens.html
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: concepts/tokens/rippling.md
|
||||
parent: tokens.html
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: concepts/tokens/transfer-fees.md
|
||||
parent: tokens.html
|
||||
targets:
|
||||
@@ -844,12 +844,7 @@ pages:
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: concepts/accounts/account-creating.md
|
||||
parent: accounts.html
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
|
||||
- md: concepts/accounts/account-deleting.md
|
||||
parent: accounts.html
|
||||
|
||||
Reference in New Issue
Block a user