mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-14 08:45:50 +00:00
fix broken links
This commit is contained in:
@@ -222,7 +222,7 @@
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Set the <code>Fee</code>, <code>Sequence</code>, and <code>LastLedgerSequence</code> parameters <a href="reference-transaction-format.html#signing-and-sending-transactions">in the typical way</a>.</p>
|
||||
<p>Set the <code>Fee</code>, <code>Sequence</code>, and <code>LastLedgerSequence</code> parameters <a href="reference-transaction-format.html#signing-and-submitting-transactions">in the typical way</a>.</p>
|
||||
<p>Example of submitting a TrustSet transaction to enable an individual freeze using the <a href="reference-rippled.html#websocket-api">WebSocket API</a>:</p>
|
||||
<pre><code>{
|
||||
"id": 12,
|
||||
|
||||
@@ -82,7 +82,7 @@ To enable or disable Individual Freeze on a specific trust line, send a `TrustSe
|
||||
| LimitAmount.value | String | The amount of currency you trust this counterparty to issue to you, as a quoted number. From the perspective of a gateway, this is typically `"0"`. |
|
||||
| Flags | Number | To enable a freeze, use a value with the bit `0x00100000` (tfSetFreeze) enabled. To disable a freeze, use a value with the bit `0x00200000` (tfClearFreeze) enabled instead. |
|
||||
|
||||
Set the `Fee`, `Sequence`, and `LastLedgerSequence` parameters [in the typical way](reference-transaction-format.html#signing-and-sending-transactions).
|
||||
Set the `Fee`, `Sequence`, and `LastLedgerSequence` parameters [in the typical way](reference-transaction-format.html#signing-and-submitting-transactions).
|
||||
|
||||
Example of submitting a TrustSet transaction to enable an individual freeze using the [WebSocket API](reference-rippled.html#websocket-api):
|
||||
|
||||
|
||||
@@ -9021,7 +9021,7 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
## fee ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/Fee1.cpp "Source")
|
||||
|
||||
The `fee` command reports the current state of the open-ledger requirements for the [transaction cost](concept-transaction-cost.html). This requires the [FeeEscalation amendment](concept-amendments.html#feeescalationi) to be enabled. _(New in [version 0.31.0][])_
|
||||
The `fee` command reports the current state of the open-ledger requirements for the [transaction cost](concept-transaction-cost.html). This requires the [FeeEscalation amendment](concept-amendments.html#feeescalation) to be enabled. _(New in [version 0.31.0][])_
|
||||
|
||||
_The `fee` method is an [admin command](#connecting-to-rippled) that cannot be run by unpriviledged users._
|
||||
|
||||
@@ -9156,7 +9156,7 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
|----------------------------|--------|-------------|
|
||||
| current\_ledger\_size | String (Integer) | Number of transactions provisionally included in the in-progress ledger. |
|
||||
| current\_queue\_size | String (Integer) | Number of transactions currently queued for the next ledger. |
|
||||
| drops | Object | Various information about the transaction cost (the `Fee` field of a transaction), in [drops of xrp](#specifying-xrp). |
|
||||
| drops | Object | Various information about the transaction cost (the `Fee` field of a transaction), in [drops of xrp](#specifying-currency-amounts). |
|
||||
| drops.base\_fee | String (Integer) | The transaction cost required for a [reference transaction](#reference-transaction-cost) to be included in a ledger under minimum load. |
|
||||
| drops.median\_fee | String (Integer) | An approximation of the median transaction cost among transactions included in the previous validated ledger. |
|
||||
| drops.minimum\_fee | String (Integer) | The minimum transaction cost for a [reference transaction](#reference-transaction-cost) to be queued for a later ledger. If greater than `base_fee`, the transaction queue is full. |
|
||||
|
||||
@@ -34,7 +34,7 @@ A transaction can be authorized by any of the following types of signatures:
|
||||
|
||||
* A single signature from the master secret key that is mathematically associated with the sending address. You can disable or enable the master key using an [AccountSet transaction](#accountset).
|
||||
* A single signature that matches a regular key associated with the address. You can add, remove, or replace a regular key using a [SetRegularKey transaction](#setregularkey).
|
||||
* A [multi-signature](#multi-signing) that matches a list of signers owned by the address. You can add, remove, or replace a list of signers using a [SignerListSet transaction](#SignerListSet).
|
||||
* A [multi-signature](#multi-signing) that matches a list of signers owned by the address. You can add, remove, or replace a list of signers using a [SignerListSet transaction](#signerlistset).
|
||||
|
||||
Any signature type can authorize any type of transaction, with the following exceptions:
|
||||
|
||||
@@ -330,7 +330,7 @@ The `Signers` field contains a [multi-signature](#multi-signing), which has sign
|
||||
| TxnSignature | String | Blob | A signature for this transaction, verifiable using the `SigningPubKey`. |
|
||||
| SigningPubKey | String | PubKey | The public key used to create this signature. |
|
||||
|
||||
The `SigningPubKey` must be a key that is associated with the `Account` address. If the referenced `Account` is a funded account in the ledger, then the SigningPubKey can be that account's current Regular Key if one is set. It could also be that account's Master Key, unless the [lsfDisableMaster](ripple-ledger.html#accountroot-flags) flag is enabled. If the referenced `Account` address is not a funded account in the ledger, then the `SigningPubKey` must be the master key associated with that address.
|
||||
The `SigningPubKey` must be a key that is associated with the `Account` address. If the referenced `Account` is a funded account in the ledger, then the SigningPubKey can be that account's current Regular Key if one is set. It could also be that account's Master Key, unless the [lsfDisableMaster](reference-ledger-format.html#accountroot-flags) flag is enabled. If the referenced `Account` address is not a funded account in the ledger, then the `SigningPubKey` must be the master key associated with that address.
|
||||
|
||||
Because signature verification is a compute-intensive task, multi-signed transactions cost additional XRP to relay to the network. Each signature included in the multi-signature increases the [transaction cost](concept-transaction-cost.html) required for the transaction. For example, if the current minimum transaction cost to relay a transaction to the network is `10000` drops, then a multi-signed transaction with 3 entries in the `Signers` array would need a `Fee` value of at least `40000` drops to relay.
|
||||
|
||||
@@ -837,7 +837,7 @@ You cannot create a SignerList such that the SignerQuorum could never be met. Th
|
||||
|
||||
You can create, update, or remove a SignerList using the master key, regular key, or the current SignerList, if those methods of signing transactions are available.
|
||||
|
||||
You cannot remove the last method of signing transactions from an account. If an account's master key is disabled (it has the [`lsfDisableMaster` flag](ripple-ledger.html#accountroot-flags) enabled) and the account does not have a [Regular Key](#setregularkey) configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error [tecNO\_ALTERNATIVE\_KEY](#tec-codes).
|
||||
You cannot remove the last method of signing transactions from an account. If an account's master key is disabled (it has the [`lsfDisableMaster` flag](reference-ledger-format.html#accountroot-flags) enabled) and the account does not have a [Regular Key](#setregularkey) configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error [tecNO\_ALTERNATIVE\_KEY](#tec-codes).
|
||||
|
||||
|
||||
# Pseudo-Transactions #
|
||||
@@ -1145,7 +1145,7 @@ These codes indicate that the transaction failed, but it was applied to a ledger
|
||||
| tecFROZEN | 137 | The [OfferCreate transaction](#offercreate) failed because one or both of the assets involved are subject to a [global freeze](concept-freeze.html). |
|
||||
| tecINSUF\_RESERVE\_LINE | 122 | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](concept-reserves.html)) This error occurs when the counterparty already has a trust line in a non-default state to the sending account for the same currency. (See tecNO\_LINE\_INSUF\_RESERVE for the other case.) |
|
||||
| tecINSUF\_RESERVE\_OFFER | 123 | The transaction failed because the sending account does not have enough XRP to create a new Offer. (See: [Reserves](concept-reserves.html)) |
|
||||
| tecINSUFFICIENT\_RESERVE | 141 | The [SignerListSet](#signerlistset) or other transaction would increase the [reserve requirement](concept-reserves.html) higher than the sending account's balance. See [SignerLists and Reserves](ripple-ledger.html#signerlists-and-reserves) for more information. |
|
||||
| tecINSUFFICIENT\_RESERVE | 141 | The [SignerListSet](#signerlistset) or other transaction would increase the [reserve requirement](concept-reserves.html) higher than the sending account's balance. See [SignerLists and Reserves](reference-ledger-format.html#signerlists-and-reserves) for more information. |
|
||||
| tecINTERNAL | 144 | Unspecified internal error, with transaction cost applied. This error code should not normally be returned. |
|
||||
| tecNEED\_MASTER\_KEY | 142 | This transaction attempted to cause changes that require the master key, such as [disabling the master key or giving up the ability to freeze balances](#accountset-flags). _(New in [rippled 0.28.0](https://github.com/ripple/rippled/releases/tag/0.28.0-rc1))_ |
|
||||
| tecNO\_ALTERNATIVE\_KEY | 130 | The transaction tried to remove the only available method of [authorizing transactions](#authorizing-transactions). This could be a [SetRegularKey transaction](#setregularkey) to remove the regular key, a [SignerListSet transaction](#signerlistset) to delete a SignerList, or an [AccountSet transaction](#accountset) to disable the master key. (Prior to [rippled 0.30.0](https://github.com/ripple/rippled/releases/tag/0.30.0), this was called `tecMASTER_DISABLED`.) |
|
||||
|
||||
@@ -13,7 +13,7 @@ Benefits of multi-signing include:
|
||||
To use multi-signing:
|
||||
|
||||
1. [The Ripple peer-to-peer network must have multi-signing enabled.](#availability-of-multi-signing)
|
||||
2. [Set up a list of signers on your account.](#setting-up-multi-sign)
|
||||
2. [Set up a list of signers on your account.](#setting-up-multi-signing)
|
||||
3. [Send transactions using multiple signatures.](#sending-a-multi-signed-transaction)
|
||||
|
||||
|
||||
@@ -234,13 +234,13 @@ At this point, your address is ready to [send a multi-signed transaction](#sendi
|
||||
Sending a Multi-Signed Transaction
|
||||
----------------------------------
|
||||
|
||||
Before you can multi-sign a transaction, first [set up multi-signing](#set-up-multi-sign) for your address. The following procedure demonstrates how to create, sign, and submit a multi-signed transaction.
|
||||
Before you can multi-sign a transaction, first [set up multi-signing](#setting-up-multi-signing) for your address. The following procedure demonstrates how to create, sign, and submit a multi-signed transaction.
|
||||
|
||||
### 1. Create the transaction ##
|
||||
|
||||
Create a JSON object that represents the transaction you want to submit. You have to specify _everything_ about this transaction, including `Fee` and `Sequence`. Also include the field `SigningPubKey` as an empty string, to indicate that the transaction is multi-signed.
|
||||
|
||||
Keep in mind that the `Fee` for multi-signed transactions is significantly higher than for regularly-signed transactions. It should be (N+1) times the normal [transaction cost](concept-transaction-cost.html), where N is the number of signatures you plan to provide. Given that it sometimes takes a while to collect signatures from multiple sources, you may want to include additional buffer in case the [transaction cost's load scaling](concept-transaction-cost.html#load-scaling) increases in that time.
|
||||
Keep in mind that the `Fee` for multi-signed transactions is significantly higher than for regularly-signed transactions. It should be (N+1) times the normal [transaction cost](concept-transaction-cost.html), where N is the number of signatures you plan to provide. Given that it sometimes takes a while to collect signatures from multiple sources, you may want to include additional buffer in case the [transaction cost](concept-transaction-cost.html) increases in that time.
|
||||
|
||||
Here's an example transaction ready to be multi-signed:
|
||||
|
||||
|
||||
@@ -10567,7 +10567,7 @@ Connecting to 127.0.0.1:5005
|
||||
</ul>
|
||||
<h2 id="fee">fee</h2>
|
||||
<p><a href="https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/Fee1.cpp" title="Source">[Source]<br/></a></p>
|
||||
<p>The <code>fee</code> command reports the current state of the open-ledger requirements for the <a href="concept-transaction-cost.html">transaction cost</a>. This requires the <a href="concept-amendments.html#feeescalationi">FeeEscalation amendment</a> to be enabled. <em>(New in <a href="https://wiki.ripple.com/Rippled-0.31.0">version 0.31.0</a>)</em></p>
|
||||
<p>The <code>fee</code> command reports the current state of the open-ledger requirements for the <a href="concept-transaction-cost.html">transaction cost</a>. This requires the <a href="concept-amendments.html#feeescalation">FeeEscalation amendment</a> to be enabled. <em>(New in <a href="https://wiki.ripple.com/Rippled-0.31.0">version 0.31.0</a>)</em></p>
|
||||
<p><em>The <code>fee</code> method is an <a href="#connecting-to-rippled">admin command</a> that cannot be run by unpriviledged users.</em></p>
|
||||
<h4 id="request-format-37">Request Format</h4>
|
||||
<p>An example of the request format:</p>
|
||||
@@ -10691,7 +10691,7 @@ Connecting to 127.0.0.1:5005
|
||||
<tr>
|
||||
<td>drops</td>
|
||||
<td>Object</td>
|
||||
<td>Various information about the transaction cost (the <code>Fee</code> field of a transaction), in <a href="#specifying-xrp">drops of xrp</a>.</td>
|
||||
<td>Various information about the transaction cost (the <code>Fee</code> field of a transaction), in <a href="#specifying-currency-amounts">drops of xrp</a>.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>drops.base_fee</td>
|
||||
|
||||
@@ -160,7 +160,7 @@
|
||||
<ul>
|
||||
<li>A single signature from the master secret key that is mathematically associated with the sending address. You can disable or enable the master key using an <a href="#accountset">AccountSet transaction</a>.</li>
|
||||
<li>A single signature that matches a regular key associated with the address. You can add, remove, or replace a regular key using a <a href="#setregularkey">SetRegularKey transaction</a>.</li>
|
||||
<li>A <a href="#multi-signing">multi-signature</a> that matches a list of signers owned by the address. You can add, remove, or replace a list of signers using a <a href="#SignerListSet">SignerListSet transaction</a>.</li>
|
||||
<li>A <a href="#multi-signing">multi-signature</a> that matches a list of signers owned by the address. You can add, remove, or replace a list of signers using a <a href="#signerlistset">SignerListSet transaction</a>.</li>
|
||||
</ul>
|
||||
<p>Any signature type can authorize any type of transaction, with the following exceptions:</p>
|
||||
<ul>
|
||||
@@ -517,7 +517,7 @@
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>The <code>SigningPubKey</code> must be a key that is associated with the <code>Account</code> address. If the referenced <code>Account</code> is a funded account in the ledger, then the SigningPubKey can be that account's current Regular Key if one is set. It could also be that account's Master Key, unless the <a href="ripple-ledger.html#accountroot-flags">lsfDisableMaster</a> flag is enabled. If the referenced <code>Account</code> address is not a funded account in the ledger, then the <code>SigningPubKey</code> must be the master key associated with that address.</p>
|
||||
<p>The <code>SigningPubKey</code> must be a key that is associated with the <code>Account</code> address. If the referenced <code>Account</code> is a funded account in the ledger, then the SigningPubKey can be that account's current Regular Key if one is set. It could also be that account's Master Key, unless the <a href="reference-ledger-format.html#accountroot-flags">lsfDisableMaster</a> flag is enabled. If the referenced <code>Account</code> address is not a funded account in the ledger, then the <code>SigningPubKey</code> must be the master key associated with that address.</p>
|
||||
<p>Because signature verification is a compute-intensive task, multi-signed transactions cost additional XRP to relay to the network. Each signature included in the multi-signature increases the <a href="concept-transaction-cost.html">transaction cost</a> required for the transaction. For example, if the current minimum transaction cost to relay a transaction to the network is <code>10000</code> drops, then a multi-signed transaction with 3 entries in the <code>Signers</code> array would need a <code>Fee</code> value of at least <code>40000</code> drops to relay.</p>
|
||||
<h3 id="flags">Flags</h3>
|
||||
<p>The <code>Flags</code> field allows for additional boolean options regarding the behavior of a transaction. They are represented as binary values that can be combined with bitwise-or operations to set multiple flags at once.</p>
|
||||
@@ -1267,7 +1267,7 @@
|
||||
<p>An account may not have more than one SignerList. A successful SignerListSet transaction replaces the existing SignerList, if one exists. To delete a SignerList, you must set <code>SignerQuorum</code> to <code>0</code> <em>and</em> omit the <code>SignerEntries</code> field. Otherwise, the transaction fails with the error <a href="#tem-codes">temMALFORMED</a>. A transaction to delete a SignerList is considered successful even if there was no SignerList to delete.</p>
|
||||
<p>You cannot create a SignerList such that the SignerQuorum could never be met. The SignerQuorum must be greater than 0 but less than or equal to the sum of the <code>SignerWeight</code> values in the list. Otherwise, the transaction fails with the error <a href="#tem-codes">temMALFORMED</a>.</p>
|
||||
<p>You can create, update, or remove a SignerList using the master key, regular key, or the current SignerList, if those methods of signing transactions are available.</p>
|
||||
<p>You cannot remove the last method of signing transactions from an account. If an account's master key is disabled (it has the <a href="ripple-ledger.html#accountroot-flags"><code>lsfDisableMaster</code> flag</a> enabled) and the account does not have a <a href="#setregularkey">Regular Key</a> configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error <a href="#tec-codes">tecNO_ALTERNATIVE_KEY</a>.</p>
|
||||
<p>You cannot remove the last method of signing transactions from an account. If an account's master key is disabled (it has the <a href="reference-ledger-format.html#accountroot-flags"><code>lsfDisableMaster</code> flag</a> enabled) and the account does not have a <a href="#setregularkey">Regular Key</a> configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error <a href="#tec-codes">tecNO_ALTERNATIVE_KEY</a>.</p>
|
||||
<h1 id="pseudo-transactions">Pseudo-Transactions</h1>
|
||||
<p>Pseudo-Transactions are never submitted by users, nor propagated through the network. Instead, a server may choose to inject them in a proposed ledger directly. If enough servers inject an equivalent pseudo-transaction for it to pass consensus, then it becomes included in the ledger, and appears in ledger data thereafter.</p>
|
||||
<p>Some of the fields that are mandatory for normal transactions do not make sense for pseudo-transactions. In those cases, the pseudo-transaction has the following default values:</p>
|
||||
@@ -2003,7 +2003,7 @@
|
||||
<tr>
|
||||
<td>tecINSUFFICIENT_RESERVE</td>
|
||||
<td>141</td>
|
||||
<td>The <a href="#signerlistset">SignerListSet</a> or other transaction would increase the <a href="concept-reserves.html">reserve requirement</a> higher than the sending account's balance. See <a href="ripple-ledger.html#signerlists-and-reserves">SignerLists and Reserves</a> for more information.</td>
|
||||
<td>The <a href="#signerlistset">SignerListSet</a> or other transaction would increase the <a href="concept-reserves.html">reserve requirement</a> higher than the sending account's balance. See <a href="reference-ledger-format.html#signerlists-and-reserves">SignerLists and Reserves</a> for more information.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>tecINTERNAL</td>
|
||||
|
||||
@@ -138,7 +138,7 @@
|
||||
<p>To use multi-signing:</p>
|
||||
<ol>
|
||||
<li><a href="#availability-of-multi-signing">The Ripple peer-to-peer network must have multi-signing enabled.</a></li>
|
||||
<li><a href="#setting-up-multi-sign">Set up a list of signers on your account.</a></li>
|
||||
<li><a href="#setting-up-multi-signing">Set up a list of signers on your account.</a></li>
|
||||
<li><a href="#sending-a-multi-signed-transaction">Send transactions using multiple signatures.</a></li>
|
||||
</ol>
|
||||
<h2 id="availability-of-multi-signing">Availability of Multi-Signing</h2>
|
||||
@@ -322,10 +322,10 @@ Connecting to 127.0.0.1:5005
|
||||
<li>Remove the address's regular key (if you previously set one) by sending a <a href="reference-transaction-format.html#setregularkey">SetRegularKey transaction</a>.</li>
|
||||
</ul>
|
||||
<h2 id="sending-a-multi-signed-transaction">Sending a Multi-Signed Transaction</h2>
|
||||
<p>Before you can multi-sign a transaction, first <a href="#set-up-multi-sign">set up multi-signing</a> for your address. The following procedure demonstrates how to create, sign, and submit a multi-signed transaction.</p>
|
||||
<p>Before you can multi-sign a transaction, first <a href="#setting-up-multi-signing">set up multi-signing</a> for your address. The following procedure demonstrates how to create, sign, and submit a multi-signed transaction.</p>
|
||||
<h3 id="1-create-the-transaction">1. Create the transaction</h3>
|
||||
<p>Create a JSON object that represents the transaction you want to submit. You have to specify <em>everything</em> about this transaction, including <code>Fee</code> and <code>Sequence</code>. Also include the field <code>SigningPubKey</code> as an empty string, to indicate that the transaction is multi-signed.</p>
|
||||
<p>Keep in mind that the <code>Fee</code> for multi-signed transactions is significantly higher than for regularly-signed transactions. It should be (N+1) times the normal <a href="concept-transaction-cost.html">transaction cost</a>, where N is the number of signatures you plan to provide. Given that it sometimes takes a while to collect signatures from multiple sources, you may want to include additional buffer in case the <a href="concept-transaction-cost.html#load-scaling">transaction cost's load scaling</a> increases in that time.</p>
|
||||
<p>Keep in mind that the <code>Fee</code> for multi-signed transactions is significantly higher than for regularly-signed transactions. It should be (N+1) times the normal <a href="concept-transaction-cost.html">transaction cost</a>, where N is the number of signatures you plan to provide. Given that it sometimes takes a while to collect signatures from multiple sources, you may want to include additional buffer in case the <a href="concept-transaction-cost.html">transaction cost</a> increases in that time.</p>
|
||||
<p>Here's an example transaction ready to be multi-signed:</p>
|
||||
<pre><code>{
|
||||
"TransactionType": "TrustSet",
|
||||
|
||||
Reference in New Issue
Block a user