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

rippled - use new ledger page, RCL terminology

Browse Source
This commit is contained in:
mDuo13
2015-08-10 14:57:45 -07:00
parent 29ee42f024
commit 03bf0f0c21
2 changed files with 17 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
content/rippled.md
View File

@@ -1277,7 +1277,9 @@ Each offer object contains the following fields:
## account_objects ##
[[Source]<br>](https://github.com/ripple/rippled/blob/399c43cae6e90a428e9ce6a988123972b0f03c99/src/ripple/rpc/handlers/AccountObjects.cpp "Source")
The `account_objects` command returns the raw ledger format for all objects owned by an account, such as [outstanding offers](transactions.html#lifecycle-of-an-offer), trust lines in non-default state, and tickets (which are part of forthcoming multi-sign code). For getting the balance of an account's trust lines, we recommend [`account_lines`](#account-lines) instead.
The `account_objects` command returns the raw [ledger format][] for all objects owned by an account, such as [outstanding offers](transactions.html#lifecycle-of-an-offer), trust lines in non-default state, and tickets (which are part of forthcoming multi-sign code). For getting the balance of an account's trust lines, we recommend [`account_lines`](#account-lines) instead.
[ledger format]: ripple-ledger.html
#### Request Format ####
An example of the request format:
@@ -1866,7 +1868,7 @@ The response follows the [standard format](#response-formatting), with a success
| Field | Type | Description |
|-------|------|-------------|
| account | String | Unique address of the account this request corresponds to |
| account\_objects | Array | Array of objects owned by this account. Each object is in its raw [ledger format](https://ripple.com/wiki/Ledger_Format). |
| account\_objects | Array | Array of objects owned by this account. Each object is in its raw [ledger format][]. |
| ledger\_hash | String | (May be omitted) The identifying hash of the ledger that was used to generate this response. |
| ledger\_index | Number | (May be omitted) The sequence number of the ledger version that was used to generate this response. |
| ledger\_current\_index | Number | (May be omitted) The sequence number of the current in-progress ledger version that was used to generate this response. |
@@ -3523,7 +3525,7 @@ The format of each object in the `state` array depends on whether `binary` was s
| Field | Type | Description |
|-------|------|-------------|
| data | String | (Only included if `"binary":true`) Hex representation of the requested data |
| LedgerEntryType | String | (Only included if `"binary":false`) String indicating what type of object this is. See [LedgerEntryType](https://ripple.com/wiki/Ledger_Format#Entries) |
| LedgerEntryType | String | (Only included if `"binary":false`) String indicating what type of ledger node this object represents. See [ledger format][] for the full list. |
| (Additional fields) | (Various) | (Only included if `"binary":false`) Additional fields describing this object, depending on which LedgerEntryType it is. |
| index | String | Unique identifier for this ledger entry, as hex. |
@@ -3537,7 +3539,9 @@ The format of each object in the `state` array depends on whether `binary` was s
## ledger_entry ##
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/LedgerEntry.cpp "Source")
The `ledger_entry` method returns a single entry from the specified ledger. See [LedgerEntryType](https://ripple.com/wiki/Ledger_Format#Entries) for information on the different types of objects you can retrieve. __*Note:*__ There is no commandline version of this method. You can use the [`json` command](#json) to access this method from the commandline instead.
The `ledger_entry` method returns a single ledger node from the Ripple Consensus Ledger. See [ledger format][] for information on the different types of objects you can retrieve.
__*Note:*__ There is no commandline version of this method. You can use the [`json` command](#json) to access this method from the commandline instead.
#### Request Format ####
@@ -3666,7 +3670,7 @@ The response follows the [standard format](#response-formatting), with a success
|-------|------|-------------|
| index | String | Unique identifying key for this ledger_entry |
| ledger_index | Unsigned Integer | Unique sequence number of the ledger from which this data was retrieved |
| node | Object | (`"binary":false` only) Object containing the data of this ledger node; the exact contents vary depending on the [LedgerEntryType](https://ripple.com/wiki/Ledger_Format#Entries) of node retrieved. |
| node | Object | (`"binary":false` only) Object containing the data of this ledger node, according to the [ledger format][]. |
| node_binary | String | (`"binary":true` only) Binary data of the ledger node retrieved, as hex. |
#### Possible Errors ####

16
content/tx_format.md
View File

@@ -341,7 +341,7 @@ Most of the time, the `issuer` field of a non-XRP [currency amount](rippled-apis
### Creating Accounts ###
The Payment transaction type is the only way to create new accounts in the shared Ripple ledger. To do so, send an amount of XRP that is equal or greater than the [account reserve](https://wiki.ripple.com/Reserves) to a mathematically-valid account address that does not exist yet. When the payment is processed, a new [AccountRoot node](https://wiki.ripple.com/Ledger_Format#AccountRoot) will be added to the ledger to reflect the newly-created account.
The Payment transaction type is the only way to create new accounts in the shared Ripple ledger. To do so, send an amount of XRP that is equal or greater than the [account reserve](https://wiki.ripple.com/Reserves) to a mathematically-valid account address that does not exist yet. When the payment is processed, a new [AccountRoot node](ripple-ledger.html#AccountRoot) will be added to the ledger to reflect the newly-created account.
If you attempt to send an insufficient amount of XRP, or any other currency, the Payment will fail.
@@ -410,7 +410,7 @@ In the above example with a ¥95/$15 offer and a ¥5/$2 offer, the situation is
[[Source]<br>](https://github.com/ripple/rippled/blob/f65cea66ef99b1de149c02c15f06de6c61abf360/src/ripple/app/transactors/SetAccount.cpp "Source")
An AccountSet transaction modifies the properties of an [account in the global ledger](https://wiki.ripple.com/Ledger_Format#AccountRoot).
An AccountSet transaction modifies the properties of an [account in the Ripple Consensus Ledger](ripple-ledger.html#AccountRoot).
Example AccountSet:
@@ -446,7 +446,7 @@ The `Domain` field is represented as the hex string of the lowercase ASCII of th
To remove the `Domain` field from an account, send an AccountSet with the Domain set to an empty string.
Client applications can use the [ripple.txt](https://ripple.com/wiki/Ripple.txt) file hosted by the domain to confirm that the account is actually operated by that domain. *Note:* We expect the *host-meta* component of [Gateway Services](https://wiki.ripple.com/Gateway_Services) to replace ripple.txt for this purpose.
Client applications can use the [ripple.txt](https://ripple.com/wiki/Ripple.txt) file hosted by the domain to confirm that the account is actually operated by that domain.
### AccountSet Flags ###
@@ -528,7 +528,7 @@ Instead of using an account's master key to sign transactions, you can set an al
A Regular Key pair is generated in the same way as any other Ripple keys (for example, with [wallet_propose](rippled-apis.html#wallet-propose)), but it can be changed. A Master Key pair is an intrinsic part of the account's identity (the address is derived from the master public key) so the Master Key cannot be changed. Therefore, using a Regular Key to sign transactions instead of the master key whenever possible is beneficial to security.
If your regular key is compromised, but the master key is not, you can use this method to regain control of your account. As a special feature, each account is allowed to perform SetRegularKey transaction *without* a transaction fee as long as the [*lsfPasswordSpent* flag](https://wiki.ripple.com/Ledger_Format#AccountRoot) for the account is not set. To use this feature, submit a SetRegularKey transaction with a `Fee` value of 0, signed by the account's *master key*. (This way, you don't have to worry about whether the attacker has used up all the account's spare XRP.) The [*lsfPasswordSpent* flag]() is automatically cleared if your account receives a payment of XRP.
If your regular key is compromised, but the master key is not, you can use this method to regain control of your account. As a special feature, each account is allowed to perform SetRegularKey transaction *without* a transaction fee as long as the [*lsfPasswordSpent* flag](ripple-ledger.html#AccountRoot) for the account is not set. To use this feature, submit a SetRegularKey transaction with a `Fee` value of 0, signed by the account's *master key*. (This way, you don't have to worry about whether the attacker has used up all the account's spare XRP.) The [*lsfPasswordSpent* flag]() is automatically cleared if your account receives a payment of XRP.
@@ -536,7 +536,7 @@ If your regular key is compromised, but the master key is not, you can use this
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/CreateOffer.cpp "Source")
An OfferCreate transaction is effectively a [limit order](http://en.wikipedia.org/wiki/limit_order). It defines an intent to exchange currencies, and creates an Offer node in the global ledger if not completely fulfilled when placed. Offers can be partially fulfilled.
An OfferCreate transaction is effectively a [limit order](http://en.wikipedia.org/wiki/limit_order). It defines an intent to exchange currencies, and creates an Offer node in the Ripple Consensus Ledger if not completely fulfilled when placed. Offers can be partially fulfilled.
```
{
@@ -637,7 +637,7 @@ The following invalid flag combination prompts a temINVALID_FLAG error:
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/CancelOffer.cpp "Source")
An OfferCancel transaction removes an Offer node from the global ledger.
An OfferCancel transaction removes an Offer node from the Ripple Consensus Ledger.
```
{
@@ -832,7 +832,7 @@ Although it may seem unfair to charge a fee for a failed transaction, the `tec`
## Finality of Results ##
A signed transaction can be submitted to any `rippled` server, by anyone. The server processes the transaction and passes it on to other servers in the network according to its own logic. If enough servers apply a transaction to a ledger that the transaction passes consensus, then the transaction becomes a permanent part of the shared, validated global ledger. This can happen in two ways: Either the transaction is successful (a `tes` result), or the transaction fails but the fee is charged anyway (a `tec` result). No transaction with any other result is included in a ledger.
A signed transaction can be submitted to any `rippled` server, by anyone. The server processes the transaction and passes it on to other servers in the network according to its own logic. If enough servers apply a transaction to a ledger that the transaction passes consensus, then the transaction becomes a permanent part of the shared, validated Ripple Consensus Ledger. This can happen in two ways: Either the transaction is successful (a `tes` result), or the transaction fails but the fee is charged anyway (a `tec` result). No transaction with any other result is included in a ledger.
Transactions that failed in other ways could still succeed (or fail with a `tec`) and become included in later ledgers. A server might even store a temporarily-failed, signed transaction and then successfully apply it later without asking first; the signature means that the transaction is authorized to happen.
@@ -846,7 +846,7 @@ There are several ways a transaction's failure could become permanent:
## Understanding Transaction Metadata ##
The metadata section of a transaction includes detailed information about all the changes to the shared global ledger that the transaction caused. This is true of any transaction that gets included in a ledger, whether or not it is successful. Naturally, the changes are only final if the transaction is validated.
The metadata section of a transaction includes detailed information about all the changes to the shared Ripple Consensus Ledger that the transaction caused. This is true of any transaction that gets included in a ledger, whether or not it is successful. Naturally, the changes are only final if the transaction is validated.
Some fields that may appear in transaction metadata include: