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

tx format - capitalization, LedgerSequence field of SetFee, etc.

Browse Source
This commit is contained in:
mDuo13
2016-03-30 16:47:29 -07:00
parent fee3a5dc39
commit 63d5b8b2de
2 changed files with 23 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
content/reference-transaction-format.md
View File

@@ -183,7 +183,7 @@ After a transaction has been submitted, if it gets accepted into a validated led
Multi-signing in Ripple is the act of [authorizing transactions](#authorizing-transactions) for the Ripple Consensus Ledger by using a combination of multiple secret keys. Multi-signing is due to be enabled by an [Amendment](concept-amendments.html) to the Ripple Consensus Protocol. You can use multi-signing in addition to, or instead of, a master key, a [regular key](#setregularkey), or both.
The [SignerListSet transaction](#signerlistset) defines which addresses can authorize transactions from your address. You can include up to 8 addresses in a SignerList. You can achieve several different configurations using the weight and quorum values of the signer list.
The [SignerListSet transaction](#signerlistset) defines which addresses can authorize transactions from your address. You can include up to 8 addresses in a SignerList. You can achieve several different configurations using the weight and quorum values of the SignerList.
For more information, see [How to Multi-Sign](tutorial-multisign.html).
@@ -877,28 +877,29 @@ A change in [transaction cost](concept-transaction-cost.html) or [account reserv
| 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. |
## EnableAmendment ##
Tracks the progress of the [Amendment process](concept-amendments.html#amendment-process) for changes in transaction processing. This can indicate that a proposed Amendment gained or lost majority approval, or that an Amendment has been enabled.
Tracks the progress of the [amendment process](concept-amendments.html#amendment-process) for changes in transaction processing. This can indicate that a proposed amendment gained or lost majority approval, or that an amendment has been enabled.
**Note:** You cannot send a pseudo-transaction, but you may encounter one when processing ledgers.
| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
|-------|-----------|--------------------------------------------------------|-------------|
| Amendment | String | Hash256 | A unique identifier for the Amendment. This is not intended to be a human-readable name. See [Amendments](concept-amendments.html) for a list of known Amendments. |
| LedgerSequence | Number | UInt32 | The index of the ledger version where this Amendment appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |
| Amendment | String | Hash256 | A unique identifier for the amendment. This is not intended to be a human-readable name. See [Amendments](concept-amendments.html) for a list of known amendments. |
| LedgerSequence | Number | UInt32 | The index of the ledger version where this amendment appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |
### EnableAmendment Flags ###
The `Flags` value of the EnableAmendment pseudo-transaction indicates the status of the Amendment at the time of the ledger including the pseudo-transaction.
The `Flags` value of the EnableAmendment pseudo-transaction indicates the status of the amendment at the time of the ledger including the pseudo-transaction.
A `Flags` value of `0` (no flags) indicates that the Amendment has been enabled, and applies to all ledgers afterward. Other `Flags` values are as follows:
A `Flags` value of `0` (no flags) indicates that the amendment has been enabled, and applies to all ledgers afterward. Other `Flags` values are as follows:
| Flag Name | Hex Value | Decimal Value | Description |
|-----------|-----------|---------------|-------------|
| tfGotMajority | 0x00010000 | 65536 | Support for this Amendment increased to at least 80% of trusted validators starting with this ledger version. |
| tfLostMajority | 0x00020000 | 131072 | Support for this Amendment decreased to less than 80% of trusted validators starting with this ledger version. |
| tfGotMajority | 0x00010000 | 65536 | Support for this amendment increased to at least 80% of trusted validators starting with this ledger version. |
| tfLostMajority | 0x00020000 | 131072 | Support for this amendment decreased to less than 80% of trusted validators starting with this ledger version. |

22
reference-transaction-format.html
View File

@@ -300,7 +300,7 @@
</code></pre>
<h3 id="multi-signing">Multi-Signing</h3>
<p>Multi-signing in Ripple is the act of <a href="#authorizing-transactions">authorizing transactions</a> for the Ripple Consensus Ledger by using a combination of multiple secret keys. Multi-signing is due to be enabled by an <a href="concept-amendments.html">Amendment</a> to the Ripple Consensus Protocol. You can use multi-signing in addition to, or instead of, a master key, a <a href="#setregularkey">regular key</a>, or both.</p>
<p>The <a href="#signerlistset">SignerListSet transaction</a> defines which addresses can authorize transactions from your address. You can include up to 8 addresses in a SignerList. You can achieve several different configurations using the weight and quorum values of the signer list.</p>
<p>The <a href="#signerlistset">SignerListSet transaction</a> defines which addresses can authorize transactions from your address. You can include up to 8 addresses in a SignerList. You can achieve several different configurations using the weight and quorum values of the SignerList.</p>
<p>For more information, see <a href="tutorial-multisign.html">How to Multi-Sign</a>.</p>
<h3 id="reliable-transaction-submission">Reliable Transaction Submission</h3>
<p>Reliably submitting transactions is the process of achieving both of the following:</p>
@@ -1350,10 +1350,16 @@
<td>UInt32</td>
<td>The incremental reserve, in drops</td>
</tr>
<tr>
<td>LedgerSequence</td>
<td>Number</td>
<td>UInt32</td>
<td>The index of the ledger version where this pseudo-transaction appears. This distinguishes the pseudo-transaction from other occurrences of the same change.</td>
</tr>
</tbody>
</table>
<h2 id="enableamendment">EnableAmendment</h2>
<p>Tracks the progress of the <a href="concept-amendments.html#amendment-process">Amendment process</a> for changes in transaction processing. This can indicate that a proposed Amendment gained or lost majority approval, or that an Amendment has been enabled.</p>
<p>Tracks the progress of the <a href="concept-amendments.html#amendment-process">amendment process</a> for changes in transaction processing. This can indicate that a proposed amendment gained or lost majority approval, or that an amendment has been enabled.</p>
<p><strong>Note:</strong> You cannot send a pseudo-transaction, but you may encounter one when processing ledgers.</p>
<table>
<thead>
@@ -1369,19 +1375,19 @@
<td>Amendment</td>
<td>String</td>
<td>Hash256</td>
<td>A unique identifier for the Amendment. This is not intended to be a human-readable name. See <a href="concept-amendments.html">Amendments</a> for a list of known Amendments.</td>
<td>A unique identifier for the amendment. This is not intended to be a human-readable name. See <a href="concept-amendments.html">Amendments</a> for a list of known amendments.</td>
</tr>
<tr>
<td>LedgerSequence</td>
<td>Number</td>
<td>UInt32</td>
<td>The index of the ledger version where this Amendment appears. This distinguishes the pseudo-transaction from other occurrences of the same change.</td>
<td>The index of the ledger version where this amendment appears. This distinguishes the pseudo-transaction from other occurrences of the same change.</td>
</tr>
</tbody>
</table>
<h3 id="enableamendment-flags">EnableAmendment Flags</h3>
<p>The <code>Flags</code> value of the EnableAmendment pseudo-transaction indicates the status of the Amendment at the time of the ledger including the pseudo-transaction.</p>
<p>A <code>Flags</code> value of <code>0</code> (no flags) indicates that the Amendment has been enabled, and applies to all ledgers afterward. Other <code>Flags</code> values are as follows:</p>
<p>The <code>Flags</code> value of the EnableAmendment pseudo-transaction indicates the status of the amendment at the time of the ledger including the pseudo-transaction.</p>
<p>A <code>Flags</code> value of <code>0</code> (no flags) indicates that the amendment has been enabled, and applies to all ledgers afterward. Other <code>Flags</code> values are as follows:</p>
<table>
<thead>
<tr>
@@ -1396,13 +1402,13 @@
<td>tfGotMajority</td>
<td>0x00010000</td>
<td>65536</td>
<td>Support for this Amendment increased to at least 80% of trusted validators starting with this ledger version.</td>
<td>Support for this amendment increased to at least 80% of trusted validators starting with this ledger version.</td>
</tr>
<tr>
<td>tfLostMajority</td>
<td>0x00020000</td>
<td>131072</td>
<td>Support for this Amendment decreased to less than 80% of trusted validators starting with this ledger version.</td>
<td>Support for this amendment decreased to less than 80% of trusted validators starting with this ledger version.</td>
</tr>
</tbody>
</table>