RCL Accounts (draft done)

This commit is contained in:
mDuo13
2017-04-26 18:24:17 -07:00
parent 3b0ffa0712
commit 0a221e2c99
38 changed files with 694 additions and 173 deletions

View File

@@ -7,44 +7,39 @@ const base58 = require('base-x')(R_B58_DICT);
assert(crypto.getHashes().includes('sha256'));
assert(crypto.getHashes().includes('ripemd160'));
function checksum_of(payload_buf) {
const hash_1 = crypto.createHash('sha256').update(payload_buf).digest();
const hash_2 = crypto.createHash('sha256').update(hash_1).digest();
return hash_2.slice(0,4);
}
// Start with a public key. secp256k1 keys should be 33 bytes;
// Ed25519 keys should be 32 bytes prefixed with 0xED (a total of 33 bytes).
function address_of(pubkey_hex, key_type='secp256k1') {
const pubkey_buf = Buffer.from(pubkey_hex, 'hex');
// Ed25519 key:
const pubkey_hex =
'ED9434799226374926EDA3B54B1B461B4ABF7237962EAE18528FEA67595397FA32';
//// secp256k1 key:
// const pubkey_hex =
// '0303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D';
if (key_type.toLowerCase() == 'secp256k1') {
assert(pubkey_buf.length == 33);
} else if (key_type.toLowerCase() == 'ed25519') {
assert(pubkey_buf.length == 32);
} else {
throw 'UnknownKeyType';
}
const pubkey = Buffer.from(pubkey_hex, 'hex');
assert(pubkey.length == 33);
const pubkey_inner_hash = crypto.createHash('sha256');
// Calculate the RIPEMD160 hash of the SHA-256 hash of the public key
// This is the "Account ID"
const pubkey_inner_hash = crypto.createHash('sha256').update(pubkey);
const pubkey_outer_hash = crypto.createHash('ripemd160');
pubkey_outer_hash.update(pubkey_inner_hash.digest());
const account_id = pubkey_outer_hash.digest();
// Ed25519 keys are prefixed with 0xED to make them 33 bytes
if (key_type.toLowerCase() == 'ed25519') {
pubkey_inner_hash.update(Buffer.from([0xED]));
}
// Prefix the Account ID with the type prefix for "Ripple Address", then
// calculate a checksum as the first 4 bytes of the SHA-256 of the SHA-256
// of the Account ID
const address_type_prefix = Buffer.from([0x00]);
const payload = Buffer.concat([address_type_prefix, account_id]);
const chksum_hash1 = crypto.createHash('sha256').update(payload).digest();
const chksum_hash2 = crypto.createHash('sha256').update(chksum_hash1).digest();
const checksum = chksum_hash2.slice(0,4);
pubkey_inner_hash.update(pubkey_buf);
const pubkey_outer_hash = crypto.createHash('ripemd160');
pubkey_outer_hash.update(pubkey_inner_hash.digest());
const addressTypePrefix = Buffer.from([0x00]);
const accountID = pubkey_outer_hash.digest();
const checksum = checksum_of(accountID);
const dataToEncode = Buffer.concat([addressTypePrefix, accountID, checksum]);
return base58.encode(dataToEncode);
}
console.log(
address_of('0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020')
);
// rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh
// Concatenate the address type prefix, the payload, and the checksum.
// Base-58 encode the encoded value to get the address.
const dataToEncode = Buffer.concat([payload, checksum]);
const address = base58.encode(dataToEncode);
console.log(address);
// rnBFvgZphmN39GWzUJeUitaP22Fr9be75H (secp256k1 example)
// rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN (Ed25519 example)

View File

