ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-22 04:35:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

rippled v0.70.0 changes: amendments, queue_data

Browse Source 
Adds 3 new amendments (EnforceInvariants, fix1373, FlowCross) to the
Known Amendments table with descriptions for each. (DOC-963)

Adds the new queue parameter to the ledger command (DOC-801) and
reformats some of the surrounding text.

Updates the path specifications page to clarify some rules that relate
to the FlowCross amendment.

The link to the rippled 0.70.0 release tag is expected to fail until
that version is released.
This commit is contained in:
mDuo13
2017-06-14 20:01:39 -07:00
parent 90a3d877b1
commit 1ae928ef54
9 changed files with 278 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

81
concept-amendments.html
View File

@@ -155,10 +155,13 @@
<li class="level-2"><a href="#testing-amendments">Testing Amendments</a></li>
<li class="level-1"><a href="#known-amendments">Known Amendments</a></li>
<li class="level-2"><a href="#cryptoconditions">CryptoConditions</a></li>
<li class="level-2"><a href="#enforceinvariants">EnforceInvariants</a></li>
<li class="level-2"><a href="#escrow">Escrow</a></li>
<li class="level-2"><a href="#feeescalation">FeeEscalation</a></li>
<li class="level-2"><a href="#fix1368">fix1368</a></li>
<li class="level-2"><a href="#fix1373">fix1373</a></li>
<li class="level-2"><a href="#flow">Flow</a></li>
<li class="level-2"><a href="#flowcross">FlowCross</a></li>
<li class="level-2"><a href="#flowv2">FlowV2</a></li>
<li class="level-2"><a href="#multisign">MultiSign</a></li>
<li class="level-2"><a href="#ownerpaysfee">OwnerPaysFee</a></li>
@@ -253,6 +256,21 @@ TrustSetAuth
</thead>
<tbody>
<tr>
<td align="left"><a href="#flowcross">FlowCross</a></td>
<td align="left">v0.70.0</td>
<td align="left"><a title="Planned: TBD"><img alt="Planned: TBD" class="dactyl_badge" src="https://img.shields.io/badge/Planned-TBD-lightgrey.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#enforceinvariants">EnforceInvariants</a></td>
<td align="left">v0.70.0</td>
<td align="left"><a title="Expected: 2017-06-29"><img alt="Expected: 2017-06-29" class="dactyl_badge" src="https://img.shields.io/badge/Expected-2017--06--29-blue.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#fix1373">fix1373</a></td>
<td align="left">v0.70.0</td>
<td align="left"><a title="Expected: 2017-06-29"><img alt="Expected: 2017-06-29" class="dactyl_badge" src="https://img.shields.io/badge/Expected-2017--06--29-blue.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#shamapv2">SHAMapV2</a></td>
<td align="left">v0.33.0</td>
<td align="left"><a title="Planned: TBD"><img alt="Planned: TBD" class="dactyl_badge" src="https://img.shields.io/badge/Planned-TBD-lightgrey.svg"/></a></td>
@@ -341,6 +359,31 @@ TrustSetAuth
</tbody>
</table>
<p>Although this amendment is enabled, it has no effect unless the <a href="#suspay">SusPay</a> amendment is also enabled. Ripple does not expect SusPay to become enabled. Instead, Ripple plans to incorporate crypto-conditions in the <a href="#escrow">Escrow</a> amendment.</p>
<h2 id="enforceinvariants">EnforceInvariants</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">DC9CA96AEA1DCF83E527D1AFC916EFAF5D27388ECA4060A88817C1238CAEE0BF</td>
<td align="left">In voting; expected 2017-06-29</td>
</tr>
</tbody>
</table>
<p>Adds sanity checks to transaction processing to ensure that certain conditions are always met. This provides an extra layer of protection against bugs in transaction processing that could otherwise cause exploits and vulnerabilities in the Ripple Consensus Ledger. Ripple expects to add more invariant checks in future versions of <code>rippled</code> without additional amendments.</p>
<p>Introduces two new transaction error codes, <code>tecINVARIANT_FAILED</code> and <code>tefINVARIANT_FAILED</code>. Changes transaction processing to add the new checks. Adds a configuration option to disable invariant-checking.</p>
<p>Examples of invariant checks:</p>
<ul>
<li>The total amount of XRP destroyed by a transaction must match the <a href="concept-transaction-cost.html">transaction cost</a> exactly.</li>
<li>XRP cannot be created.</li>
<li><a href="reference-ledger-format.html#accountroot"><code>AccountRoot</code> objects in the ledger</a> cannot be deleted. (See also: <a href="concept-accounts.html#permanence-of-accounts">Permanence of Accounts</a>.)</li>
<li><a href="reference-ledger-format.html#ledger-node-types">An object in the ledger</a> cannot change its type. (The <code>LedgerEntryType</code> field is immutable.)</li>
<li>There cannot be a trust line for XRP.</li>
</ul>
<h2 id="escrow">Escrow</h2>
<table>
<thead>
@@ -398,6 +441,23 @@ TrustSetAuth
</tbody>
</table>
<p>Fixes a minor bug in transaction processing that causes some payments to fail when they should be valid. Specifically, during payment processing, some payment steps that are expected to produce a certain amount of currency may produce a microscopically different amount, due to a loss of precision related to floating-point number representation. When this occurs, those payments fail because they cannot deliver the exact amount intended. The fix1368 amendment corrects transaction processing so payments can no longer fail in this manner.</p>
<h2 id="fix1373">fix1373</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">42EEA5E28A97824821D4EF97081FE36A54E9593C6E4F20CBAE098C69D2E072DC</td>
<td align="left">In voting; expected 2017-06-29</td>
</tr>
</tbody>
</table>
<p>Fixes a minor bug in transaction processing that causes failures when trying to prepare certain <a href="concept-paths.html">payment paths</a> for processing. As a result, payments could not use certain paths that should have been valid but were invalidly prepared. Without this amendment, those payments are forced to use less-preferable paths or may even fail.</p>
<p>The fix1373 amendment corrects the issue so that the paths are properly prepared and payments can use them. It also disables some inappropriate paths that are currently allowed, including paths whose <a href="concept-paths.html#path-specifications">steps</a> include conflicting fields and paths that loop through the same object more than once.</p>
<h2 id="flow">Flow</h2>
<table>
<thead>
@@ -415,6 +475,27 @@ TrustSetAuth
</table>
<p>Replaces the payment processing engine with a more robust and efficient rewrite called the Flow engine. The new version of the payment processing engine is intended to follow the same rules as the old one, but occasionally produces different results due to floating point rounding. This Amendment supersedes the <a href="https://ripple.com/dev-blog/flowv2-amendment-vetoed/">FlowV2</a> amendment.</p>
<p>The Flow Engine also makes it easier to improve and expand the payment engine with further Amendments.</p>
<h2 id="flowcross">FlowCross</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC</td>
<td align="left">Released but not enabled</td>
</tr>
</tbody>
</table>
<p>Streamlines the offer crossing logic in the RCL's decentralized exchange. Uses the updated code from the <a href="#flow">Flow</a> amendment to power offer crossing, so <a href="reference-transaction-format.html#offercreate">OfferCreate transactions</a> and <a href="reference-transaction-format.html#payment">Payment transactions</a> share more code. This has subtle differences in how offers are processed:</p>
<ul>
<li>Rounding is slightly different in some cases.</li>
<li>Due to differences in rounding, some combinations of offers may be ranked higher or lower than by the old logic, and taken preferentially.</li>
<li>The new logic may delete more or fewer offers than the old logic. (This includes cases caused by differences in rounding and offers that were incorrectly removed as unfunded by the old logic.)</li>
</ul>
<h2 id="flowv2">FlowV2</h2>
<table>
<thead>

