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

Dactyl - callout syntax; secret key warning to snippet

Browse Source
This commit is contained in:
mDuo13
2016-05-25 15:48:52 -07:00
parent 3f0768f994
commit 0ed6e40a36
37 changed files with 3130 additions and 95 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
reference-transaction-format.html
View File

@@ -23,7 +23,7 @@
<!-- syntax highlighting -->
<link rel="stylesheet" href="assets/vendor/docco.min.css">
<link rel="stylesheet" href="assets/vendor/docco.min.css" />
<script src="assets/vendor/highlight.min.js"></script>
<!-- syntax selection js -->
@@ -39,6 +39,9 @@
<script src="assets/js/expandcode.js"></script>
<script src="assets/js/fixsidebarscroll.js"></script>
<!-- fontawesome icons -->
<link rel="stylesheet" href="assets/vendor/fontawesome/css/font-awesome.min.css" />
</head>
<body class="page page-template page-template-template-dev-portal page-template-template-dev-portal-php sidebar-primary wpb-js-composer js-comp-ver-3.6.2 vc_responsive">
@@ -287,7 +290,7 @@
}
</code></pre>
<p>After a transaction has been submitted, you can check its status using the API, for example using the <a href="reference-rippled.html#tx">tx command</a>.</p>
<p><strong>Caution:</strong> The success of a transaction is not final unless the transaction appears in a <strong>validated</strong> ledger with the result code <code>tesSUCCESS</code>. See also: <a href="#finality-of-results">Finality of Results</a>.</p>
<p class="devportal-callout caution"><strong>Caution:</strong> The success of a transaction is not final unless the transaction appears in a <strong>validated</strong> ledger with the result code <code>tesSUCCESS</code>. See also: <a href="#finality-of-results">Finality of Results</a>.</p>
<p>Example response from the <code>tx</code> command:</p>
<pre><code>{
"id": 6,
@@ -494,7 +497,7 @@
</tr>
</tbody>
</table>
<p><strong>Note:</strong> The deprecated <code>PreviousTxnID</code> transaction parameter was removed entirely in <a href="https://github.com/ripple/rippled/releases/tag/0.28.0-rc1">rippled 0.28.0</a>. Use <code>AccountTxnID</code> instead.</p>
<p class="devportal-callout note"><strong>Note:</strong> The deprecated <code>PreviousTxnID</code> transaction parameter was removed entirely in <a href="https://github.com/ripple/rippled/releases/tag/0.28.0-rc1">rippled 0.28.0</a>. Use <code>AccountTxnID</code> instead.</p>
<h3 id="auto-fillable-fields">Auto-fillable Fields</h3>
<p>Some fields can be automatically filled in before the transaction is signed, either by a <code>rippled</code> server or by the library used for offline signing. Both <a href="https://github.com/ripple/ripple-lib">ripple-lib</a> and <code>rippled</code> can automatically provide the following values:</p>
<ul>
@@ -506,7 +509,7 @@
<h3 id="transaction-cost">Transaction Cost</h3>
<p>In order to protect the Ripple Consensus Ledger from being disrupted by spam and denial-of-service attacks, each transaction must destroy a small amount of XRP. This <em><a href="concept-transaction-cost.html">transaction cost</a></em> is designed to increase along with the load on the network, making it very expensive to deliberately or inadvertently overload the network.</p>
<p>The <code>Fee</code> field specifies an amount, in <a href="reference-rippled.html#specifying-currency-amounts">drops of XRP</a>, to destroy as the cost for relaying this transaction. If the transaction is included in a validated ledger (whether or not it achieves its intended purpose), then the amount of XRP specified in the <code>Fee</code> parameter is destroyed forever. You can <a href="concept-transaction-cost.html#querying-the-transaction-cost">look up the transaction cost</a> in advance, or <a href="concept-transaction-cost.html#automatically-specifying-the-transaction-cost">let <code>rippled</code> set it automatically</a> when you sign a transaction.</p>
<p><strong>Note:</strong> <a href="#multi-signing">Multi-signed transactions</a> require additional fees to relay to the network.</p>
<p class="devportal-callout note"><strong>Note:</strong> <a href="#multi-signing">Multi-signed transactions</a> require additional fees to relay to the network.</p>
<h3 id="canceling-or-skipping-a-transaction">Canceling or Skipping a Transaction</h3>
<p>An important and intentional feature of the Ripple Network is that a transaction is final as soon as it has been incorporated in a validated ledger.</p>
<p>However, if a transaction has not yet been included in a validated ledger, you can effectively cancel it by rendering it invalid. Typically, this means sending another transaction with the same <code>Sequence</code> value from the same account. If you do not want to perform the same transaction again, you can perform an <a href="#accountset">AccountSet</a> transaction with no options.</p>
@@ -1081,7 +1084,7 @@
<li>A subsequent OfferCreate from the same account crosses the earlier offer. (In this case, the older offer is automatically canceled.)</li>
<li>An offer is found to be unfunded during transaction processing, typically because it was at the tip of the orderbook.</li>
<li>This includes cases where one side or the other of an offer is found to be closer to 0 than <code>rippled</code>'s precision supports.</li>
<li><em>Note:</em> there is a bug that can cause offers to be removed incorrectly in rare circumstances. (See <a href="https://ripplelabs.atlassian.net/browse/RIPD-456">RIPD-456</a> for status.)</li>
<li class="devportal-callout note"><em>Note:</em> there is a bug that can cause offers to be removed incorrectly in rare circumstances. (See <a href="https://ripplelabs.atlassian.net/browse/RIPD-456">RIPD-456</a> for status.)</li>
</ul>
<h4 id="tracking-unfunded-offers">Tracking Unfunded Offers</h4>
<p>Tracking the funding status of all offers can be computationally taxing. In particular, accounts that are actively trading may have a large number of offers open and be frequently involved in transactions that affect the funding status of their offers. Because of this, <code>rippled</code> does not proactively find and remove offers.</p>
@@ -1096,7 +1099,7 @@
<h3 id="expiration">Expiration</h3>
<p>Since transactions can take time to propagate and confirm, the timestamp of a ledger is used to determine offer validity. An offer only expires when its Expiration time occurs prior to the most-recently validated ledger. In other words, an offer with an <code>Expiration</code> field is still considered "active" if its expiration time is later than the timestamp of the most-recently validated ledger, regardless of what your local clock says.</p>
<p>You can determine the final disposition of an offer with an <code>Expiration</code> as soon as you see a fully-validated ledger with a close time equal to or greater than the expiration time.</p>
<p><em>Note:</em> Since only new transactions can modify the ledger, an expired offer can remain 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 <a href="reference-rippled.html#ledger-entry">ledger_entry</a> command). Later on, the expired offer can get finally deleted as a result of another transaction (such as another OfferCreate) if the server encounters it while processing.</p>
<p class="devportal-callout note"><em>Note:</em> Since only new transactions can modify the ledger, an expired offer can remain 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 <a href="reference-rippled.html#ledger-entry">ledger_entry</a> command). Later on, the expired offer can get finally deleted as a result of another transaction (such as another OfferCreate) if the server encounters it while processing.</p>
<h3 id="auto-bridging">Auto-Bridging</h3>
<p>Any OfferCreate that would exchange two non-XRP currencies could potentially use XRP as an intermediary currency in a synthetic order book. This is because of auto-bridging, which serves to improve liquidity across all currency pairs by using XRP as a vehicle currency. This works because of XRP's nature as a native cryptocurrency to the Ripple Consensus Ledger. Offer execution can use a combination of direct and auto-bridged offers to achieve the best total exchange rate.</p>
<p>Example: <em>Anita places an offer to sell GBP and buy BRL. She might fund that this uncommon currency market has few offers. There is one offer with a good rate, but it has insufficient quantity to satisfy Anita's trade. However, both GBP and BRL have active, competitive markets to XRP. Auto-bridging software finds a way to complete Anita's offer by purchasing XRP with GBP from one trader, then selling the XRP to another trader in order to buy BRL. Anita automatically gets the best rate possible by combining the small offer in the direct GBP:BRL market with the better composite rates created by pairing GBP:XRP and XRP:BRL offers.</em></p>
@@ -1174,7 +1177,7 @@
</tr>
</tbody>
</table>
<p><em>Tip:</em> To remove an old offer and replace it with a new one, you can use an <a href="#offercreate">OfferCreate</a> transaction with an <code>OfferSequence</code> parameter, instead of using OfferCancel and another OfferCreate.</p>
<p class="devportal-callout tip"><em>Tip:</em> To remove an old offer and replace it with a new one, you can use an <a href="#offercreate">OfferCreate</a> transaction with an <code>OfferSequence</code> parameter, instead of using OfferCancel and another OfferCreate.</p>
<p>The OfferCancel method returns <a href="#transaction-results">tesSUCCESS</a> even if it did not find an offer with the matching sequence number.</p>
<h2 id="trustset">TrustSet</h2>
<p><a href="https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/SetTrust.cpp" title="Source">[Source]<br/></a></p>
@@ -1388,7 +1391,7 @@
</table>
<h2 id="setfee">SetFee</h2>
<p>A change in <a href="concept-transaction-cost.html">transaction cost</a> or <a href="concept-reserves.html">account reserve</a> requirements as a result of <a href="concept-fee-voting.html">Fee Voting</a>.</p>
<p><strong>Note:</strong> You cannot send a pseudo-transaction, but you may encounter one when processing ledgers.</p>
<p class="devportal-callout note"><strong>Note:</strong> You cannot send a pseudo-transaction, but you may encounter one when processing ledgers.</p>
<pre><code>{
"Account": "rrrrrrrrrrrrrrrrrrrrrhoLvTp",
"BaseFee": "000000000000000A",
@@ -1448,7 +1451,7 @@
</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><strong>Note:</strong> You cannot send a pseudo-transaction, but you may encounter one when processing ledgers.</p>
<p class="devportal-callout note"><strong>Note:</strong> You cannot send a pseudo-transaction, but you may encounter one when processing ledgers.</p>
<table>
<thead>
<tr>
@@ -1535,7 +1538,7 @@
"engine_result_code": 0,
"engine_result_message": "The transaction was applied. Only final in a validated ledger."
</code></pre>
<p><strong><em>Note:</em></strong> A successful result at this stage does not indicate that the transaction has completely succeeded; only that it was successfully applied to the provisional version of the ledger kept by the local server. See <a href="#finality-of-results">Finality of Results</a> for details.</p>
<p class="devportal-callout note"><strong class="devportal-callout note"><em>Note:</em></strong> A successful result at this stage does not indicate that the transaction has completely succeeded; only that it was successfully applied to the provisional version of the ledger kept by the local server. See <a href="#finality-of-results">Finality of Results</a> for details.</p>
<h2 id="looking-up-transaction-results">Looking up Transaction Results</h2>
<p>To see the final result of a transaction, use the <a href="reference-rippled.html#tx"><code>tx</code> command</a>, <a href="reference-rippled.html#account-tx"><code>account_tx</code> command</a>, or other response from <code>rippled</code>. Look for <code>"validated": true</code> to indicate that this response uses a ledger version that has been validated by consensus.</p>
<table>