@@ -3,24 +3,40 @@
An "Account" in the Ripple Consensus Ledger represents a holder of XRP and a sender of transactions. The core elements of an account are:
- An identifying **address**, such as `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`
- One or more methods of [**authorizing transactions**](reference-transaction-format.html#authorizing-transactions), such as:
- The master key pair the address is derived from (the default)
- A regular key pair
- A signer list
- An account can send [transactions](reference-transaction-format.html) to modify the Ripple Consensus Ledger, for a variety of purposes including:
- Sending XRP to a recipient, immediately or through locking mechanisms like payment channels and escrow.
- Issuing, redeeming, or sending non-XRP assets and currencies.
- Trading in the decentralized exchange.
- Changing settings such as authorization settings, balance limits, or the behavior of assets issued by the account.
- An **XRP balance**. Some of this XRP is set aside for the [Reserve](concept-reserves.html).
- A **sequence number**, starting at 1 and increasing with each transaction sent from this account. No transaction can be included in a ledger unless the transaction's sequence number matches its sender's next sequence number.
- A **history of transactions** that modified this account and its balances.
- **Note:** For technical reasons, the transaction history of XRP balance changes and sent transactions is tracked separately from the history of changes to non-XRP balances.
- A **history of transactions** that affected this account and its balances.
In the ledger's data tree, an account's core data is stored in the [AccountRoot](reference-ledger-format.html#accountroot) ledger node type. An account can also be the owner (or partial owner) of several other types of data.
**Tip:** An "Account" in the Ripple Consensus Ledger is somewhere between the financial usage (like "bank account") and the computing usage (like "UNIX account"). Non-XRP currencies and assets aren't stored in an RCL Account itself; each such asset is stored in an accounting relationship called a "Trust Line" that connects two parties.
## Addresses
The "address" of an account is derived from the account's master [public key](https://en.wikipedia.org/wiki/Public-key_cryptography), which is in turn derived from a secret key. Ripple account addresses always start with the letter `r` and can be 25 to 35 characters in length. The data of a Ripple address includes a 4-byte checksum so that the probability of generating a valid address from random characters is approximately 1 in 2^32.
The conversion from a public key to an address involves a one-way hash function, so it is possible to confirm that a public key matches an address but it is impossible to derive the public key from the address alone. (This is part of the reason why signed transactions include the public key _and_ the address of the sender.) For more technical details, see [Address Encoding](#address-encoding).
The process of "creating" an address is the purely mathematical task of generating a key pair and calculating the address from it, so an address can exist separately from its presence as an account object in the ledger. To actually make an account for an address, someone must send the account enough XRP to satisfy the reserve. This is called _funding_ the account. Whether or not the address is a funded account, you can use the address (and the key pair it's derived from) as a regular key or as part of a signer list.
The process of "creating" an address is the purely mathematical task of generating a key pair and calculating the address from it, so an address can exist separately from its presence as an account object in the ledger. To actually make an account for an address, someone must send the address enough XRP to satisfy the reserve. This is called _funding_ the account. Whether or not the address is a funded account, you can use the address (and the key pair it's derived from) as a regular key or as part of a signer list.
### Special Addresses
Some addresses have special meaning, or historical uses, in the Ripple Consensus Ledger. In many cases, these are "black hole" addresses, meaning the address is not derived from a known secret key. Since it is effectively impossible to guess a secret key from only an address, any XRP possessed by black hole addresses is lost forever.
| Address | Name | Meaning | Black Hole? |
|-----------------------------|------|---------|-------------|
| rrrrrrrrrrrrrrrrrrrrrhoLvTp | ACCOUNT\_ZERO | An address that is the base-58 encoding of the value `0`. In peer-to-peer communications, `rippled` uses this address as the issuer for XRP. | Yes |
| rrrrrrrrrrrrrrrrrrrrBZbvji | ACCOUNT\_ONE | An address that is the base-58 encoding of the value `1`. In the ledger, [RippleState entries](reference-ledger-format.html#ripplestate) use this address as a placeholder for the issuer of a trust line balance. | Yes |
| rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh | The genesis account | When `rippled` starts a new genesis ledger from scratch (for example, in stand-alone mode), this account holds all the XRP. This address is generated from the seed value "masterpassphrase" which is [hard-coded](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184). | No |
| rrrrrrrrrrrrrrrrrNAMEtxvNvQ | Ripple Name reservation black-hole | In the past, Ripple asked users to send XRP to this account to reserve Ripple Names.| Yes |
| rrrrrrrrrrrrrrrrrrrn5RM1rHd | NaN Address | Previous versions of [ripple-lib](https://github.com/ripple/ripple-lib) generated this address when base-58 encoding the value [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN). | Yes |
## Permanence of Accounts
@@ -28,6 +44,7 @@ Once created, an account exists in the Ripple Consensus Ledger's data tree forev
Unlike Bitcoin and many other crypto-currencies, each new version of the Ripple Consensus Ledger's public ledger chain contains the full state of the ledger, which increases in size with each new account. For that reason, Ripple discourages creating new accounts unless entirely necessary. Institutions who send and receive value on behalf of many users can use **Source Tags** and **Destination Tags** to distinguish payments from and to their customers while only using one (or a handful) of accounts in the Ripple Consensus Ledger.
## Transaction History
In the Ripple Consensus Ledger, transaction history is tracked by a "thread" of transactions linked by a transaction's identifying hash and the ledger index. The `AccountRoot` ledger node has hash and ledger of the transaction that most recently modified it; the metadata of that transaction includes the previous state of the `AccountRoot` node, so it is possible to iterate through the history of a single account this way. This transaction history includes any transactions that modify the `AccountRoot` node directly, including:
@@ -46,14 +63,20 @@ However, the _conceptual_ transaction history of an account also includes transa
For more information on each of these objects, see the [Ledger Format Reference](reference-ledger-format.html).
## Address Encoding
[[Source<br>]](https://github.com/ripple/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "Source")
**Tip:** These technical details are only relevant for people building low-level library software for RCL compatibility!
Ripple addresses are encoded using [base-58](https://en.wikipedia.org/wiki/Base58) with the Ripple _dictionary_: `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`. Since Ripple encodes several types of keys with base-58, Ripple prefixes the encoded data with a "type byte" (also called a "version prefix") to distinguish them. The type byte causes addresses to usually start with different letters in base-58 format.
[[Source]<br>](https://github.com/ripple/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "Source")
The formula for calculating a Ripple address is as follows (with example code in JavaScript):
Ripple addresses are encoded using [base-58](https://en.wikipedia.org/wiki/Base58) with the Ripple _dictionary_: `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`. Since Ripple encodes several types of keys with base-58, Ripple prefixes the encoded data with a one-byte "type prefix" (also called a "version prefix") to distinguish them. The type prefix causes addresses to usually start with different letters in base-58 format.
The following diagram shows the relationship between keys and addresses:
![Passphrase → Secret Key → Public Key + Type Prefix → Account ID + Checksum → Address](img/key-address-rels.png)
The formula for calculating a Ripple address is as follows. For the complete example code, see [`encode_address.js`](https://github.com/ripple/ripple-dev-portal/blob/master/content/code_samples/address_encoding/encode_address.js).
1. Import required algorithms: SHA-256, RIPEMD160, and base58. Set the dictionary for base58.
@@ -68,24 +91,32 @@ The formula for calculating a Ripple address is as follows (with example code in
2. Start with the 33-byte ECDSA secp256k1 key, or a 32-byte Ed25119 public key. For Ed25519 keys, prefix the key with the byte `0xED`.
***TODO: further breakdown encode_address.js***
const pubkey_hex =
'ED9434799226374926EDA3B54B1B461B4ABF7237962EAE18528FEA67595397FA32';
const pubkey = Buffer.from(pubkey_hex, 'hex');
assert(pubkey.length == 33);
3. Calculate the RIPEMD160 hash of the SHA-256 hash of the public key. This value is the "payload".
3. Calculate the RIPEMD160 hash of the SHA-256 hash of the public key. This value is the "Account ID".
(todo)
const pubkey_inner_hash = crypto.createHash('sha256').update(pubkey);
const pubkey_outer_hash = crypto.createHash('ripemd160');
pubkey_outer_hash.update(pubkey_inner_hash.digest());
const account_id = pubkey_outer_hash.digest();
4. Calculate the SHA-256 hash of the SHA-256 hash of the payload; take the first 4 bytes. This value is the "checksum".
4. Calculate the SHA-256 hash of the SHA-256 hash of the Account ID; take the first 4 bytes. This value is the "checksum".
(todo)
const address_type_prefix = Buffer.from([0x00]);
const payload = Buffer.concat([address_type_prefix, account_id]);
const chksum_hash1 = crypto.createHash('sha256').update(payload).digest();
const chksum_hash2 = crypto.createHash('sha256').update(chksum_hash1).digest();
const checksum = chksum_hash2.slice(0,4);
5. Concatenate the account type byte `0x00`, the payload, and the checksum.
5. Concatenate the the payload, and the checksum, and calculate the base58 value of the concatenated buffer. The result is the address.
(todo)
6. Calculate the base58 value of the concatenated buffer. The result is the address.
(todo)
const dataToEncode = Buffer.concat([payload, checksum]);
const address = base58.encode(dataToEncode);
console.log(address);
// rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
<!--{# Reference link definitions #}-->

View File

@@ -21,7 +21,7 @@ In stand-alone mode, you can have `rippled` create a new genesis ledger. This pr
rippled -a --start --conf=/path/to/rippled.cfg
```
In a genesis ledger, the [genesis address](reference-rippled.html#special-addresses) holds all 100 billion XRP. The keys of the genesis address are [hardcoded](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184) as follows:
In a genesis ledger, the [genesis address](concept-accounts.html#special-addresses) holds all 100 billion XRP. The keys of the genesis address are [hardcoded](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184) as follows:
**Address:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`

View File

@@ -3,19 +3,7 @@ Ripple Accounts are identified by a base-58 Ripple Address, which is derived fro
* Between 25 and 35 characters in length
* Starts with the character `r`
* Case-sensitive
* [Base-58](https://wiki.ripple.com/Encodings) encoded using only the following characters: `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz` That's alphanumeric characters, excluding zero (`0`), capital O (`O`), capital I (`I`), and lowercase L (`l`).
* Contains error-checking that makes it unlikely that a randomly-generated string is a valid address.
* **Base58-encoded**, using alphanumeric characters, excluding zero (`0`), capital O (`O`), capital I (`I`), and lowercase L (`l`).
#### Special Addresses ####
[ACCOUNT_ONE]: #special-addresses
[ACCOUNT_ZERO]: #special-addresses
Some addresses have special meaning, or historical uses, in the Ripple Consensus Ledger. In many cases, these are "black hole" addresses, meaning the address is not derived from a known secret key. Since it is almost impossible to guess a secret key from only an address, any XRP possessed by those addresses is lost forever.
| Address | Name | Meaning | Black Hole? |
|-----------------------------|------|---------|-------------|
| rrrrrrrrrrrrrrrrrrrrrhoLvTp | ACCOUNT\_ZERO | An address that is the base-58 encoding of the value `0`. In peer-to-peer communications, `rippled` uses this address as the issuer for XRP. | Yes |
| rrrrrrrrrrrrrrrrrrrrBZbvji | ACCOUNT\_ONE | An address that is the base-58 encoding of the value `1`. In the ledger, [RippleState entries](reference-ledger-format.html#ripplestate) use this address as a placeholder for the issuer of a trust line balance. | Yes |
| rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh | The genesis account | When `rippled` starts a new genesis ledger from scratch (for example, in stand-alone mode), this account holds all the XRP. This address is generated from the seed value "masterpassphrase" which is [hard-coded](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184). | No |
| rrrrrrrrrrrrrrrrrNAMEtxvNvQ | Ripple Name reservation black-hole | In the past, Ripple asked users to send XRP to this account to reserve Ripple Names.| Yes |
| rrrrrrrrrrrrrrrrrrrn5RM1rHd | NaN Address | Previous versions of [ripple-lib](https://github.com/ripple/ripple-lib) generated this address when base-58 encoding the value [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN). | Yes |
For more information, see [Accounts](concept-accounts.html).

View File

@@ -0,0 +1,199 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<diagram program="umlet" version="14.2">
<zoom_level>10</zoom_level>
<element>
<id>UMLObject</id>
<coordinates>
<x>60</x>
<y>60</y>
<w>150</w>
<h>70</h>
</coordinates>
<panel_attributes>Passphrase
--
(Optional)
Any string
lt=.</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLObject</id>
<coordinates>
<x>350</x>
<y>60</y>
<w>180</w>
<h>70</h>
</coordinates>
<panel_attributes>Secret Key
--
</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>200</x>
<y>80</y>
<w>170</w>
<h>40</h>
</coordinates>
<panel_attributes>lt=&lt;.
SHA-512Half</panel_attributes>
<additional_attributes>150.0;20.0;10.0;20.0</additional_attributes>
</element>
<element>
<id>UMLObject</id>
<coordinates>
<x>650</x>
<y>60</y>
<w>220</w>
<h>70</h>
</coordinates>
<panel_attributes>Public Key
--
33 bytes (secp256k1)
0xED + 32 bytes (Ed25519)</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>520</x>
<y>80</y>
<w>150</w>
<h>50</h>
</coordinates>
<panel_attributes>lt=&lt;-
Public Key
Derivation</panel_attributes>
<additional_attributes>130.0;20.0;10.0;20.0</additional_attributes>
</element>
<element>
<id>UMLObject</id>
<coordinates>
<x>360</x>
<y>190</y>
<w>180</w>
<h>80</h>
</coordinates>
<panel_attributes>Account ID
--
(20 bytes)</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>300</x>
<y>120</y>
<w>440</w>
<h>130</h>
</coordinates>
<panel_attributes>lt=&lt;-
SHA-256 of RIPEMD160
</panel_attributes>
<additional_attributes>60.0;90.0;10.0;90.0;10.0;40.0;420.0;40.0;420.0;10.0</additional_attributes>
</element>
<element>
<id>UMLObject</id>
<coordinates>
<x>690</x>
<y>190</y>
<w>180</w>
<h>80</h>
</coordinates>
<panel_attributes>Address
--
AccountID (20 bytes)
Checksum (4 bytes)</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLObject</id>
<coordinates>
<x>60</x>
<y>190</y>
<w>190</w>
<h>80</h>
</coordinates>
<panel_attributes>Type Prefix
--
0x00
("r" in Ripple's base58)</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>240</x>
<y>230</y>
<w>140</w>
<h>30</h>
</coordinates>
<panel_attributes>lt=&lt;-</panel_attributes>
<additional_attributes>120.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>UMLObject</id>
<coordinates>
<x>400</x>
<y>320</y>
<w>100</w>
<h>70</h>
</coordinates>
<panel_attributes>Checksum
--
(4 bytes)</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>490</x>
<y>230</y>
<w>120</w>
<h>140</h>
</coordinates>
<panel_attributes>lt=&lt;-</panel_attributes>
<additional_attributes>100.0;10.0;80.0;10.0;80.0;120.0;10.0;120.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>530</x>
<y>210</y>
<w>80</w>
<h>30</h>
</coordinates>
<panel_attributes>lt=&lt;-</panel_attributes>
<additional_attributes>60.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>UMLState</id>
<coordinates>
<x>590</x>
<y>210</y>
<w>100</w>
<h>40</h>
</coordinates>
<panel_attributes>base58
type=sender</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>420</x>
<y>260</y>
<w>130</w>
<h>80</h>
</coordinates>
<panel_attributes>lt=&lt;-
SHA-256 twice</panel_attributes>
<additional_attributes>10.0;60.0;10.0;10.0</additional_attributes>
</element>
</diagram>

View File

@@ -507,7 +507,7 @@ A RippleState node has the following fields:
|-----------------|-----------|---------------|-------------|
| LedgerEntryType | String | UInt16 | The value `0x72`, mapped to the string `RippleState`, indicates that this node is a RippleState object. |
| Flags | Number | UInt32 | A bit-map of boolean options enabled for this node. |
| Balance | Object | Amount | The balance of the trust line, from the perspective of the low account. A negative balance indicates that the low account has issued currency to the high account. The issuer in this is always set to the neutral value [ACCOUNT_ONE](reference-rippled.html#special-addresses). |
| Balance | Object | Amount | The balance of the trust line, from the perspective of the low account. A negative balance indicates that the low account has issued currency to the high account. The issuer in this is always set to the neutral value [ACCOUNT_ONE](concept-accounts.html#special-addresses). |
| LowLimit | Object | Amount | The limit that the low account has set on the trust line. The `issuer` is the address of the low account that set this limit. |
| HighLimit | Object | Amount | The limit that the high account has set on the trust line. The `issuer` is the address of the high account that set this limit. |
| PreviousTxnID | String | Hash256 | The identifying hash of the transaction that most recently modified this node. |

View File

@@ -7455,12 +7455,10 @@ The request includes 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)) |
| `limit` | Unsigned Integer | (Optional) If provided, the server does not provide more than this many offers in the results. The total number of results returned may be fewer than the limit, because the server omits unfunded offers. |
| `taker` | String | (Optional, defaults to [ACCOUNT_ONE][]) The [Address][] of an account to use as a perspective. (This affects which unfunded offers are returned.) |
| `taker` | String | (Optional) The [Address][] of an account to use as a perspective. [Unfunded offers](reference-transaction-format.html#lifecycle-of-an-offer) placed by this account are always included in the response. (You can use this to look up your own orders to cancel them.) |
| `taker_gets` | Object | Specification of which currency the account taking the offer would receive, as an object with `currency` and `issuer` fields (omit issuer for XRP), like [currency amounts](#specifying-currency-amounts). |
| `taker_pays` | Object | Specification of which currency the account taking the offer would pay, as an object with `currency` and `issuer` fields (omit issuer for XRP), like [currency amounts](#specifying-currency-amounts). |
Normally, offers that are not funded are omitted; however, offers made by the specified `taker` account are always displayed. This allows you to look up your own unfunded offers to cancel them with an OfferCancel transaction.
#### Response Format ####
An example of a successful response:

View File

@@ -1119,7 +1119,7 @@ Some of the fields that are mandatory for normal transactions do not make sense
| Field | Default Value |
|:--------------|:---------------------------------------------------------|
| Account | [ACCOUNT_ZERO](reference-rippled.html#special-addresses) |
| Account | [ACCOUNT_ZERO](concept-accounts.html#special-addresses) |
| Sequence | 0 |
| Fee | 0 |
| SigningPubKey | "" |