1
concept-partial-payments.html
View File

@@ -79,6 +79,7 @@
<li><a href="tutorial-rippleapi-beginners-guide.html">RippleAPI Beginners Guide</a></li>
<li><a href="tutorial-rippled-setup.html">rippled Setup</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
<li><a href="tutorial-listing-xrp.html">Listing XRP as an Exchange</a></li>
</ul>
</li>
<li class="dropdown">

43
concept-paths.html
View File

@@ -209,39 +209,46 @@
<table>
<thead>
<tr>
<th>Field</th>
<th>Value</th>
<th>Description</th>
<th align="left">Field</th>
<th align="left">Value</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>account</td>
<td>String - Address</td>
<td>(Optional) If present, this path step represents rippling through the specified address.</td>
<td align="left"><code>account</code></td>
<td align="left">String - Address</td>
<td align="left"><em>(Optional)</em> If present, this path step represents rippling through the specified address. MUST NOT be provided if this step specifies the <code>currency</code> or <code>issuer</code> fields.</td>
</tr>
<tr>
<td>currency</td>
<td>String - currency code</td>
<td>(Optional) If present, this path step represents changing currencies through an order book. The currency specified indicates the new currency.</td>
<td align="left"><code>currency</code></td>
<td align="left">String - Currency Code</td>
<td align="left"><em>(Optional)</em> If present, this path step represents changing currencies through an order book. The currency specified indicates the new currency. MUST NOT be provided if this step specifies the <code>account</code> field.</td>
</tr>
<tr>
<td>issuer</td>
<td>String - Address</td>
<td>(Optional) If the path step represents changing currencies through an order book, this field indicates the issuer of the new currency. This field is not present when changing to XRP.</td>
<td align="left"><code>issuer</code></td>
<td align="left">String - Address</td>
<td align="left"><em>(Optional)</em> If the path step represents changing currencies through an order book, this field indicates the issuer of the new currency. If omitted in a step with a non-XRP <code>currency</code>, the previous step of the path defines the issuer. MUST be omitted if the <code>currency</code> is XRP. MUST NOT be provided if this step specifies the <code>account</code> field.</td>
</tr>
<tr>
<td>type</td>
<td>Integer</td>
<td><strong>DEPRECATED</strong> (Optional) An indicator of which other fields are present.</td>
<td align="left"><code>type</code></td>
<td align="left">Integer</td>
<td align="left"><strong>DEPRECATED</strong> <em>(Optional)</em> An indicator of which other fields are present.</td>
</tr>
<tr>
<td>type_hex</td>
<td>String</td>
<td><strong>DEPRECATED</strong>: (Optional) A hexadecimal representation of the <code>type</code> field.</td>
<td align="left"><code>type_hex</code></td>
<td align="left">String</td>
<td align="left"><strong>DEPRECATED</strong>: <em>(Optional)</em> A hexadecimal representation of the <code>type</code> field.</td>
</tr>
</tbody>
</table>
<p>In summary, the following combination of fields are valid, optionally with <code>type</code>, <code>type_hex</code>, or both:</p>
<ul>
<li><code>account</code> by itself</li>
<li><code>currency</code> by itself</li>
<li><code>currency</code> and <code>issuer</code> as long as the <code>currency</code> is not XRP</li>
</ul>
<p>Any other use of <code>account</code>, <code>currency</code>, and <code>issuer</code> fields in a path step is invalid.</p>
<p>The <code>type</code> field, used for the binary serialization of a path set, is actually constructed through bitwise operations on a single integer. The bits are defined as follows:</p>
<table>
<thead>

