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

Link fixes and other cleanup

Browse Source 
- Clarifies that SetFee transaction hashes weren't always unique
  (Fixes #696)
- Fixes some broken links and adds a couple more useful links.
- Mention different types of transactions in tx basics page
- Fix inconsistent naming of 'list xrp...' use case
This commit is contained in:
mDuo13
2019-10-04 16:34:25 -07:00
parent 6836c15b21
commit 8ab0611462
8 changed files with 19 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
content/_snippets/setfee_uniqueness_note.md Normal file
View File

@@ -0,0 +1 @@
**Note:** In the full history of the XRP Ledger, there is an exception to the rule that transaction hashes are unique. Two early [SetFee pseudo-transactions][] had the exact same fields, resulting in the same hash, `1C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B`. The first of these transactions appears [in ledger 3715073](websocket-api-tool.html?server=wss%3A%2F%2Fs2.ripple.com%2F&req=%7B%22id%22%3A%22setfee_nonunique_hash_1%22%2C%22command%22%3A%22transaction_entry%22%2C%22tx_hash%22%3A%221C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B%22%2C%22ledger_index%22%3A3715073%7D) and the second is [in ledger 3721729](websocket-api-tool.html?server=wss%3A%2F%2Fs2.ripple.com%2F&req=%7B%22id%22%3A%22setfee_nonunique_hash_1%22%2C%22command%22%3A%22transaction_entry%22%2C%22tx_hash%22%3A%221C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B%22%2C%22ledger_index%22%3A3721729%7D). Newer [SetFee pseudo-transactions][] include a `LedgerSequence` field so that they are guaranteed to be unique.

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

@@ -2,6 +2,8 @@
A _Transaction_ is the only way to modify the XRP Ledger. Transactions are only final if signed, submitted, and accepted into a validated ledger version following the [consensus process](consensus.html). Some ledger rules also generate _[pseudo-transactions](pseudo-transaction-types.html)_, which aren't signed or submitted, but still must be accepted by consensus. Transactions that fail are also included in ledgers because they modify balances of XRP to pay for the anti-spam [transaction cost][].
Transactions can do more than just send money. In addition to supporting various [Payment Types](payment-types.html), transactions in the XRP Ledger are also used to rotate [cryptographic keys](cryptographic-keys.html), manage other settings, and trade in the XRP Ledger's [decentralized exchange](decentralized-exchange.html). The [`rippled` API reference](rippled-api.html) has a complete [list of transaction types](transaction-types.html).
### Identifying Transactions
@@ -9,6 +11,9 @@ Every signed transaction has a unique `"hash"` that identifies it. The server pr
The transaction hash can be used as a "proof of payment" since anyone can [look up the transaction by its hash](look-up-transaction-results.html) to verify its final status.
{% include '_snippets/setfee_uniqueness_note.md' %}
<!--_ -->
## Claimed Cost Justification
@@ -189,8 +194,8 @@ Example response from the `tx` command:
}
```
## See Also
## See Also
- **Concepts:**
- [Payment Types](payment-types.html)

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

@@ -1,6 +1,6 @@
# Ledger History
The [consensus process](intro-to-consensus.html) creates a chain of [validated ledger versions](ledgers.html), each derived from the previous one by applying a set of transactions. Every `rippled` server stores ledger versions and transaction history locally. The amount of transaction history a server stores depends on how long that server has been online and how much history it is configured to fetch and keep.
The [consensus process](intro-to-consensus.html) creates a chain of [validated ledger versions](ledgers.html), each derived from the previous one by applying a set of [transactions](transaction-basics.html). Every [`rippled` server](the-rippled-server.html) stores ledger versions and transaction history locally. The amount of transaction history a server stores depends on how long that server has been online and how much history it is configured to fetch and keep.
Servers in the peer-to-peer XRP Ledger network share transactions and other data with each other as part of the consensus process. Each server independently builds each new ledger version and compares results with its trusted validators to ensure consistency. (If a consensus of trusted validators disagrees with a server's results, that server fetches the necessary data from its peers to achieve consistency.) Servers can download older data from their peers to fill gaps in their available history. The structure of the ledger uses cryptographic [hashes](basic-data-types.html#hashes) of the data so that any server can verify the integrity and consistency of the data.

4
content/references/rippled-api/transaction-formats/pseudo-transaction-types/setfee.md
View File

@@ -27,7 +27,9 @@ A change in [transaction cost](transaction-cost.html) or [account reserve](reser
| ReferenceFeeUnits | Unsigned Integer | UInt32 | The cost, in fee units, of the reference transaction |
| ReserveBase | Unsigned Integer | UInt32 | The base reserve, in drops |
| ReserveIncrement | Unsigned Integer | UInt32 | The incremental reserve, in drops |
| LedgerSequence | Number | UInt32 | The index of the ledger version where this pseudo-transaction appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |
| LedgerSequence | Number | UInt32 | _(Omitted for some historical `SetFee` pseudo-transactions)_ The index of the ledger version where this pseudo-transaction appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |
{% include '_snippets/setfee_uniqueness_note.md' %}
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

6
content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-validator.md
View File

@@ -343,3 +343,9 @@ For information about how to revoke a master key pair you generated for your val
- [consensus_info method][]
- [validator_list_sites method][]
- [validators method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

2
content/tutorials/manage-the-rippled-server/stand-alone-mode/load-a-saved-ledger-in-stand-alone-mode.md
View File

@@ -1,6 +1,6 @@
# Load a Saved Ledger in Stand-Alone Mode
You can start a `rippled` server in [Stand-Alone Mode](TODO) using a [historical ledger version](TODO) that was previously saved to disk. For example, if your `rippled` server was previously synced with any XRP Ledger peer-to-peer network including [the production Mainnet, the Testnet, or the Devnet](parallel-networks.html), you can load any ledger version your server had available.
You can start a `rippled` server in [Stand-Alone Mode](rippled-server-modes.html) using a [historical ledger version](ledgers.html) that was previously saved to disk. For example, if your `rippled` server was previously synced with any XRP Ledger peer-to-peer network including [the production Mainnet, the Testnet, or the Devnet](parallel-networks.html), you can load any ledger version your server had available.
Loading a historical ledger version so may be useful for "replaying" a ledger to verify that transactions were processed according to the rules of the network, or to compare the results of processing transaction sets with different [amendments](amendments.html) enabled. In the unlikely event that [an attack against the XRP Ledger's consensus mechanism](consensus-protections.html) caused unwanted effects to the shared ledger state, a consensus of validators could "roll back" to a previous, known-good network state starting with this process.

1
content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md
View File

@@ -617,7 +617,6 @@ Off-Ledger Balances</td>
- [AccountRoot object](accountroot.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

2
content/use-cases/use-cases.md
View File

@@ -8,7 +8,7 @@ Here are some of our users' most popular use cases:
Learn how to install, run, and maintain a `rippled` server in validator mode.
* **[List XRP in My Exchange](list-xrp-in-your-exchange.html)**
* **[List XRP in Your Exchange](list-xrp-in-your-exchange.html)**
Integrate with the XRP Ledger to be able to list XRP in your exchange, enabling your users to deposit and withdraw XRP.