46
content/concept-amendments.md
View File

@@ -113,6 +113,9 @@ The following is a comprehensive list of all known amendments and their status o
| Name | Introduced | Status |
|:--------------------------------------|:-----------|:------------------------|
| [FlowCross](#flowcross) | v0.70.0 | [Planned: TBD]( "BADGE_LIGHTGREY") |
| [EnforceInvariants](#enforceinvariants) | v0.70.0 | [Expected: 2017-06-29]( "BADGE_BLUE") |
| [fix1373](#fix1373) | v0.70.0 | [Expected: 2017-06-29]( "BADGE_BLUE") |
| [SHAMapV2](#shamapv2) | v0.33.0 | [Planned: TBD]( "BADGE_LIGHTGREY") |
| [OwnerPaysFee](#ownerpaysfee) | v0.33.0 | [Planned: TBD]( "BADGE_LIGHTGREY") |
| [Tickets](#tickets) | N/A | [Planned: TBD]( "BADGE_LIGHTGREY") |
@@ -139,6 +142,25 @@ The following is a comprehensive list of all known amendments and their status o
Although this amendment is enabled, it has no effect unless the [SusPay](#suspay) amendment is also enabled. Ripple does not expect SusPay to become enabled. Instead, Ripple plans to incorporate crypto-conditions in the [Escrow](#escrow) amendment.
## EnforceInvariants
| Amendment ID | Status |
|:-----------------------------------------------------------------|:--------|
| DC9CA96AEA1DCF83E527D1AFC916EFAF5D27388ECA4060A88817C1238CAEE0BF | In voting; expected 2017-06-29 |
Adds sanity checks to transaction processing to ensure that certain conditions are always met. This provides an extra layer of protection against bugs in transaction processing that could otherwise cause exploits and vulnerabilities in the Ripple Consensus Ledger. Ripple expects to add more invariant checks in future versions of `rippled` without additional amendments.
Introduces two new transaction error codes, `tecINVARIANT_FAILED` and `tefINVARIANT_FAILED`. Changes transaction processing to add the new checks. Adds a configuration option to disable invariant-checking.
Examples of invariant checks:
- The total amount of XRP destroyed by a transaction must match the [transaction cost](concept-transaction-cost.html) exactly.
- XRP cannot be created.
- [`AccountRoot` objects in the ledger](reference-ledger-format.html#accountroot) cannot be deleted. (See also: [Permanence of Accounts](concept-accounts.html#permanence-of-accounts).)
- [An object in the ledger](reference-ledger-format.html#ledger-node-types) cannot change its type. (The `LedgerEntryType` field is immutable.)
- There cannot be a trust line for XRP.
## Escrow
| Amendment ID | Status |
@@ -177,6 +199,17 @@ A transaction remains in the queue until one of the following happens:
Fixes a minor bug in transaction processing that causes some payments to fail when they should be valid. Specifically, during payment processing, some payment steps that are expected to produce a certain amount of currency may produce a microscopically different amount, due to a loss of precision related to floating-point number representation. When this occurs, those payments fail because they cannot deliver the exact amount intended. The fix1368 amendment corrects transaction processing so payments can no longer fail in this manner.
## fix1373
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 42EEA5E28A97824821D4EF97081FE36A54E9593C6E4F20CBAE098C69D2E072DC | In voting; expected 2017-06-29 |
Fixes a minor bug in transaction processing that causes failures when trying to prepare certain [payment paths](concept-paths.html) for processing. As a result, payments could not use certain paths that should have been valid but were invalidly prepared. Without this amendment, those payments are forced to use less-preferable paths or may even fail.
The fix1373 amendment corrects the issue so that the paths are properly prepared and payments can use them. It also disables some inappropriate paths that are currently allowed, including paths whose [steps](concept-paths.html#path-specifications) include conflicting fields and paths that loop through the same object more than once.
## Flow
| Amendment ID | Status |
@@ -188,6 +221,19 @@ Replaces the payment processing engine with a more robust and efficient rewrite
The Flow Engine also makes it easier to improve and expand the payment engine with further Amendments.
## FlowCross
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC | Released but not enabled |
Streamlines the offer crossing logic in the RCL's decentralized exchange. Uses the updated code from the [Flow](#flow) amendment to power offer crossing, so [OfferCreate transactions][] and [Payment transactions][] share more code. This has subtle differences in how offers are processed:
- Rounding is slightly different in some cases.
- Due to differences in rounding, some combinations of offers may be ranked higher or lower than by the old logic, and taken preferentially.
- The new logic may delete more or fewer offers than the old logic. (This includes cases caused by differences in rounding and offers that were incorrectly removed as unfunded by the old logic.)
## FlowV2
| Amendment ID | Status |

22
content/concept-paths.md
View File

@@ -69,12 +69,22 @@ You can use the [`tfNoDirectRipple` flag](reference-transaction-format.html#paym
A path set is an array. Each member of the path set is another array that represents an individual _path_. Each member of a path is an object that specifies the step. A step has the following fields:
| Field | Value | Description |
|-------|-------|-------------|
| account | String - Address | (Optional) If present, this path step represents rippling through the specified address. |
| currency | String - currency code | (Optional) If present, this path step represents changing currencies through an order book. The currency specified indicates the new currency. |
| issuer | String - Address | (Optional) If the path step represents changing currencies through an order book, this field indicates the issuer of the new currency. This field is not present when changing to XRP. |
| type | Integer | **DEPRECATED** (Optional) An indicator of which other fields are present. |
| type_hex | String | **DEPRECATED**: (Optional) A hexadecimal representation of the `type` field. |
|:-----------|:-----------------------|:---------------------------------------|
| `account` | String - Address | _(Optional)_ If present, this path step represents rippling through the specified address. MUST NOT be provided if this step specifies the `currency` or `issuer` fields. |
| `currency` | String - Currency Code | _(Optional)_ If present, this path step represents changing currencies through an order book. The currency specified indicates the new currency. MUST NOT be provided if this step specifies the `account` field. |
| `issuer` | String - Address | _(Optional)_ If the path step represents changing currencies through an order book, this field indicates the issuer of the new currency. If omitted in a step with a non-XRP `currency`, the previous step of the path defines the issuer. MUST be omitted if the `currency` is XRP. MUST NOT be provided if this step specifies the `account` field. |
| `type` | Integer | **DEPRECATED** _(Optional)_ An indicator of which other fields are present. |
| `type_hex` | String | **DEPRECATED**: _(Optional)_ A hexadecimal representation of the `type` field. |
In summary, the following combination of fields are valid, optionally with `type`, `type_hex`, or both:
- `account` by itself
- `currency` by itself
- `currency` and `issuer` as long as the `currency` is not XRP
Any other use of `account`, `currency`, and `issuer` fields in a path step is invalid.
The `type` field, used for the binary serialization of a path set, is actually constructed through bitwise operations on a single integer. The bits are defined as follows:

35
content/reference-rippled.md
View File

@@ -3314,7 +3314,7 @@ The key generated by this method can also be used as a regular key for an accoun
The globally-shared ledger is the core of the Ripple Network. Each `rippled` server keeps a current version of the ledger, which contains all the accounts, transactions, offers, and other data in the network in an optimized tree format. As transactions and offers are proposed, each server incorporates them into its current copy of the ledger, closes it periodically, and (if configured) participates in advancing the globally-validated version. After the network reaches consensus, that ledger version is validated and becomes permanently immutable. Any transactions that were not included in one ledger become candidates to be included in the next validated version.
## ledger ##
## ledger
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/LedgerHandler.cpp "Source")
Retrieve information about the public ledger.
@@ -3376,12 +3376,13 @@ The request can contain the following parameters:
|:---------------|:---------------------------|:-------------------------------|
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. (See [Specifying a Ledger](#specifying-ledgers)). |
| `ledger_index` | String or Unsigned Integer | _(Optional)_ The sequence number of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-ledgers)) |
| `full` | Boolean | (Optional, defaults to false) **Admin required** If true, return full information on the entire ledger. Ignored if you did not specify a ledger. (Equivalent to enabling `transactions`, `accounts`, and `expand`.) **Caution:** This is a very large amount of data -- on the order of several hundred megabytes! |
| `accounts` | Boolean | (Optional, defaults to false) **Admin required.** If true, return information on accounts in the ledger. Ignored if you did not specify a ledger. **Caution:** This returns a very large amount of data! |
| `transactions` | Boolean | (Optional, defaults to false) If true, return information on transactions in the specified ledger version. Ignored if you did not specify a ledger. |
| `expand` | Boolean | (Optional, defaults to false) Provide full JSON-formatted information for transaction/account information instead of only hashes. Ignored unless you requested transactions, accounts, or both. |
| `owner_funds` | Boolean | (Optional, defaults to false) Include `owner_funds` field in the metadata of OfferCreate transactions in the response. Ignored unless transactions are included and `expand` is true. |
| `binary` | Boolean | (Optional, defaults to false) If `transactions` and `expand` are both true, and this option is also true, return transaction information in binary format instead of JSON format. [New in: rippled 0.28.0][] |
| `full` | Boolean | _(Optional)_ **Admin required** If `true`, return full information on the entire ledger. Ignored if you did not specify a ledger. Defaults to `false`. (Equivalent to enabling `transactions`, `accounts`, and `expand`.) **Caution:** This is a very large amount of data -- on the order of several hundred megabytes! |
| `accounts` | Boolean | _(Optional)_ **Admin required.** If `true`, return information on accounts in the ledger. Ignored if you did not specify a ledger. Defaults to `false`. **Caution:** This returns a very large amount of data! |
| `transactions` | Boolean | _(Optional)_ If `true`, return information on transactions in the specified ledger version. Defaults to `false`. Ignored if you did not specify a ledger. |
| `expand` | Boolean | _(Optional)_ Provide full JSON-formatted information for transaction/account information instead of only hashes. Defaults to `false`. Ignored unless you request transactions, accounts, or both. |
| `owner_funds` | Boolean | _(Optional)_ If `true`, include `owner_funds` field in the metadata of OfferCreate transactions in the response. Defaults to `false`. Ignored unless transactions are included and `expand` is true. |
| `binary` | Boolean | _(Optional)_ If `true`, and `transactions` and `expand` are both also `true`, return transaction information in binary format (hexadecimal string) instead of JSON format. [New in: rippled 0.28.0][] |
| `queue` | Boolean | _(Optional)_ If `true`, and the command is requesting the `current` ledger, includes an array of [queued transactions](concept-transaction-cost.html#queued-transactions) in the results.
The `ledger` field is deprecated and may be removed without further notice.
@@ -3474,13 +3475,29 @@ The response follows the [standard format](#response-formatting), with a success
| `ledger.parent_hash` | String | Unique identifying hash of the ledger that came immediately before this one. |
| `ledger.total_coins` | String | Total number of XRP drops in the network, as a quoted integer. (This decreases as transaction costs destroy XRP.) |
| `ledger.transaction_hash` | String | Hash of the transaction information included in this ledger, as hex |
| `ledger.transactions` | Array | (Omitted unless requested) Transactions applied in this ledger version. By default, members are the transactions' identifying [Hash][] strings. If expanded, contains full representations of the transactions instead, in either JSON or binary depending on whether the request specified `binary` as true. |
| `ledger.transactions` | Array | (Omitted unless requested) Transactions applied in this ledger version. By default, members are the transactions' identifying [Hash][] strings. If the request specified `expand` as true, members are full representations of the transactions instead, in either JSON or binary depending on whether the request specified `binary` as true. |
| `ledger_hash` | String | Unique identifying hash of the entire ledger. |
| `ledger_index` | Number | The [Ledger Index][] of this ledger. |
| `queue_data` | Array | (Omitted unless requested with the `queue` parameter) Array of objects describing queued transactions, in the same order as the queue. If the request specified `expand` as true, members contain full representations of the transactions, in either JSON or binary depending on whether the request specified `binary` as true. Requires the [FeeEscalation amendment](concept-amendments.html#known-amendments). [New in: rippled 0.70.0][] |
The following fields are deprecated and may be removed without further notice: `accepted`, `hash`, `seqNum`, `totalCoins`.
**Note on `owner_funds`:** If the request specified `"owner_funds": true` and expanded transactions, the response has a field `owner_funds` in the `metaData` object of each [OfferCreate-type transaction](reference-transaction-format.html#offercreate). The purpose of this field is to make it easier to track the [funding status of offers](reference-transaction-format.html#lifecycle-of-an-offer) with each new validated ledger. This field is defined slightly different than the version of this field in [Order Book subscription streams](#order-book-streams):
Each member of the `queue_data` array represents one transaction in the queue. Some fields of this object may be omitted because they have not yet been calculated. The fields of this object are as follows:
| Field | Value | Description |
|:--------------------|:-----------------|:------------------------------------|
| `account` | String | The [Address][] of the sender for this queued transaction. |
| `tx` | String or Object | By default, this is a String containing the [identifying hash](#hashes) of the transaction. If transactions are expanded in binary format, this is an object whose only field is `tx_blob`, containing the binary form of the transaction as a decimal string. If transactions are expanded in JSON format, this is an object containing the [transaction object](reference-transaction-format.html) including the transaction's identifying hash in the `hash` field. |
| `retries_remaining` | Number | How many times this transaction can be retried before being dropped. |
| `preflight_result` | String | The tentative result from preliminary transaction checking. This is always `tesSUCCESS`. |
| `last_result` | String | _(May be omitted)_ If this transaction was put in the queue after getting a [retriable (`ter`) result](reference-transaction-format.html#result-categories), this is the exact `ter` result code it got. |
| `auth_change` | Boolean | _(May be omitted)_ Whether this transaction changes this address's [ways of authorizing transactions](reference-transaction-format.html#authorizing-transactions). |
| `fee` | String | _(May be omitted)_ The [Transaction Cost](concept-transaction-cost.html) of this transaction, in [drops of XRP](#specifying-currency-amounts). |
| `fee_level` | String | _(May be omitted)_ The transaction cost of this transaction, relative to the minimum cost for this type of transaction, in [fee levels][]. |
| `max_spend_drops` | String | _(May be omitted)_ The maximum amount of XRP, [in drops](#specifying-currency-amounts), this transaction could send or destroy. |
| `seq` | Integer | _(May be omitted)_ The [Sequence Number][] of this transaction. |
If the request specified `"owner_funds": true` and expanded transactions, the response has a field `owner_funds` in the `metaData` object of each [OfferCreate-type transaction](reference-transaction-format.html#offercreate). The purpose of this field is to make it easier to track the [funding status of offers](reference-transaction-format.html#lifecycle-of-an-offer) with each new validated ledger. This field is defined slightly different than the version of this field in [Order Book subscription streams](#order-book-streams):
| `Field` | Value | Description |
|:--------------|:-------|:----------------------------------------------------|

1
content/snippets/rippled_versions.md
View File

@@ -26,3 +26,4 @@
[New in: rippled 0.32.1]: https://github.com/ripple/rippled/releases/tag/0.32.1 "BADGE_BLUE"
[New in: rippled 0.33.0]: https://github.com/ripple/rippled/releases/tag/0.33.0 "BADGE_BLUE"
[New in: rippled 0.50.0]: https://github.com/ripple/rippled/releases/tag/0.50.0 "BADGE_BLUE"
[New in: rippled 0.70.0]: https://github.com/ripple/rippled/releases/tag/0.70.0 "BADGE_BLUE"

88
reference-rippled.html
View File

@@ -4210,32 +4210,37 @@ rippled ledger current
<tr>
<td align="left"><code>full</code></td>
<td align="left">Boolean</td>
<td align="left">(Optional, defaults to false) <strong>Admin required</strong> If true, return full information on the entire ledger. Ignored if you did not specify a ledger. (Equivalent to enabling <code>transactions</code>, <code>accounts</code>, and <code>expand</code>.) <strong>Caution:</strong> This is a very large amount of data -- on the order of several hundred megabytes!</td>
<td align="left"><em>(Optional)</em> <strong>Admin required</strong> If <code>true</code>, return full information on the entire ledger. Ignored if you did not specify a ledger. Defaults to <code>false</code>. (Equivalent to enabling <code>transactions</code>, <code>accounts</code>, and <code>expand</code>.) <strong>Caution:</strong> This is a very large amount of data -- on the order of several hundred megabytes!</td>
</tr>
<tr>
<td align="left"><code>accounts</code></td>
<td align="left">Boolean</td>
<td align="left">(Optional, defaults to false) <strong>Admin required.</strong> If true, return information on accounts in the ledger. Ignored if you did not specify a ledger. <strong>Caution:</strong> This returns a very large amount of data!</td>
<td align="left"><em>(Optional)</em> <strong>Admin required.</strong> If <code>true</code>, return information on accounts in the ledger. Ignored if you did not specify a ledger. Defaults to <code>false</code>. <strong>Caution:</strong> This returns a very large amount of data!</td>
</tr>
<tr>
<td align="left"><code>transactions</code></td>
<td align="left">Boolean</td>
<td align="left">(Optional, defaults to false) If true, return information on transactions in the specified ledger version. Ignored if you did not specify a ledger.</td>
<td align="left"><em>(Optional)</em> If <code>true</code>, return information on transactions in the specified ledger version. Defaults to <code>false</code>. Ignored if you did not specify a ledger.</td>
</tr>
<tr>
<td align="left"><code>expand</code></td>
<td align="left">Boolean</td>
<td align="left">(Optional, defaults to false) Provide full JSON-formatted information for transaction/account information instead of only hashes. Ignored unless you requested transactions, accounts, or both.</td>
<td align="left"><em>(Optional)</em> Provide full JSON-formatted information for transaction/account information instead of only hashes. Defaults to <code>false</code>. Ignored unless you request transactions, accounts, or both.</td>
</tr>
<tr>
<td align="left"><code>owner_funds</code></td>
<td align="left">Boolean</td>
<td align="left">(Optional, defaults to false) Include <code>owner_funds</code> field in the metadata of OfferCreate transactions in the response. Ignored unless transactions are included and <code>expand</code> is true.</td>
<td align="left"><em>(Optional)</em> If <code>true</code>, include <code>owner_funds</code> field in the metadata of OfferCreate transactions in the response. Defaults to <code>false</code>. Ignored unless transactions are included and <code>expand</code> is true.</td>
</tr>
<tr>
<td align="left"><code>binary</code></td>
<td align="left">Boolean</td>
<td align="left">(Optional, defaults to false) If <code>transactions</code> and <code>expand</code> are both true, and this option is also true, return transaction information in binary format instead of JSON format. <a href="https://github.com/ripple/rippled/releases/tag/0.28.0" title="New in: rippled 0.28.0"><img alt="New in: rippled 0.28.0" class="dactyl_badge" src="https://img.shields.io/badge/New%20in-rippled%200.28.0-blue.svg"/></a></td>
<td align="left"><em>(Optional)</em> If <code>true</code>, and <code>transactions</code> and <code>expand</code> are both also <code>true</code>, return transaction information in binary format (hexadecimal string) instead of JSON format. <a href="https://github.com/ripple/rippled/releases/tag/0.28.0" title="New in: rippled 0.28.0"><img alt="New in: rippled 0.28.0" class="dactyl_badge" src="https://img.shields.io/badge/New%20in-rippled%200.28.0-blue.svg"/></a></td>
</tr>
<tr>
<td align="left"><code>queue</code></td>
<td align="left">Boolean</td>
<td align="left"><em>(Optional)</em> If <code>true</code>, and the command is requesting the <code>current</code> ledger, includes an array of <a href="concept-transaction-cost.html#queued-transactions">queued transactions</a> in the results.</td>
</tr>
</tbody>
</table>
@@ -4376,7 +4381,7 @@ rippled ledger current
<tr>
<td align="left"><code>ledger.transactions</code></td>
<td align="left">Array</td>
<td align="left">(Omitted unless requested) Transactions applied in this ledger version. By default, members are the transactions' identifying <a href="#hashes">Hash</a> strings. If expanded, contains full representations of the transactions instead, in either JSON or binary depending on whether the request specified <code>binary</code> as true.</td>
<td align="left">(Omitted unless requested) Transactions applied in this ledger version. By default, members are the transactions' identifying <a href="#hashes">Hash</a> strings. If the request specified <code>expand</code> as true, members are full representations of the transactions instead, in either JSON or binary depending on whether the request specified <code>binary</code> as true.</td>
</tr>
<tr>
<td align="left"><code>ledger_hash</code></td>
@@ -4388,10 +4393,77 @@ rippled ledger current
<td align="left">Number</td>
<td align="left">The <a href="#ledger-index">Ledger Index</a> of this ledger.</td>
</tr>
<tr>
<td align="left"><code>queue_data</code></td>
<td align="left">Array</td>
<td align="left">(Omitted unless requested with the <code>queue</code> parameter) Array of objects describing queued transactions, in the same order as the queue. If the request specified <code>expand</code> as true, members contain full representations of the transactions, in either JSON or binary depending on whether the request specified <code>binary</code> as true. Requires the <a href="concept-amendments.html#known-amendments">FeeEscalation amendment</a>. <a href="https://github.com/ripple/rippled/releases/tag/0.70.0" title="New in: rippled 0.70.0"><img alt="New in: rippled 0.70.0" class="dactyl_badge" src="https://img.shields.io/badge/New%20in-rippled%200.70.0-blue.svg"/></a></td>
</tr>
</tbody>
</table>
<p>The following fields are deprecated and may be removed without further notice: <code>accepted</code>, <code>hash</code>, <code>seqNum</code>, <code>totalCoins</code>.</p>
<p><strong>Note on <code>owner_funds</code>:</strong> If the request specified <code>"owner_funds": true</code> and expanded transactions, the response has a field <code>owner_funds</code> in the <code>metaData</code> object of each <a href="reference-transaction-format.html#offercreate">OfferCreate-type transaction</a>. The purpose of this field is to make it easier to track the <a href="reference-transaction-format.html#lifecycle-of-an-offer">funding status of offers</a> with each new validated ledger. This field is defined slightly different than the version of this field in <a href="#order-book-streams">Order Book subscription streams</a>:</p>
<p>Each member of the <code>queue_data</code> array represents one transaction in the queue. Some fields of this object may be omitted because they have not yet been calculated. The fields of this object are as follows:</p>
<table>
<thead>
<tr>
<th align="left">Field</th>
<th align="left">Value</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left"><code>account</code></td>
<td align="left">String</td>
<td align="left">The <a href="#addresses">Address</a> of the sender for this queued transaction.</td>
</tr>
<tr>
<td align="left"><code>tx</code></td>
<td align="left">String or Object</td>
<td align="left">By default, this is a String containing the <a href="#hashes">identifying hash</a> of the transaction. If transactions are expanded in binary format, this is an object whose only field is <code>tx_blob</code>, containing the binary form of the transaction as a decimal string. If transactions are expanded in JSON format, this is an object containing the <a href="reference-transaction-format.html">transaction object</a> including the transaction's identifying hash in the <code>hash</code> field.</td>
</tr>
<tr>
<td align="left"><code>retries_remaining</code></td>
<td align="left">Number</td>
<td align="left">How many times this transaction can be retried before being dropped.</td>
</tr>
<tr>
<td align="left"><code>preflight_result</code></td>
<td align="left">String</td>
<td align="left">The tentative result from preliminary transaction checking. This is always <code>tesSUCCESS</code>.</td>
</tr>
<tr>
<td align="left"><code>last_result</code></td>
<td align="left">String</td>
<td align="left"><em>(May be omitted)</em> If this transaction was put in the queue after getting a <a href="reference-transaction-format.html#result-categories">retriable (<code>ter</code>) result</a>, this is the exact <code>ter</code> result code it got.</td>
</tr>
<tr>
<td align="left"><code>auth_change</code></td>
<td align="left">Boolean</td>
<td align="left"><em>(May be omitted)</em> Whether this transaction changes this address's <a href="reference-transaction-format.html#authorizing-transactions">ways of authorizing transactions</a>.</td>
</tr>
<tr>
<td align="left"><code>fee</code></td>
<td align="left">String</td>
<td align="left"><em>(May be omitted)</em> The <a href="concept-transaction-cost.html">Transaction Cost</a> of this transaction, in <a href="#specifying-currency-amounts">drops of XRP</a>.</td>
</tr>
<tr>
<td align="left"><code>fee_level</code></td>
<td align="left">String</td>
<td align="left"><em>(May be omitted)</em> The transaction cost of this transaction, relative to the minimum cost for this type of transaction, in <a href="concept-transaction-cost.html#fee-levels">fee levels</a>.</td>
</tr>
<tr>
<td align="left"><code>max_spend_drops</code></td>
<td align="left">String</td>
<td align="left"><em>(May be omitted)</em> The maximum amount of XRP, <a href="#specifying-currency-amounts">in drops</a>, this transaction could send or destroy.</td>
</tr>
<tr>
<td align="left"><code>seq</code></td>
<td align="left">Integer</td>
<td align="left"><em>(May be omitted)</em> The <a href="#account-sequence">Sequence Number</a> of this transaction.</td>
</tr>
</tbody>
</table>
<p>If the request specified <code>"owner_funds": true</code> and expanded transactions, the response has a field <code>owner_funds</code> in the <code>metaData</code> object of each <a href="reference-transaction-format.html#offercreate">OfferCreate-type transaction</a>. The purpose of this field is to make it easier to track the <a href="reference-transaction-format.html#lifecycle-of-an-offer">funding status of offers</a> with each new validated ledger. This field is defined slightly different than the version of this field in <a href="#order-book-streams">Order Book subscription streams</a>:</p>
<table>
<thead>
<tr>

1
tutorial-listing-xrp.html
View File

@@ -90,6 +90,7 @@
<li><a href="concept-fee-voting.html">Fee Voting</a></li>
<li><a href="concept-fees.html">Fees (Disambiguation)</a></li>
<li><a href="concept-freeze.html">Freeze</a></li>
<li><a href="concept-partial-payments.html">Partial Payments</a></li>
<li><a href="concept-paths.html">Paths</a></li>
<li><a href="concept-reserves.html">Reserves</a></li>
<li><a href="concept-stand-alone-mode.html">Stand-Alone Mode</a></li>