From 68ab7c85f0a7701bcb7bba7d538d1bf7f075f866 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Thu, 10 Sep 2015 17:58:36 -0700 Subject: [PATCH 01/40] ledger format - signerlist node --- content/reference-ledger-format.md | 34 ++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/content/reference-ledger-format.md b/content/reference-ledger-format.md index 2898ed3b61..0a7cb7b130 100644 --- a/content/reference-ledger-format.md +++ b/content/reference-ledger-format.md @@ -398,3 +398,37 @@ The `index` of a RippleState node is the SHA-512Half of the following values put * The AccountID of the low account * The AccountID of the high account * The 160-bit currency code of the trust line(s) + + +## SignerList ## +[[Source]
](https://github.com/ripple/rippled/blob/6d2e3da30696bd10e3bb11a5ff6d45d2c4dae90f/src/ripple/protocol/impl/LedgerFormats.cpp#L127 "Source") + +The `SignerList` node type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. + +Example SignerList node: + +``` +TODO +``` + +A SignerList node has the following fields: + +| Name | JSON Type | Internal Type | Description | +|-----------------|-----------|---------------|-------------| +| OwnerNode | | UInt64 | ? | +| SignerQuorum | Number | UInt32 | A target number for signer weights. To produce a valid signature for the owner of this SignerList, the signers must provide valid signatures whose weights sum to this value or more. | +| SignerEntries | Array | Array | An array of SignerEntry objects representing the parties who are part of this signer list. | +| SignerListID | | UInt32 | An ID for this signer list. Currently always set to `0`. If a future update allows multiple signer lists for an account, this may change. | +| PreviousTxnID | | Hash256 | The identifying hash of a previous transaction that modified this node? | +| PreviousTxnLgrSeq | | UInt32 | The sequence number of the ledger that included the `PreviousTxnID`. | + +### SignerEntry object ### + +Each member of the `SignerEntries` field is an object that describes that signer in the list. A SignerEntry has the following fields: + +| Name | JSON Type | Internal Type | Description | +|-----------------|-----------|---------------|-------------| +| Account | String | AccountID | An address whose signature contributes to the multi-signature. It doesn't have to exist in the ledger, or does it? | +| SignerWeight | Number | UInt16 | The weight of signatures from this signer. A multi-signature is only valid of the sum weight of the signatures provided meets or exceeds the SignerList's `SignerQuorum` value. | + + From bb8b48b0bb2ed8c55bfafcda7f6dd695685bd50e Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Tue, 15 Sep 2015 01:32:33 -0700 Subject: [PATCH 02/40] signerlist node updates; signers tx field; signerlistset stub --- content/reference-ledger-format.md | 8 ++-- content/reference-transaction-format.md | 58 +++++++++++++++++++------ 2 files changed, 48 insertions(+), 18 deletions(-) diff --git a/content/reference-ledger-format.md b/content/reference-ledger-format.md index 0a7cb7b130..0fde7f17ff 100644 --- a/content/reference-ledger-format.md +++ b/content/reference-ledger-format.md @@ -415,12 +415,12 @@ A SignerList node has the following fields: | Name | JSON Type | Internal Type | Description | |-----------------|-----------|---------------|-------------| -| OwnerNode | | UInt64 | ? | +| OwnerNode | String | UInt64 | A hint indicating which page of the owner directory links to this node, in case the directory consists of multiple nodes. | | SignerQuorum | Number | UInt32 | A target number for signer weights. To produce a valid signature for the owner of this SignerList, the signers must provide valid signatures whose weights sum to this value or more. | | SignerEntries | Array | Array | An array of SignerEntry objects representing the parties who are part of this signer list. | | SignerListID | | UInt32 | An ID for this signer list. Currently always set to `0`. If a future update allows multiple signer lists for an account, this may change. | -| PreviousTxnID | | Hash256 | The identifying hash of a previous transaction that modified this node? | -| PreviousTxnLgrSeq | | UInt32 | The sequence number of the ledger that included the `PreviousTxnID`. | +| PreviousTxnID | String | Hash256 | The identifying hash of the transaction that most recently modified this node. | +| PreviousTxnLgrSeq | Number | UInt32 | The sequence number (`ledger_index`) of the ledger that contains the transaction that most recently modified this node. | ### SignerEntry object ### @@ -428,7 +428,7 @@ Each member of the `SignerEntries` field is an object that describes that signer | Name | JSON Type | Internal Type | Description | |-----------------|-----------|---------------|-------------| -| Account | String | AccountID | An address whose signature contributes to the multi-signature. It doesn't have to exist in the ledger, or does it? | +| Account | String | AccountID | An address whose signature contributes to the multi-signature. This does not need to be a funded Ripple account. | | SignerWeight | Number | UInt16 | The weight of signatures from this signer. A multi-signature is only valid of the sum weight of the signatures provided meets or exceeds the SignerList's `SignerQuorum` value. | diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md index f54231714b..a8b6da072f 100644 --- a/content/reference-transaction-format.md +++ b/content/reference-transaction-format.md @@ -169,7 +169,7 @@ To accomplish both of these, your application should: 1. Construct and sign the transaction first, including a [`LastLedgerSequence`](#lastledgersequence) parameter that gives the transaction a limited viable lifespan. 2. Persist details of the transaction before submitting. 3. Submit the transaction. -4. Confirm that the transaction was either included in a validated ledger, or that it has expired due to `LastLedgerSequence`. +4. Confirm that the transaction was either included in a validated ledger, or that it has expired due to `LastLedgerSequence`. 5. If a transaction fails or expires, you can modify and resubmit it. Main article: [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html) @@ -193,7 +193,8 @@ Every transaction type has the same set of fundamental fields: | [LastLedgerSequence](#lastledgersequence) | Number | UInt32 | (Optional, but strongly recommended) Highest ledger sequence number that a transaction can appear in. | | [Memos](#memos) | Array of Objects | Array | (Optional) Additional arbitrary information used to identify this transaction. | | [Sequence](#canceling-or-skipping-a-transaction) | Unsigned Integer | UInt32 | (Required, but [auto-fillable](#auto-fillable-fields)) The sequence number, relative to the initiating account, of this transaction. A transaction is only valid if the `Sequence` number is exactly 1 greater than the last-valided transaction from the same account. | -| SigningPubKey | String | PubKey | (Automatically added when signing) Hex representation of the public key that corresponds to the private key used to sign this transaction. | +| SigningPubKey | String | PubKey | (Automatically added when signing) Hex representation of the public key that corresponds to the private key used to sign this transaction. If an empty string, indicates a multi-signature is present in the `Signers` field instead. | +| [Signers](#multi-signing) | Array | Array | (Optional) Array of objects that represent a multi-signature which authorizes this transaction. | | SourceTag | Unsigned Integer | UInt32 | (Optional) Arbitrary integer used to identify the reason for this payment, or the hosted wallet on whose behalf this transaction is made. Conventionally, a refund should specify the initial payment's `SourceTag` as the refund payment's `DestinationTag`. | | TransactionType | String | UInt16 | The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, `AccountSet`, and `SetRegularKey`. | | TxnSignature | String | VariableLength | (Automatically added when signing) The signature that verifies this transaction as originating from the account it says it is from. | @@ -211,13 +212,16 @@ Some fields can be automatically filled in before the transaction is signed, eit For a production system, we recommend *not* leaving these fields to be filled by the server. For example, if transaction costs become high due to a temporary spike in network load, you may want to wait for the cost to decrease before sending some transactions, instead of paying the temporarily-high cost. -The [`Paths` field](#paths) of the [Payment](#payment) transaction type can also be automatically filled in. +The [`Paths` field](#paths) of the [Payment](#payment) transaction type can also be automatically filled in. + ### Transaction Cost ### -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 transaction cost is designed to increase along with the load on the network, making it very expensive to deliberately or inadvertently overload the network. +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 _[transaction cost](concept-transaction-cost.html)_ is designed to increase along with the load on the network, making it very expensive to deliberately or inadvertently overload the network. -The `Fee` field specifies an amount, in [drops of XRP](reference-rippled.html#specifying-currency-amounts), to destroy as the cost for this transaction. If the transaction is included in a validated leger (whether or not it achieves its intended purpose), then the amount of XRP specified in the `Fee` parameter is destroyed forever. You can [look up the transaction cost](concept-transaction-cost.html#querying-the-transaction-cost) in advance, or [let `rippled` set it automatically](concept-transaction-cost.html#automatically-specifying-the-transaction-cost) when you sign a transaction. +The `Fee` field specifies an amount, in [drops of XRP](reference-rippled.html#specifying-currency-amounts), 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 `Fee` parameter is destroyed forever. You can [look up the transaction cost](concept-transaction-cost.html#querying-the-transaction-cost) in advance, or [let `rippled` set it automatically](concept-transaction-cost.html#automatically-specifying-the-transaction-cost) when you sign a transaction. + +**Note:** [Multi-signed transactions](#multi-signing) require additional fees to relay to the network. ### Canceling or Skipping a Transaction ### @@ -248,7 +252,7 @@ In order to use AccountTxnID, you must first set the [asfAccountTxnID](#accounts ### Memos ### -The Memos field allows for arbitrary messaging data that can accompany the transaction. It is presented as an array of objects. Each object has only one field, `Memo`, which in turn contains another object with *one or more* of the following fields: +The `Memos` field allows for arbitrary messaging data that can accompany the transaction. It is presented as an array of objects. Each object has only one field, `Memo`, which in turn contains another object with *one or more* of the following fields: | Field | Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description | |-------|------|--------------------------------------------------------|-------------| @@ -279,10 +283,27 @@ Example of a transaction with a Memos field: } ``` +### Multi-signing ### + +The `Signers` field contains a multi-signature, which has signatures from up to 8 key pairs, that together should authorize the transaction. A multi-signature replaces a single signature by either the master key or regular key. To provide a multi-signature, an account must first have a SignerList associated with it, which it can do by sending a [SignerListSet](#signerlistset) transaction. + +The `Signers` list is an array of objects, each with one field, `Signer`. The `Signer` field has the following nested fields: + +| Field | Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description | +|-------|------|--------------------------------------------------------|-------------| +| Account | String | AccountID | The address associated with this signature, as it appears in the SignerList. | +| TxnSignature | String | Blob | A signature for this transaction, verifiable using the `SigningPubKey`. | +| SigningPubKey | String | 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. + +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-siganture increases the `Fee` required by the amount of the minimum transaction fee. For example, if the current minimum `Fee` value to relay a transaction to the network is `10000` drops, then a multi-signed transaction with 3 entries in the `Signers` array would cost `40000` drops to relay. + + ### Flags ### -The Flags 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. +The `Flags` 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. Most flags only have meaning for a specific transaction type. The same bitwise value may be reused for flags on different transaction types, so it is important to pay attention to the `TransactionType` field when setting and reading flags. @@ -334,7 +355,7 @@ Example payment: Most of the time, the `issuer` field of a non-XRP [currency amount](reference-rippled.html#specifying-currency-amounts) indicates the account of the gateway that issues that currency. However, when describing payments, there are special rules for the `issuer` field in the `Amount` and `SendMax` fields of a payment. * There is only ever one balance for the same currency between two accounts. This means that, sometimes, the `issuer` field of an amount actually refers to a counterparty that is redeeming issuances, instead of the account that created the issuances. -* When the `issuer` field of the destination `Amount` field matches the `Destination` account address, it is treated as a special case meaning "any issuer that the destination accepts." This includes all accounts to which the destination has extended trust lines, as well as issuances created by the destination which may be held on other trust lines. +* When the `issuer` field of the destination `Amount` field matches the `Destination` account address, it is treated as a special case meaning "any issuer that the destination accepts." This includes all accounts to which the destination has extended trust lines, as well as issuances created by the destination which may be held on other trust lines. * When the `issuer` field of the `SendMax` field matches the source account's address, it is treated as a special case meaning "any issuer that the source can use." This includes creating new issuances on trust lines that other accounts have extended to the source account, as well as issuances from other accounts that the source account possesses. ### Creating Accounts ### @@ -391,11 +412,11 @@ When the [*tfPartialPayment* flag](#payment-flags) is enabled, the `Amount` fiel Ripple defines the "quality" of a currency exchange as the ratio of the numeric amount in to the numeric amount out. For example, if you spend $2 USD to receive £1 GBP, then the "quality" of that exchange is `0.5`. -The [*tfLimitQuality* flag](#payment-flags) allows you to set a minimum quality of conversions that you are willing to take. This limit quality is defined as the destination `Amount` divided by the `SendMax` amount (just the numeric amounts, regardless of currency). When set, the payment processing engine avoids using any paths whose quality (conversion rate) is worse (numerically lower) than the limit quality. +The [*tfLimitQuality* flag](#payment-flags) allows you to set a minimum quality of conversions that you are willing to take. This limit quality is defined as the destination `Amount` divided by the `SendMax` amount (just the numeric amounts, regardless of currency). When set, the payment processing engine avoids using any paths whose quality (conversion rate) is worse (numerically lower) than the limit quality. By itself, the tfLimitQuality flag reduces the number of situations in which a transaction can succeed. Specifically, it rejects payments where some part of the payment uses an unfavorable conversion, even if the overall average *average* quality of conversions in the payment is equal or better than the limit quality. If a payment is rejected in this way, the [transaction result](#transaction-results) is `tecPATH_DRY`. -Consider the following example. If I am trying to send you 100 Chinese Yuan (`Amount` = 100 CNY) for 20 United States dollars (`SendMax` = 20 USD) or less, then the limit quality is `5`. Imagine one market maker is offering ¥95 for $15 (a ratio of about `6.3` CNY per USD), but the next best offer in the market is ¥5 for $2 (a ratio of `2.5` CNY per USD). If I were to take both offers in order to send you 100 CNY, then it would cost me 17 USD, for an average quality of about `5.9`. +Consider the following example. If I am trying to send you 100 Chinese Yuan (`Amount` = 100 CNY) for 20 United States dollars (`SendMax` = 20 USD) or less, then the limit quality is `5`. Imagine one market maker is offering ¥95 for $15 (a ratio of about `6.3` CNY per USD), but the next best offer in the market is ¥5 for $2 (a ratio of `2.5` CNY per USD). If I were to take both offers in order to send you 100 CNY, then it would cost me 17 USD, for an average quality of about `5.9`. Without the tfLimitQuality flag set, this transaction would succeed, because the $17 it costs me is within my specified `SendMax`. However, with the tfLimitQuality flag enabled, the transaction would fail instead, because the path to take the second offer has a quality of `2.5`, which is worse than the limit quality of `5`. @@ -776,11 +797,21 @@ A change in [transaction cost](concept-transaction-cost.html) or [account reserv +## SignerListSet ## + +The SignerListSet transaction creates, modifies, or removes a list of signers that can be used to multi-sign a transaction. +(TODO) + + + + + + # Transaction Results # ## Immediate Response ## -The response from the [`submit` command](reference-rippled.html#submit) contains a provisional result from the `rippled` server indicating what happened during local processing of the transaction. +The response from the [`submit` command](reference-rippled.html#submit) contains a provisional result from the `rippled` server indicating what happened during local processing of the transaction. The response from `submit` contains the following fields: @@ -802,7 +833,7 @@ __*Note:*__ A successful result at this stage does not indicate that the transac ## Looking up Transaction Results ## -To see the final result of a transaction, use the [`tx` command](reference-rippled.html#tx), [`account_tx` command](reference-rippled.html#account-tx), or other response from `rippled`. Look for `"validated": true` to indicate that this response uses a ledger version that has been validated by consensus. +To see the final result of a transaction, use the [`tx` command](reference-rippled.html#tx), [`account_tx` command](reference-rippled.html#account-tx), or other response from `rippled`. Look for `"validated": true` to indicate that this response uses a ledger version that has been validated by consensus. | Field | Value | Description | |-------|-------|-------------| @@ -1028,7 +1059,7 @@ These codes indicate that the transaction failed, but it was applied to a ledger ### tej Codes ### -These codes are only ever returned by the `ripple-lib` client library, not by `rippled` itself. +These codes are only ever returned by the `ripple-lib` client library, not by `rippled` itself. | Code | Explanation | |------|-------------| @@ -1042,4 +1073,3 @@ These codes are only ever returned by the `ripple-lib` client library, not by `r | tejSecretUnknown | The secret for a given account was omitted from the transaction, and ripple-lib was unable to automatically fill it in from saved data. | | tejServerUntrusted | The application attempted to submit an account secret to an untrusted server for transaction signing. | | tejUnconnected | The application is not connected to a `rippled` server, but it needs to be in order to process the transaction. | - From bc9524974faeb955f24867a95e587eb1a4609b29 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Thu, 17 Sep 2015 16:38:52 -0700 Subject: [PATCH 03/40] rippled - signerlistset tx and related --- content/reference-ledger-format.md | 6 +++- content/reference-transaction-format.md | 40 +++++++++++++++++++------ 2 files changed, 36 insertions(+), 10 deletions(-) diff --git a/content/reference-ledger-format.md b/content/reference-ledger-format.md index 0fde7f17ff..55def9324a 100644 --- a/content/reference-ledger-format.md +++ b/content/reference-ledger-format.md @@ -418,7 +418,7 @@ A SignerList node has the following fields: | OwnerNode | String | UInt64 | A hint indicating which page of the owner directory links to this node, in case the directory consists of multiple nodes. | | SignerQuorum | Number | UInt32 | A target number for signer weights. To produce a valid signature for the owner of this SignerList, the signers must provide valid signatures whose weights sum to this value or more. | | SignerEntries | Array | Array | An array of SignerEntry objects representing the parties who are part of this signer list. | -| SignerListID | | UInt32 | An ID for this signer list. Currently always set to `0`. If a future update allows multiple signer lists for an account, this may change. | +| SignerListID | Number | UInt32 | An ID for this signer list. Currently always set to `0`. If a future update allows multiple signer lists for an account, this may change. | | PreviousTxnID | String | Hash256 | The identifying hash of the transaction that most recently modified this node. | | PreviousTxnLgrSeq | Number | UInt32 | The sequence number (`ledger_index`) of the ledger that contains the transaction that most recently modified this node. | @@ -431,4 +431,8 @@ Each member of the `SignerEntries` field is an object that describes that signer | Account | String | AccountID | An address whose signature contributes to the multi-signature. This does not need to be a funded Ripple account. | | SignerWeight | Number | UInt16 | The weight of signatures from this signer. A multi-signature is only valid of the sum weight of the signatures provided meets or exceeds the SignerList's `SignerQuorum` value. | +When processing a multi-signed transaction, the server dereferences the `Account` values with respect to the ledger at the time of transaction execution. If the address _does not_ correspond to a funded [AccountRoot node](#accountroot), then only the master secret associated with that address can be used to produce a valid signature. If the account _does_ exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. Even if the account has a SignerList configured, a multi-signature cannot be used as a valid component to another multi-signature. (In other words, "multi-level" multi-signing is disallowed.) +### SignerLists and Reserves ### + +A SignerList contributes to the [Account Reserve](https://wiki.ripple.com/Reserves). The SignerList itself counts as two objects, and each member of the list counts as one, so that the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line ([RippleState](#ripplestate)) or [Offer](#offer) node in the ledger. diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md index a8b6da072f..8645cda624 100644 --- a/content/reference-transaction-format.md +++ b/content/reference-transaction-format.md @@ -751,6 +751,31 @@ Transactions of the TrustSet type support additional values in the [`Flags` fiel | tfClearFreeze | 0x00200000 | 2097152 | [Unfreeze](concept-freeze.html) the trustline. | + +## SignerListSet ## +[[Source]
](https://github.com/ripple/rippled/blob/ef511282709a6a0721b504c6b7703f9de3eecf38/src/ripple/app/tx/impl/SetSignerList.cpp "Source") + +The SignerListSet transaction creates, modifies, or removes a list of signers that can be used to multi-sign a transaction. + +Example SignerListSet: + +``` +TODO +``` + +| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description | +|-------|-----------|--------------------------------------------------------|-------------| +| SignerQuorum | Number | UInt32 | A target number for the signer weights. A multi-signature from this list is valid only if the sum weights of the signatures provided is equal or greater than this value. To delete a SignerList, use the value `0`. | +| SignerEntries | Array | Array | (Omitted when deleting) Array of [SignerEntry objects](ripple-ledger.html#signerentry-object), indicating the addresses and weights of signers in this list. A SignerList must have at least 1 member and no more than 8 members. No address may appear more than once in the list, nor may the `Account` submitting the transaction appear in the list. | + +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 `SignerQuorum` to `0` _and_ omit the `SignerEntries` field. Otherwise, the transaction fails with the error [temMALFORMED](#tem-codes). A transaction to delete a SignerList is considered successful even if there was no SignerList to delete. + +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 `SignerWeight` values in the list. Otherwise, the transaction fails with the error [temMALFORMED](#tem-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](ripple-ledger.html#accountroot-flags) enabled) and the account does not have a Regular Key configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error [tecNO\_ALTERNATIVE\_KEY](#tec-codes). + + + # Pseudo-Transactions # 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. @@ -797,13 +822,6 @@ A change in [transaction cost](concept-transaction-cost.html) or [account reserv -## SignerListSet ## - -The SignerListSet transaction creates, modifies, or removes a list of signers that can be used to multi-sign a transaction. -(TODO) - - - @@ -966,13 +984,17 @@ These codes indicate that the transaction was malformed, and cannot succeed acco | temBAD\_SIGNATURE | The signature to authorize this transaction is either missing, or formed in a way that is not a properly-formed signature. (See [tecNO_PERMISSION](#tec-codes) for the case where the signature is properly formed, but not authorized for this account.) | | temBAD\_SRC\_ACCOUNT | The `Account` on whose behalf this transaction is being sent (the "source account") is not a properly-formed Ripple account. | | temBAD\_TRANSFER\_RATE | The [`TransferRate` field of an AccountSet transaction](#transferrate) is not properly formatted. | -| temDST\_IS\_SRC | The [TrustSet](#trustset) transaction improperly specified the destination of the trustline (the `issuer` field of `LimitAmount`) as the `Account` sending the transaction. You cannot extend a trustline to yourself. (In the future, this code could also apply to other cases where the destination of a transaction is not allowed to be the account sending it.) | +| temDST\_IS\_SRC | The [TrustSet](#trustset) transaction improperly specified the destination of the trust line (the `issuer` field of `LimitAmount`) as the `Account` sending the transaction. You cannot extend a trust line to yourself. (In the future, this code could also apply to other cases where the destination of a transaction is not allowed to be the account sending it.) | | temDST\_NEEDED | The transaction improperly omitted a destination. This could be the `Destination` field of a [Payment](#payment) transaction, or the `issuer` sub-field of the `LimitAmount` field fo a `TrustSet` transaction. | | temINVALID | The transaction is otherwise invalid. For example, the transaction ID may not be the right format, the signature may not be formed properly, or something else went wrong in understanding the transaction. | | temINVALID\_FLAG | The transaction includes a [Flag](#flags) that does not exist, or includes a contradictory combination of flags. | | temREDUNDANT | The transaction would accomplish nothing; for example, it is sending a payment directly to the sending account, or creating an offer to buy and sell the same currency from the same issuer. | | temREDUNDANT\_SEND\_MAX | _(Removed in [rippled 0.28.0][])_ | | temRIPPLE\_EMPTY | The [Payment](#payment) transaction includes an empty `Paths` field, but paths are necessary to complete this payment. | +| temBAD_WEIGHT | The [SignerListSet](#signerlistset) transaction includes a `SignerWeight` that is invalid, for example a zero or negative value. | +| temBAD_SIGNER | The [SignerListSet](#signerlistset) transaction includes a signer who is invalid: for example, it might be a duplicate, or it might be the account to which the SignerList belongs. | +| temBAD_QUORUM | The [SignerListSet](#signerlistset) transaction has an invalid `SignerQuorum` value. Either the value is not greater than zero, or it is more than the sum of all signers in the list. | + ### tef Codes ### @@ -1040,7 +1062,7 @@ These codes indicate that the transaction failed, but it was applied to a ledger | tecNO\_LINE\_REDUNDANT | 127 | The transaction failed because it attempted to set a trust line to its default state, but the trust line did not exist. | | tecPATH\_DRY | 128 | The transaction failed because the provided paths did not have enough liquidity to send anything at all. This could mean that the source and destination accounts are not linked by trust lines. | | tecUNFUNDED | 129 | **DEPRECATED.** Replaced by tecUNFUNDED\_OFFER and tecUNFUNDED\_PAYMENT. | -| tecMASTER\_DISABLED | 130 | The [SetRegularKey transaction](#setregularkey) tried to unset the Regular Key, but the account has the `lsfDisableMaster` flag enabled. (Unsetting the Regular Key while also leaving the Master Key disabled would make the account unusable.) | +| tecNO\_ALTERNATIVE\_KEY | 130 | The transaction tried to remove the only available method of signing 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. (Renamed from `tecMASTER_DISABLED` after [rippled 0.30.0](https://github.com/ripple/rippled/releases/tag/0.30.0) | | tecNO\_REGULAR\_KEY | 131 | The [AccountSet transaction](#accountset) tried to disable the Master Key, but the account does not have a Regular Key set. (Disabling the Master Key without having a Regular Key configured would make the account unusable.) | | tecOWNERS | 132 | The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the [`lsfRequireAuth`](#accountset-flags) flag if it has any trust lines or available offers. | | tecNO\_ISSUER | 133 | The account specified in the `issuer` field of a currency amount does not exist. | From d5408d73613e7d5ccdc3da7f1ae78b093934b63e Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Thu, 17 Sep 2015 17:40:33 -0700 Subject: [PATCH 04/40] rippled multi-sign mentions --- content/reference-rippled.md | 69 +++++++++++++------------ content/reference-transaction-format.md | 12 ++--- 2 files changed, 42 insertions(+), 39 deletions(-) diff --git a/content/reference-rippled.md b/content/reference-rippled.md index 4b628ccd16..ccefabb180 100644 --- a/content/reference-rippled.md +++ b/content/reference-rippled.md @@ -171,6 +171,7 @@ rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated true ``` *JSON-RPC* + ``` HTTP Status: 200 OK { @@ -192,6 +193,7 @@ HTTP Status: 200 OK } ``` *Commandline* + ``` { "result": { @@ -299,6 +301,7 @@ HTTP Status: 200 OK #### JSON-RPC API Error Response Format #### Some JSON-RPC requests will respond with an error code on the HTTP layer. In these cases, the response is a plain-text explanation in the response body. For example, if you forgot to specify the command in the `method` parameter, the response is like this: + ``` HTTP Status: 400 Bad Request Null method @@ -322,7 +325,7 @@ When your request results in an error, the entire request is copied back as part All methods can potentially return any of the following values for the `error` code: * `unknownCmd` - The request does not contain a [command](#api-methods) that the `rippled` server recognizes. -* `jsonInvalid1 - (WebSocket only) The request is not a proper JSON object. +* `jsonInvalid` - (WebSocket only) The request is not a proper JSON object. * JSON-RPC returns a 400 Bad Request HTTP error in this case instead. * `missingCommand` - (WebSocket only) The request did not specify a `command` field. * JSON-RPC returns a 400 Bad Request HTTP error in this case instead. @@ -330,7 +333,7 @@ All methods can potentially return any of the following values for the `error` c * `noNetwork` - The server is having trouble connecting to the rest of the Ripple Network (and is not running in stand-alone mode). * `noCurrent` - The server does not know what the current ledger is, due to high load, network problems, validator failures, incorrect configuration, or some other problem. * `noClosed` - The server does not have a closed ledger, typically because it has not finished starting up. -* `wsTextRequired` - (WebSocket only) The request's [opcode](https://tools.ietf.org/html/rfc6455#section-5.2) is not text. +* `wsTextRequired` - (WebSocket only) The request's [opcode](https://tools.ietf.org/html/rfc6455#section-5.2) is not text. ## Formatting Conventions ## @@ -377,12 +380,12 @@ Each closed *Ledger* has a [Ledger Index][] and a [Hash][] value. When [Specifyi Many API methods require you to specify an instance of the ledger, with the data retrieved being considered accurate and up-to-date as of that particular version of the shared ledger. The commands that accept a ledger version all work the same way. There are three ways you can specify which ledger you want to use: 1. Specify a ledger by its [Ledger Index][] in the `ledger_index` parameter. Each closed ledger has an identifying sequence number that is 1 higher than the previously-validated ledger. (The Genesis Ledger has sequence number 0) -2. Specify a ledger by its [Hash][] value in the `ledger_hash` parameter. +2. Specify a ledger by its [Hash][] value in the `ledger_hash` parameter. 3. Specify a ledger by one of the following shortcuts, in the `ledger_index` parameter: * `validated` for the most recent ledger that has been validated by the whole network * `closed` for the most recent ledger that has been closed for modifications and proposed for validation by the node * `current` for the node's current working version of the ledger. - + There is also a deprecated `ledger` parameter which accepts any of the above three formats. *Do not* use this parameter; it may be removed without further notice. If you do not specify a ledger, the `current` (in-progress) ledger will be chosen by default. If you provide more than one field specifying ledgers, the deprecated `ledger` field will be used first if it exists, falling back to `ledger_hash`. The `ledger_index` field is ignored unless neither of the other two are present. __*Note:*__ Do not rely on this default behavior; it is subject to change. Instead, you should always specify a ledger version in each call. @@ -548,7 +551,7 @@ The `owner_info` command is deprecated. Use [`account_objects`](#account-objects * [`validation_seed` - Temporarily set key to be used for validating](#validation-seed) * [`wallet_propose` - Generate keys for a new account](#wallet-propose) -The following admin commands are deprecated and may be removed without further notice: +The following admin commands are deprecated and may be removed without further notice: * `ledger_header` - Use the [`ledger` command](#ledger) instead. * `unl_add`, `unl_delete`, `unl_list`, `unl_load`, `unl_network`, `unl_reset`, `unl_score` - Use the configuration file for UNL management instead. @@ -564,7 +567,7 @@ The `rippled` application, in addition to acting as a server, can be run (as a s # Account Information # -Accounts are the core unit of authentication in the Ripple Network. Each account can hold balances in multiple currencies, and all transactions must be signed by an account's secret key. In order for an account to exist in a validated ledger version, it must hold a minimum reserve amount of XRP. (The [reserve for an account](concept-reserves.html) increases with the amount of data it is responsible for in the shared ledger.) It is expected that accounts will correspond loosely to individual users. +Accounts are the core unit of authentication in the Ripple Network. Each account can hold balances in multiple currencies, and all transactions must be signed by an account's secret key. In order for an account to exist in a validated ledger version, it must hold a minimum reserve amount of XRP. (The [reserve for an account](concept-reserves.html) increases with the amount of data it is responsible for in the shared ledger.) It is expected that accounts will correspond loosely to individual users. ## account_currencies ## @@ -721,7 +724,7 @@ The response follows the [standard format](#response-formatting), with a success ## account_info ## [[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/AccountInfo.cpp "Source") -The `account_info` command retrieves information about an account, its activity, and its XRP balance. All information retrieved is relative to a particular version of the ledger. +The `account_info` command retrieves information about an account, its activity, and its XRP balance. All information retrieved is relative to a particular version of the ledger. #### Request Format #### @@ -1108,9 +1111,9 @@ An example of a successful response: "value": "0.01886995237307572" } }, - + ... - + ], "validated": false } @@ -1156,9 +1159,9 @@ An example of a successful response: "value": "158.0380691682966" } }, - + ... - + ], "status": "success", "validated": false @@ -1203,7 +1206,7 @@ Each offer object contains the following fields: ## account_objects ## [[Source]
](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](reference-transaction-format.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](reference-transaction-format.html#lifecycle-of-an-offer), trust lines in non-default state, and [signer lists](reference-transaction-format.html#multi-signing). For getting the balance of an account's trust lines, we recommend [`account_lines`](#account-lines) instead. [ledger format]: reference-ledger-format.html @@ -1871,7 +1874,7 @@ The request includes the following parameters: | Field | Type | Description | |-------|------|-------------| -| account | String | A unique identifier for the account, most commonly the account's address. | +| account | String | A unique identifier for the account, most commonly the account's address. | | ledger\_index\_min | Integer | Use to specify the earliest ledger to include transactions from. A value of `-1` instructs the server to use the earliest validated ledger version available. | | ledger\_index\_max | Integer | Use to specify the most recent ledger to include transactions from. A value of `-1` instructs the server to use the most recent validated ledger version available. | | ledger\_hash | String | (Optional) Use instead of ledger\_index\_min and ledger\_index\_max to look for transactions from a single ledger only. (See [Specifying a Ledger](#specifying-ledgers)) | @@ -3895,7 +3898,7 @@ There are several sources of complication in transactions. Unlike traditional ba ## tx ## [[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Tx.cpp "Source") -The `tx` method retrieves information on a single transaction. +The `tx` method retrieves information on a single transaction. #### Request Format #### @@ -4098,7 +4101,7 @@ The response follows the [standard format](#response-formatting), with a success ## transaction_entry ## [[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/TransactionEntry.cpp "Source") -The `transaction_entry` method retrieves information on a single transaction from a specific ledger version. (The [`tx`](#tx) command, by contrast, searches all ledgers for the specified transaction. We recommend using that method instead.) +The `transaction_entry` method retrieves information on a single transaction from a specific ledger version. (The [`tx`](#tx) command, by contrast, searches all ledgers for the specified transaction. We recommend using that method instead.) #### Request Format #### @@ -4150,7 +4153,7 @@ The request includes the following parameters: | 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)) | | tx_hash | String | Unique hash of the transaction you are looking up | -__*Note:*__ This method does not support retrieving information from the current in-progress ledger. You must specify a ledger version in either `ledger_index` or `ledger_hash`. +__*Note:*__ This method does not support retrieving information from the current in-progress ledger. You must specify a ledger version in either `ledger_index` or `ledger_hash`. #### Response Format #### @@ -5209,11 +5212,11 @@ The fields included in each transaction object vary slightly depending on the ty ## path_find ## [[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/PathFind.cpp "Source") -*WebSocket API only!* The `path_find` method searches for a [path](concept-paths.html) along which a transaction can possibly be made, and periodically sends updates when the path changes over time. For a simpler version that is supported by JSON-RPC, see [`ripple_path_find`](#ripple-path-find). For payments occurring strictly in XRP, it is not necessary to find a path, because XRP can be sent directly to any account. +*WebSocket API only!* The `path_find` method searches for a [path](concept-paths.html) along which a transaction can possibly be made, and periodically sends updates when the path changes over time. For a simpler version that is supported by JSON-RPC, see [`ripple_path_find`](#ripple-path-find). For payments occurring strictly in XRP, it is not necessary to find a path, because XRP can be sent directly to any account. There are three different modes, or sub-commands, of the path_find command. Specify which one you want with the `subcommand` parameter: -* `create` - Start sending pathfinding information +* `create` - Start sending pathfinding information * `close` - Stop sending pathfinding information * `status` - Get the information of the currently-open pathfinding request @@ -6146,7 +6149,7 @@ An example of the request format: "TransactionType" : "Payment", "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", "Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX", - "Amount" : { + "Amount" : { "currency" : "USD", "value" : "1", "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn" @@ -6206,7 +6209,7 @@ The server automatically attempts to fill in certain fields from the `tx_json` o * `Sequence` - The server automatically uses the next Sequence number from the sender's account information. Be careful: the next sequence number for the account is not incremented until this transaction is applied. If you sign multiple transactions without submitting and waiting for the response to each one, you must provide the correct sequence numbers in the request. Automatically filled unless `offline` is true. * `Fee` - If you omit the `Fee` parameter, the server [automatically provides an appropriate transaction cost](concept-transaction-cost.html#automatically-specifying-the-transaction-cost) unless you specified `offline` as true. If you specify `offline` as true, you must fill in the transaction cost in the `Fee` parameter. Be careful: a malicious server can specify an excessively high transaction cost. * If `fee_mult_max` is included, and the automatically provided `Fee` value is greater than the long-term base transaction cost times `fee_mult_max`, then the transaction fails with the error `rpcHIGH_FEE`. This way, you can let the server fill in the current minimum `Fee` value as long as the current load-based transaction cost is not too high. -* `Paths` - For Payment-type transactions (excluding XRP-to-XRP transfers), the Paths field can be automatically filled, as if you did a [ripple_path_find](#ripple-path-find). Only filled if `build_path` is provided. +* `Paths` - For Payment-type transactions (excluding XRP-to-XRP transfers), the Paths field can be automatically filled, as if you did a [ripple_path_find](#ripple-path-find). Only filled if `build_path` is provided. #### Response Format #### @@ -6296,14 +6299,14 @@ __*Caution:*__ If this command results in an error messages, the message can con ## submit ## [[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Submit.cpp "Source") -The `submit` method sends a [transaction](reference-transaction-format.html) to the network to be confirmed and included in future ledgers. +The `submit` method sends a [transaction](reference-transaction-format.html) to the network to be confirmed and included in future ledgers. This command has two modes: * Submit-only mode takes a signed, serialized transaction as a binary blob, and submits it to the network as-is. Since signed transaction objects are immutable, no portion of the transaction can be modified or automatically filled in after submission. * Sign-and-submit mode takes a JSON-formatted Transaction object, completes and signs the transaction in the same manner as the [sign command](#sign), and then submits the signed transaction. We recommend only using this mode for testing and development. -To send a transaction as robustly as possible, you should construct and [`sign`](#sign) it in advance, persist it somewhere that you can access even after a power outage, then `submit` it as a `tx_blob`. After submission, monitor the network with the [`tx`](#tx) command to see if the transaction was successfully applied; if a restart or other problem occurs, you can safely re-submit the `tx_blob` transaction: it won't be applied twice since it has the same sequence number as the old transaction. +To send a transaction as robustly as possible, you should construct and [`sign`](#sign) it in advance, persist it somewhere that you can access even after a power outage, then `submit` it as a `tx_blob`. After submission, monitor the network with the [`tx`](#tx) command to see if the transaction was successfully applied; if a restart or other problem occurs, you can safely re-submit the `tx_blob` transaction: it won't be applied twice since it has the same sequence number as the old transaction. ### Submit-Only Mode ### @@ -6381,7 +6384,7 @@ An example of the request format: "TransactionType" : "Payment", "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", "Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX", - "Amount" : { + "Amount" : { "currency" : "USD", "value" : "1", "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn" @@ -6717,7 +6720,7 @@ JSON-RPC support for subscription callbacks is deprecated and may not work as ex ## subscribe ## [[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Subscribe.cpp "Source") -The `subscribe` method requests periodic notifications from the server when certain events happen. +The `subscribe` method requests periodic notifications from the server when certain events happen. #### Request Format #### An example of the request format: @@ -6823,7 +6826,7 @@ An example of a successful response: The response follows the [standard format](#response-formatting). The fields contained in the response vary depending on what subscriptions were included in the request. * `accounts` and `accounts_proposed` - No fields returned -* *Stream: server* - Information about the server status, such as `load_base` (the current load level of the server), `random` (a randomly-generated value), and others, subject to change. +* *Stream: server* - Information about the server status, such as `load_base` (the current load level of the server), `random` (a randomly-generated value), and others, subject to change. * *Stream: transactions*, *Stream: transactions_proposed*, and *Stream: validations* - No fields returned * *Stream: ledger* - Information about the ledgers on hand and current fee schedule, such as `fee_base` (current base fee for transactions in XRP), `fee_ref` (current base fee for transactions in fee units), `ledger_hash` (hash of the latest validated ledger), `reserve_base` (minimum reserve for accounts), and more. * `books` - No fields returned by default. If `"snapshot": true` is set in the request, returns `offers` (an array of offer definition objects defining the order book) @@ -7085,7 +7088,7 @@ The `action` field of a Peer Status stream message can have the following values ### Order Book Streams ### -When you subscribe to one or more order books with the `books` field, you get back any transactions that affect those order books. +When you subscribe to one or more order books with the `books` field, you get back any transactions that affect those order books. Example order book stream message: @@ -7881,7 +7884,7 @@ The `state` object may have some arrangement of the following fields: ## can_delete ## [[Source]
](https://github.com/ripple/rippled/blob/develop/src/ripple/rpc/handlers/CanDelete.cpp "Source") -With `online_delete` and `advisory_delete` configuration options enabled, the `can_delete` method informs the rippled server of the latest ledger which may be deleted. +With `online_delete` and `advisory_delete` configuration options enabled, the `can_delete` method informs the rippled server of the latest ledger which may be deleted. _The `can_delete` method is an [admin command](#connecting-to-rippled) that cannot be run by unpriviledged users._ @@ -8167,7 +8170,7 @@ The following is an incomplete summary of fields that may be contained in the `i | synched | Boolean | Whether this server considers itself in sync with the network. | | state | String | What portion of the consensus process is currently in progress: `open`, `consensus`, `finished`, or `accepted`. | -It is also normal to get a minimal result where the only field in `info` is `"consensus": "none"`. This indicates that the server is in between consensus rounds. +It is also normal to get a minimal result where the only field in `info` is `"consensus": "none"`. This indicates that the server is in between consensus rounds. The results of the `consensus_info` command can vary dramatically if you run it several times, even in short succession. @@ -8180,7 +8183,7 @@ The results of the `consensus_info` command can vary dramatically if you run it ## fetch_info ## [[Source]
](https://github.com/ripple/rippled/blob/315a8b6b602798a4cff4d8e1911936011e12abdb/src/ripple/rpc/handlers/FetchInfo.cpp "Source") -The `fetch_info` command returns information about objects that this server is currently fetching from the network, and how many peers have that information. It can also be used to reset current fetches. +The `fetch_info` command returns information about objects that this server is currently fetching from the network, and how many peers have that information. It can also be used to reset current fetches. _The `fetch_info` method is an [admin command](#connecting-to-rippled) that cannot be run by unpriviledged users._ @@ -8339,7 +8342,7 @@ The fields describing a fetch in progress are subject to change without notice. ## get_counts ## [[Source]
](https://github.com/ripple/rippled/blob/c7118a183a660648aa88a3546a6b2c5bce858440/src/ripple/rpc/handlers/GetCounts.cpp "Source") -The `get_counts` command provides various stats about the health of the server, mostly the number of objects of different types that it currently holds in memory. +The `get_counts` command provides various stats about the health of the server, mostly the number of objects of different types that it currently holds in memory. _The `get_counts` method is an [admin command](#connecting-to-rippled) that cannot be run by unpriviledged users._ @@ -8490,7 +8493,7 @@ For most other entries, the value indicates the number of objects of that type c ## ledger_cleaner ## [[Source]
](https://github.com/ripple/rippled/blob/df54b47cd0957a31837493cd69e4d9aade0b5055/src/ripple/rpc/handlers/LedgerCleaner.cpp "Source") -The `ledger_cleaner` command controls the [Ledger Cleaner](https://github.com/ripple/rippled/blob/f313caaa73b0ac89e793195dcc2a5001786f916f/src/ripple/app/ledger/README.md#the-ledger-cleaner), an asynchronous maintenance process that can find and repair corruption in rippled's database of ledgers. +The `ledger_cleaner` command controls the [Ledger Cleaner](https://github.com/ripple/rippled/blob/f313caaa73b0ac89e793195dcc2a5001786f916f/src/ripple/app/ledger/README.md#the-ledger-cleaner), an asynchronous maintenance process that can find and repair corruption in rippled's database of ledgers. _The `ledger_cleaner` method is an [admin command](#connecting-to-rippled) that cannot be run by unpriviledged users._ @@ -8680,7 +8683,7 @@ Connecting to 127.0.0.1:5005 -The response follows the [standard format](#response-formatting). The response format depends on whether the request specified a `severity`. If it did, the log level is changed and a successful result contains no additional fields. +The response follows the [standard format](#response-formatting). The response format depends on whether the request specified a `severity`. If it did, the log level is changed and a successful result contains no additional fields. Otherwise, the request contains the following field: @@ -9769,7 +9772,7 @@ The response follows the [standard format](#response-formatting), with a success ## json ## -The `json` method is a proxy to running other commands, and accepts the parameters for the command as a JSON value. It is *exclusive to the Commandline client*, and intended for cases where the commandline syntax for specifying parameters is inadequate or undesirable. +The `json` method is a proxy to running other commands, and accepts the parameters for the command as a JSON value. It is *exclusive to the Commandline client*, and intended for cases where the commandline syntax for specifying parameters is inadequate or undesirable. #### Request Format #### An example of the request format: diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md index 8645cda624..b9faeb8e5f 100644 --- a/content/reference-transaction-format.md +++ b/content/reference-transaction-format.md @@ -196,7 +196,7 @@ Every transaction type has the same set of fundamental fields: | SigningPubKey | String | PubKey | (Automatically added when signing) Hex representation of the public key that corresponds to the private key used to sign this transaction. If an empty string, indicates a multi-signature is present in the `Signers` field instead. | | [Signers](#multi-signing) | Array | Array | (Optional) Array of objects that represent a multi-signature which authorizes this transaction. | | SourceTag | Unsigned Integer | UInt32 | (Optional) Arbitrary integer used to identify the reason for this payment, or the hosted wallet on whose behalf this transaction is made. Conventionally, a refund should specify the initial payment's `SourceTag` as the refund payment's `DestinationTag`. | -| TransactionType | String | UInt16 | The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, `AccountSet`, and `SetRegularKey`. | +| TransactionType | String | UInt16 | The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, `AccountSet`, `SetRegularKey`, and `SignerListSet`. | | TxnSignature | String | VariableLength | (Automatically added when signing) The signature that verifies this transaction as originating from the account it says it is from. | **Note:** The deprecated `PreviousTxnID` transaction parameter was removed entirely in [rippled 0.28.0][]. Use `AccountTxnID` instead. @@ -285,7 +285,7 @@ Example of a transaction with a Memos field: ### Multi-signing ### -The `Signers` field contains a multi-signature, which has signatures from up to 8 key pairs, that together should authorize the transaction. A multi-signature replaces a single signature by either the master key or regular key. To provide a multi-signature, an account must first have a SignerList associated with it, which it can do by sending a [SignerListSet](#signerlistset) transaction. +The `Signers` field contains a multi-signature, which has signatures from up to 8 key pairs, that together should authorize the transaction. A multi-signature authorizes a transaction in place of a single-signature. To provide a multi-signature, an account must first have a SignerList associated with it, which it can do by sending a [SignerListSet](#signerlistset) transaction. The `Signers` list is an array of objects, each with one field, `Signer`. The `Signer` field has the following nested fields: @@ -486,7 +486,7 @@ The available AccountSet flags are: | asfRequireDest | 1 | Require a destination tag to send transactions to this account. | lsfRequireDestTag | | asfRequireAuth | 2 | Require authorization for users to hold balances issued by this account. (This prevents users unknown to a gateway from holding funds issued by that gateway.) | lsfRequireAuth | | asfDisallowXRP | 3 | XRP should not be sent to this account. (Enforced by client applications, not by `rippled`) | lsfDisallowXRP | -| asfDisableMaster | 4 | Disallow use of the master key. Can only be enabled if the account has a [RegularKey](#setregularkey) configured. | lsfDisableMaster | +| asfDisableMaster | 4 | Disallow use of the master key. Can only be enabled if the account has configured another way to sign transactions, such as a [Regular Key](#setregularkey) or a [Signer List](#signerlistset). | lsfDisableMaster | | asfAccountTxnID | 5 | Track the ID of this account's most recent transaction. Required for [AccountTxnID](#accounttxnid) | (None) | | asfNoFreeze | 6 | Permanently give up the ability to [freeze individual trust lines or disable Global Freeze](concept-freeze.html). This flag can never be disabled after being enabled. | lsfNoFreeze | | asfGlobalFreeze | 7 | [Freeze](concept-freeze.html) all assets issued by this account. | lsfGlobalFreeze | @@ -543,11 +543,11 @@ A SetRegularKey transaction changes the regular key used by the account to sign |-------|-----------|--------------------------------------------------------|-------------| | RegularKey | String | Account | (Optional) The public key of a new keypair, to use as the regular key to this account, as a base-58-encoded string in the same format as an account address. If omitted, removes the existing regular key. | -Instead of using an account's master key to sign transactions, you can set an alternate key pair, called the "Regular Key". As long as the public key for this key pair is set in the `RegularKey` field of an account this way, then the secret of the Regular Key pair can be used to sign transactions. (The master secret can still be used, too, unless you set the [asfDisableMaster account flag](#accountset-flags).) +Instead of using an account's master key to sign transactions, you can set an alternate key pair, called the "Regular Key". As long as the public key for this key pair is set in the `RegularKey` field of an account this way, then the secret of the Regular Key pair can be used to sign transactions. (Other methods of signing transactions can also be used, including [multi-signing](#multi-signing) or the master key. -A Regular Key pair is generated in the same way as any other Ripple keys (for example, with [wallet_propose](reference-rippled.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. +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). The Master Key can be [disabled](#accountset-flags) but it cannot be changed. Therefore, it is beneficial to security sign transactions with a Regular Key instead of the master key whenever possible. For even greater security, you can use [multi-signing](#multi-signing), but multi-signing costs additional XRP in transaction fees and reserves. -If your regular key is compromised, but the master key is not, you can use this method to regain control of your account. In some cases, you can even send a [key reset transaction](concept-transaction-cost.html#key-reset-transaction) without paying the [transaction cost](#transaction-cost). +If your regular key is compromised, but the master key is not, you can use a SetRegularKey transaction to regain control of your account. In some cases, you can even send a [key reset transaction](concept-transaction-cost.html#key-reset-transaction) without paying the [transaction cost](#transaction-cost). From 25a18df9bb5d3ff90e8753b2a5fe0cb48b89abd4 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Wed, 23 Sep 2015 12:55:38 -0700 Subject: [PATCH 05/40] tx format - multi-signing tef codes and other errors --- content/reference-transaction-format.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md index b9faeb8e5f..31657c3208 100644 --- a/content/reference-transaction-format.md +++ b/content/reference-transaction-format.md @@ -1015,6 +1015,9 @@ These codes indicate that the transaction failed to apply, but the transaction c | tefWRONG\_PRIOR | The transaction contained an `AccountTxnID` field (or the deprecated `PreviousTxnID` field), but the transaction specified there does not match the account's previous transaction. | | tefMASTER\_DISABLED | The transaction was signed with the account's master key, but the account has the `lsfDisableMaster` field set. | | tefMAX\_LEDGER | The transaction included a [`LastLedgerSequence`](#lastledgersequence) parameter, but the current ledger's sequence number is already higher than the specified value. | +| tefBAD\_SIGNATURE | The transaction was [multi-signed](#multi-signing), but contained a signature for an address not part of a SignerList associated with the sending account. | +| tefBAD\_QUORUM | The transaction was [multi-signed](#multi-signing), but the total weights of all included signatures did not meet the quorum. | +| tefNOT\_MULTI\_SIGNING | The transaction was [multi-signed](#multi-signing), but the sending account has no SignerList defined. | ### ter Codes ### @@ -1062,18 +1065,17 @@ These codes indicate that the transaction failed, but it was applied to a ledger | tecNO\_LINE\_REDUNDANT | 127 | The transaction failed because it attempted to set a trust line to its default state, but the trust line did not exist. | | tecPATH\_DRY | 128 | The transaction failed because the provided paths did not have enough liquidity to send anything at all. This could mean that the source and destination accounts are not linked by trust lines. | | tecUNFUNDED | 129 | **DEPRECATED.** Replaced by tecUNFUNDED\_OFFER and tecUNFUNDED\_PAYMENT. | -| tecNO\_ALTERNATIVE\_KEY | 130 | The transaction tried to remove the only available method of signing 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. (Renamed from `tecMASTER_DISABLED` after [rippled 0.30.0](https://github.com/ripple/rippled/releases/tag/0.30.0) | +| tecNO\_ALTERNATIVE\_KEY | 130 | The transaction tried to remove the only available method of signing 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` instead.) | | tecNO\_REGULAR\_KEY | 131 | The [AccountSet transaction](#accountset) tried to disable the Master Key, but the account does not have a Regular Key set. (Disabling the Master Key without having a Regular Key configured would make the account unusable.) | | tecOWNERS | 132 | The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the [`lsfRequireAuth`](#accountset-flags) flag if it has any trust lines or available offers. | | tecNO\_ISSUER | 133 | The account specified in the `issuer` field of a currency amount does not exist. | | tecNO\_AUTH | 134 | The transaction failed because it needs to add a balance on a trust line to an account with the `lsfRequireAuth` flag enabled, and that trust line has not been authorized. If the trust line does not exist at all, tecNO\_LINE occurs instead. | | tecNO\_LINE | 135 | The `TakerPays` field of the [OfferCreate transaction](#offercreate) specifies an asset whose issuer has `lsfRequireAuth` enabled, and the account making the offer does not have a trust line for that asset. (Normally, making an offer implicitly creates a trust line if necessary, but in this case it does not bother because you cannot hold the asset without authorization.) If the trust line exists, but is not authorized, tecNO\_AUTH occurs instead. | -| tecINSUFF\_FEE | 136 | The account sending the transaction does not possess enough XRP to pay the specified `Fee`. This error only occurs if the transaction has already been propagated through the network to achieve consensus, | | tecFROZEN | 137 | The [OfferCreate transaction](#offercreate) failed because one or both of the assets involved are subject to a [global freeze](concept-freeze.html). | -| tecNO\_TARGET | 138 | **FORTHCOMING** Part of multi-signature transactions. | -| tecNO\_PERMISSION | 139 | **FORTHCOMING** Part of multi-signature transactions. | -| tecNO\_ENTRY | 140 | **FORTHCOMING** Part of multi-signature transactions. | -| tecINSUFFICIENT\_RESERVE | 141 | **FORTHCOMING** Part of multi-signature transactions. (Code may change; see [RIPD-743](https://ripplelabs.atlassian.net/browse/RIPD-743) for status.) | +| tecNO\_TARGET | 138 | **FORTHCOMING** Reserved for future features. | +| tecNO\_PERMISSION | 139 | **FORTHCOMING** Reserved for future features. | +| tecNO\_ENTRY | 140 | **FORTHCOMING** Reserved for future features. | +| 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. | | 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))_ | | tecDST\_TAG\_NEEDED | 143 | The [Payment](#payment) transaction omitted a destination tag, but the destination account has the `lsfRequireDestTag` flag enabled. _(New in [rippled 0.28.0][])_ | | tecINTERNAL | 144 | Unspecified internal error, with transaction cost applied. This error code should not normally be returned. | From 41ee3f3271f168ba4b53dab5e21e146d5e08d7dd Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Wed, 23 Sep 2015 14:04:01 -0700 Subject: [PATCH 06/40] tx format multi-signing: minor restructure to prep for how to --- content/reference-transaction-format.md | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md index 31657c3208..ddd4537305 100644 --- a/content/reference-transaction-format.md +++ b/content/reference-transaction-format.md @@ -28,9 +28,7 @@ Transactions are only valid if signed, submitted, and accepted into a validated Signing a transaction cryptographically proves that the person in charge of the account sending the transaction is authorized to do so. Only signed transactions can be submitted to the network and included in a validated ledger. A signed transaction is immutable: its contents cannot change, and the signature is not valid for any other transaction. -You can sign a transaction using a secret key: either the master secret, or a regular secret if the account has a regular key pair associated with it. (See [SetRegularKey](#setregularkey) for details.) - -Multi-signature transactions are [in development](https://wiki.ripple.com/Multisign). +You sign a transaction using a secret key: either the master secret, or a regular secret if the account has a regular key pair associated with it. (See [SetRegularKey](#setregularkey) for details.) If your account has a SignerList associated with it, you can use a [multi-signature](#multi-signing) instead. Typically, you create a transaction in JSON format first. Here is an example of an unsigned Payment-type transaction in JSON: @@ -50,11 +48,11 @@ Typically, you create a transaction in JSON format first. Here is an example of } ``` -After doing that, you generate the signed binary format for the transaction. There are two ways to do this: +After doing that, you generate the signed binary format for the transaction. For transactions authorized by only a single signature, you have two options: 1. Convert it to a binary blob and sign it offline. This is preferable, since it means that the account secret used for signing the transaction is never transmitted over any network connection. * You can use [RippleAPI](reference-rippleapi.html#sign) to perform offline signing. -2. Have a `rippled` server sign the transaction for you. The [sign command](reference-rippled.html#sign) takes a JSON-format transaction and secret and returns the signed binary transaction format ready for submission. (Transmitting your account secret is dangerous, so you should only do this from within a trusted and encrypted sub-net, to a server you control.) +2. Have a `rippled` server sign the transaction for you. The [sign command](reference-rippled.html#sign) takes a JSON-format transaction and secret and returns the signed binary transaction format ready for submission. (Transmitting your account secret is dangerous, so you should only do this from within a trusted and encrypted connection, or through a local connection, and only to a server you control.) * As a shortcut, you can use the [submit command](reference-rippled.html#submit) with a `tx_json` object to sign and submit a transaction all at once. This is only recommended for testing and development purposes. In either case, signing a transaction generates a binary blob that can be submitted to the network. This means using `rippled`'s [submit command](reference-rippled.html#submit). Here is an example of the same transaction, as a signed blob, being submitted with the WebSocket API: @@ -157,6 +155,12 @@ After a transaction has been submitted, if it gets accepted into a validated led } ``` +### Multi-Signing ### + +A multi-signature authorizes a transaction in place of a single-signature. To provide a multi-signature, an account must first have a SignerList associated with it, which it can do by sending a [SignerListSet](#signerlistset) transaction. + +TODO: more detail on how to actually sign and submit a multi-signed transaction. + ### Reliable Transaction Submission ### Reliably submitting transactions is the process of achieving both of the following: @@ -194,7 +198,7 @@ Every transaction type has the same set of fundamental fields: | [Memos](#memos) | Array of Objects | Array | (Optional) Additional arbitrary information used to identify this transaction. | | [Sequence](#canceling-or-skipping-a-transaction) | Unsigned Integer | UInt32 | (Required, but [auto-fillable](#auto-fillable-fields)) The sequence number, relative to the initiating account, of this transaction. A transaction is only valid if the `Sequence` number is exactly 1 greater than the last-valided transaction from the same account. | | SigningPubKey | String | PubKey | (Automatically added when signing) Hex representation of the public key that corresponds to the private key used to sign this transaction. If an empty string, indicates a multi-signature is present in the `Signers` field instead. | -| [Signers](#multi-signing) | Array | Array | (Optional) Array of objects that represent a multi-signature which authorizes this transaction. | +| [Signers](#signers-field) | Array | Array | (Optional) Array of objects that represent a multi-signature which authorizes this transaction. | | SourceTag | Unsigned Integer | UInt32 | (Optional) Arbitrary integer used to identify the reason for this payment, or the hosted wallet on whose behalf this transaction is made. Conventionally, a refund should specify the initial payment's `SourceTag` as the refund payment's `DestinationTag`. | | TransactionType | String | UInt16 | The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, `AccountSet`, `SetRegularKey`, and `SignerListSet`. | | TxnSignature | String | VariableLength | (Automatically added when signing) The signature that verifies this transaction as originating from the account it says it is from. | @@ -283,17 +287,15 @@ Example of a transaction with a Memos field: } ``` -### Multi-signing ### +### Signers Field ### -The `Signers` field contains a multi-signature, which has signatures from up to 8 key pairs, that together should authorize the transaction. A multi-signature authorizes a transaction in place of a single-signature. To provide a multi-signature, an account must first have a SignerList associated with it, which it can do by sending a [SignerListSet](#signerlistset) transaction. - -The `Signers` list is an array of objects, each with one field, `Signer`. The `Signer` field has the following nested fields: +The `Signers` field contains a [multi-signature](#multi-signing), which has signatures from up to 8 key pairs, that together should authorize the transaction. The `Signers` list is an array of objects, each with one field, `Signer`. The `Signer` field has the following nested fields: | Field | Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description | |-------|------|--------------------------------------------------------|-------------| | Account | String | AccountID | The address associated with this signature, as it appears in the SignerList. | | TxnSignature | String | Blob | A signature for this transaction, verifiable using the `SigningPubKey`. | -| SigningPubKey | String | The public key used to create this signature. | +| 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. From a1e89557b801cc842e0a9b12e622faa479b0b472 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Wed, 23 Sep 2015 17:33:38 -0700 Subject: [PATCH 07/40] example signerlistset --- content/reference-transaction-format.md | 28 ++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md index ddd4537305..01ec4e88b3 100644 --- a/content/reference-transaction-format.md +++ b/content/reference-transaction-format.md @@ -762,7 +762,33 @@ The SignerListSet transaction creates, modifies, or removes a list of signers th Example SignerListSet: ``` -TODO +{ + "Flags": 0, + "TransactionType": "SignerListSet", + "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "Fee": "10000", + "SignerQuorum": 3, + "SignerEntries": [ + { + "SignerEntry": { + "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SignerWeight": 2 + } + }, + { + "SignerEntry": { + "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + "SignerWeight": 1 + } + }, + { + "SignerEntry": { + "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n", + "SignerWeight": 1 + } + } + ] +} ``` | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description | From ffdb26db768a4243649c7aa887cddb50ed7f3d1e Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Thu, 24 Sep 2015 00:59:41 -0700 Subject: [PATCH 08/40] ledger - signerlist example; tx format - tefBAD_AUTH_MASTER placeholder --- content/reference-ledger-format.md | 32 ++++++++++++++++++++++++- content/reference-transaction-format.md | 1 + 2 files changed, 32 insertions(+), 1 deletion(-) diff --git a/content/reference-ledger-format.md b/content/reference-ledger-format.md index 55def9324a..686aa968fb 100644 --- a/content/reference-ledger-format.md +++ b/content/reference-ledger-format.md @@ -408,7 +408,36 @@ The `SignerList` node type represents a list of parties that, as a group, are au Example SignerList node: ``` -TODO +{ + "Flags": 0, + "LedgerEntryType": "SignerList", + "OwnerNode": "0000000000000000", + "PreviousTxnID": "5904C0DC72C58A83AEFED2FFC5386356AA83FCA6A88C89D00646E51E687CDBE4", + "PreviousTxnLgrSeq": 16061435, + "SignerEntries": [ + { + "SignerEntry": { + "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SignerWeight": 2 + } + }, + { + "SignerEntry": { + "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n", + "SignerWeight": 1 + } + }, + { + "SignerEntry": { + "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + "SignerWeight": 1 + } + } + ], + "SignerListID": 0, + "SignerQuorum": 3, + "index": "A9C28A28B85CD533217F5C0A0C7767666B093FA58A0F2D80026FCC4CD932DDC7" +} ``` A SignerList node has the following fields: @@ -436,3 +465,4 @@ When processing a multi-signed transaction, the server dereferences the `Account ### SignerLists and Reserves ### A SignerList contributes to the [Account Reserve](https://wiki.ripple.com/Reserves). The SignerList itself counts as two objects, and each member of the list counts as one, so that the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line ([RippleState](#ripplestate)) or [Offer](#offer) node in the ledger. + diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md index 01ec4e88b3..6027c8fd45 100644 --- a/content/reference-transaction-format.md +++ b/content/reference-transaction-format.md @@ -1046,6 +1046,7 @@ These codes indicate that the transaction failed to apply, but the transaction c | tefBAD\_SIGNATURE | The transaction was [multi-signed](#multi-signing), but contained a signature for an address not part of a SignerList associated with the sending account. | | tefBAD\_QUORUM | The transaction was [multi-signed](#multi-signing), but the total weights of all included signatures did not meet the quorum. | | tefNOT\_MULTI\_SIGNING | The transaction was [multi-signed](#multi-signing), but the sending account has no SignerList defined. | +| tefBAD\_AUTH\_MASTER | (something to do with the key not being the right one for this account) | ### ter Codes ### From d04cdfc6de4dd7fa4d3a668bd9ecdaa5c3ed3cf8 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Tue, 29 Sep 2015 18:28:04 -0700 Subject: [PATCH 09/40] multisign tutorial --- concept-fee-voting.html | 1 + concept-fees.html | 1 + concept-freeze.html | 1 + ...ept-issuing-and-operational-addresses.html | 1 + concept-paths.html | 1 + concept-reserves.html | 1 + concept-transaction-cost.html | 1 + concept-transfer-fees.html | 1 + content/reference-transaction-format.md | 25 +- content/tutorial-multisign.md | 707 ++++++++++++++++ data-api-v2-tool.html | 1 + index.html | 2 + multisign.html | 190 +++++ reference-data-api.html | 1 + reference-ledger-format.html | 114 +++ reference-rippleapi.html | 1 + reference-rippled.html | 55 +- reference-transaction-format.html | 214 ++++- ripple-api-tool.html | 1 + tool-jsonrpc.html | 1 + tool/dactyl-config.yml | 7 + tool/pages.json | 162 ---- tutorial-gateway-guide.html | 1 + tutorial-multisign.html | 797 ++++++++++++++++++ tutorial-reliable-transaction-submission.html | 2 + tutorial-rippleapi-beginners-guide.html | 2 + tutorial-rippled-setup.html | 2 + 27 files changed, 2068 insertions(+), 225 deletions(-) create mode 100644 content/tutorial-multisign.md create mode 100644 multisign.html delete mode 100644 tool/pages.json create mode 100644 tutorial-multisign.html diff --git a/concept-fee-voting.html b/concept-fee-voting.html index 2793c93ef9..c80e54520d 100644 --- a/concept-fee-voting.html +++ b/concept-fee-voting.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • diff --git a/concept-fees.html b/concept-fees.html index 292434a1e0..bd7b02cbc8 100644 --- a/concept-fees.html +++ b/concept-fees.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • diff --git a/concept-freeze.html b/concept-freeze.html index 2b2b06bd76..0e82fb9097 100644 --- a/concept-freeze.html +++ b/concept-freeze.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • diff --git a/concept-issuing-and-operational-addresses.html b/concept-issuing-and-operational-addresses.html index 48a65dd615..ec0ed447df 100644 --- a/concept-issuing-and-operational-addresses.html +++ b/concept-issuing-and-operational-addresses.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • diff --git a/concept-paths.html b/concept-paths.html index 959f9a53cd..fb9949f7ed 100644 --- a/concept-paths.html +++ b/concept-paths.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • diff --git a/concept-reserves.html b/concept-reserves.html index 865c1814d4..dd6ce71020 100644 --- a/concept-reserves.html +++ b/concept-reserves.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • diff --git a/concept-transaction-cost.html b/concept-transaction-cost.html index 103e75048b..12fbb49f28 100644 --- a/concept-transaction-cost.html +++ b/concept-transaction-cost.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • diff --git a/concept-transfer-fees.html b/concept-transfer-fees.html index cd927a0a2e..5ba03fda3e 100644 --- a/concept-transfer-fees.html +++ b/concept-transfer-fees.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md index 6027c8fd45..2cb6c4a7fb 100644 --- a/content/reference-transaction-format.md +++ b/content/reference-transaction-format.md @@ -157,9 +157,30 @@ After a transaction has been submitted, if it gets accepted into a validated led ### Multi-Signing ### -A multi-signature authorizes a transaction in place of a single-signature. To provide a multi-signature, an account must first have a SignerList associated with it, which it can do by sending a [SignerListSet](#signerlistset) transaction. +Multi-signing in Ripple is the act of authorizing transactions for the Ripple +Consensus Ledger by using a combination of multiple secret keys. Multi-signing +allows various use cases including: + +* If you require keys from different devices, a malicious user must compromise multiple machines in order to send transactions on your behalf. +* If the keys to an account are in the custody of entirely different people, those people must collaborate in order to send transaction from that account. +* Delegate a group of others who can send transactions for you if you are unavailable or unable to sign normally. +* ... and more. + +To set up multi-signing for an account, the process is straightforward: + +1. Use a [SignerListSet transaction](#signerlistset) to define which accounts or keys can, together, authorize transactions for this account. +2. Optionally disable the master key with an [AccountSet transaction](#accountset) using the `asfDisableMaster` flag. +3. Optionally remove the existing regular key (if any) with a [SetRegularKey transaction](#setregularkey). + +After an account has a SignerList associated with it, the process of submitting a multi-signed transaction is as follows: + +1. Create the transaction to be signed as a JSON object +2. Generate a signature for each account using the [`sign_for` command](rippled-apis.html#sign-for). +3. Combine the signatures and submit using the [`submit_multisigned` command](rippled-apis.html#submit-multisigned). + +Main article: [How to Multi-Sign](multisign.html) + -TODO: more detail on how to actually sign and submit a multi-signed transaction. ### Reliable Transaction Submission ### diff --git a/content/tutorial-multisign.md b/content/tutorial-multisign.md new file mode 100644 index 0000000000..b754689f55 --- /dev/null +++ b/content/tutorial-multisign.md @@ -0,0 +1,707 @@ +Introduction to Multi-Signing +================================================================== + +Multi-signing in Ripple is the act of authorizing transactions for the Ripple +Consensus Ledger by using a combination of multiple secret keys. After setting +up multi-signing for an account, you can put the master secret in cold storage, +or even disable the master key entirely. With multiple secret keys required to +authorize a multi-signature, you can improve security in several ways. + +* If you keep an account's keys on different devices, a malicious user must compromise multiple machines in order to send transactions on your behalf. +* If the keys to an account are in the custody of entirely different people, those people must collaborate in order to send transaction from that account. +* You can use the SignerList as a backup, to delegate a group of others who can send transactions for you if you are unavailable or unable to sign using your regular key. +* Even more uses than can be described here. + + +Availability of Multi-Signing +----------------------------------------------------------------- + +Multi-signing is due to be enabled by an **Amendment** to the Ripple Consensus +Protocol. This Amendment must be approved by a consensus of validators showing +consistent support for the feature over a period of time. For more information, +see Amendments (TODO: link). + +You can test multi-signing by running `rippled` in stand-alone mode with the +feature enabled. In stand-alone mode, `rippled` does not communicate with the +rest of the Ripple peer-to-peer network, but you can perform most of the same +actions on your local server only. This way, you can be sure that you are ready +for multi-signing when it goes live. + + + +How to Multi-Sign +================================================================= + +The basic process of Multi-Signing a transaction is necessarily more +complex than the process of signing a transaction with a single master key or +regular key. + +1. Download and build rippled with multi-sign +----------------------------------------------------------------- + +Until a binary for `rippled` with multi-signing is available, the best you can do is build it from source. + + $ git clone git@github.com:scottschurr/rippled.git (TODO: switch to a Ripple Labs repo when available) + $ git checkout fix-sign_for + $ scons + +See [rippled build instructions](https://wiki.ripple.com/Rippled_build_instructions) for help building from source. + + +2. Configure rippled to enable MultiSign +----------------------------------------------------------------- +Add the following to the bottom of the config file: + + [features] + MultiSign + +Note that this stanza is case-sensitive. + +3. Start rippled in stand-alone mode +----------------------------------------------------------------- + +If you have previously synced to the network, you can have the server load the +latest ledger as a starting place for stand-alone mode using the `--load` +commandline option: + + $ sudo ./build/rippled --conf=/home/mduo13/.config/ripple/rippled.cfg -a --load + +If you'd rather start from scratch, you can use the `--start` commandline +option to create a fresh ledger. In this case, the root account holds all +100 billion XRP: + +**Address:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` + +**Secret:** `snoPBrXtMeMyMHUVTgbuqAfg1SUTb` ("masterpassphrase") + + +4. Generate keys for a new wallet +----------------------------------------------------------------- + +This step is not strictly necessary. For this process, we generate the keys to +a new Ripple account and then set up multi-signing for that account. To set up +multi-signing on an existing Ripple account, just use the keys to that account. + + $ build/rippled wallet_propose + Loading: "/home/mduo13/.config/ripple/rippled.cfg" + Connecting to 127.0.0.1:5005 + { + "result" : { + "account_id" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "key_type" : "secp256k1", + "master_key" : "NED MANA SPA BLUR HERS HEAT RED NIBS MAIN MELT NOB RARE", + "master_seed" : "shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq", + "master_seed_hex" : "99C7F2DCD88218372B7509ADF7DC562B", + "public_key" : "aBPvx491i2ZPVzmxoAmAVq5qXAxAZgmjfxoMTxFCg9Xxf2xwVVLc", + "public_key_hex" : "0303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D", + "status" : "success" + } + } + +As always, be sure that an account's secret key never gets transmitted to +anyone you don't trust with full control of that account, and certainly not +unencrypted over the network. + + +5. Fund the new account with an existing wallet +----------------------------------------------------------------- + +Again, this step is only necessary if you are setting up a new account to use +multi-signing for this example. + + $ build/rippled submit '{ + > "TransactionType" : "Payment", + > "Account" : "", + > "Destination" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + > "Amount" : "100000000", + > "Flags": 2147483648 + > }' + Loading: "/home/mduo13/.config/ripple/rippled.cfg" + Connecting to 127.0.0.1:5005 + { + "result" : { + "engine_result" : "tesSUCCESS", + "engine_result_code" : 0, + "engine_result_message" : "The transaction was applied. Only final in a validated ledger.", + "status" : "success", + "tx_blob" : "1200002280000000240000001E614000000005F5E10068400000000000000A7321023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC67446304402207AB5D16F58E9E6ADBBDD24837CAB80D871860E47EB0840FE57403FB979755A6D022015FE7A8838BEE6C18962C246D6D27791B7EE34B93415AE3824D12564E7A886C6811493B89AFCAD4C8EAC2B131C1331FEF12AE1522BBE83142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1", + "tx_json" : { + "Account" : "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH", + "Amount" : "100000000", + "Destination" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "Fee" : "10", + "Flags" : 2147483648, + "Sequence" : 30, + "SigningPubKey" : "023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6", + "TransactionType" : "Payment", + "TxnSignature" : "304402207AB5D16F58E9E6ADBBDD24837CAB80D871860E47EB0840FE57403FB979755A6D022015FE7A8838BEE6C18962C246D6D27791B7EE34B93415AE3824D12564E7A886C6", + "hash" : "8C7A4D35D71CE80DA4EDAC91D620B6A348B7691B78AA2896284135378E10E0C2" + } + } + } + + +6. Manually close the ledger +----------------------------------------------------------------- + +In the live network, you would simply wait for the ledger to close +automatically as the result of consensus. However, a rippled node running in +stand-alone mode does not engage in consensus, so you must manually close the +ledger with the [`ledger_accept` command](rippled-apis.html#ledger-accept). + + $ build/rippled ledger_accept + Loading: "/home/mduo13/.config/ripple/rippled.cfg" + Connecting to 127.0.0.1:5005 + { + "result" : { + "ledger_current_index" : 16061437, + "status" : "success" + } + } + + +7. Create a SignerList on the new account with a SignerListSet transaction +----------------------------------------------------------------- + +Before you can multi-sign transactions, you must associate a SignerList with +your account, so that RCL knows which keys can be used to sign for you. You do +this with a [SignerListSet transaction](transactions.html#signerlistset). + +In this example, the SignerList has 3 members, with the weights and quorum set +up such that multi-signed transactions need a signature from +rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other +two members of the list. The `Account` values you use in your list can be +funded accounts that exist in the ledger or just unused addresses. + + $ build/rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{ + > "Flags": 0, + > "TransactionType": "SignerListSet", + > "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + > "Fee": "10000", + > "SignerQuorum": 3, + > "SignerEntries": [ + > { + > "SignerEntry": { + > "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + > "SignerWeight": 2 + > } + > }, + > { + > "SignerEntry": { + > "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + > "SignerWeight": 1 + > } + > }, + > { + > "SignerEntry": { + > "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n", + > "SignerWeight": 1 + > } + > } + > ] + > }' + Loading: "/home/mduo13/.config/ripple/rippled.cfg" + Connecting to 127.0.0.1:5005 + { + "result" : { + "engine_result" : "tesSUCCESS", + "engine_result_code" : 0, + "engine_result_message" : "The transaction was applied. Only final in a validated ledger.", + "status" : "success", + "tx_blob" : "12000C2200000000240000000120230000000368400000000000271073210303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D74473045022100BEDFA12502C66DDCB64521972E5356F4DB965F553853D53D4C69B4897F11B4780220595202D1E080345B65BAF8EBD6CA161C227F1B62C7E72EA5CA282B9434A6F04281142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1F4EB1300028114204288D2E47F8EF6C99BCC457966320D12409711E1EB13000181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1EB13000181143A4C02EA95AD6AC3BED92FA036E0BBFB712C030CE1F1", + "tx_json" : { + "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "Fee" : "10000", + "Flags" : 0, + "Sequence" : 1, + "SignerEntries" : [ + { + "SignerEntry" : { + "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SignerWeight" : 2 + } + }, + { + "SignerEntry" : { + "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + "SignerWeight" : 1 + } + }, + { + "SignerEntry" : { + "Account" : "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n", + "SignerWeight" : 1 + } + } + ], + "SignerQuorum" : 3, + "SigningPubKey" : "0303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D", + "TransactionType" : "SignerListSet", + "TxnSignature" : "3045022100BEDFA12502C66DDCB64521972E5356F4DB965F553853D53D4C69B4897F11B4780220595202D1E080345B65BAF8EBD6CA161C227F1B62C7E72EA5CA282B9434A6F042", + "hash" : "3950D98AD20DA52EBB1F3937EF32F382D74092A4C8DF9A0B1A06ED25200B5756" + } + } + } + + +8. Manually close the ledger again +----------------------------------------------------------------- + +As before, you would wait for the ledger to close on a live network. We use +the [`ledger_accept` command](rippled-apis.html#ledger-accept) to manually +close the ledger when running `rippled` in stand-alone mode. + + $ build/rippled ledger_accept + Loading: "/home/mduo13/.config/ripple/rippled.cfg" + Connecting to 127.0.0.1:5005 + { + "result" : { + "ledger_current_index" : 16061438, + "status" : "success" + } + } + + +9. Confirm the presence of the new signer list using account_objects +----------------------------------------------------------------- + +Normally an account has lots of different types of objects, but for this new +account, the only thing we've done is add a SignerList, so it should be easy to +find in the results of the +[`account_objects` command](rippled-apis.html#account-objects). + + $ build/rippled account_objects rnBFvgZphmN39GWzUJeUitaP22Fr9be75H + Loading: "/home/mduo13/.config/ripple/rippled.cfg" + Connecting to 127.0.0.1:5005 + { + "result" : { + "account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "account_objects" : [ + { + "Flags" : 0, + "LedgerEntryType" : "SignerList", + "OwnerNode" : "0000000000000000", + "PreviousTxnID" : "3950D98AD20DA52EBB1F3937EF32F382D74092A4C8DF9A0B1A06ED25200B5756", + "PreviousTxnLgrSeq" : 16061437, + "SignerEntries" : [ + { + "SignerEntry" : { + "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SignerWeight" : 2 + } + }, + { + "SignerEntry" : { + "Account" : "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n", + "SignerWeight" : 1 + } + }, + { + "SignerEntry" : { + "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + "SignerWeight" : 1 + } + } + ], + "SignerListID" : 0, + "SignerQuorum" : 3, + "index" : "92373B9F1683001079764527F0BD553ED8656A9934FE641A7F0A0BF4DB230E0E" + } + ], + "ledger_current_index" : 16061438, + "status" : "success", + "validated" : false + } + } + + +10. Create a new transaction that you plan to multi-sign +----------------------------------------------------------------- + +You have to specify _everything_ about this transaction, including Fee and +Sequence. Also include the field `SigningPubKey` as an empty string -- this +indicates that the transaction is multi-signed. + +Here's an example transaction we can send from our test account: + + { + "TransactionType": "TrustSet", + "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "Flags": 262144, + "LimitAmount": { + "currency": "USD", + "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "value": "100" + }, + "Sequence": 2, + "SigningPubKey":"", + "Fee": "12000" + } + +(If you started from a fresh ledger, you first need to fund the account +specified by the `issuer` in this example, and then manually close the ledger.) + +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 fee, 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 load fee increases in that time. + + +11. Get a signature using the sign_for command +----------------------------------------------------------------- + + $ build/rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW '{ + > "TransactionType": "TrustSet", + > "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + > "Flags": 262144, + > "LimitAmount": { + > "currency": "USD", + > "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + > "value": "100" + > }, + > "Sequence": 2, + > "SigningPubKey":"", + > "Fee": "12000" + > }' + Loading: "/home/mduo13/.config/ripple/rippled.cfg" + Connecting to 127.0.0.1:5005 + { + "result" : { + "Signers" : [ + { + "Signer" : { + "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE" + } + } + ], + "status" : "success", + "tx_blob" : "1200142200040000240000000263D5038D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA9684000000000002EE0730081142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1", + "tx_json" : { + "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "Fee" : "12000", + "Flags" : 262144, + "LimitAmount" : { + "currency" : "USD", + "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "value" : "100" + }, + "Sequence" : 2, + "SigningPubKey" : "", + "TransactionType" : "TrustSet", + "hash" : "4622B2893AF3A70B4DB1FF86B25C10E92B71973895143E66029567A8541A8060" + } + } + } + +The valuable part in the response is the `Signers` field. This is the part that +you're going to need later in order to construct the full, multi-signed +transaction. + +The other parts, such as the `tx_blob`, are not very useful at this point, +unless you're "multi-signing" a transaction with only one signature. + + +12. Get additional signatures the same way +----------------------------------------------------------------- + +If the accounts in your SignerList are funded accounts, the secret key you use +to sign for those accounts can come from the regular key (if they have one), or +the master key (unless it's disabled). For accounts that don't exist in the +ledger, you can only use the master secret associated with the address. + + $ build/rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v '{ + "TransactionType": "TrustSet", + "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "Flags": 262144, + "LimitAmount": { + "currency": "USD", + "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "value": "100" + }, + "Sequence": 2, + "SigningPubKey":"", + "Fee": "12000" + }' + Loading: "/home/mduo13/.config/ripple/rippled.cfg" + Connecting to 127.0.0.1:5005 + { + "result" : { + "Signers" : [ + { + "Signer" : { + "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B", + "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1" + } + } + ], + "status" : "success", + "tx_blob" : "1200142200040000240000000263D5038D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA9684000000000002EE0730081142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1", + "tx_json" : { + "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "Fee" : "12000", + "Flags" : 262144, + "LimitAmount" : { + "currency" : "USD", + "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "value" : "100" + }, + "Sequence" : 2, + "SigningPubKey" : "", + "TransactionType" : "TrustSet", + "hash" : "4622B2893AF3A70B4DB1FF86B25C10E92B71973895143E66029567A8541A8060" + } + } + } + +Depending on the SignerList you configured, you may need to repeat this step +several times in order to get signatures from all the necessary parties. + + +13. Combine the signatures and submit +----------------------------------------------------------------- + +Take the contents of all the `Signers` arrays from all the responses, and +concatenate them in to a single `Signers` array field. The commandline syntax +for the [`submit_multisigned` command](rippled-apis.html#submit-multisigned) +takes a single JSON object with two elements: this combined `Signers` array; +and `tx_json`, which is the transaction JSON that they signed. + +This command actually submits the transaction for inclusion in the ledger. In +online mode, this relays it to other members of the network. + + $ build/rippled submit_multisigned ' { + > "Signers": [ + > { + > "Signer" : { + > "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + > "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B", + > "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1" + > } + > }, + > { + > "Signer" : { + > "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + > "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + > "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE" + > } + > } + > ], + > "tx_json": { + > "TransactionType": "TrustSet", + > "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + > "Flags": 262144, + > "LimitAmount": { + > "currency": "USD", + > "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + > "value": "100" + > }, + > "Sequence": 2, + > "SigningPubKey":"", + > "Fee": "12000" + > } + > }' + Loading: "/home/mduo13/.config/ripple/rippled.cfg" + Connecting to 127.0.0.1:5005 + { + "result" : { + "engine_result" : "tesSUCCESS", + "engine_result_code" : 0, + "engine_result_message" : "The transaction was applied. Only final in a validated ledger.", + "status" : "success", + "tx_blob" : "1200142200040000240000000263D5038D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA9684000000000002EE0730081142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF7447304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE8114204288D2E47F8EF6C99BCC457966320D12409711E1E0107321028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B7446304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1F1", + "tx_json" : { + "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "Fee" : "12000", + "Flags" : 262144, + "LimitAmount" : { + "currency" : "USD", + "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "value" : "100" + }, + "Sequence" : 2, + "Signers" : [ + { + "Signer" : { + "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE" + } + }, + { + "Signer" : { + "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B", + "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1" + } + } + ], + "SigningPubKey" : "", + "TransactionType" : "TrustSet", + "hash" : "878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78" + } + } + } + +Take note of the `hash` value from the response (In this case, it's +`878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78`) so you can +check the results of the transaction later. + + +14. Manually close the ledger one last time +----------------------------------------------------------------- + +Once again, you would wait for the ledger to close on a live network. We use +the [`ledger_accept` command](rippled-apis.html#ledger-accept) to manually +close the ledger when running `rippled` in stand-alone mode. + + $ build/rippled ledger_accept + Loading: "/home/mduo13/.config/ripple/rippled.cfg" + Connecting to 127.0.0.1:5005 + { + "result" : { + "ledger_current_index" : 16061439, + "status" : "success" + } + } + + +15. Confirm the results of the transaction +----------------------------------------------------------------- + +Use the hash value from the response to the `submit_multisigned` command. + + $ build/rippled tx 878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78 + Loading: "/home/mduo13/.config/ripple/rippled.cfg" + Connecting to 127.0.0.1:5005 + { + "result" : { + "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "Fee" : "12000", + "Flags" : 262144, + "LimitAmount" : { + "currency" : "USD", + "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "value" : "100" + }, + "Sequence" : 2, + "Signers" : [ + { + "Signer" : { + "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE" + } + }, + { + "Signer" : { + "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B", + "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1" + } + } + ], + "SigningPubKey" : "", + "TransactionType" : "TrustSet", + "date" : 496881900, + "hash" : "878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78", + "inLedger" : 16061438, + "ledger_index" : 16061438, + "meta" : { + "AffectedNodes" : [ + { + "ModifiedNode" : { + "LedgerEntryType" : "AccountRoot", + "LedgerIndex" : "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8", + "PreviousTxnID" : "6ECC8C16B76D9B9AB099CA96DD653D8A321C34F1E5972D5EE6DBA19418F4D0CC", + "PreviousTxnLgrSeq" : 16061436 + } + }, + { + "ModifiedNode" : { + "FinalFields" : { + "Flags" : 0, + "Owner" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "RootIndex" : "3B9C0CE77FCE7BCEE1A68F1E26AC467AF326239D0D816CE705E4A0E2DAD03F6D" + }, + "LedgerEntryType" : "DirectoryNode", + "LedgerIndex" : "3B9C0CE77FCE7BCEE1A68F1E26AC467AF326239D0D816CE705E4A0E2DAD03F6D" + } + }, + { + "CreatedNode" : { + "LedgerEntryType" : "RippleState", + "LedgerIndex" : "3C75A1F3DB61406AC2A9493038E8394A73F103C9229695AC7E57EB0F8AFC69E4", + "NewFields" : { + "Balance" : { + "currency" : "USD", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 65536, + "HighLimit" : { + "currency" : "USD", + "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "value" : "0" + }, + "LowLimit" : { + "currency" : "USD", + "issuer" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "value" : "100" + } + } + } + }, + { + "ModifiedNode" : { + "FinalFields" : { + "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "Balance" : "109978000", + "Flags" : 0, + "OwnerCount" : 6, + "Sequence" : 3 + }, + "LedgerEntryType" : "AccountRoot", + "LedgerIndex" : "3D728C1F82CFE419F2DC58707D1AD06E985A29217D21A991ADF154184B664F4F", + "PreviousFields" : { + "Balance" : "109990000", + "OwnerCount" : 5, + "Sequence" : 2 + }, + "PreviousTxnID" : "3950D98AD20DA52EBB1F3937EF32F382D74092A4C8DF9A0B1A06ED25200B5756", + "PreviousTxnLgrSeq" : 16061437 + } + }, + { + "ModifiedNode" : { + "FinalFields" : { + "Flags" : 0, + "Owner" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "RootIndex" : "95DA402B4D58FBFF6BAA4CB84BBC21348CC273949B61FEBCE758410EF90D147D" + }, + "LedgerEntryType" : "DirectoryNode", + "LedgerIndex" : "95DA402B4D58FBFF6BAA4CB84BBC21348CC273949B61FEBCE758410EF90D147D" + } + } + ], + "TransactionIndex" : 0, + "TransactionResult" : "tesSUCCESS" + }, + "status" : "success", + "validated" : true + } + } + +In particular, check that the `TransactionResult` is the string `tesSUCCESS`. + +On the live network, you must also confirm that the `validated` field is set to +the boolean `true`. If not, you might need to wait longer for the consensus +process to finish; or your transaction may be unable to be included in a ledger +for some reason. In stand-alone mode, the server automatically considers a +ledger to be `validated` if it has been manually closed. + + + diff --git a/data-api-v2-tool.html b/data-api-v2-tool.html index 27e3183080..5fd5199392 100644 --- a/data-api-v2-tool.html +++ b/data-api-v2-tool.html @@ -46,6 +46,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • diff --git a/index.html b/index.html index b11e3d4947..b2fe5eaaa2 100644 --- a/index.html +++ b/index.html @@ -53,6 +53,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • @@ -137,6 +138,7 @@ Ripple’s distributed settlement network is built on open-source technology tha
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
    • diff --git a/multisign.html b/multisign.html new file mode 100644 index 0000000000..a9e2ef2e11 --- /dev/null +++ b/multisign.html @@ -0,0 +1,190 @@ + + + + + + + + How to Multi-Sign a Transaction - Ripple Developer Portal + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    + + + diff --git a/reference-data-api.html b/reference-data-api.html index fad39b82df..921b2045f4 100644 --- a/reference-data-api.html +++ b/reference-data-api.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • diff --git a/reference-ledger-format.html b/reference-ledger-format.html index 847e659fa0..8fe8bbc29d 100644 --- a/reference-ledger-format.html +++ b/reference-ledger-format.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • @@ -972,6 +973,119 @@
  • The AccountID of the high account
  • The 160-bit currency code of the trust line(s)
    • +

    SignerList

    +

    [Source]

    +

    The SignerList node type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account.

    +

    Example SignerList node:

    +
    {
+    "Flags": 0,
+    "LedgerEntryType": "SignerList",
+    "OwnerNode": "0000000000000000",
+    "PreviousTxnID": "5904C0DC72C58A83AEFED2FFC5386356AA83FCA6A88C89D00646E51E687CDBE4",
+    "PreviousTxnLgrSeq": 16061435,
+    "SignerEntries": [
+        {
+            "SignerEntry": {
+                "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                "SignerWeight": 2
+            }
+        },
+        {
+            "SignerEntry": {
+                "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
+                "SignerWeight": 1
+            }
+        },
+        {
+            "SignerEntry": {
+                "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+                "SignerWeight": 1
+            }
+        }
+    ],
+    "SignerListID": 0,
+    "SignerQuorum": 3,
+    "index": "A9C28A28B85CD533217F5C0A0C7767666B093FA58A0F2D80026FCC4CD932DDC7"
+}
+
    +

    A SignerList node has the following fields:

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameJSON TypeInternal TypeDescription
    OwnerNodeStringUInt64A hint indicating which page of the owner directory links to this node, in case the directory consists of multiple nodes.
    SignerQuorumNumberUInt32A target number for signer weights. To produce a valid signature for the owner of this SignerList, the signers must provide valid signatures whose weights sum to this value or more.
    SignerEntriesArrayArrayAn array of SignerEntry objects representing the parties who are part of this signer list.
    SignerListIDNumberUInt32An ID for this signer list. Currently always set to 0. If a future update allows multiple signer lists for an account, this may change.
    PreviousTxnIDStringHash256The identifying hash of the transaction that most recently modified this node.
    PreviousTxnLgrSeqNumberUInt32The sequence number (ledger_index) of the ledger that contains the transaction that most recently modified this node.
    +

    SignerEntry object

    +

    Each member of the SignerEntries field is an object that describes that signer in the list. A SignerEntry has the following fields:

    + + + + + + + + + + + + + + + + + + + + + + + +
    NameJSON TypeInternal TypeDescription
    AccountStringAccountIDAn address whose signature contributes to the multi-signature. This does not need to be a funded Ripple account.
    SignerWeightNumberUInt16The weight of signatures from this signer. A multi-signature is only valid of the sum weight of the signatures provided meets or exceeds the SignerList's SignerQuorum value.
    +

    When processing a multi-signed transaction, the server dereferences the Account values with respect to the ledger at the time of transaction execution. If the address does not correspond to a funded AccountRoot node, then only the master secret associated with that address can be used to produce a valid signature. If the account does exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. Even if the account has a SignerList configured, a multi-signature cannot be used as a valid component to another multi-signature. (In other words, "multi-level" multi-signing is disallowed.)

    +

    SignerLists and Reserves

    +

    A SignerList contributes to the Account Reserve. The SignerList itself counts as two objects, and each member of the list counts as one, so that the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line (RippleState) or Offer node in the ledger.

    diff --git a/reference-rippleapi.html b/reference-rippleapi.html index 7a80ab8e0d..acbc978ed0 100644 --- a/reference-rippleapi.html +++ b/reference-rippleapi.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • diff --git a/reference-rippled.html b/reference-rippled.html index bbb3b3b78e..19bc46f057 100644 --- a/reference-rippled.html +++ b/reference-rippled.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • @@ -478,7 +479,7 @@ Null method

    All methods can potentially return any of the following values for the error code:

    • unknownCmd - The request does not contain a command that the rippled server recognizes.
      • -
    • `jsonInvalid1 - (WebSocket only) The request is not a proper JSON object.
        +
      • jsonInvalid - (WebSocket only) The request is not a proper JSON object.
        • JSON-RPC returns a 400 Bad Request HTTP error in this case instead.
        • @@ -490,7 +491,7 @@ Null method
      • noNetwork - The server is having trouble connecting to the rest of the Ripple Network (and is not running in stand-alone mode).
      • noCurrent - The server does not know what the current ledger is, due to high load, network problems, validator failures, incorrect configuration, or some other problem.
      • noClosed - The server does not have a closed ledger, typically because it has not finished starting up.
        • -
      • wsTextRequired - (WebSocket only) The request's opcode is not text.
        • +
      • wsTextRequired - (WebSocket only) The request's opcode is not text.

      Formatting Conventions

      The WebSocket and JSON-RPC APIs generally take the same arguments, although they're provided in a different way (See Request Formatting for details). Many similar parameters appear throughout the APIs, and there are conventions for how to specify these parameters.

      @@ -578,7 +579,7 @@ Null method

      Many API methods require you to specify an instance of the ledger, with the data retrieved being considered accurate and up-to-date as of that particular version of the shared ledger. The commands that accept a ledger version all work the same way. There are three ways you can specify which ledger you want to use:

      1. Specify a ledger by its Ledger Index in the ledger_index parameter. Each closed ledger has an identifying sequence number that is 1 higher than the previously-validated ledger. (The Genesis Ledger has sequence number 0)
        2. -
      2. Specify a ledger by its Hash value in the ledger_hash parameter.
        3. +
      3. Specify a ledger by its Hash value in the ledger_hash parameter.
      4. Specify a ledger by one of the following shortcuts, in the ledger_index parameter: -

        The following admin commands are deprecated and may be removed without further notice:

        +

        The following admin commands are deprecated and may be removed without further notice:

        Account Information

        -

        Accounts are the core unit of authentication in the Ripple Network. Each account can hold balances in multiple currencies, and all transactions must be signed by an account's secret key. In order for an account to exist in a validated ledger version, it must hold a minimum reserve amount of XRP. (The reserve for an account increases with the amount of data it is responsible for in the shared ledger.) It is expected that accounts will correspond loosely to individual users.

        +

        Accounts are the core unit of authentication in the Ripple Network. Each account can hold balances in multiple currencies, and all transactions must be signed by an account's secret key. In order for an account to exist in a validated ledger version, it must hold a minimum reserve amount of XRP. (The reserve for an account increases with the amount of data it is responsible for in the shared ledger.) It is expected that accounts will correspond loosely to individual users.

        account_currencies

        [Source]

        The account_currencies command retrieves a simple list of currencies that an account can send or receive, based on its trust lines. (This is not a thoroughly confirmed list, but it can be used to populate user interfaces.)

        @@ -970,7 +971,7 @@ Null method

    account_info

    [Source]

    -

    The account_info command retrieves information about an account, its activity, and its XRP balance. All information retrieved is relative to a particular version of the ledger.

    +

    The account_info command retrieves information about an account, its activity, and its XRP balance. All information retrieved is relative to a particular version of the ledger.

    Request Format

    An example of an account_info request:

    @@ -1629,7 +1630,7 @@ rippled account_offers r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 current

    account_objects

    [Source]

    -

    The account_objects command returns the raw ledger format for all objects owned by an account, such as outstanding offers, 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 instead.

    +

    The account_objects command returns the raw ledger format for all objects owned by an account, such as outstanding offers, trust lines in non-default state, and signer lists. For getting the balance of an account's trust lines, we recommend account_lines instead.

    Request Format

    An example of the request format:

    @@ -4731,7 +4732,7 @@ rippled ledger_accept

    There are several sources of complication in transactions. Unlike traditional banking, where a trusted third party (the bank, or the ACH) verifies the participants' identities and ensures their balances are adjusted accurately, Ripple uses cryptography and decentralized computing power to accomplish the same thing. Sending XRP, the Ripple Network's native crypto-currency, requires no third party aside from the distributed network itself. However, that is missing out on the key feature of Ripple: unlike individual crypto-currencies, the Ripple Network natively supports balances in any currency. This brings far more power, but it also means that the system must account for counterparty risk, currency conversions, and other issues. The Ripple Network must be robust to keep track of which transactions have been completely validated, even when subject to hardware failures, attacks, or natural disasters.

    tx

    [Source]

    -

    The tx method retrieves information on a single transaction.

    +

    The tx method retrieves information on a single transaction.

    Request Format

    An example of the request format:

    @@ -4961,7 +4962,7 @@ rippled tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7 fals

    transaction_entry

    [Source]

    -

    The transaction_entry method retrieves information on a single transaction from a specific ledger version. (The tx command, by contrast, searches all ledgers for the specified transaction. We recommend using that method instead.)

    +

    The transaction_entry method retrieves information on a single transaction from a specific ledger version. (The tx command, by contrast, searches all ledgers for the specified transaction. We recommend using that method instead.)

    Request Format

    An example of the request format:

    @@ -5017,7 +5018,7 @@ rippled transaction_entry E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDA -

    Note: This method does not support retrieving information from the current in-progress ledger. You must specify a ledger version in either ledger_index or ledger_hash.

    +

    Note: This method does not support retrieving information from the current in-progress ledger. You must specify a ledger version in either ledger_index or ledger_hash.

    Response Format

    An example of a successful response:

    @@ -6092,10 +6093,10 @@ rippled tx_history 0

    path_find

    [Source]

    -

    WebSocket API only! The path_find method searches for a path along which a transaction can possibly be made, and periodically sends updates when the path changes over time. For a simpler version that is supported by JSON-RPC, see ripple_path_find. For payments occurring strictly in XRP, it is not necessary to find a path, because XRP can be sent directly to any account.

    +

    WebSocket API only! The path_find method searches for a path along which a transaction can possibly be made, and periodically sends updates when the path changes over time. For a simpler version that is supported by JSON-RPC, see ripple_path_find. For payments occurring strictly in XRP, it is not necessary to find a path, because XRP can be sent directly to any account.

    There are three different modes, or sub-commands, of the path_find command. Specify which one you want with the subcommand parameter:

      -
    • create - Start sending pathfinding information
      • +
    • create - Start sending pathfinding information
    • close - Stop sending pathfinding information
    • status - Get the information of the currently-open pathfinding request
    @@ -7138,7 +7139,7 @@ rippled ripple_path_find '{"source_account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 "TransactionType" : "Payment", "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", "Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX", - "Amount" : { + "Amount" : { "currency" : "USD", "value" : "1", "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn" @@ -7224,7 +7225,7 @@ rippled sign sssssssssssssssssssssssssssss '{"TransactionType": "Payment", "Acco
  • If fee_mult_max is included, and the automatically provided Fee value is greater than the long-term base transaction cost times fee_mult_max, then the transaction fails with the error rpcHIGH_FEE. This way, you can let the server fill in the current minimum Fee value as long as the current load-based transaction cost is not too high.
    • -
  • Paths - For Payment-type transactions (excluding XRP-to-XRP transfers), the Paths field can be automatically filled, as if you did a ripple_path_find. Only filled if build_path is provided.
    • +
  • Paths - For Payment-type transactions (excluding XRP-to-XRP transfers), the Paths field can be automatically filled, as if you did a ripple_path_find. Only filled if build_path is provided.

    • Response Format

    An example of a successful response:

    @@ -7319,13 +7320,13 @@ rippled sign sssssssssssssssssssssssssssss '{"TransactionType": "Payment", "Acco

    submit

    [Source]

    -

    The submit method sends a transaction to the network to be confirmed and included in future ledgers.

    +

    The submit method sends a transaction to the network to be confirmed and included in future ledgers.

    This command has two modes:

    • Submit-only mode takes a signed, serialized transaction as a binary blob, and submits it to the network as-is. Since signed transaction objects are immutable, no portion of the transaction can be modified or automatically filled in after submission.
    • Sign-and-submit mode takes a JSON-formatted Transaction object, completes and signs the transaction in the same manner as the sign command, and then submits the signed transaction. We recommend only using this mode for testing and development.
    -

    To send a transaction as robustly as possible, you should construct and sign it in advance, persist it somewhere that you can access even after a power outage, then submit it as a tx_blob. After submission, monitor the network with the tx command to see if the transaction was successfully applied; if a restart or other problem occurs, you can safely re-submit the tx_blob transaction: it won't be applied twice since it has the same sequence number as the old transaction.

    +

    To send a transaction as robustly as possible, you should construct and sign it in advance, persist it somewhere that you can access even after a power outage, then submit it as a tx_blob. After submission, monitor the network with the tx command to see if the transaction was successfully applied; if a restart or other problem occurs, you can safely re-submit the tx_blob transaction: it won't be applied twice since it has the same sequence number as the old transaction.

    Submit-Only Mode

    A submit-only request includes the following parameters:

    @@ -7434,7 +7435,7 @@ submit 1200002280000000240000000361D4838D7EA4C6800000000000000000000000000055534 "TransactionType" : "Payment", "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", "Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX", - "Amount" : { + "Amount" : { "currency" : "USD", "value" : "1", "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn" @@ -7821,7 +7822,7 @@ rippled book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6

    JSON-RPC support for subscription callbacks is deprecated and may not work as expected.

    subscribe

    [Source]

    -

    The subscribe method requests periodic notifications from the server when certain events happen.

    +

    The subscribe method requests periodic notifications from the server when certain events happen.

    Request Format

    An example of the request format:

    @@ -7968,7 +7969,7 @@ rippled book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6

    The response follows the standard format. The fields contained in the response vary depending on what subscriptions were included in the request.

    • accounts and accounts_proposed - No fields returned
      • -
    • Stream: server - Information about the server status, such as load_base (the current load level of the server), random (a randomly-generated value), and others, subject to change.
      • +
    • Stream: server - Information about the server status, such as load_base (the current load level of the server), random (a randomly-generated value), and others, subject to change.
    • Stream: transactions, Stream: transactions_proposed, and Stream: validations - No fields returned
    • Stream: ledger - Information about the ledgers on hand and current fee schedule, such as fee_base (current base fee for transactions in XRP), fee_ref (current base fee for transactions in fee units), ledger_hash (hash of the latest validated ledger), reserve_base (minimum reserve for accounts), and more.
    • books - No fields returned by default. If "snapshot": true is set in the request, returns offers (an array of offer definition objects defining the order book)
      • @@ -8373,7 +8374,7 @@ rippled book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6

    Order Book Streams

    -

    When you subscribe to one or more order books with the books field, you get back any transactions that affect those order books.

    +

    When you subscribe to one or more order books with the books field, you get back any transactions that affect those order books.

    Example order book stream message:

    {
     "engine_result": "tesSUCCESS",
@@ -9349,7 +9350,7 @@ rippled server_state
 
 
    can_delete
    
 
    [Source]
    
-
    With online_delete and advisory_delete configuration options enabled, the can_delete method informs the rippled server of the latest ledger which may be deleted. 
    
+
    With online_delete and advisory_delete configuration options enabled, the can_delete method informs the rippled server of the latest ledger which may be deleted.
    
 
    The can_delete method is an admin command that cannot be run by unpriviledged users.
    
 
    Request Format
    
 
    An example of the request format:
    
@@ -9658,7 +9659,7 @@ Connecting to 127.0.0.1:5005
 
 
 
-
    It is also normal to get a minimal result where the only field in info is "consensus": "none". This indicates that the server is in between consensus rounds. 
    
+
    It is also normal to get a minimal result where the only field in info is "consensus": "none". This indicates that the server is in between consensus rounds.
    
 
    The results of the consensus_info command can vary dramatically if you run it several times, even in short succession.
    
 
    Possible Errors
    
 
      
@@ -9666,7 +9667,7 @@ Connecting to 127.0.0.1:5005
 
    
 
    fetch_info
    
 
    [Source]
    
-
    The fetch_info command returns information about objects that this server is currently fetching from the network, and how many peers have that information. It can also be used to reset current fetches. 
    
+
    The fetch_info command returns information about objects that this server is currently fetching from the network, and how many peers have that information. It can also be used to reset current fetches.
    
 
    The fetch_info method is an admin command that cannot be run by unpriviledged users.
    
 
    Request Format
    
 
    An example of the request format:
    
@@ -9852,7 +9853,7 @@ Connecting to 127.0.0.1:5005
 
 
    get_counts
    
 
    [Source]
    
-
    The get_counts command provides various stats about the health of the server, mostly the number of objects of different types that it currently holds in memory. 
    
+
    The get_counts command provides various stats about the health of the server, mostly the number of objects of different types that it currently holds in memory.
    
 
    The get_counts method is an admin command that cannot be run by unpriviledged users.
    
 
    Request Format
    
 
    An example of the request format:
    
@@ -10006,7 +10007,7 @@ Connecting to 127.0.0.1:5005
 
 
    ledger_cleaner
    
 
    [Source]
    
-
    The ledger_cleaner command controls the Ledger Cleaner, an asynchronous maintenance process that can find and repair corruption in rippled's database of ledgers. 
    
+
    The ledger_cleaner command controls the Ledger Cleaner, an asynchronous maintenance process that can find and repair corruption in rippled's database of ledgers.
    
 
    The ledger_cleaner method is an admin command that cannot be run by unpriviledged users.
    
 
    Request Format
    
 
    An example of the request format:
    
@@ -10219,7 +10220,7 @@ Connecting to 127.0.0.1:5005
 }
    -

    The response follows the standard format. The response format depends on whether the request specified a severity. If it did, the log level is changed and a successful result contains no additional fields.

    +

    The response follows the standard format. The response format depends on whether the request specified a severity. If it did, the log level is changed and a successful result contains no additional fields.

    Otherwise, the request contains the following field:

    @@ -11325,7 +11326,7 @@ rippled random
  • internal - Some internal error occurred, possibly relating to the random number generator.

    • json

    -

    The json method is a proxy to running other commands, and accepts the parameters for the command as a JSON value. It is exclusive to the Commandline client, and intended for cases where the commandline syntax for specifying parameters is inadequate or undesirable.

    +

    The json method is a proxy to running other commands, and accepts the parameters for the command as a JSON value. It is exclusive to the Commandline client, and intended for cases where the commandline syntax for specifying parameters is inadequate or undesirable.

    Request Format

    An example of the request format:

    diff --git a/reference-transaction-format.html b/reference-transaction-format.html index b0c6f3c4bd..57f3f7563f 100644 --- a/reference-transaction-format.html +++ b/reference-transaction-format.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • @@ -151,8 +152,7 @@

    Signing and Sending Transactions

    Signing a transaction cryptographically proves that the person in charge of the account sending the transaction is authorized to do so. Only signed transactions can be submitted to the network and included in a validated ledger. A signed transaction is immutable: its contents cannot change, and the signature is not valid for any other transaction.

    -

    You can sign a transaction using a secret key: either the master secret, or a regular secret if the account has a regular key pair associated with it. (See SetRegularKey for details.)

    -

    Multi-signature transactions are in development.

    +

    You sign a transaction using a secret key: either the master secret, or a regular secret if the account has a regular key pair associated with it. (See SetRegularKey for details.) If your account has a SignerList associated with it, you can use a multi-signature instead.

    Typically, you create a transaction in JSON format first. Here is an example of an unsigned Payment-type transaction in JSON:

    {
   "TransactionType" : "Payment",
@@ -168,13 +168,13 @@
   "Sequence": 2,
 }
    -

    After doing that, you generate the signed binary format for the transaction. There are two ways to do this:

    +

    After doing that, you generate the signed binary format for the transaction. For transactions authorized by only a single signature, you have two options:

    1. Convert it to a binary blob and sign it offline. This is preferable, since it means that the account secret used for signing the transaction is never transmitted over any network connection.
      • You can use RippleAPI to perform offline signing.
      2. -
    2. Have a rippled server sign the transaction for you. The sign command takes a JSON-format transaction and secret and returns the signed binary transaction format ready for submission. (Transmitting your account secret is dangerous, so you should only do this from within a trusted and encrypted sub-net, to a server you control.)
        +
      • Have a rippled server sign the transaction for you. The sign command takes a JSON-format transaction and secret and returns the signed binary transaction format ready for submission. (Transmitting your account secret is dangerous, so you should only do this from within a trusted and encrypted connection, or through a local connection, and only to a server you control.)
        • As a shortcut, you can use the submit command with a tx_json object to sign and submit a transaction all at once. This is only recommended for testing and development purposes.
        • @@ -273,6 +273,29 @@ } } +

        Multi-Signing

        +

        Multi-signing in Ripple is the act of authorizing transactions for the Ripple +Consensus Ledger by using a combination of multiple secret keys. Multi-signing +allows various use cases including:

        +
          +
        • If you require keys from different devices, a malicious user must compromise multiple machines in order to send transactions on your behalf.
          • +
        • If the keys to an account are in the custody of entirely different people, those people must collaborate in order to send transaction from that account.
          • +
        • Delegate a group of others who can send transactions for you if you are unavailable or unable to sign normally.
          • +
        • ... and more.
          • +
        +

        To set up multi-signing for an account, the process is straightforward:

        +
          +
        1. Use a SignerListSet transaction to define which accounts or keys can, together, authorize transactions for this account.
          2. +
        2. Optionally disable the master key with an AccountSet transaction using the asfDisableMaster flag.
          3. +
        3. Optionally remove the existing regular key (if any) with a SetRegularKey transaction.
          4. +
        +

        After an account has a SignerList associated with it, the process of submitting a multi-signed transaction is as follows:

        +
          +
        1. Create the transaction to be signed as a JSON object
          2. +
        2. Generate a signature for each account using the sign_for command.
          3. +
        3. Combine the signatures and submit using the submit_multisigned command.
          4. +
        +

        Main article: How to Multi-Sign

        Reliable Transaction Submission

        Reliably submitting transactions is the process of achieving both of the following:

          @@ -284,7 +307,7 @@
        • Construct and sign the transaction first, including a LastLedgerSequence parameter that gives the transaction a limited viable lifespan.
        • Persist details of the transaction before submitting.
        • Submit the transaction.
          • -
        • Confirm that the transaction was either included in a validated ledger, or that it has expired due to LastLedgerSequence.
          • +
        • Confirm that the transaction was either included in a validated ledger, or that it has expired due to LastLedgerSequence.
        • If a transaction fails or expires, you can modify and resubmit it.

    Main article: Reliable Transaction Submission

    @@ -349,7 +372,13 @@
    • - + + + + + + + @@ -361,7 +390,7 @@ - + @@ -379,10 +408,11 @@
  • Sequence - Automatically use the next sequence number for the account sending the transaction.

    • For a production system, we recommend not leaving these fields to be filled by the server. For example, if transaction costs become high due to a temporary spike in network load, you may want to wait for the cost to decrease before sending some transactions, instead of paying the temporarily-high cost.

    -

    The Paths field of the Payment transaction type can also be automatically filled in.

    +

    The Paths field of the Payment transaction type can also be automatically filled in.

    Transaction Cost

    -

    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 transaction cost is designed to increase along with the load on the network, making it very expensive to deliberately or inadvertently overload the network.

    -

    The Fee field specifies an amount, in drops of XRP, to destroy as the cost for this transaction. If the transaction is included in a validated leger (whether or not it achieves its intended purpose), then the amount of XRP specified in the Fee parameter is destroyed forever. You can look up the transaction cost in advance, or let rippled set it automatically when you sign a transaction.

    +

    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 transaction cost is designed to increase along with the load on the network, making it very expensive to deliberately or inadvertently overload the network.

    +

    The Fee field specifies an amount, in drops of XRP, 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 Fee parameter is destroyed forever. You can look up the transaction cost in advance, or let rippled set it automatically when you sign a transaction.

    +

    Note: Multi-signed transactions require additional fees to relay to the network.

    Canceling or Skipping a Transaction

    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.

    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 Sequence value from the same account. If you do not want to perform the same transaction again, you can perform an AccountSet transaction with no options.

    @@ -397,7 +427,7 @@

    One situation in which this is useful is if you have a primary system for submitting transactions and a passive backup system. If the passive backup system becomes disconnected from the primary, but the primary is not fully dead, and they both begin operating at the same time, you could potentially encounter serious problems like some transactions sending twice and others not at all. Chaining your transactions together with AccountTxnID ensures that, even if both systems are active, only one of them can submit valid transactions at a time.

    In order to use AccountTxnID, you must first set the asfAccountTxnID flag, so that the ledger keeps track of the ID for the account's previous transaction.

    Memos

    -

    The Memos field allows for arbitrary messaging data that can accompany the transaction. It is presented as an array of objects. Each object has only one field, Memo, which in turn contains another object with one or more of the following fields:

    +

    The Memos field allows for arbitrary messaging data that can accompany the transaction. It is presented as an array of objects. Each object has only one field, Memo, which in turn contains another object with one or more of the following fields:

    SigningPubKey String PubKey(Automatically added when signing) Hex representation of the public key that corresponds to the private key used to sign this transaction.(Automatically added when signing) Hex representation of the public key that corresponds to the private key used to sign this transaction. If an empty string, indicates a multi-signature is present in the Signers field instead.
    SignersArrayArray(Optional) Array of objects that represent a multi-signature which authorizes this transaction.
    SourceTagTransactionType String UInt16The type of transaction. Valid types include: Payment, OfferCreate, OfferCancel, TrustSet, AccountSet, and SetRegularKey.The type of transaction. Valid types include: Payment, OfferCreate, OfferCancel, TrustSet, AccountSet, SetRegularKey, and SignerListSet.
    TxnSignature
    @@ -446,8 +476,42 @@ "Amount": "1" } +

    Signers Field

    +

    The Signers field contains a multi-signature, which has signatures from up to 8 key pairs, that together should authorize the transaction. The Signers list is an array of objects, each with one field, Signer. The Signer field has the following nested fields:

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    FieldTypeInternal TypeDescription
    AccountStringAccountIDThe address associated with this signature, as it appears in the SignerList.
    TxnSignatureStringBlobA signature for this transaction, verifiable using the SigningPubKey.
    SigningPubKeyStringPubKeyThe 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 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-siganture increases the Fee required by the amount of the minimum transaction fee. For example, if the current minimum Fee value to relay a transaction to the network is 10000 drops, then a multi-signed transaction with 3 entries in the Signers array would cost 40000 drops to relay.

    Flags

    -

    The Flags 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.

    +

    The Flags 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.

    Most flags only have meaning for a specific transaction type. The same bitwise value may be reused for flags on different transaction types, so it is important to pay attention to the TransactionType field when setting and reading flags.

    The only flag that applies globally to all transactions is as follows:

    @@ -545,7 +609,7 @@

    Most of the time, the issuer field of a non-XRP currency amount indicates the account of the gateway that issues that currency. However, when describing payments, there are special rules for the issuer field in the Amount and SendMax fields of a payment.

    • There is only ever one balance for the same currency between two accounts. This means that, sometimes, the issuer field of an amount actually refers to a counterparty that is redeeming issuances, instead of the account that created the issuances.
      • -
    • When the issuer field of the destination Amount field matches the Destination account address, it is treated as a special case meaning "any issuer that the destination accepts." This includes all accounts to which the destination has extended trust lines, as well as issuances created by the destination which may be held on other trust lines.
      • +
    • When the issuer field of the destination Amount field matches the Destination account address, it is treated as a special case meaning "any issuer that the destination accepts." This includes all accounts to which the destination has extended trust lines, as well as issuances created by the destination which may be held on other trust lines.
    • When the issuer field of the SendMax field matches the source account's address, it is treated as a special case meaning "any issuer that the source can use." This includes creating new issuances on trust lines that other accounts have extended to the source account, as well as issuances from other accounts that the source account possesses.

    Creating Accounts

    @@ -603,9 +667,9 @@

    When the tfPartialPayment flag is enabled, the Amount field is not guaranteed to be the amount received. The delivered_amount field of a payment's metadata indicates the amount of currency actually received by the destination account. When receiving a payment, use delivered_amount instead of the Amount field to determine how much your account received instead.

    Limit Quality

    Ripple defines the "quality" of a currency exchange as the ratio of the numeric amount in to the numeric amount out. For example, if you spend $2 USD to receive £1 GBP, then the "quality" of that exchange is 0.5.

    -

    The tfLimitQuality flag allows you to set a minimum quality of conversions that you are willing to take. This limit quality is defined as the destination Amount divided by the SendMax amount (just the numeric amounts, regardless of currency). When set, the payment processing engine avoids using any paths whose quality (conversion rate) is worse (numerically lower) than the limit quality.

    +

    The tfLimitQuality flag allows you to set a minimum quality of conversions that you are willing to take. This limit quality is defined as the destination Amount divided by the SendMax amount (just the numeric amounts, regardless of currency). When set, the payment processing engine avoids using any paths whose quality (conversion rate) is worse (numerically lower) than the limit quality.

    By itself, the tfLimitQuality flag reduces the number of situations in which a transaction can succeed. Specifically, it rejects payments where some part of the payment uses an unfavorable conversion, even if the overall average average quality of conversions in the payment is equal or better than the limit quality. If a payment is rejected in this way, the transaction result is tecPATH_DRY.

    -

    Consider the following example. If I am trying to send you 100 Chinese Yuan (Amount = 100 CNY) for 20 United States dollars (SendMax = 20 USD) or less, then the limit quality is 5. Imagine one market maker is offering ¥95 for $15 (a ratio of about 6.3 CNY per USD), but the next best offer in the market is ¥5 for $2 (a ratio of 2.5 CNY per USD). If I were to take both offers in order to send you 100 CNY, then it would cost me 17 USD, for an average quality of about 5.9.

    +

    Consider the following example. If I am trying to send you 100 Chinese Yuan (Amount = 100 CNY) for 20 United States dollars (SendMax = 20 USD) or less, then the limit quality is 5. Imagine one market maker is offering ¥95 for $15 (a ratio of about 6.3 CNY per USD), but the next best offer in the market is ¥5 for $2 (a ratio of 2.5 CNY per USD). If I were to take both offers in order to send you 100 CNY, then it would cost me 17 USD, for an average quality of about 5.9.

    Without the tfLimitQuality flag set, this transaction would succeed, because the $17 it costs me is within my specified SendMax. However, with the tfLimitQuality flag enabled, the transaction would fail instead, because the path to take the second offer has a quality of 2.5, which is worse than the limit quality of 5.

    The tfLimitQuality flag is most useful when combined with partial payments. When both tfPartialPayment and tfLimitQuality are set on a transaction, then the transaction delivers as much of the destination Amount as it can, without using any conversions that are worse than the limit quality.

    In the above example with a ¥95/$15 offer and a ¥5/$2 offer, the situation is different if my transaction has both tfPartialPayment and tfLimitQuality enabled. If we keep my SendMax of 20 USD and a destination Amount of 100 CNY, then the limit quality is still 5. However, because I am doing a partial payment, the transaction sends as much as it can instead of failing if the full destination amount cannot be sent. This means that my transaction consumes the ¥95/$15 offer, whose quality is about 6.3, but it rejects the ¥5/$2 offer because that offer's quality of 2.5 is worse than the quality limit of 5. In the end, my transaction only delivers ¥95 instead of the full ¥100, but it avoids wasting money on poor exchange rates.

    @@ -729,7 +793,7 @@ - + @@ -844,9 +908,9 @@
    asfDisableMaster 4Disallow use of the master key. Can only be enabled if the account has a RegularKey configured.Disallow use of the master key. Can only be enabled if the account has configured another way to sign transactions, such as a Regular Key or a Signer List. lsfDisableMaster
    -

    Instead of using an account's master key to sign transactions, you can set an alternate key pair, called the "Regular Key". As long as the public key for this key pair is set in the RegularKey field of an account this way, then the secret of the Regular Key pair can be used to sign transactions. (The master secret can still be used, too, unless you set the asfDisableMaster account flag.)

    -

    A Regular Key pair is generated in the same way as any other Ripple keys (for example, with 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. In some cases, you can even send a key reset transaction without paying the transaction cost.

    +

    Instead of using an account's master key to sign transactions, you can set an alternate key pair, called the "Regular Key". As long as the public key for this key pair is set in the RegularKey field of an account this way, then the secret of the Regular Key pair can be used to sign transactions. (Other methods of signing transactions can also be used, including multi-signing or the master key.

    +

    A Regular Key pair is generated in the same way as any other Ripple keys (for example, with 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). The Master Key can be disabled but it cannot be changed. Therefore, it is beneficial to security sign transactions with a Regular Key instead of the master key whenever possible. For even greater security, you can use multi-signing, but multi-signing costs additional XRP in transaction fees and reserves.

    +

    If your regular key is compromised, but the master key is not, you can use a SetRegularKey transaction to regain control of your account. In some cases, you can even send a key reset transaction without paying the transaction cost.

    OfferCreate

    [Source]

    An OfferCreate transaction is effectively a 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.

    @@ -1134,6 +1198,65 @@ +

    SignerListSet

    +

    [Source]

    +

    The SignerListSet transaction creates, modifies, or removes a list of signers that can be used to multi-sign a transaction.

    +

    Example SignerListSet:

    +
    {
+    "Flags": 0,
+    "TransactionType": "SignerListSet",
+    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+    "Fee": "10000",
+    "SignerQuorum": 3,
+    "SignerEntries": [
+        {
+            "SignerEntry": {
+                "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                "SignerWeight": 2
+            }
+        },
+        {
+            "SignerEntry": {
+                "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+                "SignerWeight": 1
+            }
+        },
+        {
+            "SignerEntry": {
+                "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
+                "SignerWeight": 1
+            }
+        }
+    ]
+}
+
    + + + + + + + + + + + + + + + + + + + + + + + +
    FieldJSON TypeInternal TypeDescription
    SignerQuorumNumberUInt32A target number for the signer weights. A multi-signature from this list is valid only if the sum weights of the signatures provided is equal or greater than this value. To delete a SignerList, use the value 0.
    SignerEntriesArrayArray(Omitted when deleting) Array of SignerEntry objects, indicating the addresses and weights of signers in this list. A SignerList must have at least 1 member and no more than 8 members. No address may appear more than once in the list, nor may the Account submitting the transaction appear in the list.
    +

    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 SignerQuorum to 0 and omit the SignerEntries field. Otherwise, the transaction fails with the error temMALFORMED. A transaction to delete a SignerList is considered successful even if there was no SignerList to delete.

    +

    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 SignerWeight values in the list. Otherwise, the transaction fails with the error temMALFORMED.

    +

    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 enabled) and the account does not have a Regular Key configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error tecNO_ALTERNATIVE_KEY.

    Pseudo-Transactions

    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.

    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:

    @@ -1223,7 +1346,7 @@

    Transaction Results

    Immediate Response

    -

    The response from the submit command contains a provisional result from the rippled server indicating what happened during local processing of the transaction.

    +

    The response from the submit command contains a provisional result from the rippled server indicating what happened during local processing of the transaction.

    The response from submit contains the following fields:

    @@ -1258,7 +1381,7 @@

    Note: 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 Finality of Results for details.

    Looking up Transaction Results

    -

    To see the final result of a transaction, use the tx command, account_tx command, or other response from rippled. Look for "validated": true to indicate that this response uses a ledger version that has been validated by consensus.

    +

    To see the final result of a transaction, use the tx command, account_tx command, or other response from rippled. Look for "validated": true to indicate that this response uses a ledger version that has been validated by consensus.

    @@ -1560,7 +1683,7 @@ - + @@ -1586,6 +1709,18 @@ + + + + + + + + + + + +
    temDST_IS_SRCThe TrustSet transaction improperly specified the destination of the trustline (the issuer field of LimitAmount) as the Account sending the transaction. You cannot extend a trustline to yourself. (In the future, this code could also apply to other cases where the destination of a transaction is not allowed to be the account sending it.)The TrustSet transaction improperly specified the destination of the trust line (the issuer field of LimitAmount) as the Account sending the transaction. You cannot extend a trust line to yourself. (In the future, this code could also apply to other cases where the destination of a transaction is not allowed to be the account sending it.)
    temDST_NEEDEDtemRIPPLE_EMPTY The Payment transaction includes an empty Paths field, but paths are necessary to complete this payment.
    temBAD_WEIGHTThe SignerListSet transaction includes a SignerWeight that is invalid, for example a zero or negative value.
    temBAD_SIGNERThe SignerListSet transaction includes a signer who is invalid: for example, it might be a duplicate, or it might be the account to which the SignerList belongs.
    temBAD_QUORUMThe SignerListSet transaction has an invalid SignerQuorum value. Either the value is not greater than zero, or it is more than the sum of all signers in the list.

    tef Codes

    @@ -1650,6 +1785,22 @@ tefMAX_LEDGER The transaction included a LastLedgerSequence parameter, but the current ledger's sequence number is already higher than the specified value. + +tefBAD_SIGNATURE +The transaction was multi-signed, but contained a signature for an address not part of a SignerList associated with the sending account. + + +tefBAD_QUORUM +The transaction was multi-signed, but the total weights of all included signatures did not meet the quorum. + + +tefNOT_MULTI_SIGNING +The transaction was multi-signed, but the sending account has no SignerList defined. + + +tefBAD_AUTH_MASTER +(something to do with the key not being the right one for this account) +

    ter Codes

    @@ -1807,9 +1958,9 @@ DEPRECATED. Replaced by tecUNFUNDED_OFFER and tecUNFUNDED_PAYMENT. -tecMASTER_DISABLED +tecNO_ALTERNATIVE_KEY 130 -The SetRegularKey transaction tried to unset the Regular Key, but the account has the lsfDisableMaster flag enabled. (Unsetting the Regular Key while also leaving the Master Key disabled would make the account unusable.) +The transaction tried to remove the only available method of signing transactions. This could be a SetRegularKey transaction to remove the Regular Key, a SignerListSet transaction to delete a SignerList, or an AccountSet transaction to disable the Master Key. (Prior to rippled 0.30.0, this was called tecMASTER_DISABLED instead.) tecNO_REGULAR_KEY @@ -1837,11 +1988,6 @@ The TakerPays field of the OfferCreate transaction specifies an asset whose issuer has lsfRequireAuth enabled, and the account making the offer does not have a trust line for that asset. (Normally, making an offer implicitly creates a trust line if necessary, but in this case it does not bother because you cannot hold the asset without authorization.) If the trust line exists, but is not authorized, tecNO_AUTH occurs instead. -tecINSUFF_FEE -136 -The account sending the transaction does not possess enough XRP to pay the specified Fee. This error only occurs if the transaction has already been propagated through the network to achieve consensus, - - tecFROZEN 137 The OfferCreate transaction failed because one or both of the assets involved are subject to a global freeze. @@ -1849,22 +1995,22 @@ tecNO_TARGET 138 -FORTHCOMING Part of multi-signature transactions. +FORTHCOMING Reserved for future features. tecNO_PERMISSION 139 -FORTHCOMING Part of multi-signature transactions. +FORTHCOMING Reserved for future features. tecNO_ENTRY 140 -FORTHCOMING Part of multi-signature transactions. +FORTHCOMING Reserved for future features. tecINSUFFICIENT_RESERVE 141 -FORTHCOMING Part of multi-signature transactions. (Code may change; see RIPD-743 for status.) +The SignerListSet or other transaction would increase the reserve requirement higher than the sending account's balance. See SignerLists and Reserves for more information. tecNEED_MASTER_KEY @@ -1889,7 +2035,7 @@

    tej Codes

    -

    These codes are only ever returned by the ripple-lib client library, not by rippled itself.

    +

    These codes are only ever returned by the ripple-lib client library, not by rippled itself.

    diff --git a/ripple-api-tool.html b/ripple-api-tool.html index 2b6ece60a8..0683e964f9 100644 --- a/ripple-api-tool.html +++ b/ripple-api-tool.html @@ -46,6 +46,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • diff --git a/tool-jsonrpc.html b/tool-jsonrpc.html index 906414563a..0d17736796 100644 --- a/tool-jsonrpc.html +++ b/tool-jsonrpc.html @@ -46,6 +46,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • diff --git a/tool/dactyl-config.yml b/tool/dactyl-config.yml index 375ef09ba4..1601384363 100644 --- a/tool/dactyl-config.yml +++ b/tool/dactyl-config.yml @@ -107,6 +107,13 @@ pages: ripple.com: https://ripple.com/build/reliable-transaction-submission/ sidebar: true + - name: Multi-Signing Transactions + category: Tutorials + html: tutorial-multisign.html + md: tutorial-multisign.md + ripple.com: https://wiki.ripple.com/Multisign + sidebar: true + # Concepts are introductions that explain a topic. # In the Dev Portal, these are mostly summaries of RCL features. - name: Paths diff --git a/tool/pages.json b/tool/pages.json deleted file mode 100644 index 3bc4e48627..0000000000 --- a/tool/pages.json +++ /dev/null @@ -1,162 +0,0 @@ -[ - { - "name": "Overview", - "template":"template-index.html", - "html": "index.html", - "targets": ["local", "ripple.com"], - "sidebar": false - }, - { - "name": "Ripple Developer Resources", - "template":"template-pdf_intro.html", - "html": "pdf_intro.html", - "targets": ["pdf"] - }, - { - "name": "Paths", - "md":"paths.md", - "html":"paths.html", - "ripple.com": "https://ripple.com/build/paths/", - "category": "Concepts", - "sidebar": "category-toc" - }, - { - "name": "Fees (Disambiguation)", - "md": "fees.md", - "html": "fees.html", - "ripple.com": "https://ripple.com/knowledge_center/fees-disambiguation/", - "category": "Concepts", - "sidebar": "category-toc" - }, - { - "name": "Transfer Fees", - "md":"transferrate.md", - "html":"transfer_fees.html", - "ripple.com": "https://ripple.com/knowledge_center/transfer-fees/", - "category": "Concepts", - "sidebar": "category-toc" - }, - { - "name": "Transaction Cost", - "md": "tx-cost.md", - "html": "tx-cost.html", - "ripple.com": "https://ripple.com/build/transaction-cost/", - "category": "Concepts", - "sidebar": "category-toc" - }, - { - "name": "Fee Voting", - "md": "fee-voting.md", - "html": "fee-voting.html", - "ripple.com": "https://ripple.com/build/fee-voting/", - "category": "Concepts", - "sidebar": "category-toc" - }, - { - "name": "Reserves", - "md": "reserves.md", - "html": "reserves.html", - "ripple.com": "https://ripple.com/build/reserves/", - "category": "Concepts", - "sidebar": "category-toc" - }, - { - "name": "Freeze", - "md": "freeze.md", - "html": "freeze.html", - "ripple.com": "https://ripple.com/build/freeze/", - "category": "Concepts", - "sidebar": "category-toc" - }, - { - "name": "RippleAPI Quick Start Guide", - "md": "rippleapi_quickstart.md", - "html": "rippleapi_quickstart.html", - "category": "Tutorials", - "sidebar": "page-toc" - }, - { - "name": "rippled", - "md":"rippled.md", - "html":"rippled-apis.html", - "ripple.com": "https://ripple.com/build/rippled-apis/", - "category": "References", - "sidebar": "page-toc" - }, - { - "name": "rippled Setup", - "md":"rippled-setup.md", - "html":"rippled-setup.html", - "ripple.com": "https://ripple.com/build/rippled-setup/", - "category": "Tutorials", - "sidebar": "page-toc" - }, - { - "name": "Transactions", - "md":"tx_format.md", - "html":"transactions.html", - "ripple.com": "https://ripple.com/build/transactions/", - "category": "References", - "sidebar": "page-toc" - }, - { - "name": "Ledger Format", - "md":"ledger_format.md", - "html":"ripple-ledger.html", - "ripple.com": "https://ripple.com/build/ledger-format/", - "category": "References", - "sidebar": "page-toc" - }, - { - "name": "Reliable Transaction Submission", - "md":"reliable_tx.md", - "html":"reliable_tx.html", - "ripple.com": "https://ripple.com/build/reliable-transaction-submission/", - "category": "Tutorials", - "sidebar": "page-toc" - }, - { - "name": "Gateway Guide", - "md":"gateway_guide.md", - "html":"gateway_guide.html", - "ripple.com": "https://ripple.com/build/gateway-guide/", - "category": "Tutorials", - "sidebar": "page-toc" - }, - { - "name": "Ripple Data API v2", - "md": "data_v2.md", - "html": "data_api_v2.html", - "ripple.com": "https://ripple.com/build/data-api-v2/", - "category": "References", - "sidebar": "page-toc" - }, - { - "name": "RippleAPI", - "md": "https://raw.githubusercontent.com/ripple/ripple-lib/0.16.7/docs/index.md", - "html": "rippleapi.html", - "ripple.com": "https://ripple.com/build/rippleapi/", - "category": "References", - "sidebar": "page-toc" - }, - { - "name": "WebSocket API Tool", - "template":"template-ripple-api-tool.html", - "category": "API Tools", - "ripple.com": "https://ripple.com/build/websocket-tool/", - "html": "ripple-api-tool.html", - "targets": ["local","ripple.com"], - "sidebar": "custom" - }, - { - "name": "Data API v2 Tool", - "template":"template-rest-api-tool.html", - "methods_js": "js/apitool-methods-data_v2.js", - "category": "API Tools", - "rest_host": "https://data.ripple.com", - "html": "data-api-v2-tool.html", - "targets": ["local","ripple.com"], - "sidebar": "custom" - } -] - diff --git a/tutorial-gateway-guide.html b/tutorial-gateway-guide.html index 64d26830ea..b33d4aeee8 100644 --- a/tutorial-gateway-guide.html +++ b/tutorial-gateway-guide.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • diff --git a/tutorial-multisign.html b/tutorial-multisign.html new file mode 100644 index 0000000000..47de643fee --- /dev/null +++ b/tutorial-multisign.html @@ -0,0 +1,797 @@ + + + + + + + +Multi-Signing Transactions - Ripple Developer Portal + + + + + + + + + + + + + + + + + + + + + +
    + +
    +
    +

    Introduction to Multi-Signing

    +

    Multi-signing in Ripple is the act of authorizing transactions for the Ripple +Consensus Ledger by using a combination of multiple secret keys. After setting +up multi-signing for an account, you can put the master secret in cold storage, +or even disable the master key entirely. With multiple secret keys required to +authorize a multi-signature, you can improve security in several ways.

    +
      +
    • If you keep an account's keys on different devices, a malicious user must compromise multiple machines in order to send transactions on your behalf.
      • +
    • If the keys to an account are in the custody of entirely different people, those people must collaborate in order to send transaction from that account.
      • +
    • You can use the SignerList as a backup, to delegate a group of others who can send transactions for you if you are unavailable or unable to sign using your regular key.
      • +
    • Even more uses than can be described here.
      • +
    +

    Availability of Multi-Signing

    +

    Multi-signing is due to be enabled by an Amendment to the Ripple Consensus +Protocol. This Amendment must be approved by a consensus of validators showing +consistent support for the feature over a period of time. For more information, +see Amendments (TODO: link).

    +

    You can test multi-signing by running rippled in stand-alone mode with the +feature enabled. In stand-alone mode, rippled does not communicate with the +rest of the Ripple peer-to-peer network, but you can perform most of the same +actions on your local server only. This way, you can be sure that you are ready +for multi-signing when it goes live.

    +

    How to Multi-Sign

    +

    The basic process of Multi-Signing a transaction is necessarily more +complex than the process of signing a transaction with a single master key or +regular key.

    +

    1. Download and build rippled with multi-sign

    +

    Until a binary for rippled with multi-signing is available, the best you can do is build it from source.

    +
    $ git clone git@github.com:scottschurr/rippled.git (TODO: switch to a Ripple Labs repo when available)
+$ git checkout fix-sign_for
+$ scons
+
    +

    See rippled build instructions for help building from source.

    +

    2. Configure rippled to enable MultiSign

    +

    Add the following to the bottom of the config file:

    +
    [features]
+MultiSign
+
    +

    Note that this stanza is case-sensitive.

    +

    3. Start rippled in stand-alone mode

    +

    If you have previously synced to the network, you can have the server load the +latest ledger as a starting place for stand-alone mode using the --load +commandline option:

    +
    $ sudo ./build/rippled --conf=/home/mduo13/.config/ripple/rippled.cfg -a --load
+
    +

    If you'd rather start from scratch, you can use the --start commandline +option to create a fresh ledger. In this case, the root account holds all +100 billion XRP:

    +

    Address: rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh

    +

    Secret: snoPBrXtMeMyMHUVTgbuqAfg1SUTb ("masterpassphrase")

    +

    4. Generate keys for a new wallet

    +

    This step is not strictly necessary. For this process, we generate the keys to +a new Ripple account and then set up multi-signing for that account. To set up +multi-signing on an existing Ripple account, just use the keys to that account.

    +
    $ build/rippled wallet_propose
+Loading: "/home/mduo13/.config/ripple/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "account_id" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+      "key_type" : "secp256k1",
+      "master_key" : "NED MANA SPA BLUR HERS HEAT RED NIBS MAIN MELT NOB RARE",
+      "master_seed" : "shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq",
+      "master_seed_hex" : "99C7F2DCD88218372B7509ADF7DC562B",
+      "public_key" : "aBPvx491i2ZPVzmxoAmAVq5qXAxAZgmjfxoMTxFCg9Xxf2xwVVLc",
+      "public_key_hex" : "0303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D",
+      "status" : "success"
+   }
+}
+
    +

    As always, be sure that an account's secret key never gets transmitted to +anyone you don't trust with full control of that account, and certainly not +unencrypted over the network.

    +

    5. Fund the new account with an existing wallet

    +

    Again, this step is only necessary if you are setting up a new account to use +multi-signing for this example.

    +
    $ build/rippled submit <your existing account secret> '{
+>   "TransactionType" : "Payment",
+>   "Account" : "<your existing account address>",
+>   "Destination" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+>   "Amount" : "100000000",
+>   "Flags": 2147483648
+> }'
+Loading: "/home/mduo13/.config/ripple/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "engine_result" : "tesSUCCESS",
+      "engine_result_code" : 0,
+      "engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
+      "status" : "success",
+      "tx_blob" : "1200002280000000240000001E614000000005F5E10068400000000000000A7321023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC67446304402207AB5D16F58E9E6ADBBDD24837CAB80D871860E47EB0840FE57403FB979755A6D022015FE7A8838BEE6C18962C246D6D27791B7EE34B93415AE3824D12564E7A886C6811493B89AFCAD4C8EAC2B131C1331FEF12AE1522BBE83142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1",
+      "tx_json" : {
+         "Account" : "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
+         "Amount" : "100000000",
+         "Destination" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+         "Fee" : "10",
+         "Flags" : 2147483648,
+         "Sequence" : 30,
+         "SigningPubKey" : "023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6",
+         "TransactionType" : "Payment",
+         "TxnSignature" : "304402207AB5D16F58E9E6ADBBDD24837CAB80D871860E47EB0840FE57403FB979755A6D022015FE7A8838BEE6C18962C246D6D27791B7EE34B93415AE3824D12564E7A886C6",
+         "hash" : "8C7A4D35D71CE80DA4EDAC91D620B6A348B7691B78AA2896284135378E10E0C2"
+      }
+   }
+}
+
    +

    6. Manually close the ledger

    +

    In the live network, you would simply wait for the ledger to close +automatically as the result of consensus. However, a rippled node running in +stand-alone mode does not engage in consensus, so you must manually close the +ledger with the ledger_accept command.

    +
    $ build/rippled ledger_accept
+Loading: "/home/mduo13/.config/ripple/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "ledger_current_index" : 16061437,
+      "status" : "success"
+   }
+}
+
    +

    7. Create a SignerList on the new account with a SignerListSet transaction

    +

    Before you can multi-sign transactions, you must associate a SignerList with +your account, so that RCL knows which keys can be used to sign for you. You do +this with a SignerListSet transaction.

    +

    In this example, the SignerList has 3 members, with the weights and quorum set +up such that multi-signed transactions need a signature from +rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other +two members of the list. The Account values you use in your list can be +funded accounts that exist in the ledger or just unused addresses.

    +
    $ build/rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{
+>     "Flags": 0,
+>     "TransactionType": "SignerListSet",
+>     "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+>     "Fee": "10000",
+>     "SignerQuorum": 3,
+>     "SignerEntries": [
+>         {
+>             "SignerEntry": {
+>                 "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+>                 "SignerWeight": 2
+>             }
+>         },
+>         {
+>             "SignerEntry": {
+>                 "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+>                 "SignerWeight": 1
+>             }
+>         },
+>         {
+>             "SignerEntry": {
+>                 "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
+>                 "SignerWeight": 1
+>             }
+>         }
+>     ]
+> }'
+Loading: "/home/mduo13/.config/ripple/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "engine_result" : "tesSUCCESS",
+      "engine_result_code" : 0,
+      "engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
+      "status" : "success",
+      "tx_blob" : "12000C2200000000240000000120230000000368400000000000271073210303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D74473045022100BEDFA12502C66DDCB64521972E5356F4DB965F553853D53D4C69B4897F11B4780220595202D1E080345B65BAF8EBD6CA161C227F1B62C7E72EA5CA282B9434A6F04281142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1F4EB1300028114204288D2E47F8EF6C99BCC457966320D12409711E1EB13000181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1EB13000181143A4C02EA95AD6AC3BED92FA036E0BBFB712C030CE1F1",
+      "tx_json" : {
+         "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+         "Fee" : "10000",
+         "Flags" : 0,
+         "Sequence" : 1,
+         "SignerEntries" : [
+            {
+               "SignerEntry" : {
+                  "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                  "SignerWeight" : 2
+               }
+            },
+            {
+               "SignerEntry" : {
+                  "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+                  "SignerWeight" : 1
+               }
+            },
+            {
+               "SignerEntry" : {
+                  "Account" : "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
+                  "SignerWeight" : 1
+               }
+            }
+         ],
+         "SignerQuorum" : 3,
+         "SigningPubKey" : "0303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D",
+         "TransactionType" : "SignerListSet",
+         "TxnSignature" : "3045022100BEDFA12502C66DDCB64521972E5356F4DB965F553853D53D4C69B4897F11B4780220595202D1E080345B65BAF8EBD6CA161C227F1B62C7E72EA5CA282B9434A6F042",
+         "hash" : "3950D98AD20DA52EBB1F3937EF32F382D74092A4C8DF9A0B1A06ED25200B5756"
+      }
+   }
+}
+
    +

    8. Manually close the ledger again

    +

    As before, you would wait for the ledger to close on a live network. We use +the ledger_accept command to manually +close the ledger when running rippled in stand-alone mode.

    +
    $ build/rippled ledger_accept
+Loading: "/home/mduo13/.config/ripple/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "ledger_current_index" : 16061438,
+      "status" : "success"
+   }
+}
+
    +

    9. Confirm the presence of the new signer list using account_objects

    +

    Normally an account has lots of different types of objects, but for this new +account, the only thing we've done is add a SignerList, so it should be easy to +find in the results of the +account_objects command.

    +
    $ build/rippled account_objects rnBFvgZphmN39GWzUJeUitaP22Fr9be75H
+Loading: "/home/mduo13/.config/ripple/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+      "account_objects" : [
+         {
+            "Flags" : 0,
+            "LedgerEntryType" : "SignerList",
+            "OwnerNode" : "0000000000000000",
+            "PreviousTxnID" : "3950D98AD20DA52EBB1F3937EF32F382D74092A4C8DF9A0B1A06ED25200B5756",
+            "PreviousTxnLgrSeq" : 16061437,
+            "SignerEntries" : [
+               {
+                  "SignerEntry" : {
+                     "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                     "SignerWeight" : 2
+                  }
+               },
+               {
+                  "SignerEntry" : {
+                     "Account" : "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
+                     "SignerWeight" : 1
+                  }
+               },
+               {
+                  "SignerEntry" : {
+                     "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+                     "SignerWeight" : 1
+                  }
+               }
+            ],
+            "SignerListID" : 0,
+            "SignerQuorum" : 3,
+            "index" : "92373B9F1683001079764527F0BD553ED8656A9934FE641A7F0A0BF4DB230E0E"
+         }
+      ],
+      "ledger_current_index" : 16061438,
+      "status" : "success",
+      "validated" : false
+   }
+}
+
    +

    10. Create a new transaction that you plan to multi-sign

    +

    You have to specify everything about this transaction, including Fee and +Sequence. Also include the field SigningPubKey as an empty string -- this +indicates that the transaction is multi-signed.

    +

    Here's an example transaction we can send from our test account:

    +
    {
+    "TransactionType": "TrustSet",
+    "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+    "Flags": 262144,
+    "LimitAmount": {
+      "currency": "USD",
+      "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+      "value": "100"
+    },
+    "Sequence": 2,
+    "SigningPubKey":"",
+    "Fee": "12000"
+}
+
    +

    (If you started from a fresh ledger, you first need to fund the account +specified by the issuer in this example, and then manually close the ledger.)

    +

    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 fee, 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 load fee increases in that time.

    +

    11. Get a signature using the sign_for command

    +
    $ build/rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW <rsA2's secret> '{
+>     "TransactionType": "TrustSet",
+>     "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+>     "Flags": 262144,
+>     "LimitAmount": {
+>       "currency": "USD",
+>       "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+>       "value": "100"
+>     },
+>     "Sequence": 2,
+>     "SigningPubKey":"",
+>     "Fee": "12000"
+> }'
+Loading: "/home/mduo13/.config/ripple/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "Signers" : [
+         {
+            "Signer" : {
+               "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+               "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+               "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE"
+            }
+         }
+      ],
+      "status" : "success",
+      "tx_blob" : "1200142200040000240000000263D5038D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA9684000000000002EE0730081142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1",
+      "tx_json" : {
+         "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+         "Fee" : "12000",
+         "Flags" : 262144,
+         "LimitAmount" : {
+            "currency" : "USD",
+            "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+            "value" : "100"
+         },
+         "Sequence" : 2,
+         "SigningPubKey" : "",
+         "TransactionType" : "TrustSet",
+         "hash" : "4622B2893AF3A70B4DB1FF86B25C10E92B71973895143E66029567A8541A8060"
+      }
+   }
+}
+
    +

    The valuable part in the response is the Signers field. This is the part that +you're going to need later in order to construct the full, multi-signed +transaction.

    +

    The other parts, such as the tx_blob, are not very useful at this point, +unless you're "multi-signing" a transaction with only one signature.

    +

    12. Get additional signatures the same way

    +

    If the accounts in your SignerList are funded accounts, the secret key you use +to sign for those accounts can come from the regular key (if they have one), or +the master key (unless it's disabled). For accounts that don't exist in the +ledger, you can only use the master secret associated with the address.

    +
    $ build/rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v <rUpy's secret> '{
+    "TransactionType": "TrustSet",
+    "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+    "Flags": 262144,
+    "LimitAmount": {
+      "currency": "USD",
+      "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+      "value": "100"
+    },            
+    "Sequence": 2,
+    "SigningPubKey":"",
+    "Fee": "12000"
+}'
+Loading: "/home/mduo13/.config/ripple/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "Signers" : [
+         {
+            "Signer" : {
+               "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+               "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
+               "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1"
+            }
+         }
+      ],
+      "status" : "success",
+      "tx_blob" : "1200142200040000240000000263D5038D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA9684000000000002EE0730081142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1",
+      "tx_json" : {
+         "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+         "Fee" : "12000",
+         "Flags" : 262144,
+         "LimitAmount" : {
+            "currency" : "USD",
+            "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+            "value" : "100"
+         },
+         "Sequence" : 2,
+         "SigningPubKey" : "",
+         "TransactionType" : "TrustSet",
+         "hash" : "4622B2893AF3A70B4DB1FF86B25C10E92B71973895143E66029567A8541A8060"
+      }
+   }
+}
+
    +

    Depending on the SignerList you configured, you may need to repeat this step +several times in order to get signatures from all the necessary parties.

    +

    13. Combine the signatures and submit

    +

    Take the contents of all the Signers arrays from all the responses, and +concatenate them in to a single Signers array field. The commandline syntax +for the submit_multisigned command +takes a single JSON object with two elements: this combined Signers array; +and tx_json, which is the transaction JSON that they signed.

    +

    This command actually submits the transaction for inclusion in the ledger. In +online mode, this relays it to other members of the network.

    +
    $ build/rippled submit_multisigned '    {
+>         "Signers": [
+>             {
+>                 "Signer" : {
+>                    "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+>                    "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
+>                    "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1"
+>                 }
+>             },
+>             {
+>                 "Signer" : {
+>                    "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+>                    "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+>                    "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE"
+>                 }
+>             }
+>         ],
+>         "tx_json": {
+>             "TransactionType": "TrustSet",
+>             "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+>             "Flags": 262144,
+>             "LimitAmount": {
+>               "currency": "USD",
+>               "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+>               "value": "100"
+>             },
+>             "Sequence": 2,
+>             "SigningPubKey":"",
+>             "Fee": "12000"
+>         }
+>     }'
+Loading: "/home/mduo13/.config/ripple/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "engine_result" : "tesSUCCESS",
+      "engine_result_code" : 0,
+      "engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
+      "status" : "success",
+      "tx_blob" : "1200142200040000240000000263D5038D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA9684000000000002EE0730081142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF7447304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE8114204288D2E47F8EF6C99BCC457966320D12409711E1E0107321028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B7446304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1F1",
+      "tx_json" : {
+         "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+         "Fee" : "12000",
+         "Flags" : 262144,
+         "LimitAmount" : {
+            "currency" : "USD",
+            "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+            "value" : "100"
+         },
+         "Sequence" : 2,
+         "Signers" : [
+            {
+               "Signer" : {
+                  "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                  "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+                  "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE"
+               }
+            },
+            {
+               "Signer" : {
+                  "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+                  "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
+                  "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1"
+               }
+            }
+         ],
+         "SigningPubKey" : "",
+         "TransactionType" : "TrustSet",
+         "hash" : "878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78"
+      }
+   }
+}
+
    +

    Take note of the hash value from the response (In this case, it's +878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78) so you can +check the results of the transaction later.

    +

    14. Manually close the ledger one last time

    +

    Once again, you would wait for the ledger to close on a live network. We use +the ledger_accept command to manually +close the ledger when running rippled in stand-alone mode.

    +
    $ build/rippled ledger_accept
+Loading: "/home/mduo13/.config/ripple/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "ledger_current_index" : 16061439,
+      "status" : "success"
+   }
+}
+
    +

    15. Confirm the results of the transaction

    +

    Use the hash value from the response to the submit_multisigned command.

    +
    $ build/rippled tx 878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78
+Loading: "/home/mduo13/.config/ripple/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+      "Fee" : "12000",
+      "Flags" : 262144,
+      "LimitAmount" : {
+         "currency" : "USD",
+         "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+         "value" : "100"
+      },
+      "Sequence" : 2,
+      "Signers" : [
+         {
+            "Signer" : {
+               "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+               "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+               "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE"
+            }
+         },
+         {
+            "Signer" : {
+               "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+               "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
+               "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1"
+            }
+         }
+      ],
+      "SigningPubKey" : "",
+      "TransactionType" : "TrustSet",
+      "date" : 496881900,
+      "hash" : "878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78",
+      "inLedger" : 16061438,
+      "ledger_index" : 16061438,
+      "meta" : {
+         "AffectedNodes" : [
+            {
+               "ModifiedNode" : {
+                  "LedgerEntryType" : "AccountRoot",
+                  "LedgerIndex" : "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
+                  "PreviousTxnID" : "6ECC8C16B76D9B9AB099CA96DD653D8A321C34F1E5972D5EE6DBA19418F4D0CC",
+                  "PreviousTxnLgrSeq" : 16061436
+               }
+            },
+            {
+               "ModifiedNode" : {
+                  "FinalFields" : {
+                     "Flags" : 0,
+                     "Owner" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+                     "RootIndex" : "3B9C0CE77FCE7BCEE1A68F1E26AC467AF326239D0D816CE705E4A0E2DAD03F6D"
+                  },
+                  "LedgerEntryType" : "DirectoryNode",
+                  "LedgerIndex" : "3B9C0CE77FCE7BCEE1A68F1E26AC467AF326239D0D816CE705E4A0E2DAD03F6D"
+               }
+            },
+            {
+               "CreatedNode" : {
+                  "LedgerEntryType" : "RippleState",
+                  "LedgerIndex" : "3C75A1F3DB61406AC2A9493038E8394A73F103C9229695AC7E57EB0F8AFC69E4",
+                  "NewFields" : {
+                     "Balance" : {
+                        "currency" : "USD",
+                        "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+                        "value" : "0"
+                     },
+                     "Flags" : 65536,
+                     "HighLimit" : {
+                        "currency" : "USD",
+                        "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+                        "value" : "0"
+                     },
+                     "LowLimit" : {
+                        "currency" : "USD",
+                        "issuer" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+                        "value" : "100"
+                     }
+                  }
+               }
+            },
+            {
+               "ModifiedNode" : {
+                  "FinalFields" : {
+                     "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+                     "Balance" : "109978000",
+                     "Flags" : 0,
+                     "OwnerCount" : 6,
+                     "Sequence" : 3
+                  },
+                  "LedgerEntryType" : "AccountRoot",
+                  "LedgerIndex" : "3D728C1F82CFE419F2DC58707D1AD06E985A29217D21A991ADF154184B664F4F",
+                  "PreviousFields" : {
+                     "Balance" : "109990000",
+                     "OwnerCount" : 5,
+                     "Sequence" : 2
+                  },
+                  "PreviousTxnID" : "3950D98AD20DA52EBB1F3937EF32F382D74092A4C8DF9A0B1A06ED25200B5756",
+                  "PreviousTxnLgrSeq" : 16061437
+               }
+            },
+            {
+               "ModifiedNode" : {
+                  "FinalFields" : {
+                     "Flags" : 0,
+                     "Owner" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+                     "RootIndex" : "95DA402B4D58FBFF6BAA4CB84BBC21348CC273949B61FEBCE758410EF90D147D"
+                  },
+                  "LedgerEntryType" : "DirectoryNode",
+                  "LedgerIndex" : "95DA402B4D58FBFF6BAA4CB84BBC21348CC273949B61FEBCE758410EF90D147D"
+               }
+            }
+         ],
+         "TransactionIndex" : 0,
+         "TransactionResult" : "tesSUCCESS"
+      },
+      "status" : "success",
+      "validated" : true
+   }
+}
+
    +

    In particular, check that the TransactionResult is the string tesSUCCESS.

    +

    On the live network, you must also confirm that the validated field is set to +the boolean true. If not, you might need to wait longer for the consensus +process to finish; or your transaction may be unable to be included in a ledger +for some reason. In stand-alone mode, the server automatically considers a +ledger to be validated if it has been manually closed.

    +
    +
    +
    + + + diff --git a/tutorial-reliable-transaction-submission.html b/tutorial-reliable-transaction-submission.html index cf156ea895..97f310c7c7 100644 --- a/tutorial-reliable-transaction-submission.html +++ b/tutorial-reliable-transaction-submission.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • @@ -113,6 +114,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
    • In this page:
    diff --git a/tutorial-rippleapi-beginners-guide.html b/tutorial-rippleapi-beginners-guide.html index 402b9e6b88..f6e33e4795 100644 --- a/tutorial-rippleapi-beginners-guide.html +++ b/tutorial-rippleapi-beginners-guide.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • @@ -113,6 +114,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
    • In this page:
    diff --git a/tutorial-rippled-setup.html b/tutorial-rippled-setup.html index 3e811f8f00..256fb1baa7 100644 --- a/tutorial-rippled-setup.html +++ b/tutorial-rippled-setup.html @@ -60,6 +60,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
  • @@ -113,6 +114,7 @@
  • RippleAPI Beginners Guide
  • rippled Setup
  • Reliable Transaction Submission
    • +
  • Multi-Signing Transactions
    • In this page:
    From e8b8eb87a6ad83d9343f47c95ef33f7b84371562 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Wed, 14 Oct 2015 19:52:24 -0700 Subject: [PATCH 10/40] amendments rough --- concept-amendments.html | 198 ++++++++++++++++++ concept-fee-voting.html | 2 + concept-fees.html | 2 + concept-freeze.html | 2 + ...ept-issuing-and-operational-addresses.html | 1 + concept-paths.html | 2 + concept-reserves.html | 2 + concept-transaction-cost.html | 2 + concept-transfer-fees.html | 2 + content/concept-amendments.md | 25 +++ data-api-v2-tool.html | 1 + index.html | 2 + multisign.html | 190 ----------------- reference-data-api.html | 1 + reference-ledger-format.html | 1 + reference-rippleapi.html | 1 + reference-rippled.html | 1 + reference-transaction-format.html | 1 + ripple-api-tool.html | 1 + tool-jsonrpc.html | 1 + tool/dactyl-config.yml | 7 + tutorial-gateway-guide.html | 1 + tutorial-multisign.html | 1 + tutorial-reliable-transaction-submission.html | 1 + tutorial-rippleapi-beginners-guide.html | 1 + tutorial-rippled-setup.html | 1 + 26 files changed, 260 insertions(+), 190 deletions(-) create mode 100644 concept-amendments.html create mode 100644 content/concept-amendments.md delete mode 100644 multisign.html diff --git a/concept-amendments.html b/concept-amendments.html new file mode 100644 index 0000000000..1c48e1c7b5 --- /dev/null +++ b/concept-amendments.html @@ -0,0 +1,198 @@ + + + + + + + +Amendments - Ripple Developer Portal + + + + + + + + + + + + + + + + + + + + + +
    + +
    +
    +

    Amendments

    +

    The Amendments system provides a means of introducing new features to the decentralized Ripple consensus network without causing disruptions. The amendments system works by utilizing the core consensus process of the network to approve any changes by showing continuous support for two weeks before they go into effect.

    +

    Background

    +

    Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. This could cause anything from minor inconveniences (a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot rely on their own) to serious problems: consensus might halt from validating ledgers because servers are unable to reach a majority who agree on the same result.

    +

    In theory, this could prompt a situation where the Ripple Consensus Ledger ceases to function because only a portion of validators have upgraded to a new version of the software.

    +

    Amendments fix that problem while also providing advance notice of when any transaction processing changes will go into effect, so that any users and businesses who rely on the behavior of the Ripple Consensus Ledger have fair warning in advance. API changes that do not impact the Consensus process do not require Amendments.

    +

    Amendment Lifecycle

    +

    An amendment is a fully-functional feature or change, ready to apply as soon as a consensus of servers can handle it. A server that wants to use an amendment must have functional code for two modes: without the amendment (previous behavior) and with the amendment (new behavior). Every amendment has a unique identifying string, which should indicate who developed it, in order to avoid potential overlap.

    +

    Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger: at this time, rippled validator servers submit votes in favor of specific amendments alongside their validations for that ledger.

    +

    In the flag ledger itself, there is nothing unusual. However, during that time, the servers look at the votes of the validators they trust, and decide whether to insert an Amendment pseudo-transaction into the following ledger, with flags to indicate what it thinks happened:

    +
      +
    • The tfGotMajority flag means that support for a feature has increased across the threshold of 80% of trusted validators.
      • +
    • The tfLostMajority flag means that support for a feature has decreased across the threshold of 80% of trusted validators.
      • +
    • An Amendment pseudo-transaction with no flags means that support for a feature has been enabled. This is called the "Enabled" Amendment.
      • +
    +

    A server only inserts the "Enabled" Amendment if there is a validated ledger which closed at least two weeks prior to the current flag ledger, with a Got-Majority Amendment psuedo-transaction, and no Lost-Majority Amendment psuedo-transactions for the same feature in the validated ledgers in between.

    +
    +
    +
    + + + diff --git a/concept-fee-voting.html b/concept-fee-voting.html index c80e54520d..87158c643f 100644 --- a/concept-fee-voting.html +++ b/concept-fee-voting.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • @@ -118,6 +119,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
    • In this page:
    diff --git a/concept-fees.html b/concept-fees.html index bd7b02cbc8..72612f9fdf 100644 --- a/concept-fees.html +++ b/concept-fees.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • @@ -118,6 +119,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
    • In this page:
    diff --git a/concept-freeze.html b/concept-freeze.html index 0e82fb9097..5f11ded28d 100644 --- a/concept-freeze.html +++ b/concept-freeze.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • @@ -118,6 +119,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
    • In this page:
    diff --git a/concept-issuing-and-operational-addresses.html b/concept-issuing-and-operational-addresses.html index ec0ed447df..5899c0bd45 100644 --- a/concept-issuing-and-operational-addresses.html +++ b/concept-issuing-and-operational-addresses.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • diff --git a/concept-paths.html b/concept-paths.html index fb9949f7ed..e75dd477ae 100644 --- a/concept-paths.html +++ b/concept-paths.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • @@ -118,6 +119,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
    • In this page:
    diff --git a/concept-reserves.html b/concept-reserves.html index dd6ce71020..a457f82400 100644 --- a/concept-reserves.html +++ b/concept-reserves.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • @@ -118,6 +119,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
    • In this page:
    diff --git a/concept-transaction-cost.html b/concept-transaction-cost.html index 12fbb49f28..ee09630ace 100644 --- a/concept-transaction-cost.html +++ b/concept-transaction-cost.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • @@ -118,6 +119,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
    • In this page:
    diff --git a/concept-transfer-fees.html b/concept-transfer-fees.html index 5ba03fda3e..a2d6c68a65 100644 --- a/concept-transfer-fees.html +++ b/concept-transfer-fees.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • @@ -118,6 +119,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
    • In this page:
    diff --git a/content/concept-amendments.md b/content/concept-amendments.md new file mode 100644 index 0000000000..2d7e63d7d3 --- /dev/null +++ b/content/concept-amendments.md @@ -0,0 +1,25 @@ +# Amendments # + +The Amendments system provides a means of introducing new features to the decentralized Ripple consensus network without causing disruptions. The amendments system works by utilizing the core consensus process of the network to approve any changes by showing continuous support for two weeks before they go into effect. + +## Background ## + +Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. This could cause anything from minor inconveniences (a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot rely on their own) to serious problems: consensus might halt from validating ledgers because servers are unable to reach a majority who agree on the same result. + +In theory, this could prompt a situation where the Ripple Consensus Ledger ceases to function because only a portion of validators have upgraded to a new version of the software. + +Amendments fix that problem while also providing advance notice of when any transaction processing changes will go into effect, so that any users and businesses who rely on the behavior of the Ripple Consensus Ledger have fair warning in advance. API changes that do not impact the Consensus process do not require Amendments. + +## Amendment Lifecycle ## + +An amendment is a fully-functional feature or change, ready to apply as soon as a consensus of servers can handle it. A server that wants to use an amendment must have functional code for two modes: without the amendment (previous behavior) and with the amendment (new behavior). Every amendment has a unique identifying string, which should indicate who developed it, in order to avoid potential overlap. + +Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger: at this time, `rippled` validator servers submit votes in favor of specific amendments alongside their validations for that ledger. + +In the flag ledger itself, there is nothing unusual. However, during that time, the servers look at the votes of the validators they trust, and decide whether to insert an `Amendment` pseudo-transaction into the following ledger, with flags to indicate what it thinks happened: + +* The `tfGotMajority` flag means that support for a feature has increased across the threshold of 80% of trusted validators. +* The `tfLostMajority` flag means that support for a feature has decreased across the threshold of 80% of trusted validators. +* An Amendment pseudo-transaction with no flags means that support for a feature has been enabled. This is called the _"Enabled"_ Amendment. + +A server only inserts the "Enabled" Amendment if there is a validated ledger which closed at least two weeks prior to the current flag ledger, with a Got-Majority Amendment psuedo-transaction, and no Lost-Majority Amendment psuedo-transactions for the same feature in the validated ledgers in between. diff --git a/data-api-v2-tool.html b/data-api-v2-tool.html index 5fd5199392..d0a712c2de 100644 --- a/data-api-v2-tool.html +++ b/data-api-v2-tool.html @@ -59,6 +59,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • diff --git a/index.html b/index.html index b2fe5eaaa2..58ac4c14cd 100644 --- a/index.html +++ b/index.html @@ -66,6 +66,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • @@ -151,6 +152,7 @@ Ripple’s distributed settlement network is built on open-source technology tha
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
    • diff --git a/multisign.html b/multisign.html deleted file mode 100644 index a9e2ef2e11..0000000000 --- a/multisign.html +++ /dev/null @@ -1,190 +0,0 @@ - - - - - - - - How to Multi-Sign a Transaction - Ripple Developer Portal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    - - - diff --git a/reference-data-api.html b/reference-data-api.html index 921b2045f4..f3073eb5af 100644 --- a/reference-data-api.html +++ b/reference-data-api.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • diff --git a/reference-ledger-format.html b/reference-ledger-format.html index 8fe8bbc29d..05ac9bfa47 100644 --- a/reference-ledger-format.html +++ b/reference-ledger-format.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • diff --git a/reference-rippleapi.html b/reference-rippleapi.html index acbc978ed0..aa0bc9d37c 100644 --- a/reference-rippleapi.html +++ b/reference-rippleapi.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • diff --git a/reference-rippled.html b/reference-rippled.html index 19bc46f057..a719b036ce 100644 --- a/reference-rippled.html +++ b/reference-rippled.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • diff --git a/reference-transaction-format.html b/reference-transaction-format.html index 57f3f7563f..bd5150a04f 100644 --- a/reference-transaction-format.html +++ b/reference-transaction-format.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • diff --git a/ripple-api-tool.html b/ripple-api-tool.html index 0683e964f9..9c056723df 100644 --- a/ripple-api-tool.html +++ b/ripple-api-tool.html @@ -59,6 +59,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • diff --git a/tool-jsonrpc.html b/tool-jsonrpc.html index 0d17736796..b10b94e614 100644 --- a/tool-jsonrpc.html +++ b/tool-jsonrpc.html @@ -59,6 +59,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • diff --git a/tool/dactyl-config.yml b/tool/dactyl-config.yml index 1601384363..1a3d154f25 100644 --- a/tool/dactyl-config.yml +++ b/tool/dactyl-config.yml @@ -165,6 +165,13 @@ pages: ripple.com: https://ripple.com/build/freeze/ sidebar: true + - name: Amendments + category: Concepts + html: concept-amendments.html + md: concept-amendments.md + ripple.com: https://wiki.ripple.com/Understanding:_Feature_adoption + sidebar: true + # "Best Practices" documents are mostly in the same category as tutorials - name: Issuing and Operational Addresses category: Best Practices diff --git a/tutorial-gateway-guide.html b/tutorial-gateway-guide.html index b33d4aeee8..dca7beb6b3 100644 --- a/tutorial-gateway-guide.html +++ b/tutorial-gateway-guide.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • diff --git a/tutorial-multisign.html b/tutorial-multisign.html index 47de643fee..212bdc7553 100644 --- a/tutorial-multisign.html +++ b/tutorial-multisign.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • diff --git a/tutorial-reliable-transaction-submission.html b/tutorial-reliable-transaction-submission.html index 97f310c7c7..a70b478382 100644 --- a/tutorial-reliable-transaction-submission.html +++ b/tutorial-reliable-transaction-submission.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • diff --git a/tutorial-rippleapi-beginners-guide.html b/tutorial-rippleapi-beginners-guide.html index f6e33e4795..b6883e0dc5 100644 --- a/tutorial-rippleapi-beginners-guide.html +++ b/tutorial-rippleapi-beginners-guide.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • diff --git a/tutorial-rippled-setup.html b/tutorial-rippled-setup.html index 256fb1baa7..8d71922483 100644 --- a/tutorial-rippled-setup.html +++ b/tutorial-rippled-setup.html @@ -73,6 +73,7 @@
  • Fee Voting
  • Reserves
  • Freeze
    • +
  • Amendments
  • From aac47fa398342f3530d876a1fa48a116bfb1c6f3 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Tue, 22 Mar 2016 11:19:34 -0700 Subject: [PATCH 11/40] remove hard linebreaks in multisign tutorial --- content/tutorial-multisign.md | 164 +++++++++++----------------------- 1 file changed, 51 insertions(+), 113 deletions(-) diff --git a/content/tutorial-multisign.md b/content/tutorial-multisign.md index b754689f55..75a3e0047d 100644 --- a/content/tutorial-multisign.md +++ b/content/tutorial-multisign.md @@ -1,11 +1,7 @@ Introduction to Multi-Signing ================================================================== -Multi-signing in Ripple is the act of authorizing transactions for the Ripple -Consensus Ledger by using a combination of multiple secret keys. After setting -up multi-signing for an account, you can put the master secret in cold storage, -or even disable the master key entirely. With multiple secret keys required to -authorize a multi-signature, you can improve security in several ways. +Multi-signing in Ripple is the act of authorizing transactions for the Ripple Consensus Ledger by using a combination of multiple secret keys. After setting up multi-signing for an account, you can put the master secret in cold storage, or even disable the master key entirely. With multiple secret keys required to authorize a multi-signature, you can improve security in several ways. * If you keep an account's keys on different devices, a malicious user must compromise multiple machines in order to send transactions on your behalf. * If the keys to an account are in the custody of entirely different people, those people must collaborate in order to send transaction from that account. @@ -16,40 +12,30 @@ authorize a multi-signature, you can improve security in several ways. Availability of Multi-Signing ----------------------------------------------------------------- -Multi-signing is due to be enabled by an **Amendment** to the Ripple Consensus -Protocol. This Amendment must be approved by a consensus of validators showing -consistent support for the feature over a period of time. For more information, -see Amendments (TODO: link). +Multi-signing is due to be enabled by an **Amendment** to the Ripple Consensus Protocol. This Amendment must be approved by a consensus of validators showing consistent support for the feature over a period of time. For more information, see [Amendments](concept-amendments.html). -You can test multi-signing by running `rippled` in stand-alone mode with the -feature enabled. In stand-alone mode, `rippled` does not communicate with the -rest of the Ripple peer-to-peer network, but you can perform most of the same -actions on your local server only. This way, you can be sure that you are ready -for multi-signing when it goes live. +You can test multi-signing by running `rippled` in stand-alone mode with the feature enabled. In stand-alone mode, `rippled` does not communicate with the rest of the Ripple peer-to-peer network, but you can perform most of the same actions on your local server only. This way, you can be sure that you are ready for multi-signing when it goes live. How to Multi-Sign ================================================================= -The basic process of Multi-Signing a transaction is necessarily more -complex than the process of signing a transaction with a single master key or -regular key. +The basic process of Multi-Signing a transaction is necessarily more complex than the process of signing a transaction with a single master key or regular key. -1. Download and build rippled with multi-sign ------------------------------------------------------------------ +## 1. Download and build rippled with multi-sign ## Until a binary for `rippled` with multi-signing is available, the best you can do is build it from source. - $ git clone git@github.com:scottschurr/rippled.git (TODO: switch to a Ripple Labs repo when available) - $ git checkout fix-sign_for + $ git clone git@github.com:ripple/rippled.git + $ git checkout release $ scons See [rippled build instructions](https://wiki.ripple.com/Rippled_build_instructions) for help building from source. -2. Configure rippled to enable MultiSign ------------------------------------------------------------------ +## 2. Configure rippled to enable MultiSign ## + Add the following to the bottom of the config file: [features] @@ -57,30 +43,22 @@ Add the following to the bottom of the config file: Note that this stanza is case-sensitive. -3. Start rippled in stand-alone mode ------------------------------------------------------------------ +## 3. Start rippled in stand-alone mode ## -If you have previously synced to the network, you can have the server load the -latest ledger as a starting place for stand-alone mode using the `--load` -commandline option: +If you have previously synced to the network, you can have the server load the latest ledger as a starting place for stand-alone mode using the `--load` commandline option: $ sudo ./build/rippled --conf=/home/mduo13/.config/ripple/rippled.cfg -a --load -If you'd rather start from scratch, you can use the `--start` commandline -option to create a fresh ledger. In this case, the root account holds all -100 billion XRP: +If you'd rather start from scratch, you can use the `--start` commandline option to create a fresh ledger. In this case, the root account holds all 100 billion XRP: **Address:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` **Secret:** `snoPBrXtMeMyMHUVTgbuqAfg1SUTb` ("masterpassphrase") -4. Generate keys for a new wallet ------------------------------------------------------------------ +## 4. Generate keys for a new wallet ## -This step is not strictly necessary. For this process, we generate the keys to -a new Ripple account and then set up multi-signing for that account. To set up -multi-signing on an existing Ripple account, just use the keys to that account. +This step is not strictly necessary. For this process, we generate and fund a new Ripple account and then set up multi-signing for that account. To set up multi-signing on an existing Ripple account, skip ahead to [Step 7: creating a signer list](#7-create-a-signerlist-on-the-account-with-a-signerlistset-transaction). $ build/rippled wallet_propose Loading: "/home/mduo13/.config/ripple/rippled.cfg" @@ -98,16 +76,12 @@ multi-signing on an existing Ripple account, just use the keys to that account. } } -As always, be sure that an account's secret key never gets transmitted to -anyone you don't trust with full control of that account, and certainly not -unencrypted over the network. +As always, be sure that an account's secret key never gets transmitted to anyone you don't trust with full control of that account, and certainly not unencrypted over the network. -5. Fund the new account with an existing wallet ------------------------------------------------------------------ +## 5. Fund the new account with an existing wallet ## -Again, this step is only necessary if you are setting up a new account to use -multi-signing for this example. +Again, this step is only necessary if you are setting up a new account to use multi-signing for this example. $ build/rippled submit '{ > "TransactionType" : "Payment", @@ -141,12 +115,11 @@ multi-signing for this example. } -6. Manually close the ledger ------------------------------------------------------------------ +## 6. Manually close the ledger ## -In the live network, you would simply wait for the ledger to close -automatically as the result of consensus. However, a rippled node running in -stand-alone mode does not engage in consensus, so you must manually close the +In the live network, you would simply wait for the ledger to close +automatically as the result of consensus. However, a rippled node running in +stand-alone mode does not engage in consensus, so you must manually close the ledger with the [`ledger_accept` command](rippled-apis.html#ledger-accept). $ build/rippled ledger_accept @@ -160,18 +133,11 @@ ledger with the [`ledger_accept` command](rippled-apis.html#ledger-accept). } -7. Create a SignerList on the new account with a SignerListSet transaction ------------------------------------------------------------------ +## 7. Create a SignerList on the new account with a SignerListSet transaction ## -Before you can multi-sign transactions, you must associate a SignerList with -your account, so that RCL knows which keys can be used to sign for you. You do -this with a [SignerListSet transaction](transactions.html#signerlistset). +Before you can multi-sign transactions, you must associate a SignerList with your account, so that RCL knows which keys can be used to sign for you. You do this with a [SignerListSet transaction](transactions.html#signerlistset). -In this example, the SignerList has 3 members, with the weights and quorum set -up such that multi-signed transactions need a signature from -rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other -two members of the list. The `Account` values you use in your list can be -funded accounts that exist in the ledger or just unused addresses. +In this example, the SignerList has 3 members, with the weights and quorum set up such that multi-signed transactions need a signature from rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other two members of the list. The `Account` values you use in your list can be funded accounts that exist in the ledger or just unused addresses. $ build/rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{ > "Flags": 0, @@ -244,12 +210,9 @@ funded accounts that exist in the ledger or just unused addresses. } -8. Manually close the ledger again ------------------------------------------------------------------ +## 8. Manually close the ledger again ## -As before, you would wait for the ledger to close on a live network. We use -the [`ledger_accept` command](rippled-apis.html#ledger-accept) to manually -close the ledger when running `rippled` in stand-alone mode. +As before, you would wait for the ledger to close on a live network. We use the [`ledger_accept` command](reference-rippled.html#ledger-accept) to manually close the ledger when running `rippled` in stand-alone mode. $ build/rippled ledger_accept Loading: "/home/mduo13/.config/ripple/rippled.cfg" @@ -262,13 +225,9 @@ close the ledger when running `rippled` in stand-alone mode. } -9. Confirm the presence of the new signer list using account_objects ------------------------------------------------------------------ +## 9. Confirm the presence of the new signer list using account_objects ## -Normally an account has lots of different types of objects, but for this new -account, the only thing we've done is add a SignerList, so it should be easy to -find in the results of the -[`account_objects` command](rippled-apis.html#account-objects). +Normally an account has lots of different types of objects, but for this new account, the only thing we've done is add a SignerList, so it should be easy to find in the results of the [`account_objects` command](reference-rippled.html#account-objects). $ build/rippled account_objects rnBFvgZphmN39GWzUJeUitaP22Fr9be75H Loading: "/home/mduo13/.config/ripple/rippled.cfg" @@ -318,8 +277,8 @@ find in the results of the 10. Create a new transaction that you plan to multi-sign ----------------------------------------------------------------- -You have to specify _everything_ about this transaction, including Fee and -Sequence. Also include the field `SigningPubKey` as an empty string -- this +You have to specify _everything_ about this transaction, including `Fee` and +`Sequence`. Also include the field `SigningPubKey` as an empty string -- this indicates that the transaction is multi-signed. Here's an example transaction we can send from our test account: @@ -338,18 +297,17 @@ Here's an example transaction we can send from our test account: "Fee": "12000" } -(If you started from a fresh ledger, you first need to fund the account +(If you started from a fresh ledger, you first need to fund the account specified by the `issuer` in this example, and then manually close the ledger.) -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 +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 fee, 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 load fee increases in that time. -11. Get a signature using the sign_for command ------------------------------------------------------------------ +## 11. Get a signature using the sign_for command ## $ build/rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW '{ > "TransactionType": "TrustSet", @@ -396,21 +354,14 @@ want to include additional buffer in case the load fee increases in that time. } } -The valuable part in the response is the `Signers` field. This is the part that -you're going to need later in order to construct the full, multi-signed -transaction. +The valuable part in the response is the `Signers` field. This is the part that you're going to need later in order to construct the full, multi-signed transaction. -The other parts, such as the `tx_blob`, are not very useful at this point, -unless you're "multi-signing" a transaction with only one signature. +The other parts, such as the `tx_blob`, are not very useful at this point, unless you're "multi-signing" a transaction with only one signature. -12. Get additional signatures the same way ------------------------------------------------------------------ +## 12. Get additional signatures the same way ## -If the accounts in your SignerList are funded accounts, the secret key you use -to sign for those accounts can come from the regular key (if they have one), or -the master key (unless it's disabled). For accounts that don't exist in the -ledger, you can only use the master secret associated with the address. +If the accounts in your SignerList are funded accounts, the secret key you use to sign for those accounts can come from the regular key (if they have one), or the master key (unless it's disabled). For accounts that don't exist in the ledger, you can only use the master secret associated with the address. $ build/rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v '{ "TransactionType": "TrustSet", @@ -457,21 +408,15 @@ ledger, you can only use the master secret associated with the address. } } -Depending on the SignerList you configured, you may need to repeat this step -several times in order to get signatures from all the necessary parties. +Depending on the SignerList you configured, you may need to repeat this step several times in order to get signatures from all the necessary parties. 13. Combine the signatures and submit ----------------------------------------------------------------- -Take the contents of all the `Signers` arrays from all the responses, and -concatenate them in to a single `Signers` array field. The commandline syntax -for the [`submit_multisigned` command](rippled-apis.html#submit-multisigned) -takes a single JSON object with two elements: this combined `Signers` array; -and `tx_json`, which is the transaction JSON that they signed. +Take the contents of all the `Signers` arrays from all the responses, and concatenate them in to a single `Signers` array field. The commandline syntax for the [`submit_multisigned` command](reference-rippled.html#submit-multisigned) takes a single JSON object with two elements: this combined `Signers` array; and `tx_json`, which is the transaction JSON that they signed. -This command actually submits the transaction for inclusion in the ledger. In -online mode, this relays it to other members of the network. +This command actually submits the transaction for inclusion in the ledger. In online mode, this relays it to other members of the network. $ build/rippled submit_multisigned ' { > "Signers": [ @@ -546,16 +491,13 @@ online mode, this relays it to other members of the network. } } -Take note of the `hash` value from the response (In this case, it's -`878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78`) so you can -check the results of the transaction later. +Take note of the `hash` value from the response (In this case, it's `878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78`) so you can check the results of the transaction later. -14. Manually close the ledger one last time ------------------------------------------------------------------ +## 14. Manually close the ledger one last time ## -Once again, you would wait for the ledger to close on a live network. We use -the [`ledger_accept` command](rippled-apis.html#ledger-accept) to manually +Once again, you would wait for the ledger to close on a live network. We use +the [`ledger_accept` command](reference-rippled.html#ledger-accept) to manually close the ledger when running `rippled` in stand-alone mode. $ build/rippled ledger_accept @@ -569,8 +511,7 @@ close the ledger when running `rippled` in stand-alone mode. } -15. Confirm the results of the transaction ------------------------------------------------------------------ +## 15. Confirm the results of the transaction ## Use the hash value from the response to the `submit_multisigned` command. @@ -695,13 +636,10 @@ Use the hash value from the response to the `submit_multisigned` command. } } -In particular, check that the `TransactionResult` is the string `tesSUCCESS`. +In particular, check that the `TransactionResult` is the string `tesSUCCESS`. -On the live network, you must also confirm that the `validated` field is set to -the boolean `true`. If not, you might need to wait longer for the consensus -process to finish; or your transaction may be unable to be included in a ledger -for some reason. In stand-alone mode, the server automatically considers a +On the live network, you must also confirm that the `validated` field is set to +the boolean `true`. If not, you might need to wait longer for the consensus +process to finish; or your transaction may be unable to be included in a ledger +for some reason. In stand-alone mode, the server automatically considers a ledger to be `validated` if it has been manually closed. - - - From dfafdcc237265d4ded136d1797bd89551b7101b7 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Tue, 22 Mar 2016 18:00:34 -0700 Subject: [PATCH 12/40] multi-sign - standalone mode in separate article --- concept-amendments.html | 2 + concept-fee-voting.html | 2 + concept-fees.html | 2 + concept-freeze.html | 2 + ...ept-issuing-and-operational-addresses.html | 1 + concept-paths.html | 2 + concept-reserves.html | 2 + concept-stand-alone-mode.html | 234 ++++++++++++++++++ concept-transaction-cost.html | 2 + concept-transfer-fees.html | 2 + content/concept-stand-alone-mode.md | 94 +++++++ content/tutorial-multisign.md | 120 ++++----- data-api-v2-tool.html | 1 + index.html | 2 + reference-data-api.html | 1 + reference-ledger-format.html | 1 + reference-rippleapi.html | 1 + reference-rippled.html | 1 + reference-transaction-format.html | 1 + ripple-api-tool.html | 1 + tool-jsonrpc.html | 1 + tool/dactyl-config.yml | 7 + tutorial-gateway-guide.html | 1 + tutorial-multisign.html | 178 ++++--------- tutorial-reliable-transaction-submission.html | 1 + tutorial-rippleapi-beginners-guide.html | 1 + tutorial-rippled-setup.html | 1 + 27 files changed, 464 insertions(+), 200 deletions(-) create mode 100644 concept-stand-alone-mode.html create mode 100644 content/concept-stand-alone-mode.md diff --git a/concept-amendments.html b/concept-amendments.html index 1c48e1c7b5..cb53e2322e 100644 --- a/concept-amendments.html +++ b/concept-amendments.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • @@ -120,6 +121,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
    • In this page:
    diff --git a/concept-fee-voting.html b/concept-fee-voting.html index 87158c643f..819271ddf7 100644 --- a/concept-fee-voting.html +++ b/concept-fee-voting.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • @@ -120,6 +121,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
    • In this page:
    diff --git a/concept-fees.html b/concept-fees.html index 72612f9fdf..5bfbbb2269 100644 --- a/concept-fees.html +++ b/concept-fees.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • @@ -120,6 +121,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
    • In this page:
    diff --git a/concept-freeze.html b/concept-freeze.html index 5f11ded28d..698212cc31 100644 --- a/concept-freeze.html +++ b/concept-freeze.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • @@ -120,6 +121,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
    • In this page:
    diff --git a/concept-issuing-and-operational-addresses.html b/concept-issuing-and-operational-addresses.html index 5899c0bd45..215d010645 100644 --- a/concept-issuing-and-operational-addresses.html +++ b/concept-issuing-and-operational-addresses.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • diff --git a/concept-paths.html b/concept-paths.html index e75dd477ae..6825135c6b 100644 --- a/concept-paths.html +++ b/concept-paths.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • @@ -120,6 +121,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
    • In this page:
    diff --git a/concept-reserves.html b/concept-reserves.html index a457f82400..2bf281ca19 100644 --- a/concept-reserves.html +++ b/concept-reserves.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • @@ -120,6 +121,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
    • In this page:
    diff --git a/concept-stand-alone-mode.html b/concept-stand-alone-mode.html new file mode 100644 index 0000000000..5740eaf662 --- /dev/null +++ b/concept-stand-alone-mode.html @@ -0,0 +1,234 @@ + + + + + + + +Stand-Alone Mode - Ripple Developer Portal + + + + + + + + + + + + + + + + + + + + + +
    + +
    +
    +

    Stand-Alone Mode

    +

    You can run rippled in stand-alone mode without a consensus of trusted servers. In stand-alone mode, rippled does not communicate with any other servers in the Ripple peer-to-peer network, but you can perform most of the same actions on your local server only. Stand-alone provides a method for testing rippled behavior, including the effects of Amendments before those Amendments have gone into effect across the decentralized network.

    +

    When you run rippled in stand-alone mode, you have to tell it what ledger version to start from:

    + +

    Caution: In stand-alone mode, you must manually advance the ledger.

    +

    New Genesis Ledger

    +

    In stand-alone mode, you can have rippled create a new genesis ledger. This provides a known state, with none of the ledger history from the production Ripple network. (This is very useful for unit tests, among other things.)

    +
      +
    • To start rippled in stand-alone mode with a new genesis ledger, use the -a and --start options:
      • +
    +
    rippled -a --start --conf=/path/to/rippled.cfg
+
    +

    In a genesis ledger, the genesis account holds all 100 billion XRP. The keys of the genesis account are hardcoded as follows:

    +

    Address: rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh

    +

    Secret: snoPBrXtMeMyMHUVTgbuqAfg1SUTb ("masterpassphrase")

    +

    Load Saved Ledger

    +

    You can start with a ledger version that was saved to disk if your rippled server was previously synced with the Ripple peer-to-peer network (either the production network or the Test Net).

    +

    1. To retrieve existing ledgers, start rippled normally:

    +
    rippled --conf=/path/to/rippled.cfg
+
    +

    2. Wait until rippled is synced:

    +

    When rippled is synced with the state of the network, the response from the server_info command shows a server_state value that is full, proposing, or validating.

    +

    3. (Optional) Retrieve specific ledger versions:

    +

    If you only want the most recent ledger, you can skip this step.

    +

    If you want to load a specific historical ledger version, use the ledger_request command to make rippled fetch it. If rippled does not already have the ledger version, you may have to run the ledger_request command multiple times until it has finished retrieving the ledger.

    +

    If you want to replay a specific historical ledger version, you must fetch both the ledger version to replay and the ledger version immediately before it.

    +

    4. Shut down rippled:

    +
    rippled stop --conf=/path/to/rippled.cfg
+
    +

    5. Start rippled in stand-alone mode, loading the saved ledger.

    +

    To load the most recent ledger version, you can use the -a and --load options:

    +
    rippled -a --load --conf=/path/to/rippled.cfg
+
    +

    To instead load a specific historical ledger, use the --ledger parameter with the ledger index or identifying hash of the ledger version to load:

    +
    rippled -a --ledger 19860944 --conf=/path/to/rippled.cfg
+
    +

    (TODO: test this)

    +

    6. Manually advance the ledger.

    +

    When you load a ledger with --ledger in stand-alone mode, it goes to the current open ledger, so you need to manually advance the ledger to finalize it:

    +
    rippled ledger_accept --conf=/path/to/rippled.cfg
+
    +

    Advancing Ledgers in Stand-Alone Mode

    +

    In stand-alone mode, rippled does not communicate to other members of the peer-to-peer network or participate in a consensus process. Instead, you must manually advance the ledger index using the ledger_accept command:

    +
    rippled ledger_accept --conf=/path/to/rippled.cfg
+
    +

    In stand-alone mode, rippled makes no distinction between a "closed" ledger version and a "validated" ledger version. (For more information about the difference, see The Ripple Ledger Consensus Process.)

    +

    Whenever rippled closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since different rippled servers may see transactions in a different order.) When using rippled in stand-alone mode, it is important to manually advance the ledger before submitting a transaction that depends on the result of a previous transaction. Otherwise, the second transaction might be executed before the first transaction when you manually advance the ledger. Note: You can safely submit multiple transactions from a single account to a single ledger, because rippled sorts transactions from the same account in ascending order by Sequence number.

    +
    +
    +
    + + + diff --git a/concept-transaction-cost.html b/concept-transaction-cost.html index ee09630ace..9790422311 100644 --- a/concept-transaction-cost.html +++ b/concept-transaction-cost.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • @@ -120,6 +121,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
    • In this page:
    diff --git a/concept-transfer-fees.html b/concept-transfer-fees.html index a2d6c68a65..744056c8ea 100644 --- a/concept-transfer-fees.html +++ b/concept-transfer-fees.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • @@ -120,6 +121,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
    • In this page:
    diff --git a/content/concept-stand-alone-mode.md b/content/concept-stand-alone-mode.md new file mode 100644 index 0000000000..3b8bf2b21f --- /dev/null +++ b/content/concept-stand-alone-mode.md @@ -0,0 +1,94 @@ +Stand-Alone Mode +=============================================================================== + +You can run `rippled` in stand-alone mode without a consensus of trusted servers. In stand-alone mode, `rippled` does not communicate with any other servers in the Ripple peer-to-peer network, but you can perform most of the same actions on your local server only. Stand-alone provides a method for testing `rippled` behavior, including the effects of [Amendments](concept-amendments.html) before those Amendments have gone into effect across the decentralized network. + +When you run `rippled` in stand-alone mode, you have to tell it what ledger version to start from: + +* Create a [new genesis ledger](#new-genesis-ledger) from scratch. +* [Load an existing ledger version](#load-saved-ledger) from disk. + +**Caution:** In stand-alone mode, you must [manually advance the ledger](#advancing-ledgers-in-stand-alone-mode). + +New Genesis Ledger +------------------------------------------------------------------------------- +In stand-alone mode, you can have `rippled` create a new genesis ledger. This provides a known state, with none of the ledger history from the production Ripple network. (This is very useful for unit tests, among other things.) + +* To start `rippled` in stand-alone mode with a new genesis ledger, use the `-a` and `--start` options: + +``` +rippled -a --start --conf=/path/to/rippled.cfg +``` + +In a genesis ledger, the [genesis account](reference-rippled.html#special-addresses) holds all 100 billion XRP. The keys of the genesis account are [hardcoded](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184) as follows: + +**Address:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` + +**Secret:** `snoPBrXtMeMyMHUVTgbuqAfg1SUTb` ("masterpassphrase") + + +Load Saved Ledger +------------------------------------------------------------------------------- +You can start with a ledger version that was saved to disk if your `rippled` server was previously synced with the Ripple peer-to-peer network (either the production network or the [Test Net](tutorial-rippled-setup.html#parallel-networks)). + +### 1. To retrieve existing ledgers, start `rippled` normally: ### + +``` +rippled --conf=/path/to/rippled.cfg +``` + +### 2. Wait until `rippled` is synced: ### + +When `rippled` is synced with the state of the network, the response from the [`server_info` command](reference-rippled.html#server-info) shows a `server_state` value that is `full`, `proposing`, or `validating`. + +### 3. (Optional) Retrieve specific ledger versions: ### + +If you only want the most recent ledger, you can skip this step. + +If you want to load a specific historical ledger version, use the [`ledger_request` command](reference-rippled.html#ledger-request) to make `rippled` fetch it. If `rippled` does not already have the ledger version, you may have to run the `ledger_request` command multiple times until it has finished retrieving the ledger. + +If you want to replay a specific historical ledger version, you must fetch both the ledger version to replay and the ledger version immediately before it. + +### 4. Shut down `rippled`: ### + +``` +rippled stop --conf=/path/to/rippled.cfg +``` + +### 5. Start `rippled` in stand-alone mode, loading the saved ledger. + +To load the most recent ledger version, you can use the `-a` and `--load` options: + +``` +rippled -a --load --conf=/path/to/rippled.cfg +``` + +To instead load a specific historical ledger, use the ``--ledger`` parameter with the ledger index or identifying hash of the ledger version to load: + +``` +rippled -a --ledger 19860944 --conf=/path/to/rippled.cfg +``` + +(TODO: test this) + +### 6. Manually advance the ledger. ### + +When you load a ledger with `--ledger` in stand-alone mode, it goes to the current open ledger, so you need to [manually advance the ledger](#advancing-ledgers-in-stand-alone-mode) to finalize it: + +``` +rippled ledger_accept --conf=/path/to/rippled.cfg +``` + + +Advancing Ledgers in Stand-Alone Mode +------------------------------------------------------------------------------- + +In stand-alone mode, `rippled` does not communicate to other members of the peer-to-peer network or participate in a consensus process. Instead, you must manually advance the ledger index using the [`ledger_accept` command](reference-rippled.html#ledger-accept): + +``` +rippled ledger_accept --conf=/path/to/rippled.cfg +``` + +In stand-alone mode, `rippled` makes no distinction between a "closed" ledger version and a "validated" ledger version. (For more information about the difference, see [The Ripple Ledger Consensus Process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/).) + +Whenever `rippled` closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since different `rippled` servers may see transactions in a different order.) When using `rippled` in stand-alone mode, it is important to manually advance the ledger before submitting a transaction that depends on the result of a previous transaction. Otherwise, the second transaction might be executed before the first transaction when you manually advance the ledger. **Note:** You can safely submit multiple transactions from a single account to a single ledger, because `rippled` sorts transactions from the same account in ascending order by `Sequence` number. diff --git a/content/tutorial-multisign.md b/content/tutorial-multisign.md index 75a3e0047d..8207f3e372 100644 --- a/content/tutorial-multisign.md +++ b/content/tutorial-multisign.md @@ -1,5 +1,5 @@ Introduction to Multi-Signing -================================================================== +=============================================================================== Multi-signing in Ripple is the act of authorizing transactions for the Ripple Consensus Ledger by using a combination of multiple secret keys. After setting up multi-signing for an account, you can put the master secret in cold storage, or even disable the master key entirely. With multiple secret keys required to authorize a multi-signature, you can improve security in several ways. @@ -10,57 +10,26 @@ Multi-signing in Ripple is the act of authorizing transactions for the Ripple Co Availability of Multi-Signing ------------------------------------------------------------------ +------------------------------------------------------------------------------- -Multi-signing is due to be enabled by an **Amendment** to the Ripple Consensus Protocol. This Amendment must be approved by a consensus of validators showing consistent support for the feature over a period of time. For more information, see [Amendments](concept-amendments.html). +Multi-signing is built into `rippled` starting with version **0.31.0**. Because multi-signing is a change in transaction processing, the change is due to be enabled by an **Amendment** to the Ripple Consensus Protocol. This Amendment must be approved by a consensus of validators showing consistent support for the feature over a period of time. For more information, see [Amendments](concept-amendments.html). -You can test multi-signing by running `rippled` in stand-alone mode with the feature enabled. In stand-alone mode, `rippled` does not communicate with the rest of the Ripple peer-to-peer network, but you can perform most of the same actions on your local server only. This way, you can be sure that you are ready for multi-signing when it goes live. - - - -How to Multi-Sign -================================================================= - -The basic process of Multi-Signing a transaction is necessarily more complex than the process of signing a transaction with a single master key or regular key. - -## 1. Download and build rippled with multi-sign ## - -Until a binary for `rippled` with multi-signing is available, the best you can do is build it from source. - - $ git clone git@github.com:ripple/rippled.git - $ git checkout release - $ scons - -See [rippled build instructions](https://wiki.ripple.com/Rippled_build_instructions) for help building from source. - - -## 2. Configure rippled to enable MultiSign ## - -Add the following to the bottom of the config file: +You can test multi-signing by running `rippled` in [stand-alone mode](concept-stand-alone-mode.html) with the Multi-Sign feature enabled. To enable Multi-Sign for testing, add the following stanza to your `rippled.cfg`: [features] MultiSign -Note that this stanza is case-sensitive. -## 3. Start rippled in stand-alone mode ## +How to Multi-Sign +=============================================================================== -If you have previously synced to the network, you can have the server load the latest ledger as a starting place for stand-alone mode using the `--load` commandline option: +The basic process of Multi-Signing a transaction is necessarily more complex than the process of signing a transaction with a single master key or regular key. - $ sudo ./build/rippled --conf=/home/mduo13/.config/ripple/rippled.cfg -a --load +## 1. (Optional) Generate keys for a new wallet ## -If you'd rather start from scratch, you can use the `--start` commandline option to create a fresh ledger. In this case, the root account holds all 100 billion XRP: +This step is not strictly necessary. For this process, we generate and fund a new Ripple account and then set up multi-signing for that account. To set up multi-signing on an existing Ripple account, skip ahead to [Step 4: creating a signer list](4-create-a-signerlist-on-the-new-account-with-a-signerlistset-transaction). -**Address:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` - -**Secret:** `snoPBrXtMeMyMHUVTgbuqAfg1SUTb` ("masterpassphrase") - - -## 4. Generate keys for a new wallet ## - -This step is not strictly necessary. For this process, we generate and fund a new Ripple account and then set up multi-signing for that account. To set up multi-signing on an existing Ripple account, skip ahead to [Step 7: creating a signer list](#7-create-a-signerlist-on-the-account-with-a-signerlistset-transaction). - - $ build/rippled wallet_propose + $ rippled wallet_propose Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 { @@ -79,11 +48,11 @@ This step is not strictly necessary. For this process, we generate and fund a ne As always, be sure that an account's secret key never gets transmitted to anyone you don't trust with full control of that account, and certainly not unencrypted over the network. -## 5. Fund the new account with an existing wallet ## +## 2. Fund the new account with an existing wallet ## Again, this step is only necessary if you are setting up a new account to use multi-signing for this example. - $ build/rippled submit '{ + $ rippled submit '{ > "TransactionType" : "Payment", > "Account" : "", > "Destination" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", @@ -115,14 +84,13 @@ Again, this step is only necessary if you are setting up a new account to use mu } -## 6. Manually close the ledger ## +## 3. Close the ledger ## -In the live network, you would simply wait for the ledger to close -automatically as the result of consensus. However, a rippled node running in -stand-alone mode does not engage in consensus, so you must manually close the -ledger with the [`ledger_accept` command](rippled-apis.html#ledger-accept). +If you are using the live network, you can wait for the ledger to close automatically as the result of consensus. This typically takes 4-7 seconds. - $ build/rippled ledger_accept +If you are running `rippled` in stand-alone mode, you must manually close the ledger with the [`ledger_accept` command](reference-rippled.html#ledger-accept). + + $ rippled ledger_accept Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 { @@ -133,13 +101,13 @@ ledger with the [`ledger_accept` command](rippled-apis.html#ledger-accept). } -## 7. Create a SignerList on the new account with a SignerListSet transaction ## +## 4. Create a SignerList on the new account with a SignerListSet transaction ## -Before you can multi-sign transactions, you must associate a SignerList with your account, so that RCL knows which keys can be used to sign for you. You do this with a [SignerListSet transaction](transactions.html#signerlistset). +Before you can multi-sign transactions, you must associate a SignerList with your account, so that RCL knows which keys can be used to sign for you. You do this with a [SignerListSet transaction](reference-transaction-format.html#signerlistset). In this example, the SignerList has 3 members, with the weights and quorum set up such that multi-signed transactions need a signature from rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other two members of the list. The `Account` values you use in your list can be funded accounts that exist in the ledger or just unused addresses. - $ build/rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{ + $ rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{ > "Flags": 0, > "TransactionType": "SignerListSet", > "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", @@ -210,11 +178,13 @@ In this example, the SignerList has 3 members, with the weights and quorum set u } -## 8. Manually close the ledger again ## +## 5. Close the ledger again ## -As before, you would wait for the ledger to close on a live network. We use the [`ledger_accept` command](reference-rippled.html#ledger-accept) to manually close the ledger when running `rippled` in stand-alone mode. +As before, on the live network, you can wait for the ledger to close automatically. - $ build/rippled ledger_accept +If running `rippled` in stand-alone mode, use the [`ledger_accept` command](reference-rippled.html#ledger-accept) to manually close the ledger: + + $ rippled ledger_accept Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 { @@ -225,11 +195,11 @@ As before, you would wait for the ledger to close on a live network. We use the } -## 9. Confirm the presence of the new signer list using account_objects ## +## 6. Confirm the presence of the new signer list using account_objects ## Normally an account has lots of different types of objects, but for this new account, the only thing we've done is add a SignerList, so it should be easy to find in the results of the [`account_objects` command](reference-rippled.html#account-objects). - $ build/rippled account_objects rnBFvgZphmN39GWzUJeUitaP22Fr9be75H + $ rippled account_objects rnBFvgZphmN39GWzUJeUitaP22Fr9be75H Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 { @@ -274,8 +244,7 @@ Normally an account has lots of different types of objects, but for this new acc } -10. Create a new transaction that you plan to multi-sign ------------------------------------------------------------------ +## 7. Create a new transaction that you plan to multi-sign ## You have to specify _everything_ about this transaction, including `Fee` and `Sequence`. Also include the field `SigningPubKey` as an empty string -- this @@ -307,9 +276,9 @@ it sometimes takes a while to collect signatures from multiple sources, you may want to include additional buffer in case the load fee increases in that time. -## 11. Get a signature using the sign_for command ## +## 8. Get a signature using the sign_for command ## - $ build/rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW '{ + $ rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW '{ > "TransactionType": "TrustSet", > "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", > "Flags": 262144, @@ -359,11 +328,11 @@ The valuable part in the response is the `Signers` field. This is the part that The other parts, such as the `tx_blob`, are not very useful at this point, unless you're "multi-signing" a transaction with only one signature. -## 12. Get additional signatures the same way ## +## 9. Get additional signatures the same way ## If the accounts in your SignerList are funded accounts, the secret key you use to sign for those accounts can come from the regular key (if they have one), or the master key (unless it's disabled). For accounts that don't exist in the ledger, you can only use the master secret associated with the address. - $ build/rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v '{ + $ rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v '{ "TransactionType": "TrustSet", "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", "Flags": 262144, @@ -411,14 +380,13 @@ If the accounts in your SignerList are funded accounts, the secret key you use t Depending on the SignerList you configured, you may need to repeat this step several times in order to get signatures from all the necessary parties. -13. Combine the signatures and submit ------------------------------------------------------------------ +## 10. Combine the signatures and submit ## Take the contents of all the `Signers` arrays from all the responses, and concatenate them in to a single `Signers` array field. The commandline syntax for the [`submit_multisigned` command](reference-rippled.html#submit-multisigned) takes a single JSON object with two elements: this combined `Signers` array; and `tx_json`, which is the transaction JSON that they signed. This command actually submits the transaction for inclusion in the ledger. In online mode, this relays it to other members of the network. - $ build/rippled submit_multisigned ' { + $ rippled submit_multisigned ' { > "Signers": [ > { > "Signer" : { @@ -494,13 +462,13 @@ This command actually submits the transaction for inclusion in the ledger. In on Take note of the `hash` value from the response (In this case, it's `878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78`) so you can check the results of the transaction later. -## 14. Manually close the ledger one last time ## +## 14. Close the ledger one last time ## -Once again, you would wait for the ledger to close on a live network. We use -the [`ledger_accept` command](reference-rippled.html#ledger-accept) to manually -close the ledger when running `rippled` in stand-alone mode. +As before, on the live network, you can wait 4-7 seconds for the ledger to close automatically. - $ build/rippled ledger_accept +If running `rippled` in stand-alone mode, use the [`ledger_accept` command](reference-rippled.html#ledger-accept) to manually close the ledger: + + $ rippled ledger_accept Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 { @@ -515,7 +483,7 @@ close the ledger when running `rippled` in stand-alone mode. Use the hash value from the response to the `submit_multisigned` command. - $ build/rippled tx 878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78 + $ rippled tx 878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78 Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 { @@ -638,8 +606,6 @@ Use the hash value from the response to the `submit_multisigned` command. In particular, check that the `TransactionResult` is the string `tesSUCCESS`. -On the live network, you must also confirm that the `validated` field is set to -the boolean `true`. If not, you might need to wait longer for the consensus -process to finish; or your transaction may be unable to be included in a ledger -for some reason. In stand-alone mode, the server automatically considers a -ledger to be `validated` if it has been manually closed. +On the live network, you must also confirm that the `validated` field is set to the boolean `true`. If the field is not `true`, you might need to wait longer for the consensus process to finish; or your transaction may be unable to be included in a ledger for some reason. + +In stand-alone mode, the server automatically considers a ledger to be `validated` if it has been manually closed. diff --git a/data-api-v2-tool.html b/data-api-v2-tool.html index d0a712c2de..26bc275e0c 100644 --- a/data-api-v2-tool.html +++ b/data-api-v2-tool.html @@ -60,6 +60,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • diff --git a/index.html b/index.html index 58ac4c14cd..c3d088bf1f 100644 --- a/index.html +++ b/index.html @@ -67,6 +67,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • @@ -153,6 +154,7 @@ Ripple’s distributed settlement network is built on open-source technology tha
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
    • diff --git a/reference-data-api.html b/reference-data-api.html index f3073eb5af..4c32a369c0 100644 --- a/reference-data-api.html +++ b/reference-data-api.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • diff --git a/reference-ledger-format.html b/reference-ledger-format.html index 05ac9bfa47..a8c8207562 100644 --- a/reference-ledger-format.html +++ b/reference-ledger-format.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • diff --git a/reference-rippleapi.html b/reference-rippleapi.html index aa0bc9d37c..b275d4f15d 100644 --- a/reference-rippleapi.html +++ b/reference-rippleapi.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • diff --git a/reference-rippled.html b/reference-rippled.html index a719b036ce..814a405814 100644 --- a/reference-rippled.html +++ b/reference-rippled.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • diff --git a/reference-transaction-format.html b/reference-transaction-format.html index bd5150a04f..0d5b611f51 100644 --- a/reference-transaction-format.html +++ b/reference-transaction-format.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • diff --git a/ripple-api-tool.html b/ripple-api-tool.html index 9c056723df..a747aca3f8 100644 --- a/ripple-api-tool.html +++ b/ripple-api-tool.html @@ -60,6 +60,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • diff --git a/tool-jsonrpc.html b/tool-jsonrpc.html index b10b94e614..442c28d2a8 100644 --- a/tool-jsonrpc.html +++ b/tool-jsonrpc.html @@ -60,6 +60,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • diff --git a/tool/dactyl-config.yml b/tool/dactyl-config.yml index 1a3d154f25..15441eebbc 100644 --- a/tool/dactyl-config.yml +++ b/tool/dactyl-config.yml @@ -172,6 +172,13 @@ pages: ripple.com: https://wiki.ripple.com/Understanding:_Feature_adoption sidebar: true + - name: Stand-Alone Mode + category: Concepts + html: concept-stand-alone-mode.html + md: concept-stand-alone-mode.md + ripple.com: https://wiki.ripple.com/Rippled#--standalone.2C_-a + sidebar: true + # "Best Practices" documents are mostly in the same category as tutorials - name: Issuing and Operational Addresses category: Best Practices diff --git a/tutorial-gateway-guide.html b/tutorial-gateway-guide.html index dca7beb6b3..573c8373f0 100644 --- a/tutorial-gateway-guide.html +++ b/tutorial-gateway-guide.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • diff --git a/tutorial-multisign.html b/tutorial-multisign.html index 212bdc7553..c39d9b0ffd 100644 --- a/tutorial-multisign.html +++ b/tutorial-multisign.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • @@ -126,11 +127,7 @@

    Introduction to Multi-Signing

    -

    Multi-signing in Ripple is the act of authorizing transactions for the Ripple -Consensus Ledger by using a combination of multiple secret keys. After setting -up multi-signing for an account, you can put the master secret in cold storage, -or even disable the master key entirely. With multiple secret keys required to -authorize a multi-signature, you can improve security in several ways.

    +

    Multi-signing in Ripple is the act of authorizing transactions for the Ripple Consensus Ledger by using a combination of multiple secret keys. After setting up multi-signing for an account, you can put the master secret in cold storage, or even disable the master key entirely. With multiple secret keys required to authorize a multi-signature, you can improve security in several ways.

    • If you keep an account's keys on different devices, a malicious user must compromise multiple machines in order to send transactions on your behalf.
    • If the keys to an account are in the custody of entirely different people, those people must collaborate in order to send transaction from that account.
      • @@ -138,48 +135,16 @@ authorize a multi-signature, you can improve security in several ways.

    • Even more uses than can be described here.

    Availability of Multi-Signing

    -

    Multi-signing is due to be enabled by an Amendment to the Ripple Consensus -Protocol. This Amendment must be approved by a consensus of validators showing -consistent support for the feature over a period of time. For more information, -see Amendments (TODO: link).

    -

    You can test multi-signing by running rippled in stand-alone mode with the -feature enabled. In stand-alone mode, rippled does not communicate with the -rest of the Ripple peer-to-peer network, but you can perform most of the same -actions on your local server only. This way, you can be sure that you are ready -for multi-signing when it goes live.

    -

    How to Multi-Sign

    -

    The basic process of Multi-Signing a transaction is necessarily more -complex than the process of signing a transaction with a single master key or -regular key.

    -

    1. Download and build rippled with multi-sign

    -

    Until a binary for rippled with multi-signing is available, the best you can do is build it from source.

    -
    $ git clone git@github.com:scottschurr/rippled.git (TODO: switch to a Ripple Labs repo when available)
-$ git checkout fix-sign_for
-$ scons
-
    -

    See rippled build instructions for help building from source.

    -

    2. Configure rippled to enable MultiSign

    -

    Add the following to the bottom of the config file:

    +

    Multi-signing is built into rippled starting with version 0.31.0. Because multi-signing is a change in transaction processing, the change is due to be enabled by an Amendment to the Ripple Consensus Protocol. This Amendment must be approved by a consensus of validators showing consistent support for the feature over a period of time. For more information, see Amendments.

    +

    You can test multi-signing by running rippled in stand-alone mode with the Multi-Sign feature enabled. To enable Multi-Sign for testing, add the following stanza to your rippled.cfg:

    [features]
 MultiSign
    -

    Note that this stanza is case-sensitive.

    -

    3. Start rippled in stand-alone mode

    -

    If you have previously synced to the network, you can have the server load the -latest ledger as a starting place for stand-alone mode using the --load -commandline option:

    -
    $ sudo ./build/rippled --conf=/home/mduo13/.config/ripple/rippled.cfg -a --load
-
    -

    If you'd rather start from scratch, you can use the --start commandline -option to create a fresh ledger. In this case, the root account holds all -100 billion XRP:

    -

    Address: rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh

    -

    Secret: snoPBrXtMeMyMHUVTgbuqAfg1SUTb ("masterpassphrase")

    -

    4. Generate keys for a new wallet

    -

    This step is not strictly necessary. For this process, we generate the keys to -a new Ripple account and then set up multi-signing for that account. To set up -multi-signing on an existing Ripple account, just use the keys to that account.

    -
    $ build/rippled wallet_propose
+
    How to Multi-Sign
    
+
    The basic process of Multi-Signing a transaction is necessarily more complex than the process of signing a transaction with a single master key or regular key.
    
+
    1. (Optional) Generate keys for a new wallet
    
+
    This step is not strictly necessary. For this process, we generate and fund a new Ripple account and then set up multi-signing for that account. To set up multi-signing on an existing Ripple account, skip ahead to Step 4: creating a signer list.
    
+
    $ rippled wallet_propose
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
 {
@@ -195,13 +160,10 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    As always, be sure that an account's secret key never gets transmitted to 
-anyone you don't trust with full control of that account, and certainly not 
-unencrypted over the network.
    
-
    5. Fund the new account with an existing wallet
    
-
    Again, this step is only necessary if you are setting up a new account to use 
-multi-signing for this example.
    
-
    $ build/rippled submit <your existing account secret> '{
+
    As always, be sure that an account's secret key never gets transmitted to anyone you don't trust with full control of that account, and certainly not unencrypted over the network.
    
+
    2. Fund the new account with an existing wallet
    
+
    Again, this step is only necessary if you are setting up a new account to use multi-signing for this example.
    
+
    $ rippled submit <your existing account secret> '{
 >   "TransactionType" : "Payment",
 >   "Account" : "<your existing account address>",
 >   "Destination" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
@@ -232,12 +194,10 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    6. Manually close the ledger
    
-
    In the live network, you would simply wait for the ledger to close 
-automatically as the result of consensus. However, a rippled node running in 
-stand-alone mode does not engage in consensus, so you must manually close the 
-ledger with the ledger_accept command.
    
-
    $ build/rippled ledger_accept
+
    3. Close the ledger
    
+
    If you are using the live network, you can wait for the ledger to close automatically as the result of consensus. This typically takes 4-7 seconds.
    
+
    If you are running rippled in stand-alone mode, you must manually close the ledger with the ledger_accept command.
    
+
    $ rippled ledger_accept
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
 {
@@ -247,16 +207,10 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    7. Create a SignerList on the new account with a SignerListSet transaction
    
-
    Before you can multi-sign transactions, you must associate a SignerList with 
-your account, so that RCL knows which keys can be used to sign for you. You do 
-this with a SignerListSet transaction.
    
-
    In this example, the SignerList has 3 members, with the weights and quorum set 
-up such that multi-signed transactions need a signature from 
-rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other 
-two members of the list. The Account values you use in your list can be 
-funded accounts that exist in the ledger or just unused addresses.
    
-
    $ build/rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{
+
    4. Create a SignerList on the new account with a SignerListSet transaction
    
+
    Before you can multi-sign transactions, you must associate a SignerList with your account, so that RCL knows which keys can be used to sign for you. You do this with a SignerListSet transaction.
    
+
    In this example, the SignerList has 3 members, with the weights and quorum set up such that multi-signed transactions need a signature from rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other two members of the list. The Account values you use in your list can be funded accounts that exist in the ledger or just unused addresses.
    
+
    $ rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{
 >     "Flags": 0,
 >     "TransactionType": "SignerListSet",
 >     "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
@@ -326,11 +280,10 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    8. Manually close the ledger again
    
-
    As before, you would wait for the ledger to close on a live network. We use 
-the ledger_accept command to manually 
-close the ledger when running rippled in stand-alone mode.
    
-
    $ build/rippled ledger_accept
+
    5. Close the ledger again
    
+
    As before, on the live network, you can wait for the ledger to close automatically.
    
+
    If running rippled in stand-alone mode, use the ledger_accept command to manually close the ledger:
    
+
    $ rippled ledger_accept
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
 {
@@ -340,12 +293,9 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    9. Confirm the presence of the new signer list using account_objects
    
-
    Normally an account has lots of different types of objects, but for this new 
-account, the only thing we've done is add a SignerList, so it should be easy to 
-find in the results of the 
-account_objects command.
    
-
    $ build/rippled account_objects rnBFvgZphmN39GWzUJeUitaP22Fr9be75H
+
    6. Confirm the presence of the new signer list using account_objects
    
+
    Normally an account has lots of different types of objects, but for this new account, the only thing we've done is add a SignerList, so it should be easy to find in the results of the account_objects command.
    
+
    $ rippled account_objects rnBFvgZphmN39GWzUJeUitaP22Fr9be75H
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
 {
@@ -389,9 +339,9 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    10. Create a new transaction that you plan to multi-sign
    
-
    You have to specify everything about this transaction, including Fee and 
-Sequence. Also include the field SigningPubKey as an empty string -- this
+
    7. Create a new transaction that you plan to multi-sign
    
+
    You have to specify everything about this transaction, including Fee and
+Sequence. Also include the field SigningPubKey as an empty string -- this
 indicates that the transaction is multi-signed.
    
 
    Here's an example transaction we can send from our test account:
    
 
    {
@@ -408,15 +358,15 @@ indicates that the transaction is multi-signed.
    
     "Fee": "12000"
 }
 
    
-
    (If you started from a fresh ledger, you first need to fund the account 
+
    (If you started from a fresh ledger, you first need to fund the account
 specified by the issuer in this example, and then manually close the ledger.)
    
-
    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 
+
    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 fee, 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 load fee increases in that time.
    
-
    11. Get a signature using the sign_for command
    
-
    $ build/rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW <rsA2's secret> '{
+
    8. Get a signature using the sign_for command
    
+
    $ rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW <rsA2's secret> '{
 >     "TransactionType": "TrustSet",
 >     "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
 >     "Flags": 262144,
@@ -461,17 +411,11 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    The valuable part in the response is the Signers field. This is the part that 
-you're going to need later in order to construct the full, multi-signed 
-transaction.
    
-
    The other parts, such as the tx_blob, are not very useful at this point, 
-unless you're "multi-signing" a transaction with only one signature.
    
-
    12. Get additional signatures the same way
    
-
    If the accounts in your SignerList are funded accounts, the secret key you use 
-to sign for those accounts can come from the regular key (if they have one), or 
-the master key (unless it's disabled). For accounts that don't exist in the 
-ledger, you can only use the master secret associated with the address.
    
-
    $ build/rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v <rUpy's secret> '{
+
    The valuable part in the response is the Signers field. This is the part that you're going to need later in order to construct the full, multi-signed transaction.
    
+
    The other parts, such as the tx_blob, are not very useful at this point, unless you're "multi-signing" a transaction with only one signature.
    
+
    9. Get additional signatures the same way
    
+
    If the accounts in your SignerList are funded accounts, the secret key you use to sign for those accounts can come from the regular key (if they have one), or the master key (unless it's disabled). For accounts that don't exist in the ledger, you can only use the master secret associated with the address.
    
+
    $ rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v <rUpy's secret> '{
     "TransactionType": "TrustSet",
     "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
     "Flags": 262144,
@@ -516,17 +460,11 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    Depending on the SignerList you configured, you may need to repeat this step
-several times in order to get signatures from all the necessary parties.
    
-
    13. Combine the signatures and submit
    
-
    Take the contents of all the Signers arrays from all the responses, and 
-concatenate them in to a single Signers array field. The commandline syntax 
-for the submit_multisigned command 
-takes a single JSON object with two elements: this combined Signers array; 
-and tx_json, which is the transaction JSON that they signed.
    
-
    This command actually submits the transaction for inclusion in the ledger. In 
-online mode, this relays it to other members of the network.
    
-
    $ build/rippled submit_multisigned '    {
+
    Depending on the SignerList you configured, you may need to repeat this step several times in order to get signatures from all the necessary parties.
    
+
    10. Combine the signatures and submit
    
+
    Take the contents of all the Signers arrays from all the responses, and concatenate them in to a single Signers array field. The commandline syntax for the submit_multisigned command takes a single JSON object with two elements: this combined Signers array; and tx_json, which is the transaction JSON that they signed.
    
+
    This command actually submits the transaction for inclusion in the ledger. In online mode, this relays it to other members of the network.
    
+
    $ rippled submit_multisigned '    {
 >         "Signers": [
 >             {
 >                 "Signer" : {
@@ -599,14 +537,11 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    Take note of the hash value from the response (In this case, it's
-878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78) so you can 
-check the results of the transaction later.
    
-
    14. Manually close the ledger one last time
    
-
    Once again, you would wait for the ledger to close on a live network. We use 
-the ledger_accept command to manually 
-close the ledger when running rippled in stand-alone mode.
    
-
    $ build/rippled ledger_accept
+
    Take note of the hash value from the response (In this case, it's 878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78) so you can check the results of the transaction later.
    
+
    14. Close the ledger one last time
    
+
    As before, on the live network, you can wait 4-7 seconds for the ledger to close automatically.
    
+
    If running rippled in stand-alone mode, use the ledger_accept command to manually close the ledger:
    
+
    $ rippled ledger_accept
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
 {
@@ -618,7 +553,7 @@ Connecting to 127.0.0.1:5005
 
    
 
    15. Confirm the results of the transaction
    
 
    Use the hash value from the response to the submit_multisigned command.
    
-
    $ build/rippled tx 878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78
+
    $ rippled tx 878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
 {
@@ -739,12 +674,9 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    In particular, check that the TransactionResult is the string tesSUCCESS. 
    
-
    On the live network, you must also confirm that the validated field is set to 
-the boolean true. If not, you might need to wait longer for the consensus 
-process to finish; or your transaction may be unable to be included in a ledger 
-for some reason. In stand-alone mode, the server automatically considers a 
-ledger to be validated if it has been manually closed.
    
+
    In particular, check that the TransactionResult is the string tesSUCCESS.
    
+
    On the live network, you must also confirm that the validated field is set to the boolean true. If the field is not true, you might need to wait longer for the consensus process to finish; or your transaction may be unable to be included in a ledger for some reason.
    
+
    In stand-alone mode, the server automatically considers a ledger to be validated if it has been manually closed.
    • diff --git a/tutorial-reliable-transaction-submission.html b/tutorial-reliable-transaction-submission.html index a70b478382..5d528f8201 100644 --- a/tutorial-reliable-transaction-submission.html +++ b/tutorial-reliable-transaction-submission.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • diff --git a/tutorial-rippleapi-beginners-guide.html b/tutorial-rippleapi-beginners-guide.html index b6883e0dc5..1d7625718e 100644 --- a/tutorial-rippleapi-beginners-guide.html +++ b/tutorial-rippleapi-beginners-guide.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • diff --git a/tutorial-rippled-setup.html b/tutorial-rippled-setup.html index 8d71922483..bb8f52b4ac 100644 --- a/tutorial-rippled-setup.html +++ b/tutorial-rippled-setup.html @@ -74,6 +74,7 @@
  • Reserves
  • Freeze
  • Amendments
    • +
  • Stand-Alone Mode
  • From 499faf6ea1316a3a144457981424f92bab74638a Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Thu, 24 Mar 2016 17:48:55 -0700 Subject: [PATCH 13/40] rippled multisign - updated tutorial to new response formats, more details; standalonemode gotchas --- concept-stand-alone-mode.html | 1 + content/concept-stand-alone-mode.md | 2 + content/tutorial-multisign.md | 621 +++++++++++++++------------- tutorial-multisign.html | 592 +++++++++++++------------- 4 files changed, 633 insertions(+), 583 deletions(-) diff --git a/concept-stand-alone-mode.html b/concept-stand-alone-mode.html index 5740eaf662..2a57a14c06 100644 --- a/concept-stand-alone-mode.html +++ b/concept-stand-alone-mode.html @@ -149,6 +149,7 @@

    In a genesis ledger, the genesis account holds all 100 billion XRP. The keys of the genesis account are hardcoded as follows:

    Address: rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh

    Secret: snoPBrXtMeMyMHUVTgbuqAfg1SUTb ("masterpassphrase")

    +

    Caution: If you create a new genesis ledger, the hard-coded default Reserve is 200 XRP minimum for an account, with an increment of 50 XRP per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: Fee Voting)

    Load Saved Ledger

    You can start with a ledger version that was saved to disk if your rippled server was previously synced with the Ripple peer-to-peer network (either the production network or the Test Net).

    1. To retrieve existing ledgers, start rippled normally:

    diff --git a/content/concept-stand-alone-mode.md b/content/concept-stand-alone-mode.md index 3b8bf2b21f..654e72ef1b 100644 --- a/content/concept-stand-alone-mode.md +++ b/content/concept-stand-alone-mode.md @@ -26,6 +26,8 @@ In a genesis ledger, the [genesis account](reference-rippled.html#special-addres **Secret:** `snoPBrXtMeMyMHUVTgbuqAfg1SUTb` ("masterpassphrase") +**Caution:** If you create a new genesis ledger, the hard-coded default [Reserve](concept-reserves.html) is **200 XRP** minimum for an account, with an increment of **50 XRP** per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: [Fee Voting](concept-fee-voting.html)) + Load Saved Ledger ------------------------------------------------------------------------------- diff --git a/content/tutorial-multisign.md b/content/tutorial-multisign.md index 8207f3e372..3182adb01c 100644 --- a/content/tutorial-multisign.md +++ b/content/tutorial-multisign.md @@ -34,17 +34,18 @@ This step is not strictly necessary. For this process, we generate and fund a ne Connecting to 127.0.0.1:5005 { "result" : { - "account_id" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "account_id" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", "key_type" : "secp256k1", - "master_key" : "NED MANA SPA BLUR HERS HEAT RED NIBS MAIN MELT NOB RARE", - "master_seed" : "shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq", - "master_seed_hex" : "99C7F2DCD88218372B7509ADF7DC562B", - "public_key" : "aBPvx491i2ZPVzmxoAmAVq5qXAxAZgmjfxoMTxFCg9Xxf2xwVVLc", - "public_key_hex" : "0303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D", + "master_key" : "LOST FOUR ALOE ABE SLUG ITS HACK MAGI SOCK BASS APE DELL", + "master_seed" : "sn1CmMEkPijNrfyr8HJqsgP416dr3", + "master_seed_hex" : "E42AD02985BB56923DFC1D002DB510B3", + "public_key" : "aBQgQDutj8YUc7ZRtfj86dnzPCvPcRHtUszxeCCDMgZ7Zq1Thfri", + "public_key_hex" : "03668837C3DCA0F4858587703524E61BB40128B9F6910B80B4655E152CAEE2E321", "status" : "success" } } + As always, be sure that an account's secret key never gets transmitted to anyone you don't trust with full control of that account, and certainly not unencrypted over the network. @@ -52,12 +53,12 @@ As always, be sure that an account's secret key never gets transmitted to anyone Again, this step is only necessary if you are setting up a new account to use multi-signing for this example. - $ rippled submit '{ - > "TransactionType" : "Payment", - > "Account" : "", - > "Destination" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", - > "Amount" : "100000000", - > "Flags": 2147483648 + $ rippled submit snoPBrXtMeMyMHUVTgbuqAfg1SUTb '{ + > "TransactionType": "Payment", + > "Account": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + > "Destination": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + > "Amount": "100000000", + > "Flags": 2147483648 > }' Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 @@ -67,23 +68,25 @@ Again, this step is only necessary if you are setting up a new account to use mu "engine_result_code" : 0, "engine_result_message" : "The transaction was applied. Only final in a validated ledger.", "status" : "success", - "tx_blob" : "1200002280000000240000001E614000000005F5E10068400000000000000A7321023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC67446304402207AB5D16F58E9E6ADBBDD24837CAB80D871860E47EB0840FE57403FB979755A6D022015FE7A8838BEE6C18962C246D6D27791B7EE34B93415AE3824D12564E7A886C6811493B89AFCAD4C8EAC2B131C1331FEF12AE1522BBE83142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1", + "tx_blob" : "12000022800000002400000004614000000005F5E10068400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100ED13CDD4B8F6BA836F7732A029316393A5D9B50712FE79972236ECAD850F813802203148D8944B0BF3D30A3177EFCE6A9F12B3F5A3C3AFF7B73E9A7D65B370E526EE8114B5F762798A53D543A014CAF8B297CFF8F2F937E88314A3780F5CB5A44D366520FC44055E8ED44D9A2270", "tx_json" : { - "Account" : "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH", + "Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "Amount" : "100000000", - "Destination" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "Destination" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", "Fee" : "10", "Flags" : 2147483648, - "Sequence" : 30, - "SigningPubKey" : "023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6", + "Sequence" : 4, + "SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020", "TransactionType" : "Payment", - "TxnSignature" : "304402207AB5D16F58E9E6ADBBDD24837CAB80D871860E47EB0840FE57403FB979755A6D022015FE7A8838BEE6C18962C246D6D27791B7EE34B93415AE3824D12564E7A886C6", - "hash" : "8C7A4D35D71CE80DA4EDAC91D620B6A348B7691B78AA2896284135378E10E0C2" + "TxnSignature" : "3045022100ED13CDD4B8F6BA836F7732A029316393A5D9B50712FE79972236ECAD850F813802203148D8944B0BF3D30A3177EFCE6A9F12B3F5A3C3AFF7B73E9A7D65B370E526EE", + "hash" : "64FAA44F671E2CBB4E1E4156FCDA72BA3C32EF951C94EDDFEBEBE8BEC3F55696" } } } +Make sure that the `engine_result` value in the response is **tesSUCCESS**. Otherwise, the transaction failed. + ## 3. Close the ledger ## If you are using the live network, you can wait for the ledger to close automatically as the result of consensus. This typically takes 4-7 seconds. @@ -105,7 +108,9 @@ If you are running `rippled` in stand-alone mode, you must manually close the le Before you can multi-sign transactions, you must associate a SignerList with your account, so that RCL knows which keys can be used to sign for you. You do this with a [SignerListSet transaction](reference-transaction-format.html#signerlistset). -In this example, the SignerList has 3 members, with the weights and quorum set up such that multi-signed transactions need a signature from rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other two members of the list. The `Account` values you use in your list can be funded accounts that exist in the ledger or just unused addresses. +The `Account` values in your SignerList can be the addresses of funded accounts that exist in the ledger, or you can generate new addresses that are not currently in use. For funded accounts in the SignerList, a regular key associated with the account can contribute to a multi-signature, and the master key secret can be used only if it is not disabled. For unfunded addresses, only the master key associated with that address can be used to contribute to a multi-signature. + +In this example, the SignerList has 3 members, with the weights and quorum set up such that multi-signed transactions need a signature from rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other two members of the list. $ rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{ > "Flags": 0, @@ -177,6 +182,7 @@ In this example, the SignerList has 3 members, with the weights and quorum set u } } +Make sure that the `engine_result` value in the response is **tesSUCCESS**. Otherwise, the transaction failed. ## 5. Close the ledger again ## @@ -189,7 +195,7 @@ If running `rippled` in stand-alone mode, use the [`ledger_accept` command](refe Connecting to 127.0.0.1:5005 { "result" : { - "ledger_current_index" : 16061438, + "ledger_current_index" : 6, "status" : "success" } } @@ -197,21 +203,21 @@ If running `rippled` in stand-alone mode, use the [`ledger_accept` command](refe ## 6. Confirm the presence of the new signer list using account_objects ## -Normally an account has lots of different types of objects, but for this new account, the only thing we've done is add a SignerList, so it should be easy to find in the results of the [`account_objects` command](reference-rippled.html#account-objects). +Normally an account can own many objects of different types (such as trust lines and offers). For this tutorial, we created a new account, so the SignerList is the only object in the response from the [`account_objects` command](reference-rippled.html#account-objects). - $ rippled account_objects rnBFvgZphmN39GWzUJeUitaP22Fr9be75H + $ rippled account_objects rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC validated Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 { "result" : { - "account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", "account_objects" : [ { "Flags" : 0, "LedgerEntryType" : "SignerList", "OwnerNode" : "0000000000000000", - "PreviousTxnID" : "3950D98AD20DA52EBB1F3937EF32F382D74092A4C8DF9A0B1A06ED25200B5756", - "PreviousTxnLgrSeq" : 16061437, + "PreviousTxnID" : "8FDC18960455C196A8C4DE0D24799209A21F4A17E32102B5162BD79466B90222", + "PreviousTxnLgrSeq" : 5, "SignerEntries" : [ { "SignerEntry" : { @@ -234,16 +240,42 @@ Normally an account has lots of different types of objects, but for this new acc ], "SignerListID" : 0, "SignerQuorum" : 3, - "index" : "92373B9F1683001079764527F0BD553ED8656A9934FE641A7F0A0BF4DB230E0E" + "index" : "79FD203E4DDDF2EA78B798C963487120C048C78652A28682425E47C96D016F92" + }, + { + "Balance" : { + "currency" : "USD", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2162688, + "HighLimit" : { + "currency" : "USD", + "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "value" : "0" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "USD", + "issuer" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "value" : "100" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6", + "PreviousTxnLgrSeq" : 6, + "index" : "93E317B32022977C77810A2C558FBB28E30E744C68E73720622B797F957EC5FA" } ], - "ledger_current_index" : 16061438, + "ledger_hash" : "56E81069F06492FB410A70218C08169BE3AB3CFD5AEA20E999662D81DC361D9F", + "ledger_index" : 5, "status" : "success", - "validated" : false + "validated" : true } } + ## 7. Create a new transaction that you plan to multi-sign ## You have to specify _everything_ about this transaction, including `Fee` and @@ -263,7 +295,7 @@ Here's an example transaction we can send from our test account: }, "Sequence": 2, "SigningPubKey":"", - "Fee": "12000" + "Fee": "30000" } (If you started from a fresh ledger, you first need to fund the account @@ -276,103 +308,110 @@ it sometimes takes a while to collect signatures from multiple sources, you may want to include additional buffer in case the load fee increases in that time. -## 8. Get a signature using the sign_for command ## +## 8. Get one signature ## - $ rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW '{ - > "TransactionType": "TrustSet", - > "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", - > "Flags": 262144, - > "LimitAmount": { - > "currency": "USD", - > "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", - > "value": "100" - > }, - > "Sequence": 2, - > "SigningPubKey":"", - > "Fee": "12000" +The [`sign_for` command](reference-rippled.html#sign-for) takes an address and related secret, and a transaction in JSON form. It generates a signature for that transaction, using the secret key and address specified. By using this, you can provide signatures that contribute to a multi-signed transaction. (The signatures should come from the members of your SignerList.) + + $ rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW '{ "TransactionType": "TrustSet", "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", "Flags": 262144, "LimitAmount": { "currency": "USD", "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "value": "100" }, "Sequence": 2, "SigningPubKey":"", "Fee": "30000" }' + Loading: "/home/mduo13/.config/ripple/rippled.cfg" + Connecting to 127.0.0.1:5005 + { + "result" : { + "status" : "success", + "tx_blob" : "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1F1", + "tx_json" : { + "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "Fee" : "30000", + "Flags" : 262144, + "LimitAmount" : { + "currency" : "USD", + "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "value" : "100" + }, + "Sequence" : 2, + "Signers" : [ + { + "Signer" : { + "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + "TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5" + } + } + ], + "SigningPubKey" : "", + "TransactionType" : "TrustSet", + "hash" : "A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE" + } + } + } + +Save the `tx_json` field of the response: it has the new signature in the `Signers` field. + +The `tx_blob` is not very useful at this point, unless you're "multi-signing" a transaction with only one signature. + + +## 9. Get additional signatures the same way ## + +You can collect additional signatures for the same transaction in parallel by using the `sign_for` command with the same transaction JSON. You can also collect additional signatures in serial: if you provide the `tx_json` value from a previous `sign_for` response, the response appends a signature to the existing Signers array. + + $ rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v '{ + > "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + > "Fee" : "30000", + > "Flags" : 262144, + > "LimitAmount" : { + > "currency" : "USD", + > "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + > "value" : "100" + > }, + > "Sequence" : 2, + > "Signers" : [ + > { + > "Signer" : { + > "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + > "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + > "TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5" + > } + > } + > ], + > "SigningPubKey" : "", + > "TransactionType" : "TrustSet", + > "hash" : "A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE" > }' Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 { "result" : { - "Signers" : [ - { - "Signer" : { - "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", - "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", - "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE" - } - } - ], "status" : "success", - "tx_blob" : "1200142200040000240000000263D5038D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA9684000000000002EE0730081142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1", + "tx_blob" : "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1E0107321028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B744630440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1F1", "tx_json" : { - "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", - "Fee" : "12000", + "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "Fee" : "30000", "Flags" : 262144, "LimitAmount" : { "currency" : "USD", - "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "value" : "100" }, "Sequence" : 2, - "SigningPubKey" : "", - "TransactionType" : "TrustSet", - "hash" : "4622B2893AF3A70B4DB1FF86B25C10E92B71973895143E66029567A8541A8060" - } - } - } - -The valuable part in the response is the `Signers` field. This is the part that you're going to need later in order to construct the full, multi-signed transaction. - -The other parts, such as the `tx_blob`, are not very useful at this point, unless you're "multi-signing" a transaction with only one signature. - - -## 9. Get additional signatures the same way ## - -If the accounts in your SignerList are funded accounts, the secret key you use to sign for those accounts can come from the regular key (if they have one), or the master key (unless it's disabled). For accounts that don't exist in the ledger, you can only use the master secret associated with the address. - - $ rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v '{ - "TransactionType": "TrustSet", - "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", - "Flags": 262144, - "LimitAmount": { - "currency": "USD", - "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", - "value": "100" - }, - "Sequence": 2, - "SigningPubKey":"", - "Fee": "12000" - }' - Loading: "/home/mduo13/.config/ripple/rippled.cfg" - Connecting to 127.0.0.1:5005 - { - "result" : { - "Signers" : [ - { - "Signer" : { - "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", - "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B", - "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1" + "Signers" : [ + { + "Signer" : { + "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + "TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5" + } + }, + { + "Signer" : { + "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B", + "TxnSignature" : "30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1" + } } - } - ], - "status" : "success", - "tx_blob" : "1200142200040000240000000263D5038D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA9684000000000002EE0730081142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1", - "tx_json" : { - "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", - "Fee" : "12000", - "Flags" : 262144, - "LimitAmount" : { - "currency" : "USD", - "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", - "value" : "100" - }, - "Sequence" : 2, + ], "SigningPubKey" : "", "TransactionType" : "TrustSet", - "hash" : "4622B2893AF3A70B4DB1FF86B25C10E92B71973895143E66029567A8541A8060" + "hash" : "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6" } } } @@ -382,84 +421,81 @@ Depending on the SignerList you configured, you may need to repeat this step sev ## 10. Combine the signatures and submit ## -Take the contents of all the `Signers` arrays from all the responses, and concatenate them in to a single `Signers` array field. The commandline syntax for the [`submit_multisigned` command](reference-rippled.html#submit-multisigned) takes a single JSON object with two elements: this combined `Signers` array; and `tx_json`, which is the transaction JSON that they signed. +The commandline syntax for the [`submit_multisigned` command](reference-rippled.html#submit-multisigned) takes a single transaction JSON containing a `Signers` array, so you need to combine all the signatures from the all the responses into a single `Signers` array field with all the signatures. If you collected signatures serially, the `tx_json` from the last response is sufficient. -This command actually submits the transaction for inclusion in the ledger. In online mode, this relays it to other members of the network. +The `submit_multisigned` command actually submits the transaction for inclusion in the ledger. In online mode, this also relays it to other members of the network. - $ rippled submit_multisigned ' { - > "Signers": [ - > { - > "Signer" : { - > "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", - > "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B", - > "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1" + $ rippled submit_multisigned '{ + > "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + > "Fee" : "30000", + > "Flags" : 262144, + > "LimitAmount" : { + > "currency" : "USD", + > "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + > "value" : "100" + > }, + > "Sequence" : 2, + > "Signers" : [ + > { + > "Signer" : { + > "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + > "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + > "TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5" + > } + > }, + > { + > "Signer" : { + > "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + > "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B", + > "TxnSignature" : "30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1" + > } > } - > }, - > { - > "Signer" : { - > "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", - > "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", - > "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE" - > } - > } - > ], - > "tx_json": { - > "TransactionType": "TrustSet", - > "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", - > "Flags": 262144, - > "LimitAmount": { - > "currency": "USD", - > "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", - > "value": "100" - > }, - > "Sequence": 2, - > "SigningPubKey":"", - > "Fee": "12000" - > } - > }' + > ], + > "SigningPubKey" : "", + > "TransactionType" : "TrustSet", + > "hash" : "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6" + > }' Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 { - "result" : { - "engine_result" : "tesSUCCESS", - "engine_result_code" : 0, - "engine_result_message" : "The transaction was applied. Only final in a validated ledger.", - "status" : "success", - "tx_blob" : "1200142200040000240000000263D5038D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA9684000000000002EE0730081142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF7447304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE8114204288D2E47F8EF6C99BCC457966320D12409711E1E0107321028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B7446304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1F1", - "tx_json" : { - "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", - "Fee" : "12000", - "Flags" : 262144, - "LimitAmount" : { - "currency" : "USD", - "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", - "value" : "100" - }, - "Sequence" : 2, - "Signers" : [ - { - "Signer" : { - "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", - "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", - "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE" - } - }, - { - "Signer" : { - "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", - "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B", - "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1" - } - } - ], - "SigningPubKey" : "", - "TransactionType" : "TrustSet", - "hash" : "878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78" - } - } + "result": { + "engine_result": "tesSUCCESS", + "engine_result_code": 0, + "engine_result_message": "The transaction was applied. Only final in a validated ledger.", + "status": "success", + "tx_blob": "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1E0107321028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B744630440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1F1", + "tx_json": { + "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "Fee": "30000", + "Flags": 262144, + "LimitAmount": { + "currency": "USD", + "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "value": "100" + }, + "Sequence": 2, + "Signers": [{ + "Signer": { + "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + "TxnSignature": "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5" + } + }, { + "Signer": { + "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + "SigningPubKey": "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B", + "TxnSignature": "30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1" + } + }], + "SigningPubKey": "", + "TransactionType": "TrustSet", + "hash": "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6" + } + } } -Take note of the `hash` value from the response (In this case, it's `878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78`) so you can check the results of the transaction later. + +Take note of the `hash` value from the response so you can check the results of the transaction later. (In this case, the hash is `BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6`.) ## 14. Close the ledger one last time ## @@ -473,7 +509,7 @@ If running `rippled` in stand-alone mode, use the [`ledger_accept` command](refe Connecting to 127.0.0.1:5005 { "result" : { - "ledger_current_index" : 16061439, + "ledger_current_index" : 7, "status" : "success" } } @@ -483,127 +519,118 @@ If running `rippled` in stand-alone mode, use the [`ledger_accept` command](refe Use the hash value from the response to the `submit_multisigned` command. - $ rippled tx 878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78 + $ rippled tx BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6 Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 { - "result" : { - "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", - "Fee" : "12000", - "Flags" : 262144, - "LimitAmount" : { - "currency" : "USD", - "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", - "value" : "100" - }, - "Sequence" : 2, - "Signers" : [ - { - "Signer" : { - "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", - "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", - "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE" - } - }, - { - "Signer" : { - "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", - "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B", - "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1" - } - } - ], - "SigningPubKey" : "", - "TransactionType" : "TrustSet", - "date" : 496881900, - "hash" : "878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78", - "inLedger" : 16061438, - "ledger_index" : 16061438, - "meta" : { - "AffectedNodes" : [ - { - "ModifiedNode" : { - "LedgerEntryType" : "AccountRoot", - "LedgerIndex" : "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8", - "PreviousTxnID" : "6ECC8C16B76D9B9AB099CA96DD653D8A321C34F1E5972D5EE6DBA19418F4D0CC", - "PreviousTxnLgrSeq" : 16061436 - } - }, - { - "ModifiedNode" : { - "FinalFields" : { - "Flags" : 0, - "Owner" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", - "RootIndex" : "3B9C0CE77FCE7BCEE1A68F1E26AC467AF326239D0D816CE705E4A0E2DAD03F6D" - }, - "LedgerEntryType" : "DirectoryNode", - "LedgerIndex" : "3B9C0CE77FCE7BCEE1A68F1E26AC467AF326239D0D816CE705E4A0E2DAD03F6D" - } - }, - { - "CreatedNode" : { - "LedgerEntryType" : "RippleState", - "LedgerIndex" : "3C75A1F3DB61406AC2A9493038E8394A73F103C9229695AC7E57EB0F8AFC69E4", - "NewFields" : { - "Balance" : { - "currency" : "USD", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 65536, - "HighLimit" : { - "currency" : "USD", - "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", - "value" : "0" - }, - "LowLimit" : { - "currency" : "USD", - "issuer" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", - "value" : "100" - } - } - } - }, - { - "ModifiedNode" : { - "FinalFields" : { - "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", - "Balance" : "109978000", - "Flags" : 0, - "OwnerCount" : 6, - "Sequence" : 3 - }, - "LedgerEntryType" : "AccountRoot", - "LedgerIndex" : "3D728C1F82CFE419F2DC58707D1AD06E985A29217D21A991ADF154184B664F4F", - "PreviousFields" : { - "Balance" : "109990000", - "OwnerCount" : 5, - "Sequence" : 2 - }, - "PreviousTxnID" : "3950D98AD20DA52EBB1F3937EF32F382D74092A4C8DF9A0B1A06ED25200B5756", - "PreviousTxnLgrSeq" : 16061437 - } - }, - { - "ModifiedNode" : { - "FinalFields" : { - "Flags" : 0, - "Owner" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", - "RootIndex" : "95DA402B4D58FBFF6BAA4CB84BBC21348CC273949B61FEBCE758410EF90D147D" - }, - "LedgerEntryType" : "DirectoryNode", - "LedgerIndex" : "95DA402B4D58FBFF6BAA4CB84BBC21348CC273949B61FEBCE758410EF90D147D" - } - } - ], - "TransactionIndex" : 0, - "TransactionResult" : "tesSUCCESS" - }, - "status" : "success", - "validated" : true - } + "result": { + "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "Fee": "30000", + "Flags": 262144, + "LimitAmount": { + "currency": "USD", + "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "value": "100" + }, + "Sequence": 2, + "Signers": [{ + "Signer": { + "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + "TxnSignature": "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5" + } + }, { + "Signer": { + "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + "SigningPubKey": "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B", + "TxnSignature": "30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1" + } + }], + "SigningPubKey": "", + "TransactionType": "TrustSet", + "date": 512172510, + "hash": "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6", + "inLedger": 6, + "ledger_index": 6, + "meta": { + "AffectedNodes": [{ + "ModifiedNode": { + "LedgerEntryType": "AccountRoot", + "LedgerIndex": "2B6AC232AA4C4BE41BF49D2459FA4A0347E1B543A4C92FCEE0821C0201E2E9A8", + "PreviousTxnID": "B7E1D33DB7DEA3BB65BFAB2C80E02125F47FCCF6C957A7FDECD915B3EBE0C1DD", + "PreviousTxnLgrSeq": 4 + } + }, { + "CreatedNode": { + "LedgerEntryType": "RippleState", + "LedgerIndex": "93E317B32022977C77810A2C558FBB28E30E744C68E73720622B797F957EC5FA", + "NewFields": { + "Balance": { + "currency": "USD", + "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value": "0" + }, + "Flags": 2162688, + "HighLimit": { + "currency": "USD", + "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "value": "0" + }, + "LowLimit": { + "currency": "USD", + "issuer": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "value": "100" + } + } + } + }, { + "ModifiedNode": { + "FinalFields": { + "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "Balance": "999960000", + "Flags": 0, + "OwnerCount": 6, + "Sequence": 3 + }, + "LedgerEntryType": "AccountRoot", + "LedgerIndex": "A6B1BA6F2D70813100908EA84ABB7783695050312735E2C3665259F388804EA0", + "PreviousFields": { + "Balance": "999990000", + "OwnerCount": 5, + "Sequence": 2 + }, + "PreviousTxnID": "8FDC18960455C196A8C4DE0D24799209A21F4A17E32102B5162BD79466B90222", + "PreviousTxnLgrSeq": 5 + } + }, { + "ModifiedNode": { + "FinalFields": { + "Flags": 0, + "Owner": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "RootIndex": "C2728175908D82FB1DE6676F203D8D3C056995A9FA9B369EF326523F1C65A1DE" + }, + "LedgerEntryType": "DirectoryNode", + "LedgerIndex": "C2728175908D82FB1DE6676F203D8D3C056995A9FA9B369EF326523F1C65A1DE" + } + }, { + "CreatedNode": { + "LedgerEntryType": "DirectoryNode", + "LedgerIndex": "D8120FC732737A2CF2E9968FDF3797A43B457F2A81AA06D2653171A1EA635204", + "NewFields": { + "Owner": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "RootIndex": "D8120FC732737A2CF2E9968FDF3797A43B457F2A81AA06D2653171A1EA635204" + } + } + }], + "TransactionIndex": 0, + "TransactionResult": "tesSUCCESS" + }, + "status": "success", + "validated": true + } } + In particular, check that the `TransactionResult` is the string `tesSUCCESS`. On the live network, you must also confirm that the `validated` field is set to the boolean `true`. If the field is not `true`, you might need to wait longer for the consensus process to finish; or your transaction may be unable to be included in a ledger for some reason. diff --git a/tutorial-multisign.html b/tutorial-multisign.html index c39d9b0ffd..19e760bae1 100644 --- a/tutorial-multisign.html +++ b/tutorial-multisign.html @@ -149,13 +149,13 @@ Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 { "result" : { - "account_id" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "account_id" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", "key_type" : "secp256k1", - "master_key" : "NED MANA SPA BLUR HERS HEAT RED NIBS MAIN MELT NOB RARE", - "master_seed" : "shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq", - "master_seed_hex" : "99C7F2DCD88218372B7509ADF7DC562B", - "public_key" : "aBPvx491i2ZPVzmxoAmAVq5qXAxAZgmjfxoMTxFCg9Xxf2xwVVLc", - "public_key_hex" : "0303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D", + "master_key" : "LOST FOUR ALOE ABE SLUG ITS HACK MAGI SOCK BASS APE DELL", + "master_seed" : "sn1CmMEkPijNrfyr8HJqsgP416dr3", + "master_seed_hex" : "E42AD02985BB56923DFC1D002DB510B3", + "public_key" : "aBQgQDutj8YUc7ZRtfj86dnzPCvPcRHtUszxeCCDMgZ7Zq1Thfri", + "public_key_hex" : "03668837C3DCA0F4858587703524E61BB40128B9F6910B80B4655E152CAEE2E321", "status" : "success" } } @@ -163,12 +163,12 @@ Connecting to 127.0.0.1:5005

    As always, be sure that an account's secret key never gets transmitted to anyone you don't trust with full control of that account, and certainly not unencrypted over the network.

    2. Fund the new account with an existing wallet

    Again, this step is only necessary if you are setting up a new account to use multi-signing for this example.

    -
    $ rippled submit <your existing account secret> '{
->   "TransactionType" : "Payment",
->   "Account" : "<your existing account address>",
->   "Destination" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
->   "Amount" : "100000000",
->   "Flags": 2147483648
+
    $ rippled submit snoPBrXtMeMyMHUVTgbuqAfg1SUTb '{
+> "TransactionType": "Payment",
+> "Account": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+> "Destination": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+> "Amount": "100000000",
+> "Flags": 2147483648
 > }'
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
@@ -178,22 +178,23 @@ Connecting to 127.0.0.1:5005
       "engine_result_code" : 0,
       "engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
       "status" : "success",
-      "tx_blob" : "1200002280000000240000001E614000000005F5E10068400000000000000A7321023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC67446304402207AB5D16F58E9E6ADBBDD24837CAB80D871860E47EB0840FE57403FB979755A6D022015FE7A8838BEE6C18962C246D6D27791B7EE34B93415AE3824D12564E7A886C6811493B89AFCAD4C8EAC2B131C1331FEF12AE1522BBE83142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1",
+      "tx_blob" : "12000022800000002400000004614000000005F5E10068400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100ED13CDD4B8F6BA836F7732A029316393A5D9B50712FE79972236ECAD850F813802203148D8944B0BF3D30A3177EFCE6A9F12B3F5A3C3AFF7B73E9A7D65B370E526EE8114B5F762798A53D543A014CAF8B297CFF8F2F937E88314A3780F5CB5A44D366520FC44055E8ED44D9A2270",
       "tx_json" : {
-         "Account" : "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
+         "Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
          "Amount" : "100000000",
-         "Destination" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+         "Destination" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
          "Fee" : "10",
          "Flags" : 2147483648,
-         "Sequence" : 30,
-         "SigningPubKey" : "023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6",
+         "Sequence" : 4,
+         "SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
          "TransactionType" : "Payment",
-         "TxnSignature" : "304402207AB5D16F58E9E6ADBBDD24837CAB80D871860E47EB0840FE57403FB979755A6D022015FE7A8838BEE6C18962C246D6D27791B7EE34B93415AE3824D12564E7A886C6",
-         "hash" : "8C7A4D35D71CE80DA4EDAC91D620B6A348B7691B78AA2896284135378E10E0C2"
+         "TxnSignature" : "3045022100ED13CDD4B8F6BA836F7732A029316393A5D9B50712FE79972236ECAD850F813802203148D8944B0BF3D30A3177EFCE6A9F12B3F5A3C3AFF7B73E9A7D65B370E526EE",
+         "hash" : "64FAA44F671E2CBB4E1E4156FCDA72BA3C32EF951C94EDDFEBEBE8BEC3F55696"
       }
    }
 }
 
    
+
    Make sure that the engine_result value in the response is tesSUCCESS. Otherwise, the transaction failed.
    
 
    3. Close the ledger
    
 
    If you are using the live network, you can wait for the ledger to close automatically as the result of consensus. This typically takes 4-7 seconds.
    
 
    If you are running rippled in stand-alone mode, you must manually close the ledger with the ledger_accept command.
    
@@ -209,7 +210,8 @@ Connecting to 127.0.0.1:5005

    4. Create a SignerList on the new account with a SignerListSet transaction

    Before you can multi-sign transactions, you must associate a SignerList with your account, so that RCL knows which keys can be used to sign for you. You do this with a SignerListSet transaction.

    -

    In this example, the SignerList has 3 members, with the weights and quorum set up such that multi-signed transactions need a signature from rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other two members of the list. The Account values you use in your list can be funded accounts that exist in the ledger or just unused addresses.

    +

    The Account values in your SignerList can be the addresses of funded accounts that exist in the ledger, or you can generate new addresses that are not currently in use. For funded accounts in the SignerList, a regular key associated with the account can contribute to a multi-signature, and the master key secret can be used only if it is not disabled. For unfunded addresses, only the master key associated with that address can be used to contribute to a multi-signature.

    +

    In this example, the SignerList has 3 members, with the weights and quorum set up such that multi-signed transactions need a signature from rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other two members of the list.

    $ rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{
 >     "Flags": 0,
 >     "TransactionType": "SignerListSet",
@@ -280,6 +282,7 @@ Connecting to 127.0.0.1:5005
    }
 }
    +

    Make sure that the engine_result value in the response is tesSUCCESS. Otherwise, the transaction failed.

    5. Close the ledger again

    As before, on the live network, you can wait for the ledger to close automatically.

    If running rippled in stand-alone mode, use the ledger_accept command to manually close the ledger:

    @@ -288,26 +291,26 @@ Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 { "result" : { - "ledger_current_index" : 16061438, + "ledger_current_index" : 6, "status" : "success" } }

    6. Confirm the presence of the new signer list using account_objects

    -

    Normally an account has lots of different types of objects, but for this new account, the only thing we've done is add a SignerList, so it should be easy to find in the results of the account_objects command.

    -
    $ rippled account_objects rnBFvgZphmN39GWzUJeUitaP22Fr9be75H
+
    Normally an account can own many objects of different types (such as trust lines and offers). For this tutorial, we created a new account, so the SignerList is the only object in the response from the account_objects command.
    
+
    $ rippled account_objects rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC validated
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
 {
    "result" : {
-      "account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+      "account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
       "account_objects" : [
          {
             "Flags" : 0,
             "LedgerEntryType" : "SignerList",
             "OwnerNode" : "0000000000000000",
-            "PreviousTxnID" : "3950D98AD20DA52EBB1F3937EF32F382D74092A4C8DF9A0B1A06ED25200B5756",
-            "PreviousTxnLgrSeq" : 16061437,
+            "PreviousTxnID" : "8FDC18960455C196A8C4DE0D24799209A21F4A17E32102B5162BD79466B90222",
+            "PreviousTxnLgrSeq" : 5,
             "SignerEntries" : [
                {
                   "SignerEntry" : {
@@ -330,12 +333,37 @@ Connecting to 127.0.0.1:5005
             ],
             "SignerListID" : 0,
             "SignerQuorum" : 3,
-            "index" : "92373B9F1683001079764527F0BD553ED8656A9934FE641A7F0A0BF4DB230E0E"
+            "index" : "79FD203E4DDDF2EA78B798C963487120C048C78652A28682425E47C96D016F92"
+         },
+         {
+            "Balance" : {
+               "currency" : "USD",
+               "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+               "value" : "0"
+            },
+            "Flags" : 2162688,
+            "HighLimit" : {
+               "currency" : "USD",
+               "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+               "value" : "0"
+            },
+            "HighNode" : "0000000000000000",
+            "LedgerEntryType" : "RippleState",
+            "LowLimit" : {
+               "currency" : "USD",
+               "issuer" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+               "value" : "100"
+            },
+            "LowNode" : "0000000000000000",
+            "PreviousTxnID" : "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6",
+            "PreviousTxnLgrSeq" : 6,
+            "index" : "93E317B32022977C77810A2C558FBB28E30E744C68E73720622B797F957EC5FA"
          }
       ],
-      "ledger_current_index" : 16061438,
+      "ledger_hash" : "56E81069F06492FB410A70218C08169BE3AB3CFD5AEA20E999662D81DC361D9F",
+      "ledger_index" : 5,
       "status" : "success",
-      "validated" : false
+      "validated" : true
    }
 }
 
    
@@ -355,7 +383,7 @@ indicates that the transaction is multi-signed.
    
     },
     "Sequence": 2,
     "SigningPubKey":"",
-    "Fee": "12000"
+    "Fee": "30000"
 }

    (If you started from a fresh ledger, you first need to fund the account @@ -365,152 +393,22 @@ higher than for regularly-signed transactions. It should be (N+1) times the normal fee, 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 load fee increases in that time.

    -

    8. Get a signature using the sign_for command

    -
    $ rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW <rsA2's secret> '{
->     "TransactionType": "TrustSet",
->     "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
->     "Flags": 262144,
->     "LimitAmount": {
->       "currency": "USD",
->       "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
->       "value": "100"
->     },
->     "Sequence": 2,
->     "SigningPubKey":"",
->     "Fee": "12000"
-> }'
+
    8. Get one signature
    
+
    The sign_for command takes an address and related secret, and a transaction in JSON form. It generates a signature for that transaction, using the secret key and address specified. By using this, you can provide signatures that contribute to a multi-signed transaction. (The signatures should come from the members of your SignerList.)
    
+
    $ rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW <rsA2L..'s secret> '{ "TransactionType": "TrustSet", "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", "Flags": 262144, "LimitAmount": { "currency": "USD", "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "value": "100" }, "Sequence": 2, "SigningPubKey":"", "Fee": "30000" }'
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
 {
    "result" : {
-      "Signers" : [
-         {
-            "Signer" : {
-               "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
-               "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
-               "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE"
-            }
-         }
-      ],
       "status" : "success",
-      "tx_blob" : "1200142200040000240000000263D5038D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA9684000000000002EE0730081142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1",
+      "tx_blob" : "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1F1",
       "tx_json" : {
-         "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
-         "Fee" : "12000",
+         "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+         "Fee" : "30000",
          "Flags" : 262144,
          "LimitAmount" : {
             "currency" : "USD",
-            "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
-            "value" : "100"
-         },
-         "Sequence" : 2,
-         "SigningPubKey" : "",
-         "TransactionType" : "TrustSet",
-         "hash" : "4622B2893AF3A70B4DB1FF86B25C10E92B71973895143E66029567A8541A8060"
-      }
-   }
-}
-
    
-
    The valuable part in the response is the Signers field. This is the part that you're going to need later in order to construct the full, multi-signed transaction.
    
-
    The other parts, such as the tx_blob, are not very useful at this point, unless you're "multi-signing" a transaction with only one signature.
    
-
    9. Get additional signatures the same way
    
-
    If the accounts in your SignerList are funded accounts, the secret key you use to sign for those accounts can come from the regular key (if they have one), or the master key (unless it's disabled). For accounts that don't exist in the ledger, you can only use the master secret associated with the address.
    
-
    $ rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v <rUpy's secret> '{
-    "TransactionType": "TrustSet",
-    "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
-    "Flags": 262144,
-    "LimitAmount": {
-      "currency": "USD",
-      "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
-      "value": "100"
-    },            
-    "Sequence": 2,
-    "SigningPubKey":"",
-    "Fee": "12000"
-}'
-Loading: "/home/mduo13/.config/ripple/rippled.cfg"
-Connecting to 127.0.0.1:5005
-{
-   "result" : {
-      "Signers" : [
-         {
-            "Signer" : {
-               "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
-               "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
-               "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1"
-            }
-         }
-      ],
-      "status" : "success",
-      "tx_blob" : "1200142200040000240000000263D5038D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA9684000000000002EE0730081142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1",
-      "tx_json" : {
-         "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
-         "Fee" : "12000",
-         "Flags" : 262144,
-         "LimitAmount" : {
-            "currency" : "USD",
-            "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
-            "value" : "100"
-         },
-         "Sequence" : 2,
-         "SigningPubKey" : "",
-         "TransactionType" : "TrustSet",
-         "hash" : "4622B2893AF3A70B4DB1FF86B25C10E92B71973895143E66029567A8541A8060"
-      }
-   }
-}
-
    
-
    Depending on the SignerList you configured, you may need to repeat this step several times in order to get signatures from all the necessary parties.
    
-
    10. Combine the signatures and submit
    
-
    Take the contents of all the Signers arrays from all the responses, and concatenate them in to a single Signers array field. The commandline syntax for the submit_multisigned command takes a single JSON object with two elements: this combined Signers array; and tx_json, which is the transaction JSON that they signed.
    
-
    This command actually submits the transaction for inclusion in the ledger. In online mode, this relays it to other members of the network.
    
-
    $ rippled submit_multisigned '    {
->         "Signers": [
->             {
->                 "Signer" : {
->                    "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
->                    "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
->                    "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1"
->                 }
->             },
->             {
->                 "Signer" : {
->                    "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
->                    "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
->                    "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE"
->                 }
->             }
->         ],
->         "tx_json": {
->             "TransactionType": "TrustSet",
->             "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
->             "Flags": 262144,
->             "LimitAmount": {
->               "currency": "USD",
->               "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
->               "value": "100"
->             },
->             "Sequence": 2,
->             "SigningPubKey":"",
->             "Fee": "12000"
->         }
->     }'
-Loading: "/home/mduo13/.config/ripple/rippled.cfg"
-Connecting to 127.0.0.1:5005
-{
-   "result" : {
-      "engine_result" : "tesSUCCESS",
-      "engine_result_code" : 0,
-      "engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
-      "status" : "success",
-      "tx_blob" : "1200142200040000240000000263D5038D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA9684000000000002EE0730081142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF7447304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE8114204288D2E47F8EF6C99BCC457966320D12409711E1E0107321028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B7446304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1F1",
-      "tx_json" : {
-         "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
-         "Fee" : "12000",
-         "Flags" : 262144,
-         "LimitAmount" : {
-            "currency" : "USD",
-            "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+            "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
             "value" : "100"
          },
          "Sequence" : 2,
@@ -519,25 +417,157 @@ Connecting to 127.0.0.1:5005
                "Signer" : {
                   "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
                   "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
-                  "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE"
+                  "TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
+               }
+            }
+         ],
+         "SigningPubKey" : "",
+         "TransactionType" : "TrustSet",
+         "hash" : "A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE"
+      }
+   }
+}
+
    
+
    Save the tx_json field of the response: it has the new signature in the Signers field.
    
+
    The tx_blob is not very useful at this point, unless you're "multi-signing" a transaction with only one signature.
    
+
    9. Get additional signatures the same way
    
+
    You can collect additional signatures for the same transaction in parallel by using the sign_for command with the same transaction JSON. You can also collect additional signatures in serial: if you provide the tx_json value from a previous sign_for response, the response appends a signature to the existing Signers array.
    
+
    $ rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v <rUpy..'s secret> '{
+>    "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+>    "Fee" : "30000",
+>    "Flags" : 262144,
+>    "LimitAmount" : {
+>       "currency" : "USD",
+>       "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+>       "value" : "100"
+>    },
+>    "Sequence" : 2,
+>    "Signers" : [
+>       {
+>          "Signer" : {
+>             "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+>             "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+>             "TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
+>          }
+>       }
+>    ],
+>    "SigningPubKey" : "",
+>    "TransactionType" : "TrustSet",
+>    "hash" : "A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE"
+> }'
+Loading: "/home/mduo13/.config/ripple/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "status" : "success",
+      "tx_blob" : "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1E0107321028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B744630440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1F1",
+      "tx_json" : {
+         "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+         "Fee" : "30000",
+         "Flags" : 262144,
+         "LimitAmount" : {
+            "currency" : "USD",
+            "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+            "value" : "100"
+         },
+         "Sequence" : 2,
+         "Signers" : [
+            {
+               "Signer" : {
+                  "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                  "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+                  "TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
                }
             },
             {
                "Signer" : {
                   "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
                   "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
-                  "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1"
+                  "TxnSignature" : "30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1"
                }
             }
          ],
          "SigningPubKey" : "",
          "TransactionType" : "TrustSet",
-         "hash" : "878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78"
+         "hash" : "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6"
       }
    }
 }
 
    
-
    Take note of the hash value from the response (In this case, it's 878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78) so you can check the results of the transaction later.
    
+
    Depending on the SignerList you configured, you may need to repeat this step several times in order to get signatures from all the necessary parties.
    
+
    10. Combine the signatures and submit
    
+
    The commandline syntax for the submit_multisigned command takes a single transaction JSON containing a Signers array, so you need to combine all the signatures from the all the responses into a single Signers array field with all the signatures. If you collected signatures serially, the tx_json from the last response is sufficient.
    
+
    The submit_multisigned command actually submits the transaction for inclusion in the ledger. In online mode, this also relays it to other members of the network.
    
+
    $ rippled submit_multisigned '{
+>              "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+>              "Fee" : "30000",
+>              "Flags" : 262144,
+>              "LimitAmount" : {
+>                 "currency" : "USD",
+>                 "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+>                 "value" : "100"
+>              },
+>              "Sequence" : 2,
+>              "Signers" : [
+>                 {
+>                    "Signer" : {
+>                       "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+>                       "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+>                       "TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
+>                    }
+>                 },
+>                 {
+>                    "Signer" : {
+>                       "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+>                       "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
+>                       "TxnSignature" : "30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1"
+>                    }
+>                 }
+>              ],
+>              "SigningPubKey" : "",
+>              "TransactionType" : "TrustSet",
+>              "hash" : "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6"
+>           }'
+Loading: "/home/mduo13/.config/ripple/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+    "result": {
+        "engine_result": "tesSUCCESS",
+        "engine_result_code": 0,
+        "engine_result_message": "The transaction was applied. Only final in a validated ledger.",
+        "status": "success",
+        "tx_blob": "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1E0107321028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B744630440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1F1",
+        "tx_json": {
+            "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+            "Fee": "30000",
+            "Flags": 262144,
+            "LimitAmount": {
+                "currency": "USD",
+                "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+                "value": "100"
+            },
+            "Sequence": 2,
+            "Signers": [{
+                "Signer": {
+                    "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                    "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+                    "TxnSignature": "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
+                }
+            }, {
+                "Signer": {
+                    "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+                    "SigningPubKey": "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
+                    "TxnSignature": "30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1"
+                }
+            }],
+            "SigningPubKey": "",
+            "TransactionType": "TrustSet",
+            "hash": "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6"
+        }
+    }
+}
+
    
+
    Take note of the hash value from the response so you can check the results of the transaction later.  (In this case, the hash is BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6.)
    
 
    14. Close the ledger one last time
    
 
    As before, on the live network, you can wait 4-7 seconds for the ledger to close automatically.
    
 
    If running rippled in stand-alone mode, use the ledger_accept command to manually close the ledger:
    
@@ -546,132 +576,122 @@ Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
 {
    "result" : {
-      "ledger_current_index" : 16061439,
+      "ledger_current_index" : 7,
       "status" : "success"
    }
 }

    15. Confirm the results of the transaction

    Use the hash value from the response to the submit_multisigned command.

    -
    $ rippled tx 878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78
+
    $ rippled tx BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
 {
-   "result" : {
-      "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
-      "Fee" : "12000",
-      "Flags" : 262144,
-      "LimitAmount" : {
-         "currency" : "USD",
-         "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
-         "value" : "100"
-      },
-      "Sequence" : 2,
-      "Signers" : [
-         {
-            "Signer" : {
-               "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
-               "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
-               "TxnSignature" : "304502210093EED0F75190385282C6369EE3C5C0FCC65227917F545EC8848B94E17105BC3D022073B3FB14452056FF8E966736150E2D75F3B7460AD7DEF6E2932ECD6690B6C3FE"
+    "result": {
+        "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+        "Fee": "30000",
+        "Flags": 262144,
+        "LimitAmount": {
+            "currency": "USD",
+            "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+            "value": "100"
+        },
+        "Sequence": 2,
+        "Signers": [{
+            "Signer": {
+                "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+                "TxnSignature": "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
             }
-         },
-         {
-            "Signer" : {
-               "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
-               "SigningPubKey" : "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
-               "TxnSignature" : "304402204C1A4FFE1628A4BBEA4E8BEDE7C7080B94299704207479D1334096721629DB9802206BB07EBAB23EA288D5714CF7D3231D041BBB2AFD973D24ED693197C4881DC2E1"
+        }, {
+            "Signer": {
+                "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+                "SigningPubKey": "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
+                "TxnSignature": "30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1"
             }
-         }
-      ],
-      "SigningPubKey" : "",
-      "TransactionType" : "TrustSet",
-      "date" : 496881900,
-      "hash" : "878C1C988305D87070F3E961FC27AC9D02C46FFDD92FC7EBB74E962344E58C78",
-      "inLedger" : 16061438,
-      "ledger_index" : 16061438,
-      "meta" : {
-         "AffectedNodes" : [
-            {
-               "ModifiedNode" : {
-                  "LedgerEntryType" : "AccountRoot",
-                  "LedgerIndex" : "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
-                  "PreviousTxnID" : "6ECC8C16B76D9B9AB099CA96DD653D8A321C34F1E5972D5EE6DBA19418F4D0CC",
-                  "PreviousTxnLgrSeq" : 16061436
-               }
-            },
-            {
-               "ModifiedNode" : {
-                  "FinalFields" : {
-                     "Flags" : 0,
-                     "Owner" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
-                     "RootIndex" : "3B9C0CE77FCE7BCEE1A68F1E26AC467AF326239D0D816CE705E4A0E2DAD03F6D"
-                  },
-                  "LedgerEntryType" : "DirectoryNode",
-                  "LedgerIndex" : "3B9C0CE77FCE7BCEE1A68F1E26AC467AF326239D0D816CE705E4A0E2DAD03F6D"
-               }
-            },
-            {
-               "CreatedNode" : {
-                  "LedgerEntryType" : "RippleState",
-                  "LedgerIndex" : "3C75A1F3DB61406AC2A9493038E8394A73F103C9229695AC7E57EB0F8AFC69E4",
-                  "NewFields" : {
-                     "Balance" : {
-                        "currency" : "USD",
-                        "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
-                        "value" : "0"
-                     },
-                     "Flags" : 65536,
-                     "HighLimit" : {
-                        "currency" : "USD",
-                        "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
-                        "value" : "0"
-                     },
-                     "LowLimit" : {
-                        "currency" : "USD",
-                        "issuer" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
-                        "value" : "100"
-                     }
-                  }
-               }
-            },
-            {
-               "ModifiedNode" : {
-                  "FinalFields" : {
-                     "Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
-                     "Balance" : "109978000",
-                     "Flags" : 0,
-                     "OwnerCount" : 6,
-                     "Sequence" : 3
-                  },
-                  "LedgerEntryType" : "AccountRoot",
-                  "LedgerIndex" : "3D728C1F82CFE419F2DC58707D1AD06E985A29217D21A991ADF154184B664F4F",
-                  "PreviousFields" : {
-                     "Balance" : "109990000",
-                     "OwnerCount" : 5,
-                     "Sequence" : 2
-                  },
-                  "PreviousTxnID" : "3950D98AD20DA52EBB1F3937EF32F382D74092A4C8DF9A0B1A06ED25200B5756",
-                  "PreviousTxnLgrSeq" : 16061437
-               }
-            },
-            {
-               "ModifiedNode" : {
-                  "FinalFields" : {
-                     "Flags" : 0,
-                     "Owner" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
-                     "RootIndex" : "95DA402B4D58FBFF6BAA4CB84BBC21348CC273949B61FEBCE758410EF90D147D"
-                  },
-                  "LedgerEntryType" : "DirectoryNode",
-                  "LedgerIndex" : "95DA402B4D58FBFF6BAA4CB84BBC21348CC273949B61FEBCE758410EF90D147D"
-               }
-            }
-         ],
-         "TransactionIndex" : 0,
-         "TransactionResult" : "tesSUCCESS"
-      },
-      "status" : "success",
-      "validated" : true
-   }
+        }],
+        "SigningPubKey": "",
+        "TransactionType": "TrustSet",
+        "date": 512172510,
+        "hash": "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6",
+        "inLedger": 6,
+        "ledger_index": 6,
+        "meta": {
+            "AffectedNodes": [{
+                "ModifiedNode": {
+                    "LedgerEntryType": "AccountRoot",
+                    "LedgerIndex": "2B6AC232AA4C4BE41BF49D2459FA4A0347E1B543A4C92FCEE0821C0201E2E9A8",
+                    "PreviousTxnID": "B7E1D33DB7DEA3BB65BFAB2C80E02125F47FCCF6C957A7FDECD915B3EBE0C1DD",
+                    "PreviousTxnLgrSeq": 4
+                }
+            }, {
+                "CreatedNode": {
+                    "LedgerEntryType": "RippleState",
+                    "LedgerIndex": "93E317B32022977C77810A2C558FBB28E30E744C68E73720622B797F957EC5FA",
+                    "NewFields": {
+                        "Balance": {
+                            "currency": "USD",
+                            "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
+                            "value": "0"
+                        },
+                        "Flags": 2162688,
+                        "HighLimit": {
+                            "currency": "USD",
+                            "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+                            "value": "0"
+                        },
+                        "LowLimit": {
+                            "currency": "USD",
+                            "issuer": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+                            "value": "100"
+                        }
+                    }
+                }
+            }, {
+                "ModifiedNode": {
+                    "FinalFields": {
+                        "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+                        "Balance": "999960000",
+                        "Flags": 0,
+                        "OwnerCount": 6,
+                        "Sequence": 3
+                    },
+                    "LedgerEntryType": "AccountRoot",
+                    "LedgerIndex": "A6B1BA6F2D70813100908EA84ABB7783695050312735E2C3665259F388804EA0",
+                    "PreviousFields": {
+                        "Balance": "999990000",
+                        "OwnerCount": 5,
+                        "Sequence": 2
+                    },
+                    "PreviousTxnID": "8FDC18960455C196A8C4DE0D24799209A21F4A17E32102B5162BD79466B90222",
+                    "PreviousTxnLgrSeq": 5
+                }
+            }, {
+                "ModifiedNode": {
+                    "FinalFields": {
+                        "Flags": 0,
+                        "Owner": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+                        "RootIndex": "C2728175908D82FB1DE6676F203D8D3C056995A9FA9B369EF326523F1C65A1DE"
+                    },
+                    "LedgerEntryType": "DirectoryNode",
+                    "LedgerIndex": "C2728175908D82FB1DE6676F203D8D3C056995A9FA9B369EF326523F1C65A1DE"
+                }
+            }, {
+                "CreatedNode": {
+                    "LedgerEntryType": "DirectoryNode",
+                    "LedgerIndex": "D8120FC732737A2CF2E9968FDF3797A43B457F2A81AA06D2653171A1EA635204",
+                    "NewFields": {
+                        "Owner": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+                        "RootIndex": "D8120FC732737A2CF2E9968FDF3797A43B457F2A81AA06D2653171A1EA635204"
+                    }
+                }
+            }],
+            "TransactionIndex": 0,
+            "TransactionResult": "tesSUCCESS"
+        },
+        "status": "success",
+        "validated": true
+    }
 }
 
    
 
    In particular, check that the TransactionResult is the string tesSUCCESS.
    

From 752f8fa0c0e8c9c92d0df197995c5b9ad2ee7d40 Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Mon, 28 Mar 2016 16:49:40 -0700
Subject: [PATCH 14/40] fix table of contents overflowing sidebar on some
 screen widths

---
 assets/css/devportal.css | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/assets/css/devportal.css b/assets/css/devportal.css
index ccc4baeaa3..a17c7624d6 100644
--- a/assets/css/devportal.css
+++ b/assets/css/devportal.css
@@ -202,7 +202,7 @@
 }
 @media (max-width: 1200px) {
   .page-template-template-dev-portal-php .dev_nav_wrapper {
-    max-width: 300px;
+    max-width: 290px;
   }
 }
 @media (max-width: 992px) {
@@ -396,7 +396,7 @@
 	z-index: 1;
 	padding-left: 10px;
 }
-	
+
 .multicode ul {
     padding-bottom: 0;
 }
@@ -426,14 +426,13 @@
 
 .multicode a.current {
 	background: #fff;
-	border-bottom: 1px solid #fff; 
+	border-bottom: 1px solid #fff;
     color : black;
 }
 
 .multicode a:hover {
 	color: black;
-	background: white; 
+	background: white;
 }
 
 .multicode a.current:hover {}
-

From 976a383ed0f47fccdd3dd2ff5fd3c2bd1c4b4eab Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Mon, 28 Mar 2016 18:51:39 -0700
Subject: [PATCH 15/40] multi-sign - revisions to tutorial and reorg based on
 feedback.

---
 concept-reserves.html                   |   1 +
 concept-stand-alone-mode.html           |   8 +-
 content/concept-reserves.md             |   2 +-
 content/concept-stand-alone-mode.md     |   9 +-
 content/reference-ledger-format.md      |   3 +-
 content/reference-rippled.md            |  12 +
 content/reference-transaction-format.md |  75 ++++---
 content/tutorial-multisign.md           | 279 +++++++++++-------------
 reference-ledger-format.html            |   1 +
 reference-rippled.html                  |   4 +
 reference-transaction-format.html       |  76 ++++---
 tutorial-multisign.html                 | 240 +++++++++-----------
 12 files changed, 335 insertions(+), 375 deletions(-)

diff --git a/concept-reserves.html b/concept-reserves.html
index 2bf281ca19..6fa4721fd8 100644
--- a/concept-reserves.html
+++ b/concept-reserves.html
@@ -146,6 +146,7 @@
 
      
 
    • Offers are owned by the account that placed them. An Offer can be automatically removed from the ledger if it is fully consumed or if it is found unfunded during transaction processing. Alternatively, the owner can cancel an offer by sending an OfferCancel transaction, or by sending an OfferCreate transaction that contains an OfferSequence parameter.
      • 
 
    • Trust lines are shared between two accounts. The owner reserve can apply to one or both of the accounts, depending on whether the fields that account controls are in their default state. See Contributing to the Owner Reserve for details.
      • 
+
    • A single SignerList counts as 3 to 10 objects for purposes of the owner reserve, depending on how many members it has. See also: SignerLists and Reserves.
      • 
 
    • Owner directories list all the ledger nodes that contribute to an account's owner reserve. However, the owner directory itself does not count towards the reserve.
      • 
 
    
 
    Owner Reserve Edge Cases
    
diff --git a/concept-stand-alone-mode.html b/concept-stand-alone-mode.html
index 2a57a14c06..59b79a7637 100644
--- a/concept-stand-alone-mode.html
+++ b/concept-stand-alone-mode.html
@@ -132,7 +132,7 @@
 
    
 
    
 
    Stand-Alone Mode
    
-
    You can run rippled in stand-alone mode without a consensus of trusted servers. In stand-alone mode, rippled does not communicate with any other servers in the Ripple peer-to-peer network, but you can perform most of the same actions on your local server only. Stand-alone provides a method for testing rippled behavior, including the effects of Amendments before those Amendments have gone into effect across the decentralized network.
    
+
    You can run rippled in stand-alone mode without a consensus of trusted servers. In stand-alone mode, rippled does not communicate with any other servers in the Ripple peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing rippled behavior, including the effects of Amendments before those Amendments have gone into effect across the decentralized network.
    
 
    When you run rippled in stand-alone mode, you have to tell it what ledger version to start from:
    
 
 
    Caution: In stand-alone mode, you must manually advance the ledger.
    
 
    New Genesis Ledger
    
-
    In stand-alone mode, you can have rippled create a new genesis ledger. This provides a known state, with none of the ledger history from the production Ripple network. (This is very useful for unit tests, among other things.)
    
+
    In stand-alone mode, you can have rippled create a new genesis ledger. This provides a known state, with none of the ledger history from the production Ripple Consensus Ledger. (This is very useful for unit tests, among other things.)
    
 
      
 
    • To start rippled in stand-alone mode with a new genesis ledger, use the -a and --start options:
      • 
 
    
@@ -173,7 +173,7 @@

    (TODO: test this)

    6. Manually advance the ledger.

    -

    When you load a ledger with --ledger in stand-alone mode, it goes to the current open ledger, so you need to manually advance the ledger to finalize it:

    +

    When you load a ledger with --ledger in stand-alone mode, it goes to the current open ledger, so you must manually advance the ledger:

    rippled ledger_accept --conf=/path/to/rippled.cfg

    Advancing Ledgers in Stand-Alone Mode

    @@ -181,7 +181,7 @@ 
    rippled ledger_accept --conf=/path/to/rippled.cfg

    In stand-alone mode, rippled makes no distinction between a "closed" ledger version and a "validated" ledger version. (For more information about the difference, see The Ripple Ledger Consensus Process.)

    -

    Whenever rippled closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since different rippled servers may see transactions in a different order.) When using rippled in stand-alone mode, it is important to manually advance the ledger before submitting a transaction that depends on the result of a previous transaction. Otherwise, the second transaction might be executed before the first transaction when you manually advance the ledger. Note: You can safely submit multiple transactions from a single account to a single ledger, because rippled sorts transactions from the same account in ascending order by Sequence number.

    +

    Whenever rippled closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since different rippled servers may see transactions in a different order.) When using rippled in stand-alone mode, you should manually advance the ledger before submitting a transaction that depends on the result of a previous transaction. Otherwise, the second transaction might be executed before the first transaction when you manually advance the ledger. Note: You can safely submit multiple transactions from a single account to a single ledger, because rippled sorts transactions from the same account in ascending order by Sequence number.

    diff --git a/content/concept-reserves.md b/content/concept-reserves.md index fee741cc24..9f4297f0c6 100644 --- a/content/concept-reserves.md +++ b/content/concept-reserves.md @@ -21,6 +21,7 @@ Many objects in the ledger are owned by a particular account, and therefore coun * [Offers](reference-ledger-format.html#offer) are owned by the account that placed them. An Offer can be automatically removed from the ledger if it is fully consumed or if it is found unfunded during transaction processing. Alternatively, the owner can cancel an offer by sending an [OfferCancel transaction](reference-transaction-format.html#offercancel), or by sending an [OfferCreate transaction](reference-transaction-format.html#offercreate) that contains an `OfferSequence` parameter. * [Trust lines](reference-ledger-format.html#ripplestate) are shared between two accounts. The owner reserve can apply to one or both of the accounts, depending on whether the fields that account controls are in their default state. See [Contributing to the Owner Reserve](reference-ledger-format.html#contributing-to-the-owner-reserve) for details. +* A single [SignerList](reference-ledger-format.html#signerlist) counts as 3 to 10 objects for purposes of the owner reserve, depending on how many members it has. See also: [SignerLists and Reserves](reference-ledger-format.html#signerlists-and-reserves). * [Owner directories](reference-ledger-format.html#directorynode) list all the ledger nodes that contribute to an account's owner reserve. However, the owner directory itself does not count towards the reserve. #### Owner Reserve Edge Cases #### @@ -40,4 +41,3 @@ When an account has less XRP than its current reserve requirement, it cannot sen ## Changing the Reserve Requirements ## The Ripple Consensus Ledger has a mechanism for changing the reserve requirements in order to account for long-term changes in the value of XRP. Any changes have to be approved by the consensus process. See [Fee Voting](concept-fee-voting.html) for more information. - diff --git a/content/concept-stand-alone-mode.md b/content/concept-stand-alone-mode.md index 654e72ef1b..322ae60602 100644 --- a/content/concept-stand-alone-mode.md +++ b/content/concept-stand-alone-mode.md @@ -1,7 +1,7 @@ Stand-Alone Mode =============================================================================== -You can run `rippled` in stand-alone mode without a consensus of trusted servers. In stand-alone mode, `rippled` does not communicate with any other servers in the Ripple peer-to-peer network, but you can perform most of the same actions on your local server only. Stand-alone provides a method for testing `rippled` behavior, including the effects of [Amendments](concept-amendments.html) before those Amendments have gone into effect across the decentralized network. +You can run `rippled` in stand-alone mode without a consensus of trusted servers. In stand-alone mode, `rippled` does not communicate with any other servers in the Ripple peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing `rippled` behavior, including the effects of [Amendments](concept-amendments.html) before those Amendments have gone into effect across the decentralized network. When you run `rippled` in stand-alone mode, you have to tell it what ledger version to start from: @@ -12,7 +12,7 @@ When you run `rippled` in stand-alone mode, you have to tell it what ledger vers New Genesis Ledger ------------------------------------------------------------------------------- -In stand-alone mode, you can have `rippled` create a new genesis ledger. This provides a known state, with none of the ledger history from the production Ripple network. (This is very useful for unit tests, among other things.) +In stand-alone mode, you can have `rippled` create a new genesis ledger. This provides a known state, with none of the ledger history from the production Ripple Consensus Ledger. (This is very useful for unit tests, among other things.) * To start `rippled` in stand-alone mode with a new genesis ledger, use the `-a` and `--start` options: @@ -29,6 +29,7 @@ In a genesis ledger, the [genesis account](reference-rippled.html#special-addres **Caution:** If you create a new genesis ledger, the hard-coded default [Reserve](concept-reserves.html) is **200 XRP** minimum for an account, with an increment of **50 XRP** per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: [Fee Voting](concept-fee-voting.html)) + Load Saved Ledger ------------------------------------------------------------------------------- You can start with a ledger version that was saved to disk if your `rippled` server was previously synced with the Ripple peer-to-peer network (either the production network or the [Test Net](tutorial-rippled-setup.html#parallel-networks)). @@ -75,7 +76,7 @@ rippled -a --ledger 19860944 --conf=/path/to/rippled.cfg ### 6. Manually advance the ledger. ### -When you load a ledger with `--ledger` in stand-alone mode, it goes to the current open ledger, so you need to [manually advance the ledger](#advancing-ledgers-in-stand-alone-mode) to finalize it: +When you load a ledger with `--ledger` in stand-alone mode, it goes to the current open ledger, so you must [manually advance the ledger](#advancing-ledgers-in-stand-alone-mode): ``` rippled ledger_accept --conf=/path/to/rippled.cfg @@ -93,4 +94,4 @@ rippled ledger_accept --conf=/path/to/rippled.cfg In stand-alone mode, `rippled` makes no distinction between a "closed" ledger version and a "validated" ledger version. (For more information about the difference, see [The Ripple Ledger Consensus Process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/).) -Whenever `rippled` closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since different `rippled` servers may see transactions in a different order.) When using `rippled` in stand-alone mode, it is important to manually advance the ledger before submitting a transaction that depends on the result of a previous transaction. Otherwise, the second transaction might be executed before the first transaction when you manually advance the ledger. **Note:** You can safely submit multiple transactions from a single account to a single ledger, because `rippled` sorts transactions from the same account in ascending order by `Sequence` number. +Whenever `rippled` closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since different `rippled` servers may see transactions in a different order.) When using `rippled` in stand-alone mode, you should manually advance the ledger before submitting a transaction that depends on the result of a previous transaction. Otherwise, the second transaction might be executed before the first transaction when you manually advance the ledger. **Note:** You can safely submit multiple transactions from a single account to a single ledger, because `rippled` sorts transactions from the same account in ascending order by `Sequence` number. diff --git a/content/reference-ledger-format.md b/content/reference-ledger-format.md index 686aa968fb..2ad775e176 100644 --- a/content/reference-ledger-format.md +++ b/content/reference-ledger-format.md @@ -451,6 +451,8 @@ A SignerList node has the following fields: | PreviousTxnID | String | Hash256 | The identifying hash of the transaction that most recently modified this node. | | PreviousTxnLgrSeq | Number | UInt32 | The sequence number (`ledger_index`) of the ledger that contains the transaction that most recently modified this node. | +The `SignerEntries` may be any combination of funded and unfunded addresses that use either secp256k1 or ed25519 keys. + ### SignerEntry object ### Each member of the `SignerEntries` field is an object that describes that signer in the list. A SignerEntry has the following fields: @@ -465,4 +467,3 @@ When processing a multi-signed transaction, the server dereferences the `Account ### SignerLists and Reserves ### A SignerList contributes to the [Account Reserve](https://wiki.ripple.com/Reserves). The SignerList itself counts as two objects, and each member of the list counts as one, so that the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line ([RippleState](#ripplestate)) or [Offer](#offer) node in the ledger. - diff --git a/content/reference-rippled.md b/content/reference-rippled.md index ccefabb180..bafafb1cd6 100644 --- a/content/reference-rippled.md +++ b/content/reference-rippled.md @@ -6296,6 +6296,12 @@ __*Caution:*__ If this command results in an error messages, the message can con * `noPath` - The transaction did not include paths, and the server was unable to find a path by which this payment can occur. +## sign_for ## + +The `sign_for` command provides one signature for a multi-signed transaction. takes an address and related secret, and a transaction in JSON form. (TODO: finish this section.) It generates a signature for that transaction, using the secret key and address specified. By using this, you can provide signatures that contribute to a multi-signed transaction. (The signatures should come from the members of your SignerList.) + + + ## submit ## [[Source]
    ](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Submit.cpp "Source") @@ -6526,6 +6532,12 @@ __*Caution:*__ If this command results in an error messages, the message can con * `internalJson` - An internal error occurred when serializing the transaction to JSON. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed. +## submit_multisigned ## + +The `submit_multisigned` command takes a transaction specification with multiple signatures and applies that transaction. (TODO: finish this section.) + + + ## book_offers ## [[Source]
    ](https://github.com/ripple/rippled/blob/develop/src/ripple/rpc/handlers/BookOffers.cpp "Source") diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md index 2cb6c4a7fb..d318c47858 100644 --- a/content/reference-transaction-format.md +++ b/content/reference-transaction-format.md @@ -19,18 +19,39 @@ Additionally, there are *Psuedo-Transactions* that are not created and submitted Transactions are only valid if signed, submitted, and accepted into a validated ledger version. There are many ways a transaction can fail. -* [Signing and Sending Transactions](#signing-and-sending-transactions) +* [Authorized Transactions](#authorizing-transactions) * [Reliable Transaction Submission](#reliable-transaction-submission) * [Transaction Results - How to find and interpret transaction results](#transaction-results) * [Full Transaction Response List - Complete table of all error codes](#full-transaction-response-list) -## Signing and Sending Transactions ## +## Authorizing Transactions ## -Signing a transaction cryptographically proves that the person in charge of the account sending the transaction is authorized to do so. Only signed transactions can be submitted to the network and included in a validated ledger. A signed transaction is immutable: its contents cannot change, and the signature is not valid for any other transaction. +In the decentralized Ripple Consensus Ledger, a digital signature proves that a transaction is authorized to perform a specific set of actions. Only signed transactions can be submitted to the network and included in a validated ledger. A signed transaction is immutable: its contents cannot change, and the signature is not valid for any other transaction. -You sign a transaction using a secret key: either the master secret, or a regular secret if the account has a regular key pair associated with it. (See [SetRegularKey](#setregularkey) for details.) If your account has a SignerList associated with it, you can use a [multi-signature](#multi-signing) instead. +A transaction can be authorized by any of the following types of signatures: -Typically, you create a transaction in JSON format first. Here is an example of an unsigned Payment-type transaction in JSON: +* A single signature from the master secret key that is mathematically associated with the address. You can disable or enable the master key using an [AccountSet transaction](#accountset). +* A single signature that matches a regular key enabled for the address. You can enable, remove, or replace a regular key using a [SetRegularKey transaction](#setregularkey). +* A [multi-signature](#multi-signing) that matches a list of signers enabled for the address. You can enable, 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: + +* Only the master key can [disable the master key](#accountset-flags). +* Only the master key can [permanently give up the ability to freeze](concept-freeze.html#no-freeze). +* You can never remove the last method of signing transactions from an address. + +## Signing and Submitting Transactions ## + +Sending a transaction to the Ripple Consensus Ledger involves several steps: + +1. Create an unsigned transaction in JSON format. +2. Use one or more signatures to [authorize the transaction](#authorizing-transactions). +3. Submit a transaction to a `rippled` server. If the transaction is properly formed, the server provisionally applies the transaction to its current version of the ledger and relays the transaction to other members of the peer-to-peer network. +4. The [consensus process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/) determines which provisional transactions get included in the next validated ledger. +5. The `rippled` servers apply those transactions to the previous ledger in a canonical order and share their results. +6. If enough [trusted validators](tutorial-rippled-setup.html#reasons-to-run-a-validator) created the exact same ledger, that ledger is declared _validated_ and the [results of the transactions](#transaction-results) in that ledger are immutable. + +Here is an example of an unsigned [Payment-type transaction](#payment) in JSON: ``` { @@ -155,31 +176,14 @@ After a transaction has been submitted, if it gets accepted into a validated led } ``` + ### Multi-Signing ### -Multi-signing in Ripple is the act of authorizing transactions for the Ripple -Consensus Ledger by using a combination of multiple secret keys. Multi-signing -allows various use cases including: +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. -* If you require keys from different devices, a malicious user must compromise multiple machines in order to send transactions on your behalf. -* If the keys to an account are in the custody of entirely different people, those people must collaborate in order to send transaction from that account. -* Delegate a group of others who can send transactions for you if you are unavailable or unable to sign normally. -* ... and more. - -To set up multi-signing for an account, the process is straightforward: - -1. Use a [SignerListSet transaction](#signerlistset) to define which accounts or keys can, together, authorize transactions for this account. -2. Optionally disable the master key with an [AccountSet transaction](#accountset) using the `asfDisableMaster` flag. -3. Optionally remove the existing regular key (if any) with a [SetRegularKey transaction](#setregularkey). - -After an account has a SignerList associated with it, the process of submitting a multi-signed transaction is as follows: - -1. Create the transaction to be signed as a JSON object -2. Generate a signature for each account using the [`sign_for` command](rippled-apis.html#sign-for). -3. Combine the signatures and submit using the [`submit_multisigned` command](rippled-apis.html#submit-multisigned). - -Main article: [How to Multi-Sign](multisign.html) +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. +For more information, see [How to Multi-Sign](tutorial-multisign.html). ### Reliable Transaction Submission ### @@ -550,7 +554,7 @@ In rippled's WebSocket and JSON-RPC APIs, the TransferRate is represented as an [[Source]
    ](https://github.com/ripple/rippled/blob/4239880acb5e559446d2067f00dabb31cf102a23/src/ripple/app/transactors/SetRegularKey.cpp "Source") -A SetRegularKey transaction changes the regular key used by the account to sign future transactions. +A SetRegularKey transaction changes the regular key associated with an address. ``` { @@ -564,13 +568,15 @@ A SetRegularKey transaction changes the regular key used by the account to sign | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description | |-------|-----------|--------------------------------------------------------|-------------| -| RegularKey | String | Account | (Optional) The public key of a new keypair, to use as the regular key to this account, as a base-58-encoded string in the same format as an account address. If omitted, removes the existing regular key. | +| RegularKey | String | AccountID | (Optional) A base-58-encoded [Ripple address](reference-rippled.html#addresses) to use as the regular key. If omitted, removes the existing regular key. | -Instead of using an account's master key to sign transactions, you can set an alternate key pair, called the "Regular Key". As long as the public key for this key pair is set in the `RegularKey` field of an account this way, then the secret of the Regular Key pair can be used to sign transactions. (Other methods of signing transactions can also be used, including [multi-signing](#multi-signing) or the master key. +In addition to the master key, which is mathematically-related to an address, you can associate **at most 1 additional key pair** with an address using this type of transaction. The additional key pair is called a _regular key_. If your address has a regular key pair defined, you can use the secret key of the regular key pair to [authorize transactions](#authorizing-transactions). -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). The Master Key can be [disabled](#accountset-flags) but it cannot be changed. Therefore, it is beneficial to security sign transactions with a Regular Key instead of the master key whenever possible. For even greater security, you can use [multi-signing](#multi-signing), but multi-signing costs additional XRP in transaction fees and reserves. +A regular key pair is generated in the same way as any other Ripple keys (for example, with [wallet_propose](reference-rippled.html#wallet-propose)), but it can be changed. A master key pair is an intrinsic part of an address's identity (the address is derived from the master public key). You can [disable](#accountset-flags) a master key but you cannot change it. -If your regular key is compromised, but the master key is not, you can use a SetRegularKey transaction to regain control of your account. In some cases, you can even send a [key reset transaction](concept-transaction-cost.html#key-reset-transaction) without paying the [transaction cost](#transaction-cost). +You can protect your master secret by using a regular key instead of the master key to sign transactions where possible. If your regular key is compromised, but the master key is not, you can use a SetRegularKey transaction to regain control of your address. In some cases, you can even send a [key reset transaction](concept-transaction-cost.html#key-reset-transaction) without paying the [transaction cost](#transaction-cost). + +For even greater security, you can use [multi-signing](#multi-signing), but multi-signing requires additional XRP for the [transaction cost](concept-transaction-cost.html) and [reserve](concept-reserves.html). @@ -778,7 +784,7 @@ Transactions of the TrustSet type support additional values in the [`Flags` fiel ## SignerListSet ## [[Source]
    ](https://github.com/ripple/rippled/blob/ef511282709a6a0721b504c6b7703f9de3eecf38/src/ripple/app/tx/impl/SetSignerList.cpp "Source") -The SignerListSet transaction creates, modifies, or removes a list of signers that can be used to multi-sign a transaction. +The SignerListSet transaction creates, modifies, or removes a list of signers that can be used to [multi-sign](#multi-signing) a transaction. Example SignerListSet: @@ -815,14 +821,15 @@ Example SignerListSet: | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description | |-------|-----------|--------------------------------------------------------|-------------| | SignerQuorum | Number | UInt32 | A target number for the signer weights. A multi-signature from this list is valid only if the sum weights of the signatures provided is equal or greater than this value. To delete a SignerList, use the value `0`. | -| SignerEntries | Array | Array | (Omitted when deleting) Array of [SignerEntry objects](ripple-ledger.html#signerentry-object), indicating the addresses and weights of signers in this list. A SignerList must have at least 1 member and no more than 8 members. No address may appear more than once in the list, nor may the `Account` submitting the transaction appear in the list. | +| SignerEntries | Array | Array | (Omitted when deleting) Array of [SignerEntry objects](reference-ledger-format.html#signerentry-object), indicating the addresses and weights of signers in this list. A SignerList must have at least 1 member and no more than 8 members. No address may appear more than once in the list, nor may the `Account` submitting the transaction appear in the list. | 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 `SignerQuorum` to `0` _and_ omit the `SignerEntries` field. Otherwise, the transaction fails with the error [temMALFORMED](#tem-codes). A transaction to delete a SignerList is considered successful even if there was no SignerList to delete. 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 `SignerWeight` values in the list. Otherwise, the transaction fails with the error [temMALFORMED](#tem-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](ripple-ledger.html#accountroot-flags) enabled) and the account does not have a Regular Key configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error [tecNO\_ALTERNATIVE\_KEY](#tec-codes). +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). # Pseudo-Transactions # diff --git a/content/tutorial-multisign.md b/content/tutorial-multisign.md index 3182adb01c..84eba1ca5c 100644 --- a/content/tutorial-multisign.md +++ b/content/tutorial-multisign.md @@ -1,117 +1,81 @@ -Introduction to Multi-Signing -=============================================================================== +How to Multi-Sign +============================= -Multi-signing in Ripple is the act of authorizing transactions for the Ripple Consensus Ledger by using a combination of multiple secret keys. After setting up multi-signing for an account, you can put the master secret in cold storage, or even disable the master key entirely. With multiple secret keys required to authorize a multi-signature, you can improve security in several ways. +Multi-signing is one of three ways to authorize transactions for the Ripple Consensus Ledger, alongside signing with [regular keys](reference-transaction-format.html#setregularkey) and master keys. You can configure your address to allow any combination of the three methods to authorize transactions. -* If you keep an account's keys on different devices, a malicious user must compromise multiple machines in order to send transactions on your behalf. -* If the keys to an account are in the custody of entirely different people, those people must collaborate in order to send transaction from that account. -* You can use the SignerList as a backup, to delegate a group of others who can send transactions for you if you are unavailable or unable to sign using your regular key. -* Even more uses than can be described here. +Benefits of multi-signing include: + +* You can require keys from different devices, so that a malicious actor must compromise multiple machines to send transactions on your behalf. +* You can share custody of an address between multiple people, each of whom only has one of several keys necessary to send transactions from that address. +* You can delegate the power to send transactions from your address to a group of people, who can control your address if you are unavailable or unable to sign normally. +* ... and more. + +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) +3. [Send transactions using multiple signatures.](#sending-a-multi-signed-transaction) Availability of Multi-Signing -------------------------------------------------------------------------------- +----------------------------- Multi-signing is built into `rippled` starting with version **0.31.0**. Because multi-signing is a change in transaction processing, the change is due to be enabled by an **Amendment** to the Ripple Consensus Protocol. This Amendment must be approved by a consensus of validators showing consistent support for the feature over a period of time. For more information, see [Amendments](concept-amendments.html). -You can test multi-signing by running `rippled` in [stand-alone mode](concept-stand-alone-mode.html) with the Multi-Sign feature enabled. To enable Multi-Sign for testing, add the following stanza to your `rippled.cfg`: +If you want to test multi-signing before it becomes available in the production network, or without risking real money, you can do so by running `rippled` in [stand-alone mode](concept-stand-alone-mode.html) with the MultiSign feature enabled. To enable multi-signing for testing, add the following stanza to your `rippled.cfg`: [features] MultiSign -How to Multi-Sign -=============================================================================== +Setting up Multi-Signing +------------------------ -The basic process of Multi-Signing a transaction is necessarily more complex than the process of signing a transaction with a single master key or regular key. +To multi-sign transactions from a particular address, you must create a list of addresses that can contribute to a multi-signature for your address. This list is stored in the Ripple Consensus Ledger as a [SignerList node](reference-ledger-format.html#signerlist). The following procedure demonstrates how to set up a SignerList for your address: -## 1. (Optional) Generate keys for a new wallet ## -This step is not strictly necessary. For this process, we generate and fund a new Ripple account and then set up multi-signing for that account. To set up multi-signing on an existing Ripple account, skip ahead to [Step 4: creating a signer list](4-create-a-signerlist-on-the-new-account-with-a-signerlistset-transaction). +### 1. Prepare a funded address ### + +You need a Ripple address that can send transactions, and has enough XRP available. Multi-signing requires more than the usual amount of XRP for the [account reserve](concept-reserves.html) and [transaction cost](concept-transaction-cost.html), increasing with the number of signers and signatures you use. + +If you started `rippled` in [stand-alone mode](concept-stand-alone-mode.html) with a new genesis ledger, you must: + +1. Generate keys for a new address, or reuse keys you already have. +2. Submit a Payment transaction to fund the new address from the genesis account. (Send at least 100,000,000 [drops of XRP](reference-rippled.html#specifying-currency-amounts).) +3. Manually close the ledger. + + +### 2. Prepare member keys ### + +You need several sets of Ripple keys (address and secret) to include as members of your SignerList. These can be funded addresses that exist in the ledger, or you can generate new addresses using the [`wallet_propose` command](reference-rippled.html#wallet-propose). For example: $ rippled wallet_propose Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 { - "result" : { - "account_id" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", - "key_type" : "secp256k1", - "master_key" : "LOST FOUR ALOE ABE SLUG ITS HACK MAGI SOCK BASS APE DELL", - "master_seed" : "sn1CmMEkPijNrfyr8HJqsgP416dr3", - "master_seed_hex" : "E42AD02985BB56923DFC1D002DB510B3", - "public_key" : "aBQgQDutj8YUc7ZRtfj86dnzPCvPcRHtUszxeCCDMgZ7Zq1Thfri", - "public_key_hex" : "03668837C3DCA0F4858587703524E61BB40128B9F6910B80B4655E152CAEE2E321", - "status" : "success" - } + "result" : { + "account_id" : "rnRJ4dpSBKDR2M1itf4Ah6tZZm5xuNZFPH", + "key_type" : "secp256k1", + "master_key" : "FLOG SEND GOES CUFF GAGE FAT ANTI DEL GUM TIRE ISLE BEAR", + "master_seed" : "snheH5UUjU4CWqiNVLny2k21TyKPC", + "master_seed_hex" : "A9F859765EB8614D26809836382AFB82", + "public_key" : "aBR4hxFXcDNHnGYvTiqb2KU8TTTV1cYV9wXTAuz2DjBm7S8TYEBU", + "public_key_hex" : "03C09A5D112B393D531E4F092E3A5769A5752129F0A9C55C61B3A226BB9B567B9B", + "status" : "success" + } } - -As always, be sure that an account's secret key never gets transmitted to anyone you don't trust with full control of that account, and certainly not unencrypted over the network. +Take note of the `account_id` (Ripple Address) and `master_seed` (Ripple secret key) for each one you generate. -## 2. Fund the new account with an existing wallet ## +### 3. Send SignerListSet transaction ### -Again, this step is only necessary if you are setting up a new account to use multi-signing for this example. - - $ rippled submit snoPBrXtMeMyMHUVTgbuqAfg1SUTb '{ - > "TransactionType": "Payment", - > "Account": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", - > "Destination": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", - > "Amount": "100000000", - > "Flags": 2147483648 - > }' - Loading: "/home/mduo13/.config/ripple/rippled.cfg" - Connecting to 127.0.0.1:5005 - { - "result" : { - "engine_result" : "tesSUCCESS", - "engine_result_code" : 0, - "engine_result_message" : "The transaction was applied. Only final in a validated ledger.", - "status" : "success", - "tx_blob" : "12000022800000002400000004614000000005F5E10068400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100ED13CDD4B8F6BA836F7732A029316393A5D9B50712FE79972236ECAD850F813802203148D8944B0BF3D30A3177EFCE6A9F12B3F5A3C3AFF7B73E9A7D65B370E526EE8114B5F762798A53D543A014CAF8B297CFF8F2F937E88314A3780F5CB5A44D366520FC44055E8ED44D9A2270", - "tx_json" : { - "Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", - "Amount" : "100000000", - "Destination" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", - "Fee" : "10", - "Flags" : 2147483648, - "Sequence" : 4, - "SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020", - "TransactionType" : "Payment", - "TxnSignature" : "3045022100ED13CDD4B8F6BA836F7732A029316393A5D9B50712FE79972236ECAD850F813802203148D8944B0BF3D30A3177EFCE6A9F12B3F5A3C3AFF7B73E9A7D65B370E526EE", - "hash" : "64FAA44F671E2CBB4E1E4156FCDA72BA3C32EF951C94EDDFEBEBE8BEC3F55696" - } - } - } - - -Make sure that the `engine_result` value in the response is **tesSUCCESS**. Otherwise, the transaction failed. - -## 3. Close the ledger ## - -If you are using the live network, you can wait for the ledger to close automatically as the result of consensus. This typically takes 4-7 seconds. - -If you are running `rippled` in stand-alone mode, you must manually close the ledger with the [`ledger_accept` command](reference-rippled.html#ledger-accept). - - $ rippled ledger_accept - Loading: "/home/mduo13/.config/ripple/rippled.cfg" - Connecting to 127.0.0.1:5005 - { - "result" : { - "ledger_current_index" : 16061437, - "status" : "success" - } - } - - -## 4. Create a SignerList on the new account with a SignerListSet transaction ## - -Before you can multi-sign transactions, you must associate a SignerList with your account, so that RCL knows which keys can be used to sign for you. You do this with a [SignerListSet transaction](reference-transaction-format.html#signerlistset). - -The `Account` values in your SignerList can be the addresses of funded accounts that exist in the ledger, or you can generate new addresses that are not currently in use. For funded accounts in the SignerList, a regular key associated with the account can contribute to a multi-signature, and the master key secret can be used only if it is not disabled. For unfunded addresses, only the master key associated with that address can be used to contribute to a multi-signature. +[Sign and submit](reference-transaction-format.html#signing-and-submitting-transactions) a [SignerListSet transaction](reference-transaction-format.html#signerlistset) in the normal (single-signature) way. This associates a SignerList with your Ripple address, so that a combination of signatures from the members of that SignerList can multi-sign later transactions on your behalf. In this example, the SignerList has 3 members, with the weights and quorum set up such that multi-signed transactions need a signature from rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other two members of the list. +**Caution:** Never submit a secret key to a server you do not control. Do not transmit a secret key unencrypted over the network. + $ rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{ > "Flags": 0, > "TransactionType": "SignerListSet", @@ -182,13 +146,16 @@ In this example, the SignerList has 3 members, with the weights and quorum set u } } -Make sure that the `engine_result` value in the response is **tesSUCCESS**. Otherwise, the transaction failed. +Make sure that the [Transaction Result](reference-transaction-format.html#transaction-results) is [**tesSUCCESS**](reference-transaction-format.html#tes-success). Otherwise, the transaction failed. -## 5. Close the ledger again ## +**Note:** The more members in the SignerList, the more XRP your address must have for purposes of the [owner reserve](concept-reserves.html#owner-reserves). If your address does not have enough XRP, the transaction fails with [tecINSUFFICIENT_RESERVE](reference-transaction-format.html#tec-codes). See also: [SignerLists and Reserves](reference-ledger-format.html#signerlists-and-reserves). -As before, on the live network, you can wait for the ledger to close automatically. -If running `rippled` in stand-alone mode, use the [`ledger_accept` command](reference-rippled.html#ledger-accept) to manually close the ledger: +### 4. Close the ledger ### + +On the live network, you can wait 4-7 seconds for the ledger to close automatically. + +If you're running `rippled` in stand-alone mode, use the [`ledger_accept` command](reference-rippled.html#ledger-accept) to manually close the ledger: $ rippled ledger_accept Loading: "/home/mduo13/.config/ripple/rippled.cfg" @@ -201,9 +168,11 @@ If running `rippled` in stand-alone mode, use the [`ledger_accept` command](refe } -## 6. Confirm the presence of the new signer list using account_objects ## +### 5. Confirm the new signer list ### -Normally an account can own many objects of different types (such as trust lines and offers). For this tutorial, we created a new account, so the SignerList is the only object in the response from the [`account_objects` command](reference-rippled.html#account-objects). +Use the [`account_objects` command](reference-rippled.html#account-objects) to confirm that the SignerList is associated with the address in the latest validated ledger. + +Normally, an account can own many objects of different types (such as trust lines and offers). If you funded a new address for this tutorial, the SignerList is the only object in the response. $ rippled account_objects rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC validated Loading: "/home/mduo13/.config/ripple/rippled.cfg" @@ -241,30 +210,6 @@ Normally an account can own many objects of different types (such as trust lines "SignerListID" : 0, "SignerQuorum" : 3, "index" : "79FD203E4DDDF2EA78B798C963487120C048C78652A28682425E47C96D016F92" - }, - { - "Balance" : { - "currency" : "USD", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2162688, - "HighLimit" : { - "currency" : "USD", - "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", - "value" : "0" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "USD", - "issuer" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", - "value" : "100" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6", - "PreviousTxnLgrSeq" : 6, - "index" : "93E317B32022977C77810A2C558FBB28E30E744C68E73720622B797F957EC5FA" } ], "ledger_hash" : "56E81069F06492FB410A70218C08169BE3AB3CFD5AEA20E999662D81DC361D9F", @@ -274,45 +219,65 @@ Normally an account can own many objects of different types (such as trust lines } } +If the SignerList is present with the expected contents, then your address is ready to multi-sign. + +### 6. Further steps ### + +At this point, your address is ready to [send a multi-signed transaction](#sending-a-multi-signed-transaction). You may also want to: + +* Disable the address's master key by sending an [AccountSet transaction](reference-transaction-format.html#accountset) using the `asfDisableMaster` flag. +* Remove the address's regular key (if you previously set one) by sending a [SetRegularKey transaction](reference-transaction-format.html#setregularkey). -## 7. Create a new transaction that you plan to multi-sign ## +Sending a Multi-Signed Transaction +---------------------------------- -You have to specify _everything_ about this transaction, including `Fee` and -`Sequence`. Also include the field `SigningPubKey` as an empty string -- this -indicates that the transaction is multi-signed. +Before you can multi-sign a transaction, first check that [multi-sign is available](#availability-of-multi-signing) and [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. -Here's an example transaction we can send from our test account: +### 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. + +Here's an example transaction ready to be multi-signed: { "TransactionType": "TrustSet", - "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H", + "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", "Flags": 262144, "LimitAmount": { - "currency": "USD", - "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", - "value": "100" + "currency": "USD", + "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "value": "100" }, "Sequence": 2, - "SigningPubKey":"", + "SigningPubKey": "", "Fee": "30000" } -(If you started from a fresh ledger, you first need to fund the account -specified by the `issuer` in this example, and then manually close the ledger.) - -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 fee, 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 load fee increases in that time. +(This transaction creates an accounting relationship from rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC to rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh with a maximum balance of 100 USD.) -## 8. Get one signature ## +### 2. Get one signature ### -The [`sign_for` command](reference-rippled.html#sign-for) takes an address and related secret, and a transaction in JSON form. It generates a signature for that transaction, using the secret key and address specified. By using this, you can provide signatures that contribute to a multi-signed transaction. (The signatures should come from the members of your SignerList.) +Use the [`sign_for` command](reference-rippled.html#sign-for) with the secret key and address of one of the members of your SignerList to get a signature for that member. - $ rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW '{ "TransactionType": "TrustSet", "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", "Flags": 262144, "LimitAmount": { "currency": "USD", "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "value": "100" }, "Sequence": 2, "SigningPubKey":"", "Fee": "30000" }' +**Caution:** Never submit a secret key to a server you do not control. Do not transmit a secret key unencrypted over the network. + + $ rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW '{ + > "TransactionType": "TrustSet", + > "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + > "Flags": 262144, + > "LimitAmount": { + > "currency": "USD", + > "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + > "value": "100" + > }, + > "Sequence": 2, + > "SigningPubKey": "", + > "Fee": "30000" + > }' Loading: "/home/mduo13/.config/ripple/rippled.cfg" Connecting to 127.0.0.1:5005 { @@ -345,14 +310,17 @@ The [`sign_for` command](reference-rippled.html#sign-for) takes an address and r } } -Save the `tx_json` field of the response: it has the new signature in the `Signers` field. - -The `tx_blob` is not very useful at this point, unless you're "multi-signing" a transaction with only one signature. +Save the `tx_json` field of the response: it has the new signature in the `Signers` field. You can discard the value of the `tx_blob` field. -## 9. Get additional signatures the same way ## +### 3. Get additional signatures ### -You can collect additional signatures for the same transaction in parallel by using the `sign_for` command with the same transaction JSON. You can also collect additional signatures in serial: if you provide the `tx_json` value from a previous `sign_for` response, the response appends a signature to the existing Signers array. +You can collect additional signatures in parallel or in serial: + +* In parallel: Use the `sign_for` command with the original JSON for the transaction. Each response has a single signature in the `Signers` array. +* In serial: Use the `sign_for` command with the `tx_json` value from the previous `sign_for` response. Each response adds a new signature to the existing `Signers` array. + +**Caution:** Never submit a secret key to a server you do not control. Do not transmit a secret key unencrypted over the network. $ rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v '{ > "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", @@ -416,14 +384,14 @@ You can collect additional signatures for the same transaction in parallel by us } } -Depending on the SignerList you configured, you may need to repeat this step several times in order to get signatures from all the necessary parties. +Depending on the SignerList you configured, you may need to repeat this step several times to get signatures from all the necessary parties. -## 10. Combine the signatures and submit ## +### 4. Combine signatures and submit ### -The commandline syntax for the [`submit_multisigned` command](reference-rippled.html#submit-multisigned) takes a single transaction JSON containing a `Signers` array, so you need to combine all the signatures from the all the responses into a single `Signers` array field with all the signatures. If you collected signatures serially, the `tx_json` from the last response is sufficient. +If you collected the signatures in serial, the `tx_json` from the last `sign_for` response has all the signatures assembled, so you can use that as the argument to the [`submit_multisigned` command](reference-rippled.html#submit-multisigned). -The `submit_multisigned` command actually submits the transaction for inclusion in the ledger. In online mode, this also relays it to other members of the network. +If you collected the signatures in parallel, you must manually construct a `tx_json` object with all the signatures included. Take the `Signers` arrays from all the `sign_for` responses, and combine their contents into a single `Signers` array that has each signature. Add the combined `Signers` array to the original transaction JSON value, and use that as the argument to the [`submit_multisigned` command](reference-rippled.html#submit-multisigned). $ rippled submit_multisigned '{ > "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", @@ -498,11 +466,11 @@ The `submit_multisigned` command actually submits the transaction for inclusion Take note of the `hash` value from the response so you can check the results of the transaction later. (In this case, the hash is `BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6`.) -## 14. Close the ledger one last time ## +### 5. Close the ledger ## -As before, on the live network, you can wait 4-7 seconds for the ledger to close automatically. +If you are using the live network, you can wait 4-7 seconds for the ledger to close automatically. -If running `rippled` in stand-alone mode, use the [`ledger_accept` command](reference-rippled.html#ledger-accept) to manually close the ledger: +If you're running `rippled` in stand-alone mode, use the [`ledger_accept` command](reference-rippled.html#ledger-accept) to manually close the ledger: $ rippled ledger_accept Loading: "/home/mduo13/.config/ripple/rippled.cfg" @@ -515,9 +483,13 @@ If running `rippled` in stand-alone mode, use the [`ledger_accept` command](refe } -## 15. Confirm the results of the transaction ## +### 6. Confirm transaction results ### -Use the hash value from the response to the `submit_multisigned` command. +Use the hash value from the response to the `submit_multisigned` command to look up the transaction using the [`tx` command](reference-rippled.html#tx). In particular, check that the `TransactionResult` is the string `tesSUCCESS`. + +On the live network, you must also confirm that the `validated` field is set to the boolean `true`. If the field is not `true`, you might need to wait longer for the consensus process to finish; or your transaction may be unable to be included in a ledger for some reason. + +In stand-alone mode, the server automatically considers a ledger to be `validated` if it has been manually closed. $ rippled tx BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6 Loading: "/home/mduo13/.config/ripple/rippled.cfg" @@ -629,10 +601,3 @@ Use the hash value from the response to the `submit_multisigned` command. "validated": true } } - - -In particular, check that the `TransactionResult` is the string `tesSUCCESS`. - -On the live network, you must also confirm that the `validated` field is set to the boolean `true`. If the field is not `true`, you might need to wait longer for the consensus process to finish; or your transaction may be unable to be included in a ledger for some reason. - -In stand-alone mode, the server automatically considers a ledger to be `validated` if it has been manually closed. diff --git a/reference-ledger-format.html b/reference-ledger-format.html index a8c8207562..ae73cab2e0 100644 --- a/reference-ledger-format.html +++ b/reference-ledger-format.html @@ -1059,6 +1059,7 @@
    • +

    The SignerEntries may be any combination of funded and unfunded addresses that use either secp256k1 or ed25519 keys.

    SignerEntry object

    Each member of the SignerEntries field is an object that describes that signer in the list. A SignerEntry has the following fields:

    diff --git a/reference-rippled.html b/reference-rippled.html index 814a405814..91be30de2d 100644 --- a/reference-rippled.html +++ b/reference-rippled.html @@ -7320,6 +7320,8 @@ rippled sign sssssssssssssssssssssssssssss '{"TransactionType": "Payment", "Acco
  • tooBusy - The transaction did not include paths, but the server is too busy to do pathfinding right now. Does not occur if you are connected as an admin.
  • noPath - The transaction did not include paths, and the server was unable to find a path by which this payment can occur.
    • +

    sign_for

    +

    The sign_for command provides one signature for a multi-signed transaction. takes an address and related secret, and a transaction in JSON form. (TODO: finish this section.) It generates a signature for that transaction, using the secret key and address specified. By using this, you can provide signatures that contribute to a multi-signed transaction. (The signatures should come from the members of your SignerList.)

    submit

    [Source]

    The submit method sends a transaction to the network to be confirmed and included in future ledgers.

    @@ -7588,6 +7590,8 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r
  • internalSubmit - An internal error occurred when submitting the transaction. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed.
  • internalJson - An internal error occurred when serializing the transaction to JSON. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed.
    • +

    submit_multisigned

    +

    The submit_multisigned command takes a transaction specification with multiple signatures and applies that transaction. (TODO: finish this section.)

    book_offers

    [Source]

    The book_offers method retrieves a list of offers, also known as the order book, between two currencies. If the results are very large, a partial result is returned with a marker so that subsequent requests can resume from where the previous one left off.

    diff --git a/reference-transaction-format.html b/reference-transaction-format.html index 0d5b611f51..46928e135b 100644 --- a/reference-transaction-format.html +++ b/reference-transaction-format.html @@ -147,15 +147,36 @@

    Transactions are only valid if signed, submitted, and accepted into a validated ledger version. There are many ways a transaction can fail.

    -

    Signing and Sending Transactions

    -

    Signing a transaction cryptographically proves that the person in charge of the account sending the transaction is authorized to do so. Only signed transactions can be submitted to the network and included in a validated ledger. A signed transaction is immutable: its contents cannot change, and the signature is not valid for any other transaction.

    -

    You sign a transaction using a secret key: either the master secret, or a regular secret if the account has a regular key pair associated with it. (See SetRegularKey for details.) If your account has a SignerList associated with it, you can use a multi-signature instead.

    -

    Typically, you create a transaction in JSON format first. Here is an example of an unsigned Payment-type transaction in JSON:

    +

    Authorizing Transactions

    +

    In the decentralized Ripple Consensus Ledger, a digital signature proves that a transaction is authorized to perform a specific set of actions. Only signed transactions can be submitted to the network and included in a validated ledger. A signed transaction is immutable: its contents cannot change, and the signature is not valid for any other transaction.

    +

    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 address. You can disable or enable the master key using an AccountSet transaction.
      • +
    • A single signature that matches a regular key enabled for the address. You can enable, remove, or replace a regular key using a SetRegularKey transaction.
      • +
    • A multi-signature that matches a list of signers enabled for the address. You can enable, remove, or replace a list of signers using a SignerListSet transaction.
      • +
    +

    Any signature type can authorize any type of transaction, with the following exceptions:

    + +

    Signing and Submitting Transactions

    +

    Sending a transaction to the Ripple Consensus Ledger involves several steps:

    +
      +
    1. Create an unsigned transaction in JSON format.
      2. +
    2. Use one or more signatures to authorize the transaction.
      3. +
    3. Submit a transaction to a rippled server. If the transaction is properly formed, the server provisionally applies the transaction to its current version of the ledger and relays the transaction to other members of the peer-to-peer network.
      4. +
    4. The consensus process determines which provisional transactions get included in the next validated ledger.
      5. +
    5. The rippled servers apply those transactions to the previous ledger in a canonical order and share their results.
      6. +
    6. If enough trusted validators created the exact same ledger, that ledger is declared validated and the results of the transactions in that ledger are immutable.
      7. +
    +

    Here is an example of an unsigned Payment-type transaction in JSON:

    {
   "TransactionType" : "Payment",
   "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
@@ -276,28 +297,9 @@
 }

    Multi-Signing

    -

    Multi-signing in Ripple is the act of authorizing transactions for the Ripple -Consensus Ledger by using a combination of multiple secret keys. Multi-signing -allows various use cases including:

    -
      -
    • If you require keys from different devices, a malicious user must compromise multiple machines in order to send transactions on your behalf.
      • -
    • If the keys to an account are in the custody of entirely different people, those people must collaborate in order to send transaction from that account.
      • -
    • Delegate a group of others who can send transactions for you if you are unavailable or unable to sign normally.
      • -
    • ... and more.
      • -
    -

    To set up multi-signing for an account, the process is straightforward:

    -
      -
    1. Use a SignerListSet transaction to define which accounts or keys can, together, authorize transactions for this account.
      2. -
    2. Optionally disable the master key with an AccountSet transaction using the asfDisableMaster flag.
      3. -
    3. Optionally remove the existing regular key (if any) with a SetRegularKey transaction.
      4. -
    -

    After an account has a SignerList associated with it, the process of submitting a multi-signed transaction is as follows:

    -
      -
    1. Create the transaction to be signed as a JSON object
      2. -
    2. Generate a signature for each account using the sign_for command.
      3. -
    3. Combine the signatures and submit using the submit_multisigned command.
      4. -
    -

    Main article: How to Multi-Sign

    +

    Multi-signing in Ripple is the act of 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 to the Ripple Consensus Protocol. You can use multi-signing in addition to, or instead of, a master key, a regular key, or both.

    +

    The SignerListSet transaction 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.

    +

    For more information, see How to Multi-Sign.

    Reliable Transaction Submission

    Reliably submitting transactions is the process of achieving both of the following:

      @@ -883,7 +885,7 @@ allows various use cases including:

      In rippled's WebSocket and JSON-RPC APIs, the TransferRate is represented as an integer, the amount that must be sent in order for 1 billion units to arrive. For example, a 20% transfer fee is represented as the value 1200000000. The value cannot be less than 1000000000. (Less than that would indicate giving away money for sending transactions, which is exploitable.) You can specify 0 as a shortcut for 1000000000, meaning no fee.

      SetRegularKey

      [Source]

      -

      A SetRegularKey transaction changes the regular key used by the account to sign future transactions.

      +

      A SetRegularKey transaction changes the regular key associated with an address.

      {
     "Flags": 0,
     "TransactionType": "SetRegularKey",
@@ -905,14 +907,15 @@ allows various use cases including:
    - - + +
    RegularKey StringAccount(Optional) The public key of a new keypair, to use as the regular key to this account, as a base-58-encoded string in the same format as an account address. If omitted, removes the existing regular key.AccountID(Optional) A base-58-encoded Ripple address to use as the regular key. If omitted, removes the existing regular key.
    -

    Instead of using an account's master key to sign transactions, you can set an alternate key pair, called the "Regular Key". As long as the public key for this key pair is set in the RegularKey field of an account this way, then the secret of the Regular Key pair can be used to sign transactions. (Other methods of signing transactions can also be used, including multi-signing or the master key.

    -

    A Regular Key pair is generated in the same way as any other Ripple keys (for example, with 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). The Master Key can be disabled but it cannot be changed. Therefore, it is beneficial to security sign transactions with a Regular Key instead of the master key whenever possible. For even greater security, you can use multi-signing, but multi-signing costs additional XRP in transaction fees and reserves.

    -

    If your regular key is compromised, but the master key is not, you can use a SetRegularKey transaction to regain control of your account. In some cases, you can even send a key reset transaction without paying the transaction cost.

    +

    In addition to the master key, which is mathematically-related to an address, you can associate at most 1 additional key pair with an address using this type of transaction. The additional key pair is called a regular key. If your address has a regular key pair defined, you can use the secret key of the regular key pair to authorize transactions.

    +

    A regular key pair is generated in the same way as any other Ripple keys (for example, with wallet_propose), but it can be changed. A master key pair is an intrinsic part of an address's identity (the address is derived from the master public key). You can disable a master key but you cannot change it.

    +

    You can protect your master secret by using a regular key instead of the master key to sign transactions where possible. If your regular key is compromised, but the master key is not, you can use a SetRegularKey transaction to regain control of your address. In some cases, you can even send a key reset transaction without paying the transaction cost.

    +

    For even greater security, you can use multi-signing, but multi-signing requires additional XRP for the transaction cost and reserve.

    OfferCreate

    [Source]

    An OfferCreate transaction is effectively a 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.

    @@ -1202,7 +1205,7 @@ allows various use cases including:

    SignerListSet

    [Source]

    -

    The SignerListSet transaction creates, modifies, or removes a list of signers that can be used to multi-sign a transaction.

    +

    The SignerListSet transaction creates, modifies, or removes a list of signers that can be used to multi-sign a transaction.

    Example SignerListSet:

    {
     "Flags": 0,
@@ -1252,13 +1255,14 @@ allows various use cases including:
    
 SignerEntries
 Array
 Array
-(Omitted when deleting) Array of SignerEntry objects, indicating the addresses and weights of signers in this list. A SignerList must have at least 1 member and no more than 8 members. No address may appear more than once in the list, nor may the Account submitting the transaction appear in the list.
+(Omitted when deleting) Array of SignerEntry objects, indicating the addresses and weights of signers in this list. A SignerList must have at least 1 member and no more than 8 members. No address may appear more than once in the list, nor may the Account submitting the transaction appear in the list.
 
 
 
 
    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 SignerQuorum to 0 and omit the SignerEntries field. Otherwise, the transaction fails with the error temMALFORMED. A transaction to delete a SignerList is considered successful even if there was no SignerList to delete.
    
 
    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 SignerWeight values in the list. Otherwise, the transaction fails with the error temMALFORMED.
    
-
    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 enabled) and the account does not have a Regular Key configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error tecNO_ALTERNATIVE_KEY.
    
+
    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 enabled) and the account does not have a Regular Key configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error tecNO_ALTERNATIVE_KEY.
    
 
    Pseudo-Transactions
    
 
    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.
    
 
    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:
    
diff --git a/tutorial-multisign.html b/tutorial-multisign.html
index 19e760bae1..572b70e63f 100644
--- a/tutorial-multisign.html
+++ b/tutorial-multisign.html
@@ -126,92 +126,60 @@
 
 
    
 
    
-
    Introduction to Multi-Signing
    
-
    Multi-signing in Ripple is the act of authorizing transactions for the Ripple Consensus Ledger by using a combination of multiple secret keys. After setting up multi-signing for an account, you can put the master secret in cold storage, or even disable the master key entirely. With multiple secret keys required to authorize a multi-signature, you can improve security in several ways.
    
+
    How to Multi-Sign
    
+
    Multi-signing is one of three ways to authorize transactions for the Ripple Consensus Ledger, alongside signing with regular keys and master keys. You can configure your address to allow any combination of the three methods to authorize transactions.
    
+
    Benefits of multi-signing include:
    
 
      
-
    • If you keep an account's keys on different devices, a malicious user must compromise multiple machines in order to send transactions on your behalf.
      • 
-
    • If the keys to an account are in the custody of entirely different people, those people must collaborate in order to send transaction from that account.
      • 
-
    • You can use the SignerList as a backup, to delegate a group of others who can send transactions for you if you are unavailable or unable to sign using your regular key.
      • 
-
    • Even more uses than can be described here.
      • 
+
    • You can require keys from different devices, so that a malicious actor must compromise multiple machines to send transactions on your behalf.
      • 
+
    • You can share custody of an address between multiple people, each of whom only has one of several keys necessary to send transactions from that address.
      • 
+
    • You can delegate the power to send transactions from your address to a group of people, who can control your address if you are unavailable or unable to sign normally.
      • 
+
    • ... and more.
      • 
 
    
+
    To use multi-signing:
    
+
      
+
    1. The Ripple peer-to-peer network must have multi-signing enabled.
      2. 
+
    2. Set up a list of signers on your account.
      3. 
+
    3. Send transactions using multiple signatures.
      4. 
+
    
 
    Availability of Multi-Signing
    
 
    Multi-signing is built into rippled starting with version 0.31.0. Because multi-signing is a change in transaction processing, the change is due to be enabled by an Amendment to the Ripple Consensus Protocol. This Amendment must be approved by a consensus of validators showing consistent support for the feature over a period of time. For more information, see Amendments.
    
-
    You can test multi-signing by running rippled in stand-alone mode with the Multi-Sign feature enabled. To enable Multi-Sign for testing, add the following stanza to your rippled.cfg:
    
+
    If you want to test multi-signing before it becomes available in the production network, or without risking real money, you can do so by running rippled in stand-alone mode with the MultiSign feature enabled. To enable multi-signing for testing, add the following stanza to your rippled.cfg:
    
 
    [features]
 MultiSign
 
    
-
    How to Multi-Sign
    
-
    The basic process of Multi-Signing a transaction is necessarily more complex than the process of signing a transaction with a single master key or regular key.
    
-
    1. (Optional) Generate keys for a new wallet
    
-
    This step is not strictly necessary. For this process, we generate and fund a new Ripple account and then set up multi-signing for that account. To set up multi-signing on an existing Ripple account, skip ahead to Step 4: creating a signer list.
    
+
    Setting up Multi-Signing
    
+
    To multi-sign transactions from a particular address, you must create a list of addresses that can contribute to a multi-signature for your address. This list is stored in the Ripple Consensus Ledger as a SignerList node. The following procedure demonstrates how to set up a SignerList for your address:
    
+
    1. Prepare a funded address
    
+
    You need a Ripple address that can send transactions, and has enough XRP available. Multi-signing requires more than the usual amount of XRP for the account reserve and transaction cost, increasing with the number of signers and signatures you use.
    
+
    If you started rippled in stand-alone mode with a new genesis ledger, you must:
    
+
      
+
    1. Generate keys for a new address, or reuse keys you already have.
      2. 
+
    2. Submit a Payment transaction to fund the new address from the genesis account. (Send at least 100,000,000 drops of XRP.)
      3. 
+
    3. Manually close the ledger.
      4. 
+
    
+
    2. Prepare member keys
    
+
    You need several sets of Ripple keys (address and secret) to include as members of your SignerList. These can be funded addresses that exist in the ledger, or you can generate new addresses using the wallet_propose command. For example:
    
 
    $ rippled wallet_propose
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
 {
-   "result" : {
-      "account_id" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
-      "key_type" : "secp256k1",
-      "master_key" : "LOST FOUR ALOE ABE SLUG ITS HACK MAGI SOCK BASS APE DELL",
-      "master_seed" : "sn1CmMEkPijNrfyr8HJqsgP416dr3",
-      "master_seed_hex" : "E42AD02985BB56923DFC1D002DB510B3",
-      "public_key" : "aBQgQDutj8YUc7ZRtfj86dnzPCvPcRHtUszxeCCDMgZ7Zq1Thfri",
-      "public_key_hex" : "03668837C3DCA0F4858587703524E61BB40128B9F6910B80B4655E152CAEE2E321",
-      "status" : "success"
-   }
+    "result" : {
+        "account_id" : "rnRJ4dpSBKDR2M1itf4Ah6tZZm5xuNZFPH",
+        "key_type" : "secp256k1",
+        "master_key" : "FLOG SEND GOES CUFF GAGE FAT ANTI DEL GUM TIRE ISLE BEAR",
+        "master_seed" : "snheH5UUjU4CWqiNVLny2k21TyKPC",
+        "master_seed_hex" : "A9F859765EB8614D26809836382AFB82",
+        "public_key" : "aBR4hxFXcDNHnGYvTiqb2KU8TTTV1cYV9wXTAuz2DjBm7S8TYEBU",
+        "public_key_hex" : "03C09A5D112B393D531E4F092E3A5769A5752129F0A9C55C61B3A226BB9B567B9B",
+        "status" : "success"
+    }
 }
 
    
-
    As always, be sure that an account's secret key never gets transmitted to anyone you don't trust with full control of that account, and certainly not unencrypted over the network.
    
-
    2. Fund the new account with an existing wallet
    
-
    Again, this step is only necessary if you are setting up a new account to use multi-signing for this example.
    
-
    $ rippled submit snoPBrXtMeMyMHUVTgbuqAfg1SUTb '{
-> "TransactionType": "Payment",
-> "Account": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
-> "Destination": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
-> "Amount": "100000000",
-> "Flags": 2147483648
-> }'
-Loading: "/home/mduo13/.config/ripple/rippled.cfg"
-Connecting to 127.0.0.1:5005
-{
-   "result" : {
-      "engine_result" : "tesSUCCESS",
-      "engine_result_code" : 0,
-      "engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
-      "status" : "success",
-      "tx_blob" : "12000022800000002400000004614000000005F5E10068400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100ED13CDD4B8F6BA836F7732A029316393A5D9B50712FE79972236ECAD850F813802203148D8944B0BF3D30A3177EFCE6A9F12B3F5A3C3AFF7B73E9A7D65B370E526EE8114B5F762798A53D543A014CAF8B297CFF8F2F937E88314A3780F5CB5A44D366520FC44055E8ED44D9A2270",
-      "tx_json" : {
-         "Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
-         "Amount" : "100000000",
-         "Destination" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
-         "Fee" : "10",
-         "Flags" : 2147483648,
-         "Sequence" : 4,
-         "SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
-         "TransactionType" : "Payment",
-         "TxnSignature" : "3045022100ED13CDD4B8F6BA836F7732A029316393A5D9B50712FE79972236ECAD850F813802203148D8944B0BF3D30A3177EFCE6A9F12B3F5A3C3AFF7B73E9A7D65B370E526EE",
-         "hash" : "64FAA44F671E2CBB4E1E4156FCDA72BA3C32EF951C94EDDFEBEBE8BEC3F55696"
-      }
-   }
-}
-
    
-
    Make sure that the engine_result value in the response is tesSUCCESS. Otherwise, the transaction failed.
    
-
    3. Close the ledger
    
-
    If you are using the live network, you can wait for the ledger to close automatically as the result of consensus. This typically takes 4-7 seconds.
    
-
    If you are running rippled in stand-alone mode, you must manually close the ledger with the ledger_accept command.
    
-
    $ rippled ledger_accept
-Loading: "/home/mduo13/.config/ripple/rippled.cfg"
-Connecting to 127.0.0.1:5005
-{
-   "result" : {
-      "ledger_current_index" : 16061437,
-      "status" : "success"
-   }
-}
-
    
-
    4. Create a SignerList on the new account with a SignerListSet transaction
    
-
    Before you can multi-sign transactions, you must associate a SignerList with your account, so that RCL knows which keys can be used to sign for you. You do this with a SignerListSet transaction.
    
-
    The Account values in your SignerList can be the addresses of funded accounts that exist in the ledger, or you can generate new addresses that are not currently in use. For funded accounts in the SignerList, a regular key associated with the account can contribute to a multi-signature, and the master key secret can be used only if it is not disabled. For unfunded addresses, only the master key associated with that address can be used to contribute to a multi-signature.
    
+
    Take note of the account_id (Ripple Address) and master_seed (Ripple secret key) for each one you generate.
    
+
    3. Send SignerListSet transaction
    
+
    Sign and submit a SignerListSet transaction in the normal (single-signature) way. This associates a SignerList with your Ripple address, so that a combination of signatures from the members of that SignerList can multi-sign later transactions on your behalf.
    
 
    In this example, the SignerList has 3 members, with the weights and quorum set up such that multi-signed transactions need a signature from rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other two members of the list.
    
+
    Caution: Never submit a secret key to a server you do not control. Do not transmit a secret key unencrypted over the network.
    
 
    $ rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{
 >     "Flags": 0,
 >     "TransactionType": "SignerListSet",
@@ -282,10 +250,11 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    Make sure that the engine_result value in the response is tesSUCCESS. Otherwise, the transaction failed.
    
-
    5. Close the ledger again
    
-
    As before, on the live network, you can wait for the ledger to close automatically.
    
-
    If running rippled in stand-alone mode, use the ledger_accept command to manually close the ledger:
    
+
    Make sure that the Transaction Result is tesSUCCESS. Otherwise, the transaction failed.
    
+
    Note: The more members in the SignerList, the more XRP your address must have for purposes of the owner reserve. If your address does not have enough XRP, the transaction fails with tecINSUFFICIENT_RESERVE. See also: SignerLists and Reserves.
    
+
    4. Close the ledger
    
+
    On the live network, you can wait 4-7 seconds for the ledger to close automatically.
    
+
    If you're running rippled in stand-alone mode, use the ledger_accept command to manually close the ledger:
    
 
    $ rippled ledger_accept
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
@@ -296,8 +265,9 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    6. Confirm the presence of the new signer list using account_objects
    
-
    Normally an account can own many objects of different types (such as trust lines and offers). For this tutorial, we created a new account, so the SignerList is the only object in the response from the account_objects command.
    
+
    5. Confirm the new signer list
    
+
    Use the account_objects command to confirm that the SignerList is associated with the address in the latest validated ledger.
    
+
    Normally, an account can own many objects of different types (such as trust lines and offers). If you funded a new address for this tutorial, the SignerList is the only object in the response.
    
 
    $ rippled account_objects rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC validated
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
@@ -334,30 +304,6 @@ Connecting to 127.0.0.1:5005
             "SignerListID" : 0,
             "SignerQuorum" : 3,
             "index" : "79FD203E4DDDF2EA78B798C963487120C048C78652A28682425E47C96D016F92"
-         },
-         {
-            "Balance" : {
-               "currency" : "USD",
-               "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
-               "value" : "0"
-            },
-            "Flags" : 2162688,
-            "HighLimit" : {
-               "currency" : "USD",
-               "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
-               "value" : "0"
-            },
-            "HighNode" : "0000000000000000",
-            "LedgerEntryType" : "RippleState",
-            "LowLimit" : {
-               "currency" : "USD",
-               "issuer" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
-               "value" : "100"
-            },
-            "LowNode" : "0000000000000000",
-            "PreviousTxnID" : "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6",
-            "PreviousTxnLgrSeq" : 6,
-            "index" : "93E317B32022977C77810A2C558FBB28E30E744C68E73720622B797F957EC5FA"
          }
       ],
       "ledger_hash" : "56E81069F06492FB410A70218C08169BE3AB3CFD5AEA20E999662D81DC361D9F",
@@ -367,35 +313,50 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    7. Create a new transaction that you plan to multi-sign
    
-
    You have to specify everything about this transaction, including Fee and
-Sequence. Also include the field SigningPubKey as an empty string -- this
-indicates that the transaction is multi-signed.
    
-
    Here's an example transaction we can send from our test account:
    
+
    If the SignerList is present with the expected contents, then your address is ready to multi-sign.
    
+
    6. Further steps
    
+
    At this point, your address is ready to send a multi-signed transaction. You may also want to:
    
+
+
    Sending a Multi-Signed Transaction
    
+
    Before you can multi-sign a transaction, first check that multi-sign is available and set 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, 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 increases in that time.
    
+
    Here's an example transaction ready to be multi-signed:
    
 
    {
     "TransactionType": "TrustSet",
-    "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
+    "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
     "Flags": 262144,
     "LimitAmount": {
-      "currency": "USD",
-      "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
-      "value": "100"
+        "currency": "USD",
+        "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+        "value": "100"
     },
     "Sequence": 2,
-    "SigningPubKey":"",
+    "SigningPubKey": "",
     "Fee": "30000"
 }
 
    
-
    (If you started from a fresh ledger, you first need to fund the account
-specified by the issuer in this example, and then manually close the ledger.)
    
-
    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 fee, 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 load fee increases in that time.
    
-
    8. Get one signature
    
-
    The sign_for command takes an address and related secret, and a transaction in JSON form. It generates a signature for that transaction, using the secret key and address specified. By using this, you can provide signatures that contribute to a multi-signed transaction. (The signatures should come from the members of your SignerList.)
    
-
    $ rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW <rsA2L..'s secret> '{ "TransactionType": "TrustSet", "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", "Flags": 262144, "LimitAmount": { "currency": "USD", "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "value": "100" }, "Sequence": 2, "SigningPubKey":"", "Fee": "30000" }'
+
    (This transaction creates an accounting relationship from rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC to rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh with a maximum balance of 100 USD.)
    
+
    2. Get one signature
    
+
    Use the sign_for command with the secret key and address of one of the members of your SignerList to get a signature for that member.
    
+
    Caution: Never submit a secret key to a server you do not control. Do not transmit a secret key unencrypted over the network.
    
+
    $ rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW <rsA2L..'s secret> '{
+>     "TransactionType": "TrustSet",
+>     "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+>     "Flags": 262144,
+>     "LimitAmount": {
+>         "currency": "USD",
+>         "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+>         "value": "100"
+>     },
+>     "Sequence": 2,
+>     "SigningPubKey": "",
+>     "Fee": "30000"
+> }'
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
 {
@@ -428,10 +389,14 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    Save the tx_json field of the response: it has the new signature in the Signers field.
    
-
    The tx_blob is not very useful at this point, unless you're "multi-signing" a transaction with only one signature.
    
-
    9. Get additional signatures the same way
    
-
    You can collect additional signatures for the same transaction in parallel by using the sign_for command with the same transaction JSON. You can also collect additional signatures in serial: if you provide the tx_json value from a previous sign_for response, the response appends a signature to the existing Signers array.
    
+
    Save the tx_json field of the response: it has the new signature in the Signers field. You can discard the value of the tx_blob field.
    
+
    3. Get additional signatures
    
+
    You can collect additional signatures in parallel or in serial:
    
+
      
+
    • In parallel: Use the sign_for command with the original JSON for the transaction. Each response has a single signature in the Signers array.
      • 
+
    • In serial: Use the sign_for command with the tx_json value from the previous sign_for response. Each response adds a new signature to the existing Signers array.
      • 
+
    
+
    Caution: Never submit a secret key to a server you do not control. Do not transmit a secret key unencrypted over the network.
    
 
    $ rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v <rUpy..'s secret> '{
 >    "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
 >    "Fee" : "30000",
@@ -494,10 +459,10 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    Depending on the SignerList you configured, you may need to repeat this step several times in order to get signatures from all the necessary parties.
    
-
    10. Combine the signatures and submit
    
-
    The commandline syntax for the submit_multisigned command takes a single transaction JSON containing a Signers array, so you need to combine all the signatures from the all the responses into a single Signers array field with all the signatures. If you collected signatures serially, the tx_json from the last response is sufficient.
    
-
    The submit_multisigned command actually submits the transaction for inclusion in the ledger. In online mode, this also relays it to other members of the network.
    
+
    Depending on the SignerList you configured, you may need to repeat this step several times to get signatures from all the necessary parties.
    
+
    4. Combine signatures and submit
    
+
    If you collected the signatures in serial, the tx_json from the last sign_for response has all the signatures assembled, so you can use that as the argument to the submit_multisigned command.
    
+
    If you collected the signatures in parallel, you must manually construct a tx_json object with all the signatures included. Take the Signers arrays from all the sign_for responses, and combine their contents into a single Signers array that has each signature. Add the combined Signers array to the original transaction JSON value, and use that as the argument to the submit_multisigned command.
    
 
    $ rippled submit_multisigned '{
 >              "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
 >              "Fee" : "30000",
@@ -568,9 +533,9 @@ Connecting to 127.0.0.1:5005
 }
 
    
 
    Take note of the hash value from the response so you can check the results of the transaction later.  (In this case, the hash is BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6.)
    
-
    14. Close the ledger one last time
    
-
    As before, on the live network, you can wait 4-7 seconds for the ledger to close automatically.
    
-
    If running rippled in stand-alone mode, use the ledger_accept command to manually close the ledger:
    
+
    5. Close the ledger
    
+
    If you are using the live network, you can wait 4-7 seconds for the ledger to close automatically.
    
+
    If you're running rippled in stand-alone mode, use the ledger_accept command to manually close the ledger:
    
 
    $ rippled ledger_accept
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
@@ -581,8 +546,10 @@ Connecting to 127.0.0.1:5005
    }
 }
 
    
-
    15. Confirm the results of the transaction
    
-
    Use the hash value from the response to the submit_multisigned command.
    
+
    6. Confirm transaction results
    
+
    Use the hash value from the response to the submit_multisigned command to look up the transaction using the tx command. In particular, check that the TransactionResult is the string tesSUCCESS.
    
+
    On the live network, you must also confirm that the validated field is set to the boolean true. If the field is not true, you might need to wait longer for the consensus process to finish; or your transaction may be unable to be included in a ledger for some reason.
    
+
    In stand-alone mode, the server automatically considers a ledger to be validated if it has been manually closed.
    
 
    $ rippled tx BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6
 Loading: "/home/mduo13/.config/ripple/rippled.cfg"
 Connecting to 127.0.0.1:5005
@@ -694,9 +661,6 @@ Connecting to 127.0.0.1:5005
     }
 }
 
    
-
    In particular, check that the TransactionResult is the string tesSUCCESS.
    
-
    On the live network, you must also confirm that the validated field is set to the boolean true. If the field is not true, you might need to wait longer for the consensus process to finish; or your transaction may be unable to be included in a ledger for some reason.
    
-
    In stand-alone mode, the server automatically considers a ledger to be validated if it has been manually closed.
    
 
    
 
    
 

From d1a537f4343ecb40e2a1608af7ec14d265de4bfa Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Wed, 30 Mar 2016 13:45:05 -0700
Subject: [PATCH 16/40] amendments updates

---
 concept-amendments.html                 | 165 ++++++++++++++++++++++--
 content/concept-amendments.md           | 125 ++++++++++++++++--
 content/reference-transaction-format.md |  45 +++++--
 reference-transaction-format.html       |  80 ++++++++++--
 4 files changed, 367 insertions(+), 48 deletions(-)

diff --git a/concept-amendments.html b/concept-amendments.html
index cb53e2322e..ba47eee9d5 100644
--- a/concept-amendments.html
+++ b/concept-amendments.html
@@ -132,21 +132,162 @@
 
    
 
    
 
    Amendments
    
-
    The Amendments system provides a means of introducing new features to the decentralized Ripple consensus network without causing disruptions. The amendments system works by utilizing the core consensus process of the network to approve any changes by showing continuous support for two weeks before they go into effect.
    
+
    The Amendments system provides a means of introducing new features to the decentralized Ripple consensus network without causing disruptions. The amendments system works by utilizing the core consensus process of the network to approve any changes by showing continuous support before those changes go into effect. An amendment normally requires 80% support for two weeks before it can apply.
    
+
    When an Amendment has been enabled, it applies permanently to all ledger versions after the one that included it. You cannot disable an Amendment, unless you introduce a new Amendment to do so.
    
 
    Background
    
-
    Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. This could cause anything from minor inconveniences (a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot rely on their own) to serious problems: consensus might halt from validating ledgers because servers are unable to reach a majority who agree on the same result.
    
-
    In theory, this could prompt a situation where the Ripple Consensus Ledger ceases to function because only a portion of validators have upgraded to a new version of the software.
    
-
    Amendments fix that problem while also providing advance notice of when any transaction processing changes will go into effect, so that any users and businesses who rely on the behavior of the Ripple Consensus Ledger have fair warning in advance. API changes that do not impact the Consensus process do not require Amendments.
    
-
    Amendment Lifecycle
    
-
    An amendment is a fully-functional feature or change, ready to apply as soon as a consensus of servers can handle it. A server that wants to use an amendment must have functional code for two modes: without the amendment (previous behavior) and with the amendment (new behavior). Every amendment has a unique identifying string, which should indicate who developed it, in order to avoid potential overlap.
    
-
    Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger: at this time, rippled validator servers submit votes in favor of specific amendments alongside their validations for that ledger.
    
-
    In the flag ledger itself, there is nothing unusual. However, during that time, the servers look at the votes of the validators they trust, and decide whether to insert an Amendment pseudo-transaction into the following ledger, with flags to indicate what it thinks happened:
    
+
    Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. This could cause anything from minor inconveniences (a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot rely on their own) to serious problems: consensus might be unable to validate new ledger versions because servers are unable to reach a consensus who agree to the exact same result.
    
+
    In theory, this could prompt a situation where the Ripple Consensus Ledger cannot make progress because only a portion of validators have upgraded to a new version of the software. Amendments provide solution to this problem, so that new features can be enabled only when enough validators support those features.
    
+
    Users and businesses who rely on the Ripple Consensus Ledger can also use Amendments to provide advance notice of changes in transaction processing that might affect their business. However, API changes that do not impact transaction processing or the consensus process do not require Amendments.
    
+
    Amendment Process
    
+
    An amendment is a fully-functional feature or change, ready to apply when a consensus of servers can handle it. A rippled server that wants to use an amendment has business logic for two modes: without the amendment (previous behavior) and with the amendment (new behavior). Every amendment has a unique identifying hex value and a short name. The short name is for human use, and does not affect the status of the amendment.
    
+
    Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger: at this time, rippled validator servers submit votes in favor of specific amendments alongside their validations for that ledger. (Fee Voting also occurs around flag ledgers.)
    
+
    In the flag ledger itself, there is nothing unusual. However, during that time, the servers look at the votes of the validators they trust, and decide whether to insert an EnableAmendment pseudo-transaction into the following ledger. The flags of an EnableAmendment pseudo-transaction indicate what the server thinks happened:
    
 
      
-
    • The tfGotMajority flag means that support for a feature has increased across the threshold of 80% of trusted validators.
      • 
-
    • The tfLostMajority flag means that support for a feature has decreased across the threshold of 80% of trusted validators.
      • 
-
    • An Amendment pseudo-transaction with no flags means that support for a feature has been enabled. This is called the "Enabled" Amendment.
      • 
+
    • The tfGotMajority flag means that support for the amendment has increased to at least 80% of trusted validators.
      • 
+
    • The tfLostMajority flag means that support for the amendment has decreased to less than 80% of trusted validators.
      • 
+
    • An EnableAmendment pseudo-transaction with no flags means that support for the amendment has been enabled. (The change in transaction processing applies to every ledger after this one.)
      • 
 
    
-
    A server only inserts the "Enabled" Amendment if there is a validated ledger which closed at least two weeks prior to the current flag ledger, with a Got-Majority Amendment psuedo-transaction, and no Lost-Majority Amendment psuedo-transactions for the same feature in the validated ledgers in between.
    
+
    A server only inserts the pseudo-transaction to enable an amendment if all of the following conditions are met:
    
+
      
+
    • There is a validated ledger which closed at least two weeks prior to the current flag ledger, which includes an EnableAmendment pseudo-transaction for this amendment with the tfGotMajority flag enabled.
      • 
+
    • There are no EnableAmendment pseudo-transactions for this amendment with the tfLostMajority flag enabled in the validated ledgers between the tfGotMajority pseudo-transaction and the current ledger.
      • 
+
    
+
    It is theoretically possible (but extremely unlikely) that a tfLostMajority EnableAmendment pseudo-transaction could be included in the same ledger as the pseudo-transaction to enable an amendment. In this case, the pseudo-transaction with the tfLostMajority pseudo-transaction has no effect.
    
+
    Amendment Voting
    
+
    Operators of rippled validators can choose which amendments to support or reject using the feature command. This decides which amendments the validator votes for in the amendment process. By default, rippled votes in favor of every amendment it knows about.
    
+
    The operator of a rippled validator can "veto" an amendment using the feature command. In this case, that validator never sends a vote in favor of the amendment. If enough trusted validators veto an amendment, then the amendment does not apply.
    
+
    As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. Currently, Ripple recommends only trusting the 5 default validators that Ripple (the company) operates. For now, trusting only those validators is sufficient to coordinate with Ripple on releasing new features.
    
+
    Known Amendments
    
+
    The following is a comprehensive list of all known amendments and their status on the production Ripple Consensus Ledger:
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    NameIntroducedEnabled
    Ticketsv0.31.0TBD
    SusPayv0.31.0TBD
    TrustSetAuthv0.30.0TBD
    MultiSignv0.31.0Expected 2016-04-18
    FeeEscalationv0.31.0Expected 2016-04-11
    
+
    FeeEscalation
    
+
+
+
+
+
+
+
+
+
+
+
+
    Amendment ID
    42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE
    
+
    Changes the way the transaction cost applies to proposed transactions. Modifies the consensus process to prioritize transactions that pay a higher transaction cost.
    
+
    This amendment introduces a fixed-size transaction queue for transactions that were not able to be included in the previous consensus round. If the rippled servers in the consensus network are under heavy load, they queue the transactions with the lowest transaction cost for later ledgers. Each consensus round prioritizes transactions from the queue with the largest transaction cost (Fee value), and includes as many transactions as the consensus network can process. If the transaction queue is full, transactions drop from the queue entirely, starting with the ones that have the lowest transaction cost.
    
+
    While the consensus network is under heavy load, legitimate users can pay a higher transaction cost to make sure their transactions get processed. The situation persists until the entire backlog of cheap transactions is processed or discarded.
    
+
    A transaction remains in the queue until one of the following happens:
    
+
      
+
    • It gets applied to a validated ledger (regardless of success or failure)
      • 
+
    • It becomes invalid (for example, the LastLedgerSequence causes it to expire)
      • 
+
    • It gets dropped because there are too many transactions in the queue with a higher transaction cost.
      • 
+
    
+
    MultiSign
    
+
+
+
+
+
+
+
+
+
+
+
+
    Amendment ID
    4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373
    
+
    Introduces simple multi-signing as a way to authorize transactions. Creates the SignerList ledger node type and the SignerListSet transaction type. Adds the optional Signers field to all transaction types. Modifies some transaction result codes.
    
+
    This amendment allows addresses to have a list of signers who can authorize transactions from that address in a multi-signature. The list has a quorum and 1 to 8 weighted signers. This allows various configurations, such as "any 3-of-5" or "signature from A plus any other two signatures."
    
+
    Signers can be funded or unfunded addresses. Funded addresses in a signer list can sign using a regular key (if defined) or master key (unless disabled). Unfunded addresses can sign with a master key. This amendment does not allow second-level multi-signing (signers using multi-signatures to contribute to multi-signatures). Multi-signed transactions have the same permissions as transactions signed with a regular key.
    
+
    An address with a SignerList can disable the master key even without a regular key, or remove a regular key even if the master key is disabled. Therefore, the tecMASTER_DISABLED transaction result code is renamed tecNO_ALTERNATIVE_KEY. The tecNO_REGULAR_KEY transaction result is retired and replaced with tecNO_ALTERNATIVE_KEY. Additionally, this amendment adds the following new transaction result codes:
    
+
      
+
    • temBAD_SIGNER
      • 
+
    • temBAD_QUORUM
      • 
+
    • temBAD_WEIGHT
      • 
+
    • tefBAD_SIGNATURE
      • 
+
    • tefBAD_QUORUM
      • 
+
    • tefNOT_MULTI_SIGNING
      • 
+
    • tefBAD_AUTH_MASTER
      • 
+
    
+
    SusPay
    
+
+
+
+
+
+
+
+
+
+
+
+
    Amendment ID
    DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13
    
+
    Provides "Suspended Payments" for XRP as a means of escrow within the Ripple Consensus Ledger. Creates the SuspendedPayment ledger node type and the new transaction types SuspendedPaymentCreate, SuspendedPaymentFinish, and SuspendedPaymentCancel.
    
+
    This amendment is still in development. The current version is enabled on the Ripple Test Net.
    
+
    TrustSetAuth
    
+
+
+
+
+
+
+
+
+
+
+
+
    Amendment ID
    6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC
    
+
    Allows pre-authorization of accounting relationships (zero-balance trust lines) when using Authorized Accounts.
    
+
    With this amendment enabled, a TrustSet transaction with tfSetfAuth enabled can create a new RippleState ledger node even if it keeps all the other values of the RippleState node in their default state. The new RippleState node has the lsfLowAuth or lsfHighAuth flag enabled accordingly. The sender of the transaction must have lsfRequireAuth enabled.
    
+
    Tickets
    
+
+
+
+
+
+
+
+
+
+
+
+
    Amendment ID
    C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490
    
+
    Introduces Tickets as a way to reserve a transaction sequence number for later execution. Creates the Ticket ledger node type and the transaction types TicketCreate and TicketCancel.
    
+
    This amendment is still in development.
    
 
    
 
    
 
diff --git a/content/concept-amendments.md b/content/concept-amendments.md
index 2d7e63d7d3..4cc117f982 100644
--- a/content/concept-amendments.md
+++ b/content/concept-amendments.md
@@ -1,25 +1,126 @@
 # Amendments #
 
-The Amendments system provides a means of introducing new features to the decentralized Ripple consensus network without causing disruptions. The amendments system works by utilizing the core consensus process of the network to approve any changes by showing continuous support for two weeks before they go into effect.
+The Amendments system provides a means of introducing new features to the decentralized Ripple consensus network without causing disruptions. The amendments system works by utilizing the core consensus process of the network to approve any changes by showing continuous support before those changes go into effect. An amendment normally requires **80% support for two weeks** before it can apply.
+
+When an Amendment has been enabled, it applies permanently to all ledger versions after the one that included it. You cannot disable an Amendment, unless you introduce a new Amendment to do so.
+
 
 ## Background ##
 
-Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. This could cause anything from minor inconveniences (a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot rely on their own) to serious problems: consensus might halt from validating ledgers because servers are unable to reach a majority who agree on the same result.
+Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. This could cause anything from minor inconveniences (a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot rely on their own) to serious problems: consensus might be unable to validate new ledger versions because servers are unable to reach a consensus who agree to the exact same result.
 
-In theory, this could prompt a situation where the Ripple Consensus Ledger ceases to function because only a portion of validators have upgraded to a new version of the software.
+In theory, this could prompt a situation where the Ripple Consensus Ledger cannot make progress because only a portion of validators have upgraded to a new version of the software. Amendments provide solution to this problem, so that new features can be enabled only when enough validators support those features.
 
-Amendments fix that problem while also providing advance notice of when any transaction processing changes will go into effect, so that any users and businesses who rely on the behavior of the Ripple Consensus Ledger have fair warning in advance. API changes that do not impact the Consensus process do not require Amendments.
+Users and businesses who rely on the Ripple Consensus Ledger can also use Amendments to provide advance notice of changes in transaction processing that might affect their business. However, API changes that do not impact transaction processing or [the consensus process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/) do not require Amendments.
 
-## Amendment Lifecycle ##
 
-An amendment is a fully-functional feature or change, ready to apply as soon as a consensus of servers can handle it. A server that wants to use an amendment must have functional code for two modes: without the amendment (previous behavior) and with the amendment (new behavior). Every amendment has a unique identifying string, which should indicate who developed it, in order to avoid potential overlap.
+## Amendment Process ##
 
-Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger: at this time, `rippled` validator servers submit votes in favor of specific amendments alongside their validations for that ledger.
+An amendment is a fully-functional feature or change, ready to apply when a consensus of servers can handle it. A `rippled` server that wants to use an amendment has business logic for two modes: without the amendment (previous behavior) and with the amendment (new behavior). Every amendment has a unique identifying hex value and a short name. The short name is for human use, and does not affect the status of the amendment.
 
-In the flag ledger itself, there is nothing unusual. However, during that time, the servers look at the votes of the validators they trust, and decide whether to insert an `Amendment` pseudo-transaction into the following ledger, with flags to indicate what it thinks happened:
+Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger: at this time, `rippled` validator servers submit votes in favor of specific amendments alongside their validations for that ledger. ([Fee Voting](concept-fee-voting.html) also occurs around flag ledgers.)
 
-* The `tfGotMajority` flag means that support for a feature has increased across the threshold of 80% of trusted validators.
-* The `tfLostMajority` flag means that support for a feature has decreased across the threshold of 80% of trusted validators.
-* An Amendment pseudo-transaction with no flags means that support for a feature has been enabled. This is called the _"Enabled"_ Amendment.
+In the flag ledger itself, there is nothing unusual. However, during that time, the servers look at the votes of the validators they trust, and decide whether to insert an [`EnableAmendment` pseudo-transaction](reference-transaction-format.html#enableamendment) into the following ledger. The flags of an EnableAmendment pseudo-transaction indicate what the server thinks happened:
 
-A server only inserts the "Enabled" Amendment if there is a validated ledger which closed at least two weeks prior to the current flag ledger, with a Got-Majority Amendment psuedo-transaction, and no Lost-Majority Amendment psuedo-transactions for the same feature in the validated ledgers in between.
+* The `tfGotMajority` flag means that support for the amendment has increased to at least 80% of trusted validators.
+* The `tfLostMajority` flag means that support for the amendment has decreased to less than 80% of trusted validators.
+* An EnableAmendment pseudo-transaction with no flags means that support for the amendment has been enabled. (The change in transaction processing applies to every ledger after this one.)
+
+A server only inserts the pseudo-transaction to enable an amendment if all of the following conditions are met:
+
+* There is a validated ledger which closed at least two weeks prior to the current flag ledger, which includes an EnableAmendment pseudo-transaction for this amendment with the `tfGotMajority` flag enabled.
+* There are no EnableAmendment pseudo-transactions for this amendment with the `tfLostMajority` flag enabled in the validated ledgers between the `tfGotMajority` pseudo-transaction and the current ledger.
+
+It is theoretically possible (but extremely unlikely) that a `tfLostMajority` EnableAmendment pseudo-transaction could be included in the same ledger as the pseudo-transaction to enable an amendment. In this case, the pseudo-transaction with the `tfLostMajority` pseudo-transaction has no effect.
+
+## Amendment Voting ##
+
+Operators of `rippled` validators can choose which amendments to support or reject using the [`feature` command](reference-rippled.html#feature). This decides which amendments the validator votes for in the [amendment process](#amendment-process). By default, `rippled` votes in favor of every amendment it knows about.
+
+The operator of a `rippled` validator can "veto" an amendment using the [`feature` command](reference-rippled.html#feature). In this case, that validator never sends a vote in favor of the amendment. If enough trusted validators veto an amendment, then the amendment does not apply.
+
+As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. Currently, Ripple recommends only trusting the 5 default validators that Ripple (the company) operates. For now, trusting only those validators is sufficient to coordinate with Ripple on releasing new features.
+
+
+
+# Known Amendments #
+
+The following is a comprehensive list of all known amendments and their status on the production Ripple Consensus Ledger:
+
+| Name                            | Introduced | Enabled |
+|---------------------------------|------------|---------|
+| [Tickets](#tickets)             | v0.31.0    | TBD |
+| [SusPay](#suspay)               | v0.31.0    | TBD |
+| [TrustSetAuth](#trustsetauth)   | v0.30.0    | TBD |
+| [MultiSign](#multisign)         | v0.31.0    | Expected 2016-04-18 |
+| [FeeEscalation](#feeescalation) | v0.31.0    | Expected 2016-04-11 |
+
+## FeeEscalation ##
+
+| Amendment ID |
+|--------------|
+| 42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE |
+
+Changes the way the [transaction cost](concept-transaction-cost.html) applies to proposed transactions. Modifies the consensus process to prioritize transactions that pay a higher transaction cost.
+
+This amendment introduces a fixed-size transaction queue for transactions that were not able to be included in the previous consensus round. If the `rippled` servers in the consensus network are under heavy load, they queue the transactions with the lowest transaction cost for later ledgers. Each consensus round prioritizes transactions from the queue with the largest transaction cost (`Fee` value), and includes as many transactions as the consensus network can process. If the transaction queue is full, transactions drop from the queue entirely, starting with the ones that have the lowest transaction cost.
+
+While the consensus network is under heavy load, legitimate users can pay a higher transaction cost to make sure their transactions get processed. The situation persists until the entire backlog of cheap transactions is processed or discarded.
+
+A transaction remains in the queue until one of the following happens:
+
+* It gets applied to a validated ledger (regardless of success or failure)
+* It becomes invalid (for example, the [`LastLedgerSequence`](reference-transaction-format.html#lastledgersequence) causes it to expire)
+* It gets dropped because there are too many transactions in the queue with a higher transaction cost.
+
+## MultiSign ##
+
+| Amendment ID |
+|--------------|
+| 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 |
+
+Introduces simple [multi-signing](reference-transaction-format.html#multi-signing) as a way to authorize transactions. Creates the [`SignerList` ledger node type](reference-ledger-format.html#signerlist) and the [`SignerListSet` transaction type](reference-transaction-format.html#signerlistset). Adds the optional `Signers` field to all transaction types. Modifies some transaction result codes.
+
+This amendment allows addresses to have a list of signers who can authorize transactions from that address in a multi-signature. The list has a quorum and 1 to 8 weighted signers. This allows various configurations, such as "any 3-of-5" or "signature from A plus any other two signatures."
+
+Signers can be funded or unfunded addresses. Funded addresses in a signer list can sign using a regular key (if defined) or master key (unless disabled). Unfunded addresses can sign with a master key. This amendment does not allow second-level multi-signing (signers using multi-signatures to contribute to multi-signatures). Multi-signed transactions have the same permissions as transactions signed with a regular key.
+
+An address with a SignerList can disable the master key even without a regular key, or remove a regular key even if the master key is disabled. Therefore, the `tecMASTER_DISABLED` transaction result code is renamed `tecNO_ALTERNATIVE_KEY`. The `tecNO_REGULAR_KEY` transaction result is retired and replaced with `tecNO_ALTERNATIVE_KEY`. Additionally, this amendment adds the following new [transaction result codes](reference-transaction-format.html#result-categories):
+
+* `temBAD_SIGNER`
+* `temBAD_QUORUM`
+* `temBAD_WEIGHT`
+* `tefBAD_SIGNATURE`
+* `tefBAD_QUORUM`
+* `tefNOT_MULTI_SIGNING`
+* `tefBAD_AUTH_MASTER`
+
+## SusPay ##
+
+| Amendment ID |
+|--------------|
+| DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 |
+
+Provides "Suspended Payments" for XRP as a means of escrow within the Ripple Consensus Ledger. Creates the `SuspendedPayment` ledger node type and the new transaction types `SuspendedPaymentCreate`, `SuspendedPaymentFinish`, and `SuspendedPaymentCancel`.
+
+This amendment is still in development. The current version is enabled on the [Ripple Test Net](https://ripple.com/build/ripple-test-net/).
+
+## TrustSetAuth ##
+
+| Amendment ID |
+|--------------|
+| 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC |
+
+Allows pre-authorization of accounting relationships (zero-balance trust lines) when using [Authorized Accounts](tutorial-gateway-guide.html#authorized-accounts).
+
+With this amendment enabled, a `TrustSet` transaction with [`tfSetfAuth` enabled](reference-transaction-format.html#trustset-flags) can create a new [`RippleState` ledger node](reference-ledger-format.html#ripplestate) even if it keeps all the other values of the `RippleState` node in their default state. The new `RippleState` node has the [`lsfLowAuth` or `lsfHighAuth` flag](reference-ledger-format.html#ripplestate-flags) enabled accordingly. The sender of the transaction must have [`lsfRequireAuth` enabled](reference-ledger-format.html#accountroot-flags).
+
+## Tickets ##
+
+| Amendment ID |
+|--------------|
+| C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 |
+
+Introduces Tickets as a way to reserve a transaction sequence number for later execution. Creates the `Ticket` ledger node type and the transaction types `TicketCreate` and `TicketCancel`.
+
+This amendment is still in development.
diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md
index d318c47858..e291f03fc0 100644
--- a/content/reference-transaction-format.md
+++ b/content/reference-transaction-format.md
@@ -12,10 +12,12 @@ There are several different types of transactions that perform different actions
 * [OfferCreate - Submit an order to exchange currency](#offercreate)
 * [OfferCancel - Withdraw a currency-exchange order](#offercancel)
 * [TrustSet - Add or modify a trust line](#trustset)
+* [SignerListSet - Set multi-signing settings](#signerlistset)
 
-Additionally, there are *Psuedo-Transactions* that are not created and submitted in the usual way, but may appear in ledgers:
+Additionally, there are *Pseudo-Transactions* that are not created and submitted in the usual way, but may appear in ledgers:
 
 * [SetFee - Adjust the minimum transaction cost or account reserve](#setfee)
+* [EnableAmendment - Apply a change to transaction processing](#enableamendment)
 
 Transactions are only valid if signed, submitted, and accepted into a validated ledger version. There are many ways a transaction can fail.
 
@@ -30,9 +32,9 @@ In the decentralized Ripple Consensus Ledger, a digital signature proves that a
 
 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 address. You can disable or enable the master key using an [AccountSet transaction](#accountset).
-* A single signature that matches a regular key enabled for the address. You can enable, remove, or replace a regular key using a [SetRegularKey transaction](#setregularkey).
-* A [multi-signature](#multi-signing) that matches a list of signers enabled for the address. You can enable, remove, or replace a list of signers using a [SignerListSet transaction](#SignerListSet).
+* 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).
 
 Any signature type can authorize any type of transaction, with the following exceptions:
 
@@ -223,7 +225,7 @@ Every transaction type has the same set of fundamental fields:
 | [Memos](#memos) | Array of Objects | Array | (Optional) Additional arbitrary information used to identify this transaction. |
 | [Sequence](#canceling-or-skipping-a-transaction) | Unsigned Integer | UInt32 | (Required, but [auto-fillable](#auto-fillable-fields)) The sequence number, relative to the initiating account, of this transaction. A transaction is only valid if the `Sequence` number is exactly 1 greater than the last-valided transaction from the same account. |
 | SigningPubKey | String | PubKey | (Automatically added when signing) Hex representation of the public key that corresponds to the private key used to sign this transaction. If an empty string, indicates a multi-signature is present in the `Signers` field instead. |
-| [Signers](#signers-field) | Array | Array | (Optional) Array of objects that represent a multi-signature which authorizes this transaction. |
+| [Signers](#signers-field) | Array | Array | (Optional) Array of objects that represent a [multi-signature](#multi-signing) which authorizes this transaction. |
 | SourceTag | Unsigned Integer | UInt32 | (Optional) Arbitrary integer used to identify the reason for this payment, or the hosted wallet on whose behalf this transaction is made. Conventionally, a refund should specify the initial payment's `SourceTag` as the refund payment's `DestinationTag`. |
 | TransactionType | String | UInt16 | The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, `AccountSet`, `SetRegularKey`, and `SignerListSet`. |
 | TxnSignature | String | VariableLength | (Automatically added when signing) The signature that verifies this transaction as originating from the account it says it is from. |
@@ -519,7 +521,7 @@ The available AccountSet flags are:
 | asfGlobalFreeze | 7 | [Freeze](concept-freeze.html) all assets issued by this account. | lsfGlobalFreeze |
 | asfDefaultRipple | 8 | Enable [rippling](https://ripple.com/knowledge_center/understanding-the-noripple-flag/) on this account's trust lines by default. _(New in [rippled 0.27.3](https://github.com/ripple/rippled/releases/tag/0.27.3))_ | lsfDefaultRipple |
 
-_New in [rippled 0.28.0][]:_ You cannot send a transaction that enables `asfDisableMaster` or `asfNoFreeze` using a [regular key](#setregularkey). You must use the master key to sign the transaction.
+_New in [rippled 0.28.0][]:_ In order to enable the `asfDisableMaster` or `asfNoFreeze` flags, you must [authorize the transaction](#authorizing-transactions) by signing it with the master key. You cannot use a regular key or a multi-signature.
 
 The following [Transaction flags](#flags), specific to the AccountSet transaction type, serve the same purpose, but are discouraged:
 
@@ -765,7 +767,7 @@ A trust line with settings in the default state is equivalent to no trust line.
 
 The default state of all flags is off, except for the [NoRipple flag](https://ripple.com/knowledge_center/understanding-the-noripple-flag/), whose default state depends on the DefaultRipple flag.
 
-The Auth flag of a trust line does not determine whether the trust line counts towards its owner's XRP reserve requirement. However, an enabled Auth flag prevents the trust line from being in its default state. An authorized trust line can never be deleted. _(New in [rippled 0.30.0](https://github.com/ripple/rippled/releases/tag/0.30.0))_: You can pre-authorize a trust line with the `tfSetfAuth` flag only, even if the limit and balance of the trust line are 0.
+The Auth flag of a trust line does not determine whether the trust line counts towards its owner's XRP reserve requirement. However, an enabled Auth flag prevents the trust line from being in its default state. An authorized trust line can never be deleted. _(New in [rippled 0.30.0](https://github.com/ripple/rippled/releases/tag/0.30.0))_: The [`TrustSetAuth` Amendment](concept-amendments.html#trustsetauth) would allow you to pre-authorize a trust line with the `tfSetfAuth` flag only, even if the limit and balance of the trust line are 0. This Amendment is not currently enabled.
 
 ### TrustSet Flags ###
 
@@ -848,9 +850,9 @@ Some of the fields that are mandatory for normal transactions do not make sense
 
 ## SetFee ##
 
-A change in [transaction cost](concept-transaction-cost.html) or [account reserve](concept-reserves.html) requirements. This is typically in response to changes in the load on the network.
+A change in [transaction cost](concept-transaction-cost.html) or [account reserve](concept-reserves.html) requirements as a result of [Fee Voting](concept-fee-voting.html).
 
-*Note:* You cannot send a pseudo-transaction, but you may encounter one when processing ledgers.
+**Note:** You cannot send a pseudo-transaction, but you may encounter one when processing ledgers.
 
 ```
 {
@@ -876,8 +878,27 @@ A change in [transaction cost](concept-transaction-cost.html) or [account reserv
 | ReserveBase | Unsigned Integer | UInt32 | The base reserve, in drops |
 | ReserveIncrement | Unsigned Integer | UInt32 | The incremental reserve, in drops |
 
+## 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.
 
+**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. |
+
+### 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.
+
+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. |
 
 
 
@@ -1074,7 +1095,7 @@ These codes indicate that the transaction failed to apply, but the transaction c
 | tefBAD\_SIGNATURE | The transaction was [multi-signed](#multi-signing), but contained a signature for an address not part of a SignerList associated with the sending account. |
 | tefBAD\_QUORUM | The transaction was [multi-signed](#multi-signing), but the total weights of all included signatures did not meet the quorum. |
 | tefNOT\_MULTI\_SIGNING | The transaction was [multi-signed](#multi-signing), but the sending account has no SignerList defined. |
-| tefBAD\_AUTH\_MASTER | (something to do with the key not being the right one for this account) |
+| tefBAD\_AUTH\_MASTER | The single signature provided to authorize this transaction does not match the master key, but no regular key is associated with this address. |
 
 ### ter Codes ###
 
@@ -1122,8 +1143,8 @@ These codes indicate that the transaction failed, but it was applied to a ledger
 | tecNO\_LINE\_REDUNDANT | 127 | The transaction failed because it attempted to set a trust line to its default state, but the trust line did not exist. |
 | tecPATH\_DRY | 128 | The transaction failed because the provided paths did not have enough liquidity to send anything at all. This could mean that the source and destination accounts are not linked by trust lines. |
 | tecUNFUNDED | 129 | **DEPRECATED.** Replaced by tecUNFUNDED\_OFFER and tecUNFUNDED\_PAYMENT. |
-| tecNO\_ALTERNATIVE\_KEY | 130 | The transaction tried to remove the only available method of signing 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` instead.) |
-| tecNO\_REGULAR\_KEY | 131 | The [AccountSet transaction](#accountset) tried to disable the Master Key, but the account does not have a Regular Key set. (Disabling the Master Key without having a Regular Key configured would make the account unusable.) |
+| 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` instead.) |
+| tecNO\_REGULAR\_KEY | 131 | The [AccountSet transaction](#accountset) tried to disable the master key, but the account does not have another way to [authorize transactions](#authorizing-transactions). If [multi-signing](#multi-signing) is enabled, this code is deprecated and `tecNO_ALTERNATIVE_KEY` is used instead. |
 | tecOWNERS | 132 | The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the [`lsfRequireAuth`](#accountset-flags) flag if it has any trust lines or available offers. |
 | tecNO\_ISSUER | 133 | The account specified in the `issuer` field of a currency amount does not exist. |
 | tecNO\_AUTH | 134 | The transaction failed because it needs to add a balance on a trust line to an account with the `lsfRequireAuth` flag enabled, and that trust line has not been authorized. If the trust line does not exist at all, tecNO\_LINE occurs instead. |
diff --git a/reference-transaction-format.html b/reference-transaction-format.html
index 46928e135b..6a876f8b26 100644
--- a/reference-transaction-format.html
+++ b/reference-transaction-format.html
@@ -140,10 +140,12 @@
 
  • OfferCreate - Submit an order to exchange currency
    • 
 
  • OfferCancel - Withdraw a currency-exchange order
    • 
 
  • TrustSet - Add or modify a trust line
    • 
+
  • SignerListSet - Set multi-signing settings
    • 
 
-
    Additionally, there are Psuedo-Transactions that are not created and submitted in the usual way, but may appear in ledgers:
    
+
    Additionally, there are Pseudo-Transactions that are not created and submitted in the usual way, but may appear in ledgers:
    
 
 
    Transactions are only valid if signed, submitted, and accepted into a validated ledger version. There are many ways a transaction can fail.
    
 
      
@@ -156,9 +158,9 @@
 
      In the decentralized Ripple Consensus Ledger, a digital signature proves that a transaction is authorized to perform a specific set of actions. Only signed transactions can be submitted to the network and included in a validated ledger. A signed transaction is immutable: its contents cannot change, and the signature is not valid for any other transaction.
      
 
      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 address. You can disable or enable the master key using an AccountSet transaction.
        • 
-
      • A single signature that matches a regular key enabled for the address. You can enable, remove, or replace a regular key using a SetRegularKey transaction.
        • 
-
      • A multi-signature that matches a list of signers enabled for the address. You can enable, remove, or replace a list of signers using a SignerListSet transaction.
        • 
+
      • 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.
        • 
+
      • 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.
        • 
+
      • A multi-signature that matches a list of signers owned by the address. You can add, remove, or replace a list of signers using a SignerListSet transaction.
        • 
 
      
 
      Any signature type can authorize any type of transaction, with the following exceptions:
      
 
        
@@ -382,7 +384,7 @@
 Signers
 Array
 Array
-(Optional) Array of objects that represent a multi-signature which authorizes this transaction.
+(Optional) Array of objects that represent a multi-signature which authorizes this transaction.
 
 
 SourceTag
@@ -826,7 +828,7 @@
 
 
 
-
        New in rippled 0.28.0: You cannot send a transaction that enables asfDisableMaster or asfNoFreeze using a regular key. You must use the master key to sign the transaction.
        
+
        New in rippled 0.28.0: In order to enable the asfDisableMaster or asfNoFreeze flags, you must authorize the transaction by signing it with the master key. You cannot use a regular key or a multi-signature.
        
 
        The following Transaction flags, specific to the AccountSet transaction type, serve the same purpose, but are discouraged:
        
 
@@ -1158,7 +1160,7 @@
 
        Since a trust line occupies space in the ledger, a trust line increases the XRP your account must hold in reserve. This applies to the account extending trust, not to the account receiving it.
        A trust line with settings in the default state is equivalent to no trust line.
        The default state of all flags is off, except for the NoRipple flag, whose default state depends on the DefaultRipple flag.
        
-
        The Auth flag of a trust line does not determine whether the trust line counts towards its owner's XRP reserve requirement. However, an enabled Auth flag prevents the trust line from being in its default state. An authorized trust line can never be deleted. (New in rippled 0.30.0): You can pre-authorize a trust line with the tfSetfAuth flag only, even if the limit and balance of the trust line are 0.
        
+
        The Auth flag of a trust line does not determine whether the trust line counts towards its owner's XRP reserve requirement. However, an enabled Auth flag prevents the trust line from being in its default state. An authorized trust line can never be deleted. (New in rippled 0.30.0): The TrustSetAuth Amendment would allow you to pre-authorize a trust line with the tfSetfAuth flag only, even if the limit and balance of the trust line are 0. This Amendment is not currently enabled.
        TrustSet Flags
        Transactions of the TrustSet type support additional values in the Flags field, as follows:
        
 
 
 
 
 
 
        
@@ -1297,8 +1299,8 @@
 
        
 
        
 
        SetFee
        
-
        A change in transaction cost or account reserve requirements. This is typically in response to changes in the load on the network.
        
-
        Note: You cannot send a pseudo-transaction, but you may encounter one when processing ledgers.
        
+
        A change in transaction cost or account reserve requirements as a result of Fee Voting.
        
+
        Note: You cannot send a pseudo-transaction, but you may encounter one when processing ledgers.
        
 
        {
     "Account": "rrrrrrrrrrrrrrrrrrrrrhoLvTp",
     "BaseFee": "000000000000000A",
@@ -1350,6 +1352,60 @@
 
 
 
+
        EnableAmendment
        
+
        Tracks the progress of the 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.
        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
        FieldJSON TypeInternal TypeDescription
        AmendmentStringHash256A unique identifier for the Amendment. This is not intended to be a human-readable name. See Amendments for a list of known Amendments.
        LedgerSequenceNumberUInt32The 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.
        
+
        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 NameHex ValueDecimal ValueDescription
        tfGotMajority0x0001000065536Support for this Amendment increased to at least 80% of trusted validators starting with this ledger version.
        tfLostMajority0x00020000131072Support for this Amendment decreased to less than 80% of trusted validators starting with this ledger version.
        
 
        Transaction Results
        
 
        Immediate Response
        
 
        The response from the submit command contains a provisional result from the rippled server indicating what happened during local processing of the transaction.
        
@@ -1805,7 +1861,7 @@
 
 
 tefBAD_AUTH_MASTER
-(something to do with the key not being the right one for this account)
+The single signature provided to authorize this transaction does not match the master key, but no regular key is associated with this address.
 
 
 
@@ -1966,12 +2022,12 @@
 
 tecNO_ALTERNATIVE_KEY
 130
-The transaction tried to remove the only available method of signing transactions. This could be a SetRegularKey transaction to remove the Regular Key, a SignerListSet transaction to delete a SignerList, or an AccountSet transaction to disable the Master Key. (Prior to rippled 0.30.0, this was called tecMASTER_DISABLED instead.)
+The transaction tried to remove the only available method of authorizing transactions. This could be a SetRegularKey transaction to remove the regular key, a SignerListSet transaction to delete a SignerList, or an AccountSet transaction to disable the master key. (Prior to rippled 0.30.0, this was called tecMASTER_DISABLED instead.)
 
 
 tecNO_REGULAR_KEY
 131
-The AccountSet transaction tried to disable the Master Key, but the account does not have a Regular Key set. (Disabling the Master Key without having a Regular Key configured would make the account unusable.)
+The AccountSet transaction tried to disable the master key, but the account does not have another way to authorize transactions. If multi-signing is enabled, this code is deprecated and tecNO_ALTERNATIVE_KEY is used instead.
 
 
 tecOWNERS

From fee3a5dc3999165ffc378c27cbe3edc7417f40d6 Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Wed, 30 Mar 2016 16:31:53 -0700
Subject: [PATCH 17/40] amendments rewording

---
 concept-amendments.html       | 19 +++++++++++++++----
 content/concept-amendments.md | 25 +++++++++++++++++++++----
 2 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/concept-amendments.html b/concept-amendments.html
index ba47eee9d5..7a2f5af094 100644
--- a/concept-amendments.html
+++ b/concept-amendments.html
@@ -135,8 +135,8 @@
 
        The Amendments system provides a means of introducing new features to the decentralized Ripple consensus network without causing disruptions. The amendments system works by utilizing the core consensus process of the network to approve any changes by showing continuous support before those changes go into effect. An amendment normally requires 80% support for two weeks before it can apply.
        
 
        When an Amendment has been enabled, it applies permanently to all ledger versions after the one that included it. You cannot disable an Amendment, unless you introduce a new Amendment to do so.
        
 
        Background
        
-
        Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. This could cause anything from minor inconveniences (a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot rely on their own) to serious problems: consensus might be unable to validate new ledger versions because servers are unable to reach a consensus who agree to the exact same result.
        
-
        In theory, this could prompt a situation where the Ripple Consensus Ledger cannot make progress because only a portion of validators have upgraded to a new version of the software. Amendments provide solution to this problem, so that new features can be enabled only when enough validators support those features.
        
+
        Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If only a portion of validators have upgraded to a new version of the software, this could cause anything from minor inconveniences (a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot rely on their own) to serious problems: consensus might be unable to validate new ledger versions because servers are unable to reach a consensus who agree to the exact same result.
        
+
        Amendments provide solution to this problem, so that new features can be enabled only when enough validators support those features.
        
 
        Users and businesses who rely on the Ripple Consensus Ledger can also use Amendments to provide advance notice of changes in transaction processing that might affect their business. However, API changes that do not impact transaction processing or the consensus process do not require Amendments.
        
 
        Amendment Process
        
 
        An amendment is a fully-functional feature or change, ready to apply when a consensus of servers can handle it. A rippled server that wants to use an amendment has business logic for two modes: without the amendment (previous behavior) and with the amendment (new behavior). Every amendment has a unique identifying hex value and a short name. The short name is for human use, and does not affect the status of the amendment.
        
@@ -149,14 +149,25 @@
 
      
 
      A server only inserts the pseudo-transaction to enable an amendment if all of the following conditions are met:
      
 
        
-
      • There is a validated ledger which closed at least two weeks prior to the current flag ledger, which includes an EnableAmendment pseudo-transaction for this amendment with the tfGotMajority flag enabled.
        • 
-
      • There are no EnableAmendment pseudo-transactions for this amendment with the tfLostMajority flag enabled in the validated ledgers between the tfGotMajority pseudo-transaction and the current ledger.
        • 
+
      • The amendment has not already been enabled.
        • 
+
      • A previous ledger includes an EnableAmendment pseudo-transaction for this amendment with the tfGotMajority flag enabled.
        • 
+
      • The previous ledger in question is an ancestor of the current ledger.
        • 
+
      • The previous ledger in question has a close time that is at least two weeks before the close time of the latest flag ledger.
        • 
+
      • There are no EnableAmendment pseudo-transactions for this amendment with the tfLostMajority flag enabled in the consensus ledgers between the tfGotMajority pseudo-transaction and the current ledger.
        • 
 
      
 
      It is theoretically possible (but extremely unlikely) that a tfLostMajority EnableAmendment pseudo-transaction could be included in the same ledger as the pseudo-transaction to enable an amendment. In this case, the pseudo-transaction with the tfLostMajority pseudo-transaction has no effect.
      
 
      Amendment Voting
      
 
      Operators of rippled validators can choose which amendments to support or reject using the feature command. This decides which amendments the validator votes for in the amendment process. By default, rippled votes in favor of every amendment it knows about.
      
 
      The operator of a rippled validator can "veto" an amendment using the feature command. In this case, that validator never sends a vote in favor of the amendment. If enough trusted validators veto an amendment, then the amendment does not apply.
      
 
      As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. Currently, Ripple recommends only trusting the 5 default validators that Ripple (the company) operates. For now, trusting only those validators is sufficient to coordinate with Ripple on releasing new features.
      
+
      Testing Amendments
      
+
      If you want to see how rippled behaves with an amendment enabled, before that amendment gets enabled on the production network, you can run use rippled's configuration file to forcibly enable a feature. This is intended for development purposes only.
      
+
      Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run rippled in Stand-Alone Mode.
      
+
      To forcibly enable a feature, add a [features] stanza to your rippled.cfg file. In this stanza, add the short names of the features to enable, one per line. For example:
      
+
      [features]
+MultiSign
+TrustSetAuth
+
      
 
      Known Amendments
      
 
      The following is a comprehensive list of all known amendments and their status on the production Ripple Consensus Ledger:
      
 
diff --git a/content/concept-amendments.md b/content/concept-amendments.md
index 4cc117f982..1bd982d04f 100644
--- a/content/concept-amendments.md
+++ b/content/concept-amendments.md
@@ -7,9 +7,9 @@ When an Amendment has been enabled, it applies permanently to all ledger version
 
 ## Background ##
 
-Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. This could cause anything from minor inconveniences (a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot rely on their own) to serious problems: consensus might be unable to validate new ledger versions because servers are unable to reach a consensus who agree to the exact same result.
+Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If only a portion of validators have upgraded to a new version of the software, this could cause anything from minor inconveniences (a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot rely on their own) to serious problems: consensus might be unable to validate new ledger versions because servers are unable to reach a consensus who agree to the exact same result.
 
-In theory, this could prompt a situation where the Ripple Consensus Ledger cannot make progress because only a portion of validators have upgraded to a new version of the software. Amendments provide solution to this problem, so that new features can be enabled only when enough validators support those features.
+Amendments provide solution to this problem, so that new features can be enabled only when enough validators support those features.
 
 Users and businesses who rely on the Ripple Consensus Ledger can also use Amendments to provide advance notice of changes in transaction processing that might affect their business. However, API changes that do not impact transaction processing or [the consensus process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/) do not require Amendments.
 
@@ -28,8 +28,11 @@ In the flag ledger itself, there is nothing unusual. However, during that time,
 
 A server only inserts the pseudo-transaction to enable an amendment if all of the following conditions are met:
 
-* There is a validated ledger which closed at least two weeks prior to the current flag ledger, which includes an EnableAmendment pseudo-transaction for this amendment with the `tfGotMajority` flag enabled.
-* There are no EnableAmendment pseudo-transactions for this amendment with the `tfLostMajority` flag enabled in the validated ledgers between the `tfGotMajority` pseudo-transaction and the current ledger.
+* The amendment has not already been enabled.
+* A previous ledger includes an EnableAmendment pseudo-transaction for this amendment with the `tfGotMajority` flag enabled.
+* The previous ledger in question is an ancestor of the current ledger.
+* The previous ledger in question has a close time that is at least **two weeks** before the close time of the latest flag ledger.
+* There are no EnableAmendment pseudo-transactions for this amendment with the `tfLostMajority` flag enabled in the consensus ledgers between the `tfGotMajority` pseudo-transaction and the current ledger.
 
 It is theoretically possible (but extremely unlikely) that a `tfLostMajority` EnableAmendment pseudo-transaction could be included in the same ledger as the pseudo-transaction to enable an amendment. In this case, the pseudo-transaction with the `tfLostMajority` pseudo-transaction has no effect.
 
@@ -41,6 +44,20 @@ The operator of a `rippled` validator can "veto" an amendment using the [`featur
 
 As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. Currently, Ripple recommends only trusting the 5 default validators that Ripple (the company) operates. For now, trusting only those validators is sufficient to coordinate with Ripple on releasing new features.
 
+## Testing Amendments ##
+
+If you want to see how `rippled` behaves with an amendment enabled, before that amendment gets enabled on the production network, you can run use `rippled`'s configuration file to forcibly enable a feature. This is intended for development purposes only.
+
+Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run `rippled` in [Stand-Alone Mode](concept-stand-alone-mode.html).
+
+To forcibly enable a feature, add a `[features]` stanza to your `rippled.cfg` file. In this stanza, add the short names of the features to enable, one per line. For example:
+
+```
+[features]
+MultiSign
+TrustSetAuth
+```
+
 
 
 # Known Amendments #

From 63d5b8b2de3bed2f75f00e9a0ec55199cb77c860 Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Wed, 30 Mar 2016 16:47:29 -0700
Subject: [PATCH 18/40] tx format - capitalization, LedgerSequence field of
 SetFee, etc.

---
 content/reference-transaction-format.md | 17 +++++++++--------
 reference-transaction-format.html       | 22 ++++++++++++++--------
 2 files changed, 23 insertions(+), 16 deletions(-)

diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md
index e291f03fc0..7ff12c64fd 100644
--- a/content/reference-transaction-format.md
+++ b/content/reference-transaction-format.md
@@ -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. |
 
 
 
diff --git a/reference-transaction-format.html b/reference-transaction-format.html
index 6a876f8b26..1e08afd69c 100644
--- a/reference-transaction-format.html
+++ b/reference-transaction-format.html
@@ -300,7 +300,7 @@
 
 
      Multi-Signing
      
 
      Multi-signing in Ripple is the act of 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 to the Ripple Consensus Protocol. You can use multi-signing in addition to, or instead of, a master key, a regular key, or both.
      
-
      The SignerListSet transaction 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 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.
      
 
      Reliable Transaction Submission
      
 
      Reliably submitting transactions is the process of achieving both of the following:
      
@@ -1350,10 +1350,16 @@
       
+
+
+
+
+
+
      UInt32
 The incremental reserve, in drops
 
      LedgerSequenceNumberUInt32The 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 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 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.
      
 
@@ -1369,19 +1375,19 @@
 
-
+
-
+
      
 
      Amendment
 String
 Hash256A unique identifier for the Amendment. This is not intended to be a human-readable name. See Amendments for a list of known Amendments.A unique identifier for the amendment. This is not intended to be a human-readable name. See Amendments for a list of known amendments.
 
      
 
      
 LedgerSequence
 Number
 UInt32The index of the ledger version where this Amendment appears. This distinguishes the pseudo-transaction from other occurrences of the same change.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.
      
-
      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:
      
+
      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:
      
 
@@ -1396,13 +1402,13 @@
 
-
+
-
+
      
 
 
      tfGotMajority
 0x00010000
 65536Support for this Amendment increased to at least 80% of trusted validators starting with this ledger version.Support for this amendment increased to at least 80% of trusted validators starting with this ledger version.
 
      
 
      
 tfLostMajority
 0x00020000
 131072Support for this Amendment decreased to less than 80% of trusted validators starting with this ledger version.Support for this amendment decreased to less than 80% of trusted validators starting with this ledger version.
 
      
 
 
      

From 6a11960240e96c9dae6cf8a63a0a41d5bdd32a4d Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Wed, 30 Mar 2016 17:23:21 -0700
Subject: [PATCH 19/40] tx format - amendment result codes

---
 content/reference-transaction-format.md |  3 +++
 reference-transaction-format.html       | 12 ++++++++++++
 2 files changed, 15 insertions(+)

diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md
index 7ff12c64fd..bf8f9d7ee8 100644
--- a/content/reference-transaction-format.md
+++ b/content/reference-transaction-format.md
@@ -1072,6 +1072,9 @@ These codes indicate that the transaction was malformed, and cannot succeed acco
 | temBAD_WEIGHT | The [SignerListSet](#signerlistset) transaction includes a `SignerWeight` that is invalid, for example a zero or negative value. |
 | temBAD_SIGNER | The [SignerListSet](#signerlistset) transaction includes a signer who is invalid: for example, it might be a duplicate, or it might be the account to which the SignerList belongs. |
 | temBAD_QUORUM | The [SignerListSet](#signerlistset) transaction has an invalid `SignerQuorum` value. Either the value is not greater than zero, or it is more than the sum of all signers in the list. |
+| temUNCERTAIN | Used internally only. This code should never be returned. |
+| temUNKNOWN | Used internally only. This code should never be returned. |
+| temDISABLED | The transaction requires logic that is currently disabled. Typically this means you are trying to use an [amendment](concept-amendments.html) that is not enabled for the current ledger. |
 
 
 ### tef Codes ###
diff --git a/reference-transaction-format.html b/reference-transaction-format.html
index 1e08afd69c..e760c736aa 100644
--- a/reference-transaction-format.html
+++ b/reference-transaction-format.html
@@ -1789,6 +1789,18 @@
 temBAD_QUORUM
 The SignerListSet transaction has an invalid SignerQuorum value. Either the value is not greater than zero, or it is more than the sum of all signers in the list.
 
+
+temUNCERTAIN
+Used internally only. This code should never be returned.
+
+
+temUNKNOWN
+Used internally only. This code should never be returned.
+
+
+temDISABLED
+The transaction requires logic that is currently disabled. Typically this means you are trying to use an amendment that is not enabled for the current ledger.
+
 
 
 
      tef Codes
      

From 482b453602c6e83ac4de2dd2a84621d3f2b7724b Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Wed, 30 Mar 2016 19:56:44 -0700
Subject: [PATCH 20/40] rippled - sign_for command

---
 content/reference-rippled.md | 299 ++++++++++++++++++++++-
 reference-rippled.html       | 448 +++++++++++++++++++++++++++++------
 2 files changed, 676 insertions(+), 71 deletions(-)
 mode change 100644 => 100755 content/reference-rippled.md

diff --git a/content/reference-rippled.md b/content/reference-rippled.md
old mode 100644
new mode 100755
index bafafb1cd6..e8a5164df0
--- a/content/reference-rippled.md
+++ b/content/reference-rippled.md
@@ -6297,15 +6297,239 @@ __*Caution:*__ If this command results in an error messages, the message can con
 
 
 ## sign_for ##
+[[Source]
      ](https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/SignFor.cpp "Source")
 
-The `sign_for` command provides one signature for a multi-signed transaction. takes an address and related secret, and a transaction in JSON form. (TODO: finish this section.) It generates a signature for that transaction, using the secret key and address specified. By using this, you can provide signatures that contribute to a multi-signed transaction. (The signatures should come from the members of your SignerList.)
+The `sign_for` command provides one signature for a [multi-signed transaction](reference-transaction-format.html#multi-signing).
+
+#### Request Format ####
+An example of the request format:
+
+
+
+*WebSocket*
+
+```
+{
+	"id": "sign_for_example",
+	"command": "sign_for",
+	"account": "rLFd1FzHMScFhLsXeaxStzv3UC97QHGAbM",
+	"seed": "s████████████████████████████",
+	"key_type": "ed25519",
+	"tx_json": {
+		"TransactionType": "TrustSet",
+		"Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+		"Flags": 262144,
+		"LimitAmount": {
+			"currency": "USD",
+			"issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+			"value": "100"
+		},
+		"Sequence": 2,
+		"SigningPubKey": "",
+		"Fee": "30000"
+	}
+}
+```
+
+*JSON-RPC*
+
+```
+POST http://localhost:5005/
+{
+    "method": "sign_for",
+    "params": [{
+        "account": "rLFd1FzHMScFhLsXeaxStzv3UC97QHGAbM",
+        "seed": "s████████████████████████████",
+        "key_type": "ed25519",
+        "tx_json": {
+            "TransactionType": "TrustSet",
+            "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+            "Flags": 262144,
+            "LimitAmount": {
+                "currency": "USD",
+                "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+                "value": "100"
+            },
+            "Sequence": 2,
+            "SigningPubKey": "",
+            "Fee": "30000"
+        }
+    }]
+}
+```
+
+*Commandline*
+
+```
+#Syntax: rippled sign_for   [offline]
+rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW s████████████████████████████ '{
+	"TransactionType": "TrustSet",
+	"Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+	"Flags": 262144,
+	"LimitAmount": {
+		"currency": "USD",
+		"issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+		"value": "100"
+	},
+	"Sequence": 2,
+	"SigningPubKey": "",
+	"Fee": "30000"
+}'
+```
+
+
+
+The request includes the following parameters:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| account | String - [Address][] | The address which is providing the signature. |
+| tx\_json | Object | The [Transaction](reference-transaction-format.html) to sign. Unlike using the [`sign` command](#sign), all fields of the transaction must be provided, including `Fee` and `Sequence`. The transaction must include the field `SigningPubKey` with an empty string as the value. The object may optionally contain a `Signers` array with previously-collected signatures. |
+| secret | String | (Optional) The secret key to sign with. (Cannot be used with `key_type`.) |
+| passphrase | String | (Optional) A passphrase to use as the secret key to sign with. |
+| seed | String | (Optional) A base-58-encoded secret key to sign with. |
+| seed\_hex | String | (Optional) A hexadecimal secret key to sign with. |
+| key\_type | String | (Optional) The type of key to use for signing. This can be `secp256k1` or `ed25519`. (Ed25519 support is experimental.) |
+
+You must provide exactly 1 field with the secret key. You can use any of the following fields: `secret`, `passphrase`, `seed`, or `seed_hex`.
+
+#### Response Format ####
+
+An example of a successful response:
+
+
+
+*WebSocket*
+
+```
+{
+  "id": "sign_for_example",
+  "status": "success",
+  "type": "response",
+  "result": {
+    "tx_blob": "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E0107321EDDF4ECB8F34A168143B928D48EFE625501FB8552403BBBD3FC038A5788951D7707440C3DCA3FEDE6D785398EEAB10A46B44047FF1B0863FC4313051FB292C991D1E3A9878FABB301128FE4F86F3D8BE4706D53FA97F5536DBD31AF14CD83A5ACDEB068114D96CB910955AB40A0E987EEE82BB3CEDD4441AAAE1F1",
+    "tx_json": {
+      "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+      "Fee": "30000",
+      "Flags": 262144,
+      "LimitAmount": {
+        "currency": "USD",
+        "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+        "value": "100"
+      },
+      "Sequence": 2,
+      "Signers": [
+        {
+          "Signer": {
+            "Account": "rLFd1FzHMScFhLsXeaxStzv3UC97QHGAbM",
+            "SigningPubKey": "EDDF4ECB8F34A168143B928D48EFE625501FB8552403BBBD3FC038A5788951D770",
+            "TxnSignature": "C3DCA3FEDE6D785398EEAB10A46B44047FF1B0863FC4313051FB292C991D1E3A9878FABB301128FE4F86F3D8BE4706D53FA97F5536DBD31AF14CD83A5ACDEB06"
+          }
+        }
+      ],
+      "SigningPubKey": "",
+      "TransactionType": "TrustSet",
+      "hash": "5216A13A3E3CF662352F0B430C7D82B7450415B6883DD428B5EC1DF1DE45DD8C"
+    }
+  }
+}
+```
+
+*JSON-RPC*
+
+```
+200 OK
+{
+   "result" : {
+      "status" : "success",
+      "tx_blob" : "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1F1",
+      "tx_json" : {
+         "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+         "Fee" : "30000",
+         "Flags" : 262144,
+         "LimitAmount" : {
+            "currency" : "USD",
+            "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+            "value" : "100"
+         },
+         "Sequence" : 2,
+         "Signers" : [
+            {
+               "Signer" : {
+                  "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                  "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+                  "TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
+               }
+            }
+         ],
+         "SigningPubKey" : "",
+         "TransactionType" : "TrustSet",
+         "hash" : "A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE"
+      }
+   }
+}
+```
+
+*Commandline*
+
+```
+Loading: "/etc/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "status" : "success",
+      "tx_blob" : "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1F1",
+      "tx_json" : {
+         "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+         "Fee" : "30000",
+         "Flags" : 262144,
+         "LimitAmount" : {
+            "currency" : "USD",
+            "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+            "value" : "100"
+         },
+         "Sequence" : 2,
+         "Signers" : [
+            {
+               "Signer" : {
+                  "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                  "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+                  "TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
+               }
+            }
+         ],
+         "SigningPubKey" : "",
+         "TransactionType" : "TrustSet",
+         "hash" : "A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE"
+      }
+   }
+}
+```
+
+
+
+The response follows the [standard format](#response-formatting), with a successful result containing the following fields:
+
+| Field    | Type | Description |
+|----------|------|-------------|
+| tx\_blob | String | Hexadecimal representation of the signed transaction, including the newly-added signature. If it has enough signatures, you can [submit this string using the `submit` command](#submit-only-mode). |
+| tx\_json | Object | The [transaction specification](reference-transaction-format.html) in JSON format, with the newly-added signature in the `Signers` array. If it has enough signatures, you can submit this object using the [`submit_multisigned` command](#submit-multisigned). |
+
+#### Possible Errors ####
+
+* Any of the [universal error types](#universal-errors).
+* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
+* `srcActNotFound` - If the `Account` from the transaction is not a funded address in the ledger.
+* `srcActMalformed` - If the signing address (`account` field) from the request is not validly formed.
+* `badSeed` - The seed value supplied was invalidly-formatted.
+* `badSecret` - The secret value supplied was invalidly-formatted.
 
 
 
 ## submit ##
 [[Source]
      ](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Submit.cpp "Source")
 
-The `submit` method sends a [transaction](reference-transaction-format.html) to the network to be confirmed and included in future ledgers.
+The `submit` method applies a [transaction](reference-transaction-format.html) and sends it to the network to be confirmed and included in future ledgers.
 
 This command has two modes:
 
@@ -6533,8 +6757,77 @@ __*Caution:*__ If this command results in an error messages, the message can con
 
 
 ## submit_multisigned ##
+[[Source]
      ](https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/SubmitMultiSigned.cpp "Source")
+
+The `submit_multisigned` command applies a [multi-signed](reference-transaction-format.html#multi-signing) transaction and sends it to the network to be included in future ledgers. (TODO: finish this)
+
+#### Request Format ####
+An example of the request format:
+
+
      
+
+*WebSocket*
+
+```
+//actual example here
+```
+
+*Second tab*
+
+```
+//second example here
+```
+
+
      
+
+The request includes the following parameters:
+
+| Field | Type | Description |
+|-------|------|-------------|
+
+
+
+
+
+
+
+
+#### Response Format ####
+
+An example of a successful response:
+
+
      
+
+*WebSocket*
+
+```
+//actual example here
+```
+
+*Second tab*
+
+```
+//second example here
+```
+
+
      
+
+The response follows the [standard format](#response-formatting), with a successful result containing the following fields:
+
+| Field | Type | Description |
+|-------|------|-------------|
+
+
+
+
+
+#### Possible Errors ####
+
+* Any of the [universal error types](#universal-errors).
+* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
+* `actNotFound` - The address specified in the `account` field of the request does not correspond to an account in the ledger.
+* `lgrNotFound` - The ledger specified by the `ledger_hash` or `ledger_index` does not exist, or it does exist but the server does not have it.
 
-The `submit_multisigned` command takes a transaction specification with multiple signatures and applies that transaction. (TODO: finish this section.)
 
 
 
diff --git a/reference-rippled.html b/reference-rippled.html
index 91be30de2d..624ecb84d3 100644
--- a/reference-rippled.html
+++ b/reference-rippled.html
@@ -7321,10 +7321,258 @@ rippled sign sssssssssssssssssssssssssssss '{"TransactionType": "Payment", "Acco
 
    • noPath - The transaction did not include paths, and the server was unable to find a path by which this payment can occur.
      • 
 
    
 
    sign_for
    
-
    The sign_for command provides one signature for a multi-signed transaction. takes an address and related secret, and a transaction in JSON form. (TODO: finish this section.) It generates a signature for that transaction, using the secret key and address specified. By using this, you can provide signatures that contribute to a multi-signed transaction. (The signatures should come from the members of your SignerList.)
    
+
    [Source]
    
+
    The sign_for command provides one signature for a multi-signed transaction.
    
+
    Request Format
    
+
    An example of the request format:
    
+
    
+
    WebSocket
    
+
    {
+    "id": "sign_for_example",
+    "command": "sign_for",
+    "account": "rLFd1FzHMScFhLsXeaxStzv3UC97QHGAbM",
+    "seed": "s████████████████████████████",
+    "key_type": "ed25519",
+    "tx_json": {
+        "TransactionType": "TrustSet",
+        "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+        "Flags": 262144,
+        "LimitAmount": {
+            "currency": "USD",
+            "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+            "value": "100"
+        },
+        "Sequence": 2,
+        "SigningPubKey": "",
+        "Fee": "30000"
+    }
+}
+
    
+
    JSON-RPC
    
+
    POST http://localhost:5005/
+{
+    "method": "sign_for",
+    "params": [{
+        "account": "rLFd1FzHMScFhLsXeaxStzv3UC97QHGAbM",
+        "seed": "s████████████████████████████",
+        "key_type": "ed25519",
+        "tx_json": {
+            "TransactionType": "TrustSet",
+            "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+            "Flags": 262144,
+            "LimitAmount": {
+                "currency": "USD",
+                "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+                "value": "100"
+            },
+            "Sequence": 2,
+            "SigningPubKey": "",
+            "Fee": "30000"
+        }
+    }]
+}
+
    
+
    Commandline
    
+
    #Syntax: rippled sign_for <signer_address> <signer_secret> [offline]
+rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW s████████████████████████████ '{
+    "TransactionType": "TrustSet",
+    "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+    "Flags": 262144,
+    "LimitAmount": {
+        "currency": "USD",
+        "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+        "value": "100"
+    },
+    "Sequence": 2,
+    "SigningPubKey": "",
+    "Fee": "30000"
+}'
+
    
+
    
+
    The request includes the following parameters:
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    FieldTypeDescription
    accountString - AddressThe address which is providing the signature.
    tx_jsonObjectThe Transaction to sign. Unlike using the sign command, all fields of the transaction must be provided, including Fee and Sequence. The transaction must include the field SigningPubKey with an empty string as the value. The object may optionally contain a Signers array with previously-collected signatures.
    secretString(Optional) The secret key to sign with. (Cannot be used with key_type.)
    passphraseString(Optional) A passphrase to use as the secret key to sign with.
    seedString(Optional) A base-58-encoded secret key to sign with.
    seed_hexString(Optional) A hexadecimal secret key to sign with.
    key_typeString(Optional) The type of key to use for signing. This can be secp256k1 or ed25519. (Ed25519 support is experimental.)
    
+
    You must provide exactly 1 field with the secret key. You can use any of the following fields: secret, passphrase, seed, or seed_hex.
    
+
    Response Format
    
+
    An example of a successful response:
    
+
    
+
    WebSocket
    
+
    {
+  "id": "sign_for_example",
+  "status": "success",
+  "type": "response",
+  "result": {
+    "tx_blob": "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E0107321EDDF4ECB8F34A168143B928D48EFE625501FB8552403BBBD3FC038A5788951D7707440C3DCA3FEDE6D785398EEAB10A46B44047FF1B0863FC4313051FB292C991D1E3A9878FABB301128FE4F86F3D8BE4706D53FA97F5536DBD31AF14CD83A5ACDEB068114D96CB910955AB40A0E987EEE82BB3CEDD4441AAAE1F1",
+    "tx_json": {
+      "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+      "Fee": "30000",
+      "Flags": 262144,
+      "LimitAmount": {
+        "currency": "USD",
+        "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+        "value": "100"
+      },
+      "Sequence": 2,
+      "Signers": [
+        {
+          "Signer": {
+            "Account": "rLFd1FzHMScFhLsXeaxStzv3UC97QHGAbM",
+            "SigningPubKey": "EDDF4ECB8F34A168143B928D48EFE625501FB8552403BBBD3FC038A5788951D770",
+            "TxnSignature": "C3DCA3FEDE6D785398EEAB10A46B44047FF1B0863FC4313051FB292C991D1E3A9878FABB301128FE4F86F3D8BE4706D53FA97F5536DBD31AF14CD83A5ACDEB06"
+          }
+        }
+      ],
+      "SigningPubKey": "",
+      "TransactionType": "TrustSet",
+      "hash": "5216A13A3E3CF662352F0B430C7D82B7450415B6883DD428B5EC1DF1DE45DD8C"
+    }
+  }
+}
+
    
+
    JSON-RPC
    
+
    200 OK
+{
+   "result" : {
+      "status" : "success",
+      "tx_blob" : "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1F1",
+      "tx_json" : {
+         "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+         "Fee" : "30000",
+         "Flags" : 262144,
+         "LimitAmount" : {
+            "currency" : "USD",
+            "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+            "value" : "100"
+         },
+         "Sequence" : 2,
+         "Signers" : [
+            {
+               "Signer" : {
+                  "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                  "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+                  "TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
+               }
+            }
+         ],
+         "SigningPubKey" : "",
+         "TransactionType" : "TrustSet",
+         "hash" : "A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE"
+      }
+   }
+}
+
    
+
    Commandline
    
+
    Loading: "/etc/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "status" : "success",
+      "tx_blob" : "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1F1",
+      "tx_json" : {
+         "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+         "Fee" : "30000",
+         "Flags" : 262144,
+         "LimitAmount" : {
+            "currency" : "USD",
+            "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+            "value" : "100"
+         },
+         "Sequence" : 2,
+         "Signers" : [
+            {
+               "Signer" : {
+                  "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                  "SigningPubKey" : "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+                  "TxnSignature" : "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
+               }
+            }
+         ],
+         "SigningPubKey" : "",
+         "TransactionType" : "TrustSet",
+         "hash" : "A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE"
+      }
+   }
+}
+
    
+
    
+
    The response follows the standard format, with a successful result containing the following fields:
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    FieldTypeDescription
    tx_blobStringHexadecimal representation of the signed transaction, including the newly-added signature. If it has enough signatures, you can submit this string using the submit command.
    tx_jsonObjectThe transaction specification in JSON format, with the newly-added signature in the Signers array. If it has enough signatures, you can submit this object using the submit_multisigned command.
    
+
    Possible Errors
    
+
      
+
    • Any of the universal error types.
      • 
+
    • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
      • 
+
    • srcActNotFound - If the Account from the transaction is not a funded address in the ledger.
      • 
+
    • srcActMalformed - If the signing address (account field) from the request is not validly formed.
      • 
+
    • badSeed - The seed value supplied was invalidly-formatted.
      • 
+
    • badSecret - The secret value supplied was invalidly-formatted.
      • 
+
    
 
    submit
    
 
    [Source]
    
-
    The submit method sends a transaction to the network to be confirmed and included in future ledgers.
    
+
    The submit method applies a transaction and sends it to the network to be confirmed and included in future ledgers.
    
 
    This command has two modes:
    
 
      
 
    • Submit-only mode takes a signed, serialized transaction as a binary blob, and submits it to the network as-is. Since signed transaction objects are immutable, no portion of the transaction can be modified or automatically filled in after submission.
      • 
@@ -7354,7 +7602,7 @@ rippled sign sssssssssssssssssssssssssssss '{"TransactionType": "Payment", "Acco
 
 
 
-
      Request Format
      
+
      Request Format
      
 
      
 
      WebSocket
      
 
      {
@@ -7428,7 +7676,7 @@ submit 1200002280000000240000000361D4838D7EA4C6800000000000000000000000000055534
 
 
 
      See the sign command for detailed information on how the server automatically fills in certain fields.
      
-
      Request Format
      
+
      Request Format
      
 
      An example of the request format:
      
 
      
 
      WebSocket
      
@@ -7474,7 +7722,7 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r
 
      
 
      
 
      Try it! >
      
-
      Response Format
      
+
      Response Format
      
 
      An example of a successful response:
      
 
      
 
      WebSocket
      
@@ -7578,7 +7826,7 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r
 
    • Do not paste an error including your secret to a public place for debugging
      • 
 
    • Do not display an error message including your secret on a website, even by accident
      • 
 
    
-
    Possible Errors
    
+
    Possible Errors
    
 
      
 
    • Any of the universal error types.
      • 
 
    • invalidTransaction - The transaction is malformed or otherwise invalid.
      • 
@@ -7591,11 +7839,75 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r
 
    • internalJson - An internal error occurred when serializing the transaction to JSON. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed.
      • 
 
    
 
    submit_multisigned
    
-
    The submit_multisigned command takes a transaction specification with multiple signatures and applies that transaction. (TODO: finish this section.)
    
+
    [Source]
    
+
    The submit_multisigned command applies a multi-signed transaction and sends it to the network to be included in future ledgers. (TODO: finish this)
    
+
    Request Format
    
+
    An example of the request format:
    
+
    
+
+*WebSocket*
+
+
+wzxhzdk:126
+
+
+*Second tab*
+
+
+wzxhzdk:127
+
+
+
    
+
    The request includes the following parameters:
    
+
+
+
+
+
+
+
+
+
+
    FieldTypeDescription
    
+
    Response Format
    
+
    An example of a successful response:
    
+
    
+
+*WebSocket*
+
+
+wzxhzdk:128
+
+
+*Second tab*
+
+
+wzxhzdk:129
+
+
+
    
+
    The response follows the standard format, with a successful result containing the following fields:
    
+
+
+
+
+
+
+
+
+
+
    FieldTypeDescription
    
+
    Possible Errors
    
+
      
+
    • Any of the universal error types.
      • 
+
    • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
      • 
+
    • actNotFound - The address specified in the account field of the request does not correspond to an account in the ledger.
      • 
+
    • lgrNotFound - The ledger specified by the ledger_hash or ledger_index does not exist, or it does exist but the server does not have it.
      • 
+
    
 
    book_offers
    
 
    [Source]
    
 
    The book_offers method retrieves a list of offers, also known as the order book, between two currencies. If the results are very large, a partial result is returned with a marker so that subsequent requests can resume from where the previous one left off.
    
-
    Request Format
    
+
    Request Format
    
 
    An example of the request format:
    
 
    
 
    WebSocket
    
@@ -7680,7 +7992,7 @@ rippled book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6
 
 
 
    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 in order to cancel them with an OfferCancel transaction.
    
-
    Response Format
    
+
    Response Format
    
 
    An example of a successful response:
    
 
    
 
    WebSocket
    
@@ -7812,7 +8124,7 @@ rippled book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6
 
 
 
-
    Possible Errors
    
+
    Possible Errors
    
 
      
 
    • Any of the universal error types.
      • 
 
    • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
      • 
@@ -7829,7 +8141,7 @@ rippled book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6
 
      subscribe
      
 
      [Source]
      
 
      The subscribe method requests periodic notifications from the server when certain events happen.
      
-
      Request Format
      
+
      Request Format
      
 
      An example of the request format:
      
 
      
 
      Subscribe to accounts
      
@@ -7960,7 +8272,7 @@ rippled book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6
 
 
 
-
      Response Format
      
+
      Response Format
      
 
      An example of a successful response:
      
 
      
 
      WebSocket
      
@@ -7980,7 +8292,7 @@ rippled book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6
 
    • Stream: ledger - Information about the ledgers on hand and current fee schedule, such as fee_base (current base fee for transactions in XRP), fee_ref (current base fee for transactions in fee units), ledger_hash (hash of the latest validated ledger), reserve_base (minimum reserve for accounts), and more.
      • 
 
    • books - No fields returned by default. If "snapshot": true is set in the request, returns offers (an array of offer definition objects defining the order book)
      • 
 
    
-
    Possible Errors
    
+
    Possible Errors
    
 
      
 
    • Any of the universal error types.
      • 
 
    • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
      • 
@@ -8525,7 +8837,7 @@ rippled book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6
 
      unsubscribe
      
 
      [Source]
      
 
      The unsubscribe command tells the server to stop sending messages for a particular subscription or set of subscriptions.
      
-
      Request Format
      
+
      Request Format
      
 
      An example of the request format:
      
 
      
 
      WebSocket
      
@@ -8611,7 +8923,7 @@ rippled book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6
 
 
 
-
      Response Format
      
+
      Response Format
      
 
      An example of a successful response:
      
 
      
 
      WebSocket
      
@@ -8624,7 +8936,7 @@ rippled book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6

    The response follows the standard format, with a successful result containing no fields.

    -

    Possible Errors

    +

    Possible Errors

    • Any of the universal error types.
    • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
      • @@ -8642,7 +8954,7 @@ rippled book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6

      server_info

      [Source]

      The server_info command asks the server for a human-readable version of various information about the rippled server being queried.

      -

      Request Format

      +

      Request Format

      An example of the request format:

      WebSocket

      @@ -8666,7 +8978,7 @@ rippled server_info

      Try it! >

      The request does not takes any parameters.

      -

      Response Format

      +

      Response Format

      An example of a successful response:

      WebSocket

      @@ -8995,14 +9307,14 @@ rippled server_info -

      Possible Errors

      +

      Possible Errors

      server_state

      [Source]

      The server_state command asks the server for various machine-readable information about the rippled server's current state. The results are very similar to server_info, but generally the units are chosen to be easier to process instead of easier to read. (For example, XRP values are given in integer drops instead of scientific notation or decimal values, and time is given in milliseconds instead of seconds.)

      -

      Request Format

      +

      Request Format

      An example of the request format:

      WebSocket

      @@ -9026,7 +9338,7 @@ rippled server_state

      Try it! >

      The request does not takes any parameters.

      -

      Response Format

      +

      Response Format

      An example of a successful response:

      WebSocket

      @@ -9350,7 +9662,7 @@ rippled server_state -

      Possible Errors

      +

      Possible Errors

      @@ -9358,7 +9670,7 @@ rippled server_state

      [Source]

      With online_delete and advisory_delete configuration options enabled, the can_delete method informs the rippled server of the latest ledger which may be deleted.

      The can_delete method is an admin command that cannot be run by unpriviledged users.

      -

      Request Format

      +

      Request Format

      An example of the request format:

      WebSocket

      @@ -9420,7 +9732,7 @@ a successful result containing the following fields:

      Use this command with no parameter to query the existing can_delete setting.

      -

      Possible Errors

      +

      Possible Errors

      • Any of the universal error types.
      • notEnabled - Not enabled in configuration.
        • @@ -9432,7 +9744,7 @@ a successful result containing the following fields:

        [Source]

        The consensus_info command provides information about the consensus process for debugging purposes.

        The consensus_info method is an admin command that cannot be run by unpriviledged users.

        -

        Request Format

        +

        Request Format

        An example of the request format:

        WebSocket

        @@ -9455,7 +9767,7 @@ rippled consensus_info

        The request has no parameters.

        -

        Response Format

        +

        Response Format

        An example of a successful response:

        JSON-RPC

        @@ -9667,7 +9979,7 @@ Connecting to 127.0.0.1:5005

        It is also normal to get a minimal result where the only field in info is "consensus": "none". This indicates that the server is in between consensus rounds.

        The results of the consensus_info command can vary dramatically if you run it several times, even in short succession.

        -

        Possible Errors

        +

        Possible Errors

        @@ -9675,7 +9987,7 @@ Connecting to 127.0.0.1:5005

        [Source]

        The fetch_info command returns information about objects that this server is currently fetching from the network, and how many peers have that information. It can also be used to reset current fetches.

        The fetch_info method is an admin command that cannot be run by unpriviledged users.

        -

        Request Format

        +

        Request Format

        An example of the request format:

        WebSocket

        @@ -9717,7 +10029,7 @@ rippled fetch_info -

        Response Format

        +

        Response Format

        An example of a successful response:

        JSON-RPC

        @@ -9853,7 +10165,7 @@ Connecting to 127.0.0.1:5005 -

        Possible Errors

        +

        Possible Errors

        @@ -9861,7 +10173,7 @@ Connecting to 127.0.0.1:5005

        [Source]

        The get_counts command provides various stats about the health of the server, mostly the number of objects of different types that it currently holds in memory.

        The get_counts method is an admin command that cannot be run by unpriviledged users.

        -

        Request Format

        +

        Request Format

        An example of the request format:

        WebSocket

        @@ -9903,7 +10215,7 @@ rippled get_counts 100 -

        Response Format

        +

        Response Format

        An example of a successful response:

        JSON-RPC

        @@ -10006,7 +10318,7 @@ Connecting to 127.0.0.1:5005

        For most other entries, the value indicates the number of objects of that type currently in memory.

        -

        Possible Errors

        +

        Possible Errors

        • Any of the universal error types.
        • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
          • @@ -10015,7 +10327,7 @@ Connecting to 127.0.0.1:5005

          [Source]

          The ledger_cleaner command controls the Ledger Cleaner, an asynchronous maintenance process that can find and repair corruption in rippled's database of ledgers.

          The ledger_cleaner method is an admin command that cannot be run by unpriviledged users.

          -

          Request Format

          +

          Request Format

          An example of the request format:

          WebSocket

          @@ -10074,7 +10386,7 @@ Connecting to 127.0.0.1:5005 -

          Response Format

          +

          Response Format

          An example of a successful response:

          JSON-RPC

          @@ -10105,7 +10417,7 @@ Connecting to 127.0.0.1:5005 -

          Possible Errors

          +

          Possible Errors

          • Any of the universal error types.
          • internal if one the parameters was specified in a way that the server couldn't interpret. (This is a bug, and it should return invalidParams instead.)
            • @@ -10114,7 +10426,7 @@ Connecting to 127.0.0.1:5005

            [Source]

            The log_level command changes the rippled server's logging verbosity, or returns the current logging level for each category (called a partition) of log messages.

            The log_level method is an admin command that cannot be run by unpriviledged users.

            -

            Request Format

            +

            Request Format

            An example of the request format:

            WebSocket

            @@ -10152,7 +10464,7 @@ rippled log_level PathRequest debug -

            Response Format

            +

            Response Format

            Examples of successful responses:

            Commandline (set log level)

            @@ -10244,7 +10556,7 @@ Connecting to 127.0.0.1:5005 -

            Possible Errors

            +

            Possible Errors

            • Any of the universal error types.
            • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
              • @@ -10253,7 +10565,7 @@ Connecting to 127.0.0.1:5005

              [Source]

              The logrotate command closes and reopens the log file. This is intended to facilitate log rotation on Linux file systems.

              The logrotate method is an admin command that cannot be run by unpriviledged users.

              -

              Request Format

              +

              Request Format

              An example of the request format:

              WebSocket

              @@ -10267,7 +10579,7 @@ Connecting to 127.0.0.1:5005

              The request includes no parameters.

              -

              Response Format

              +

              Response Format

              An example of a successful response:

              JSON-RPC

              @@ -10309,7 +10621,7 @@ Connecting to 127.0.0.1:5005 -

              Possible Errors

              +

              Possible Errors

              @@ -10317,7 +10629,7 @@ Connecting to 127.0.0.1:5005

              [Source]

              Use the validation_create command to generate the keys for a rippled validating node. Similar to the wallet_propose command, this command makes no real changes, but only generates a set of keys in the proper format.

              The validation_create method is an admin command that cannot be run by unpriviledged users.

              -

              Request Format

              +

              Request Format

              An example of the request format:

              WebSocket

              @@ -10360,7 +10672,7 @@ rippled validation_create "BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIR

              Note: The security of your validator depends on the entropy of your seed. Do not use a secret value that is not sufficiently randomized for real business purposes. We recommend omitting the secret when generating new credentials for the first time.

              -

              Response Format

              +

              Response Format

              An example of a successful response:

              JSON-RPC

              @@ -10413,7 +10725,7 @@ Connecting to 127.0.0.1:5005 -

              Possible Errors

              +

              Possible Errors

              • Any of the universal error types.
              • badSeed - The request provided an invalid seed value. This usually means that the seed value appears to be a valid string of a different format, such as an account address or validation public key.
                • @@ -10422,7 +10734,7 @@ Connecting to 127.0.0.1:5005

                [Source]

                The validation_seed command temporarily sets the secret value that rippled uses to sign validations. This value resets based on the config file when you restart the server.

                The validation_seed request is an admin command that cannot be run by unpriviledged users!

                -

                Request Format

                +

                Request Format

                An example of the request format:

                WebSocket

                @@ -10454,7 +10766,7 @@ rippled validation_seed 'BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIRE' -

                Response Format

                +

                Response Format

                An example of a successful response:

                JSON-RPC

                @@ -10508,7 +10820,7 @@ Connecting to 127.0.0.1:5005 -

                Possible Errors

                +

                Possible Errors

                • Any of the universal error types.
                • badSeed - The request provided an invalid secret value. This usually means that the secret value appears to be a valid string of a different format, such as an account address or validation public key.
                  • @@ -10517,7 +10829,7 @@ Connecting to 127.0.0.1:5005

                  [Source]

                  The peers command returns a list of all other rippled servers currently connected to this one, including information on their connection and sync status.

                  The peers request is an admin command that cannot be run by unpriviledged users!

                  -

                  Request Format

                  +

                  Request Format

                  An example of the request format:

                  WebSocket

                  @@ -10531,7 +10843,7 @@ Connecting to 127.0.0.1:5005

                  The request includes no additional parameters.

                  -

                  Response Format

                  +

                  Response Format

                  An example of a successful response:

                  WebSocket

                  @@ -10991,7 +11303,7 @@ Connecting to 127.0.0.1:5005 -

                  Possible Errors

                  +

                  Possible Errors

                  @@ -10999,7 +11311,7 @@ Connecting to 127.0.0.1:5005

                  [Source]

                  The print command returns the current status of various internal subsystems, including peers, the ledger cleaner, and the resource manager.

                  The print request is an admin command that cannot be run by unpriviledged users!

                  -

                  Request Format

                  +

                  Request Format

                  An example of the request format:

                  WebSocket

                  @@ -11013,7 +11325,7 @@ Connecting to 127.0.0.1:5005

                  The request includes no parameters.

                  -

                  Response Format

                  +

                  Response Format

                  An example of a successful response:

                  Commandline

                  @@ -11202,7 +11514,7 @@ Connecting to 127.0.0.1:5005

                  The response follows the standard format. Additional fields in the result depend on the internal state of the rippled server. The results of this command are subject to change without notice.

                  -

                  Possible Errors

                  +

                  Possible Errors

                  @@ -11211,7 +11523,7 @@ Connecting to 127.0.0.1:5005

                  ping

                  [Source]

                  The ping command returns an acknowledgement, so that clients can test the connection status and latency.

                  -

                  Request Format

                  +

                  Request Format

                  An example of the request format:

                  WebSocket

                  @@ -11235,7 +11547,7 @@ rippled ping

                  Try it! >

                  The request includes no parameters.

                  -

                  Response Format

                  +

                  Response Format

                  An example of a successful response:

                  WebSocket

                  @@ -11256,14 +11568,14 @@ rippled ping

                  The response follows the standard format, with a successful result containing no fields. The client can measure the round-trip time from request to response as latency.

                  -

                  Possible Errors

                  +

                  Possible Errors

                  random

                  [Source]

                  The random command provides a random number to be used as a source of entropy for random number generation by clients.

                  -

                  Request Format

                  +

                  Request Format

                  An example of the request format:

                  WebSocket

                  @@ -11286,7 +11598,7 @@ rippled random

                  The request includes no parameters.

                  -

                  Response Format

                  +

                  Response Format

                  An example of a successful response:

                  WebSocket

                  @@ -11326,14 +11638,14 @@ rippled random -

                  Possible Errors

                  +

                  Possible Errors

                  • Any of the universal error types.
                  • internal - Some internal error occurred, possibly relating to the random number generator.

                  json

                  The json method is a proxy to running other commands, and accepts the parameters for the command as a JSON value. It is exclusive to the Commandline client, and intended for cases where the commandline syntax for specifying parameters is inadequate or undesirable.

                  -

                  Request Format

                  +

                  Request Format

                  An example of the request format:

                  Commandline

                  @@ -11341,7 +11653,7 @@ rippled random rippled -q json ledger_closed '{}'
                  -

                  Response Format

                  +

                  Response Format

                  An example of a successful response:

                  WebSocket

                  @@ -11359,7 +11671,7 @@ rippled -q json ledger_closed '{}'

                  [Source]

                  The connect command forces the rippled server to connect to a specific peer rippled server.

                  The connect request is an admin command that cannot be run by unpriviledged users!

                  -

                  Request Format

                  +

                  Request Format

                  An example of the request format:

                  WebSocket

                  @@ -11407,7 +11719,7 @@ rippled connect 192.170.145.88 51235 -

                  Response Format

                  +

                  Response Format

                  An example of a successful response:

                  JSON-RPC

                  @@ -11447,7 +11759,7 @@ Connecting to 127.0.0.1:5005 -

                  Possible Errors

                  +

                  Possible Errors

                  • Any of the universal error types.
                  • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
                    • @@ -11457,7 +11769,7 @@ Connecting to 127.0.0.1:5005

                    [Source]

                    Gracefully shuts down the server.

                    The stop request is an admin command that cannot be run by unpriviledged users!

                    -

                    Request Format

                    +

                    Request Format

                    An example of the request format:

                    WebSocket

                    @@ -11479,7 +11791,7 @@ Connecting to 127.0.0.1:5005

                    The request includes no parameters.

                    -

                    Response Format

                    +

                    Response Format

                    An example of a successful response:

                    JSON-RPC

                    @@ -11518,7 +11830,7 @@ Connecting to 127.0.0.1:5005 -

                    Possible Errors

                    +

                    Possible Errors

                    From dd67b51c5976ddc1a8b816ad18896c2926042986 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Thu, 31 Mar 2016 18:07:21 -0700 Subject: [PATCH 21/40] rippled - submit_multisigned (incomplete) --- content/reference-rippled.md | 673 +++++++++++++++++++++-------------- reference-rippled.html | 239 +++++++++++-- 2 files changed, 614 insertions(+), 298 deletions(-) diff --git a/content/reference-rippled.md b/content/reference-rippled.md index e8a5164df0..c6c3c2d592 100755 --- a/content/reference-rippled.md +++ b/content/reference-rippled.md @@ -382,9 +382,9 @@ Many API methods require you to specify an instance of the ledger, with the data 1. Specify a ledger by its [Ledger Index][] in the `ledger_index` parameter. Each closed ledger has an identifying sequence number that is 1 higher than the previously-validated ledger. (The Genesis Ledger has sequence number 0) 2. Specify a ledger by its [Hash][] value in the `ledger_hash` parameter. 3. Specify a ledger by one of the following shortcuts, in the `ledger_index` parameter: - * `validated` for the most recent ledger that has been validated by the whole network - * `closed` for the most recent ledger that has been closed for modifications and proposed for validation by the node - * `current` for the node's current working version of the ledger. + * `validated` for the most recent ledger that has been validated by the whole network + * `closed` for the most recent ledger that has been closed for modifications and proposed for validation by the node + * `current` for the node's current working version of the ledger. There is also a deprecated `ledger` parameter which accepts any of the above three formats. *Do not* use this parameter; it may be removed without further notice. @@ -435,9 +435,9 @@ For example, to represent $153.75 US dollars issued by account `r9cZA1mLK5R5Am25 ``` { - "currency": "USD", - "value": "153.75", - "issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59" + "currency": "USD", + "value": "153.75", + "issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59" } ``` @@ -1125,47 +1125,47 @@ An example of a successful response: ``` 200 OK { - "result": { - "account": "rpP2JgiMyTF5jR5hLG3xHCPi1knBb1v9cM", - "ledger_current_index": 18539596, - "offers": [{ - "flags": 0, - "quality": "0.000000007599140009999998", - "seq": 6578020, - "taker_gets": "29740867287", - "taker_pays": { - "currency": "USD", - "issuer": "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q", - "value": "226.0050145327418" - } - }, { - "flags": 0, - "quality": "7989247009094510e-27", - "seq": 6572128, - "taker_gets": "2361918758", - "taker_pays": { - "currency": "XAU", - "issuer": "rrh7rf1gV2pXAoqA8oYbpHd8TKv5ZQeo67", - "value": "0.01886995237307572" - } - }, { - "flags": 0, - "quality": "0.00000004059594001318974", - "seq": 6576905, - "taker_gets": "3892952574", - "taker_pays": { - "currency": "CNY", - "issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y", - "value": "158.0380691682966" - } - }, + "result": { + "account": "rpP2JgiMyTF5jR5hLG3xHCPi1knBb1v9cM", + "ledger_current_index": 18539596, + "offers": [{ + "flags": 0, + "quality": "0.000000007599140009999998", + "seq": 6578020, + "taker_gets": "29740867287", + "taker_pays": { + "currency": "USD", + "issuer": "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q", + "value": "226.0050145327418" + } + }, { + "flags": 0, + "quality": "7989247009094510e-27", + "seq": 6572128, + "taker_gets": "2361918758", + "taker_pays": { + "currency": "XAU", + "issuer": "rrh7rf1gV2pXAoqA8oYbpHd8TKv5ZQeo67", + "value": "0.01886995237307572" + } + }, { + "flags": 0, + "quality": "0.00000004059594001318974", + "seq": 6576905, + "taker_gets": "3892952574", + "taker_pays": { + "currency": "CNY", + "issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y", + "value": "158.0380691682966" + } + }, - ... + ... - ], - "status": "success", - "validated": false - } + ], + "status": "success", + "validated": false + } } ``` @@ -3016,30 +3016,30 @@ An example of a successful response: ``` 200 OK { - "result": { - "ledger": { - "accepted": true, - "account_hash": "B089E7CD4F5167249951611AAEC863D4BF84FF098500E9CB50561F1A89EED825", - "close_flags": 0, - "close_time": 508541222, - "close_time_human": "2016-Feb-11 21:27:02", - "close_time_resolution": 10, - "closed": true, - "hash": "85E6D422F1A3AE0BEA315C4F09CD0B45022312A4BBF0D308246E901536B61157", - "ledger_hash": "85E6D422F1A3AE0BEA315C4F09CD0B45022312A4BBF0D308246E901536B61157", - "ledger_index": "18851543", - "parent_close_time": 508541221, - "parent_hash": "C382DB117F2D5AAECFBFB43EA509F8E56D6E1D1297CE00C0D02A3EE695ABB78F", - "seqNum": "18851543", - "totalCoins": "99998102795090646", - "total_coins": "99998102795090646", - "transaction_hash": "BEC71A3CAD11BFC4E4013CD109F220E0850E9A3808B15FAA6DAE4D898970EFAF" - }, - "ledger_hash": "85E6D422F1A3AE0BEA315C4F09CD0B45022312A4BBF0D308246E901536B61157", - "ledger_index": 18851543, - "status": "success", - "validated": true - } + "result": { + "ledger": { + "accepted": true, + "account_hash": "B089E7CD4F5167249951611AAEC863D4BF84FF098500E9CB50561F1A89EED825", + "close_flags": 0, + "close_time": 508541222, + "close_time_human": "2016-Feb-11 21:27:02", + "close_time_resolution": 10, + "closed": true, + "hash": "85E6D422F1A3AE0BEA315C4F09CD0B45022312A4BBF0D308246E901536B61157", + "ledger_hash": "85E6D422F1A3AE0BEA315C4F09CD0B45022312A4BBF0D308246E901536B61157", + "ledger_index": "18851543", + "parent_close_time": 508541221, + "parent_hash": "C382DB117F2D5AAECFBFB43EA509F8E56D6E1D1297CE00C0D02A3EE695ABB78F", + "seqNum": "18851543", + "totalCoins": "99998102795090646", + "total_coins": "99998102795090646", + "transaction_hash": "BEC71A3CAD11BFC4E4013CD109F220E0850E9A3808B15FAA6DAE4D898970EFAF" + }, + "ledger_hash": "85E6D422F1A3AE0BEA315C4F09CD0B45022312A4BBF0D308246E901536B61157", + "ledger_index": 18851543, + "status": "success", + "validated": true + } } ``` @@ -6301,6 +6301,8 @@ __*Caution:*__ If this command results in an error messages, the message can con The `sign_for` command provides one signature for a [multi-signed transaction](reference-transaction-format.html#multi-signing). +This command requires the [MultiSign amendment](concept-amendments.html#multisign) to be enabled. + #### Request Format #### An example of the request format: @@ -6310,24 +6312,24 @@ An example of the request format: ``` { - "id": "sign_for_example", - "command": "sign_for", - "account": "rLFd1FzHMScFhLsXeaxStzv3UC97QHGAbM", - "seed": "s████████████████████████████", - "key_type": "ed25519", - "tx_json": { - "TransactionType": "TrustSet", - "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", - "Flags": 262144, - "LimitAmount": { - "currency": "USD", - "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", - "value": "100" - }, - "Sequence": 2, - "SigningPubKey": "", - "Fee": "30000" - } + "id": "sign_for_example", + "command": "sign_for", + "account": "rLFd1FzHMScFhLsXeaxStzv3UC97QHGAbM", + "seed": "s████████████████████████████", + "key_type": "ed25519", + "tx_json": { + "TransactionType": "TrustSet", + "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "Flags": 262144, + "LimitAmount": { + "currency": "USD", + "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "value": "100" + }, + "Sequence": 2, + "SigningPubKey": "", + "Fee": "30000" + } } ``` @@ -6363,17 +6365,17 @@ POST http://localhost:5005/ ``` #Syntax: rippled sign_for [offline] rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW s████████████████████████████ '{ - "TransactionType": "TrustSet", - "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", - "Flags": 262144, - "LimitAmount": { - "currency": "USD", - "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", - "value": "100" - }, - "Sequence": 2, - "SigningPubKey": "", - "Fee": "30000" + "TransactionType": "TrustSet", + "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "Flags": 262144, + "LimitAmount": { + "currency": "USD", + "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "value": "100" + }, + "Sequence": 2, + "SigningPubKey": "", + "Fee": "30000" }' ``` @@ -6728,13 +6730,13 @@ The response follows the [standard format](#response-formatting), with a success | Field | Type | Description | |-------|------|-------------| -| engine_result | String | Code indicating the status of the transaction, for example `tesSUCCESS` | -| engine_result_code | Integer | Numeric code indicating the status of the transaction, directly correlated to `engine_result` | -| engine_result_message | String | Human-readable explanation of the status of the transaction | +| engine_result | String | Code indicating the preliminary result of the transaction, for example `tesSUCCESS` | +| engine_result_code | Integer | Numeric code indicating the preliminary result of the transaction, directly correlated to `engine_result` | +| engine_result_message | String | Human-readable explanation of the transaction's preliminary result | | tx_blob | String | The complete transaction in hex string format | | tx_json | Object | The complete transaction in JSON format | -__*Caution:*__ Even if the WebSocket response has `"status":"success"`, indicating that the command was successfully received, that does not necessarily indicate that the transaction has taken place. There are many cases that can prevent a transaction from processing successfully, such as a lack of trust lines connecting the two accounts in a payment, or changes in the state of the network since the time the transaction was constructed. Even if nothing is wrong, it may take several seconds to close and validate the ledger version that includes the transaction. See the [full list of transaction responses](reference-transaction-format.html#full-transaction-response-list) for details, and do not consider the transaction's results final until they appear in a validated ledger version. +__*Caution:*__ Even if the WebSocket response has `"status":"success"`, indicating that the command was successfully received, that does _not_ indicate that the transaction executed successfully. Many situations can prevent a transaction from processing successfully, such as a lack of trust lines connecting the two accounts in a payment, or changes in the state of the ledger since the time the transaction was constructed. Even if nothing is wrong, it may take several seconds to close and validate the ledger version that includes the transaction. See the [full list of transaction responses](reference-transaction-format.html#full-transaction-response-list) for details, and do not consider the transaction's results final until they appear in a validated ledger version. __*Caution:*__ If this command results in an error messages, the message can contain an account secret, if one was provided in the request. (This is not a problem if the request contained a signed tx_blob instead.) Make sure that these errors are not visible to others, including: @@ -6759,75 +6761,220 @@ __*Caution:*__ If this command results in an error messages, the message can con ## submit_multisigned ## [[Source]
                    ](https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/SubmitMultiSigned.cpp "Source") -The `submit_multisigned` command applies a [multi-signed](reference-transaction-format.html#multi-signing) transaction and sends it to the network to be included in future ledgers. (TODO: finish this) +The `submit_multisigned` command applies a [multi-signed](reference-transaction-format.html#multi-signing) transaction and sends it to the network to be included in future ledgers. (You can also submit multi-signed transactions in binary form using the [`submit` command in submit-only mode](#submit-only-mode).) + +This command requires the [MultiSign amendment](concept-amendments.html#multisign) to be enabled. #### Request Format #### An example of the request format: -
                    + *WebSocket* ``` -//actual example here +{ + "id": "submit_multisigned_example", + "command": "submit_multisigned", + "tx_json": { + "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "Fee": "30000", + "Flags": 262144, + "LimitAmount": { + "currency": "USD", + "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "value": "0" + }, + "Sequence": 4, + "Signers": [{ + "Signer": { + "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + "TxnSignature": "3045022100CC9C56DF51251CB04BB047E5F3B5EF01A0F4A8A549D7A20A7402BF54BA744064022061EF8EF1BCCBF144F480B32508B1D10FD4271831D5303F920DE41C64671CB5B7" + } + }, { + "Signer": { + "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n", + "SigningPubKey": "03398A4EDAE8EE009A5879113EAA5BA15C7BB0F612A87F4103E793AC919BD1E3C1", + "TxnSignature": "3045022100FEE8D8FA2D06CE49E9124567DCA265A21A9F5465F4A9279F075E4CE27E4430DE022042D5305777DA1A7801446780308897699412E4EDF0E1AEFDF3C8A0532BDE4D08" + } + }], + "SigningPubKey": "", + "TransactionType": "TrustSet", + "hash": "81A477E2A362D171BB16BE17B4120D9F809A327FA00242ABCA867283BEA2F4F8" + } +} ``` -*Second tab* +*JSON-RPC* ``` -//second example here +{ + "method": "submit_multisigned", + "params": [ + { + "tx_json": { + "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "Fee": "30000", + "Flags": 262144, + "LimitAmount": { + "currency": "USD", + "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "value": "0" + }, + "Sequence": 4, + "Signers": [ + { + "Signer": { + "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + "TxnSignature": "3045022100CC9C56DF51251CB04BB047E5F3B5EF01A0F4A8A549D7A20A7402BF54BA744064022061EF8EF1BCCBF144F480B32508B1D10FD4271831D5303F920DE41C64671CB5B7" + } + }, + { + "Signer": { + "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n", + "SigningPubKey": "03398A4EDAE8EE009A5879113EAA5BA15C7BB0F612A87F4103E793AC919BD1E3C1", + "TxnSignature": "3045022100FEE8D8FA2D06CE49E9124567DCA265A21A9F5465F4A9279F075E4CE27E4430DE022042D5305777DA1A7801446780308897699412E4EDF0E1AEFDF3C8A0532BDE4D08" + } + } + ], + "SigningPubKey": "", + "TransactionType": "TrustSet", + "hash": "81A477E2A362D171BB16BE17B4120D9F809A327FA00242ABCA867283BEA2F4F8" + } + } + ] +} ``` -
                    +*Commandline* + +``` +#Syntax: submit_multisigned +rippled submit_multisigned '{ + "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "Fee": "30000", + "Flags": 262144, + "LimitAmount": { + "currency": "USD", + "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "value": "0" + }, + "Sequence": 4, + "Signers": [ + { + "Signer": { + "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + "TxnSignature": "3045022100CC9C56DF51251CB04BB047E5F3B5EF01A0F4A8A549D7A20A7402BF54BA744064022061EF8EF1BCCBF144F480B32508B1D10FD4271831D5303F920DE41C64671CB5B7" + } + }, + { + "Signer": { + "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n", + "SigningPubKey": "03398A4EDAE8EE009A5879113EAA5BA15C7BB0F612A87F4103E793AC919BD1E3C1", + "TxnSignature": "3045022100FEE8D8FA2D06CE49E9124567DCA265A21A9F5465F4A9279F075E4CE27E4430DE022042D5305777DA1A7801446780308897699412E4EDF0E1AEFDF3C8A0532BDE4D08" + } + } + ], + "SigningPubKey": "", + "TransactionType": "TrustSet", + "hash": "81A477E2A362D171BB16BE17B4120D9F809A327FA00242ABCA867283BEA2F4F8" +}' +``` + + The request includes the following parameters: -| Field | Type | Description | -|-------|------|-------------| - - - - - - - +| Field | Type | Description | +|----------|--------|-------------| +| tx\_json | Object | [Transaction in JSON format](reference-transaction-format.html) with an array of `Signers`. To be successful, the weights of the signatures must be equal or higher than the quorum of the [SignerList](reference-ledger-format.html#signerlist). | +| fail\_hard | Boolean | (Optional) If true, (TODO) whatever fail_hard actually does. | #### Response Format #### An example of a successful response: -
                    + *WebSocket* ``` -//actual example here +//TODO: actual example here ``` -*Second tab* +*JSON-RPC* ``` -//second example here +200 OK +{ + "result": { + "engine_result": "tesSUCCESS", + "engine_result_code": 0, + "engine_result_message": "The transaction was applied. Only final in a validated ledger.", + "status": "success", + "tx_blob": "120014220004000024000000046380000000000000000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF74473045022100CC9C56DF51251CB04BB047E5F3B5EF01A0F4A8A549D7A20A7402BF54BA744064022061EF8EF1BCCBF144F480B32508B1D10FD4271831D5303F920DE41C64671CB5B78114204288D2E47F8EF6C99BCC457966320D12409711E1E010732103398A4EDAE8EE009A5879113EAA5BA15C7BB0F612A87F4103E793AC919BD1E3C174473045022100FEE8D8FA2D06CE49E9124567DCA265A21A9F5465F4A9279F075E4CE27E4430DE022042D5305777DA1A7801446780308897699412E4EDF0E1AEFDF3C8A0532BDE4D0881143A4C02EA95AD6AC3BED92FA036E0BBFB712C030CE1F1", + "tx_json": { + "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "Fee": "30000", + "Flags": 262144, + "LimitAmount": { + "currency": "USD", + "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "value": "0" + }, + "Sequence": 4, + "Signers": [ + { + "Signer": { + "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + "TxnSignature": "3045022100CC9C56DF51251CB04BB047E5F3B5EF01A0F4A8A549D7A20A7402BF54BA744064022061EF8EF1BCCBF144F480B32508B1D10FD4271831D5303F920DE41C64671CB5B7" + } + }, + { + "Signer": { + "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n", + "SigningPubKey": "03398A4EDAE8EE009A5879113EAA5BA15C7BB0F612A87F4103E793AC919BD1E3C1", + "TxnSignature": "3045022100FEE8D8FA2D06CE49E9124567DCA265A21A9F5465F4A9279F075E4CE27E4430DE022042D5305777DA1A7801446780308897699412E4EDF0E1AEFDF3C8A0532BDE4D08" + } + } + ], + "SigningPubKey": "", + "TransactionType": "TrustSet", + "hash": "81A477E2A362D171BB16BE17B4120D9F809A327FA00242ABCA867283BEA2F4F8" + } + } +} ``` -
                    + The response follows the [standard format](#response-formatting), with a successful result containing the following fields: | Field | Type | Description | |-------|------|-------------| - - - - +| engine\_result | String | Code indicating the preliminary result of the transaction, for example `tesSUCCESS` | +| engine\_result\_code | Integer | Numeric code indicating the preliminary result of the transaction, directly correlated to `engine_result` | +| engine\_result\_message | String | Human-readable explanation of the preliminary transaction result | +| tx\_blob | String | The complete [transaction](reference-transaction-format.html) in hex string format | +| tx\_json | Object | The complete [transaction](reference-transaction-format.html) in JSON format | #### Possible Errors #### -* Any of the [universal error types](#universal-errors). -* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing. -* `actNotFound` - The address specified in the `account` field of the request does not correspond to an account in the ledger. -* `lgrNotFound` - The ledger specified by the `ledger_hash` or `ledger_index` does not exist, or it does exist but the server does not have it. +TODO: confirm this list (copy-pasta from traditional submit) +* Any of the [universal error types](#universal-errors). +* `invalidTransaction` - The transaction is malformed or otherwise invalid. +* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing. +* `highFee` - The `fee_mult_max` parameter was specified, but the server's current fee multiplier exceeds the specified one. (Sign-and-Submit mode only) +* `tooBusy` - The transaction did not include paths, but the server is too busy to do pathfinding right now. Does not occur if you are connected as an admin. (Sign-and-Submit mode only) +* `noPath` - The transaction did not include paths, and the server was unable to find a path by which this payment can occur. (Sign-and-Submit mode only) +* `internalTransaction` - An internal error occurred when processing the transaction. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed. +* `internalSubmit` - An internal error occurred when submitting the transaction. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed. +* `internalJson` - An internal error occurred when serializing the transaction to JSON. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed. @@ -7338,12 +7485,12 @@ Transaction stream messages have the following fields: | Field | Type | Description | |-------|------|-------------| | type | String | `transaction` indicates this is the notification of a transaction, which could come from several possible streams. | -| engine_result | String | String [Transaction result code](reference-transaction-format.html#result-categories) | -| engine_result_code | Number | Numeric [transaction response code](reference-transaction-format.html#result-categories), if applicable. | -| engine_result_message | String | Human-readable explanation for the transaction response | -| ledger_current_index | Unsigned Integer | (Omitted for validated transactions) Sequence number of the current ledger version for which this transaction is currently proposed | -| ledger_hash | String | (Omitted for unvalidated transactions) Unique hash of the ledger version that includes this transaction, as hex | -| ledger_index | Unsigned Integer | (Omitted for unvalidated transactions) Sequence number of the ledger version that includes this transaction | +| engine\_result | String | String [Transaction result code](reference-transaction-format.html#result-categories) | +| engine\_result\_code | Number | Numeric [transaction response code](reference-transaction-format.html#result-categories), if applicable. | +| engine\_result\_message | String | Human-readable explanation for the transaction response | +| ledger\_current\_index | Unsigned Integer | (Omitted for validated transactions) Sequence number of the current ledger version for which this transaction is currently proposed | +| ledger\_hash | String | (Omitted for unvalidated transactions) Unique hash of the ledger version that includes this transaction, as hex | +| ledger\_index | Unsigned Integer | (Omitted for unvalidated transactions) Sequence number of the ledger version that includes this transaction | | meta | Object | (Omitted for unvalidated transactions) Various metadata about the transaction, including which ledger entries it affected | | transaction | Object | The [definition of the transaction](reference-transaction-format.html) in JSON format | | validated | Boolean | If true, this transaction is included in a validated ledger. Responses from the `transaction` stream should always be validated. | @@ -7357,13 +7504,13 @@ Example of a Peer Status stream message: ``` { - "action": "CLOSING_LEDGER", - "date": 508546525, - "ledger_hash": "4D4CD9CD543F0C1EF023CC457F5BEFEA59EEF73E4552542D40E7C4FA08D3C320", - "ledger_index": 18853106, - "ledger_index_max": 18853106, - "ledger_index_min": 18852082, - "type": "peerStatusChange" + "action": "CLOSING_LEDGER", + "date": 508546525, + "ledger_hash": "4D4CD9CD543F0C1EF023CC457F5BEFEA59EEF73E4552542D40E7C4FA08D3C320", + "ledger_index": 18853106, + "ledger_index_max": 18853106, + "ledger_index_min": 18852082, + "type": "peerStatusChange" } ``` @@ -7399,126 +7546,126 @@ Example order book stream message: ``` { - "engine_result": "tesSUCCESS", - "engine_result_code": 0, - "engine_result_message": "The transaction was applied. Only final in a validated ledger.", - "ledger_hash": "08547DD866F099CCB3666F113116B7AA2DF520FA2E3011DD1FF9C9C04A6C7C3E", - "ledger_index": 18852105, - "meta": { - "AffectedNodes": [{ - "ModifiedNode": { - "FinalFields": { - "Account": "rfCFLzNJYvvnoGHWQYACmJpTgkLUaugLEw", - "AccountTxnID": "D295E2BE50E3B78AED24790D7B9096996DAF43F095BF17DB83EEACC283D14050", - "Balance": "3070332374272", - "Flags": 0, - "OwnerCount": 23, - "RegularKey": "r9S56zu6QeJD5d8A7QMfLAeYavgB9dhaX4", - "Sequence": 12142921 - }, - "LedgerEntryType": "AccountRoot", - "LedgerIndex": "2880A9B4FB90A306B576C2D532BFE390AB3904642647DCF739492AA244EF46D1", - "PreviousFields": { - "AccountTxnID": "3CA3422B0E42D76A7A677B0BA0BE72DFCD93676E0C80F8D2EB27C04BD8457A0F", - "Balance": "3070332385272", - "Sequence": 12142920 - }, - "PreviousTxnID": "3CA3422B0E42D76A7A677B0BA0BE72DFCD93676E0C80F8D2EB27C04BD8457A0F", - "PreviousTxnLgrSeq": 18852102 - } - }, { - "ModifiedNode": { - "FinalFields": { - "Flags": 0, - "IndexPrevious": "00000000000022D2", - "Owner": "rfCFLzNJYvvnoGHWQYACmJpTgkLUaugLEw", - "RootIndex": "F435FBBEC9654204D7151A01E686BAA8CB325A472D7B61C7916EA58B59355767" - }, - "LedgerEntryType": "DirectoryNode", - "LedgerIndex": "29A543B6681AD7FC8AFBD1386DAE7385F02F9B8C4756A467DF6834AB54BBC9DB" - } - }, { - "ModifiedNode": { - "FinalFields": { - "ExchangeRate": "4C1BA999A513EF78", - "Flags": 0, - "RootIndex": "79C54A4EBD69AB2EADCE313042F36092BE432423CC6A4F784C1BA999A513EF78", - "TakerGetsCurrency": "0000000000000000000000000000000000000000", - "TakerGetsIssuer": "0000000000000000000000000000000000000000", - "TakerPaysCurrency": "0000000000000000000000005553440000000000", - "TakerPaysIssuer": "2ADB0B3959D60A6E6991F729E1918B7163925230" - }, - "LedgerEntryType": "DirectoryNode", - "LedgerIndex": "79C54A4EBD69AB2EADCE313042F36092BE432423CC6A4F784C1BA999A513EF78" - } - }, { - "CreatedNode": { - "LedgerEntryType": "Offer", - "LedgerIndex": "92E235EE80D2B28A89BEE2C905D4545C2A004FD5D4097679C8A3FB25507FD9EB", - "NewFields": { - "Account": "rfCFLzNJYvvnoGHWQYACmJpTgkLUaugLEw", - "BookDirectory": "79C54A4EBD69AB2EADCE313042F36092BE432423CC6A4F784C1BA999A513EF78", - "Expiration": 508543674, - "OwnerNode": "00000000000022F4", - "Sequence": 12142920, - "TakerGets": "6537121438", - "TakerPays": { - "currency": "USD", - "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value": "50.9" - } - } - } - }, { - "DeletedNode": { - "FinalFields": { - "Account": "rfCFLzNJYvvnoGHWQYACmJpTgkLUaugLEw", - "BookDirectory": "79C54A4EBD69AB2EADCE313042F36092BE432423CC6A4F784C1BA999A513EF78", - "BookNode": "0000000000000000", - "Expiration": 508543133, - "Flags": 0, - "OwnerNode": "00000000000022F4", - "PreviousTxnID": "58B3279C2D56AAC3D9B06106E637C01E3D911E9D31E2FE4EA0D886AC9F4DEE1E", - "PreviousTxnLgrSeq": 18851945, - "Sequence": 12142889, - "TakerGets": "6537121438", - "TakerPays": { - "currency": "USD", - "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value": "50.9" - } - }, - "LedgerEntryType": "Offer", - "LedgerIndex": "D3436CE21925E1CB12C5C444963B47D7EA0CD9A0E387926DC76B23FE5CD1C15F" - } - }], - "TransactionIndex": 26, - "TransactionResult": "tesSUCCESS" - }, - "status": "closed", - "transaction": { - "Account": "rfCFLzNJYvvnoGHWQYACmJpTgkLUaugLEw", - "Expiration": 508543674, - "Fee": "11000", - "Flags": 2147483648, - "LastLedgerSequence": 18852106, - "OfferSequence": 12142889, - "Sequence": 12142920, - "SigningPubKey": "034841BF24BD72C7CC371EBD87CCBF258D8ADB05C18DE207130364A97D8A3EA524", - "TakerGets": "6537121438", - "TakerPays": { - "currency": "USD", - "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value": "50.9" - }, - "TransactionType": "OfferCreate", - "TxnSignature": "3045022100B9AD678A773FB61F8F9B565713C80CBF187A2F9EB8E9CE0DAC7B839CA6F4B04C02200613D173A0636CD9BE13F2E3EBD13A16932B5B7D8A96BB5F6D561CA5CDBC4AD3", - "date": 508543090, - "hash": "D295E2BE50E3B78AED24790D7B9096996DAF43F095BF17DB83EEACC283D14050", - "owner_funds": "3070197374272" - }, - "type": "transaction", - "validated": true + "engine_result": "tesSUCCESS", + "engine_result_code": 0, + "engine_result_message": "The transaction was applied. Only final in a validated ledger.", + "ledger_hash": "08547DD866F099CCB3666F113116B7AA2DF520FA2E3011DD1FF9C9C04A6C7C3E", + "ledger_index": 18852105, + "meta": { + "AffectedNodes": [{ + "ModifiedNode": { + "FinalFields": { + "Account": "rfCFLzNJYvvnoGHWQYACmJpTgkLUaugLEw", + "AccountTxnID": "D295E2BE50E3B78AED24790D7B9096996DAF43F095BF17DB83EEACC283D14050", + "Balance": "3070332374272", + "Flags": 0, + "OwnerCount": 23, + "RegularKey": "r9S56zu6QeJD5d8A7QMfLAeYavgB9dhaX4", + "Sequence": 12142921 + }, + "LedgerEntryType": "AccountRoot", + "LedgerIndex": "2880A9B4FB90A306B576C2D532BFE390AB3904642647DCF739492AA244EF46D1", + "PreviousFields": { + "AccountTxnID": "3CA3422B0E42D76A7A677B0BA0BE72DFCD93676E0C80F8D2EB27C04BD8457A0F", + "Balance": "3070332385272", + "Sequence": 12142920 + }, + "PreviousTxnID": "3CA3422B0E42D76A7A677B0BA0BE72DFCD93676E0C80F8D2EB27C04BD8457A0F", + "PreviousTxnLgrSeq": 18852102 + } + }, { + "ModifiedNode": { + "FinalFields": { + "Flags": 0, + "IndexPrevious": "00000000000022D2", + "Owner": "rfCFLzNJYvvnoGHWQYACmJpTgkLUaugLEw", + "RootIndex": "F435FBBEC9654204D7151A01E686BAA8CB325A472D7B61C7916EA58B59355767" + }, + "LedgerEntryType": "DirectoryNode", + "LedgerIndex": "29A543B6681AD7FC8AFBD1386DAE7385F02F9B8C4756A467DF6834AB54BBC9DB" + } + }, { + "ModifiedNode": { + "FinalFields": { + "ExchangeRate": "4C1BA999A513EF78", + "Flags": 0, + "RootIndex": "79C54A4EBD69AB2EADCE313042F36092BE432423CC6A4F784C1BA999A513EF78", + "TakerGetsCurrency": "0000000000000000000000000000000000000000", + "TakerGetsIssuer": "0000000000000000000000000000000000000000", + "TakerPaysCurrency": "0000000000000000000000005553440000000000", + "TakerPaysIssuer": "2ADB0B3959D60A6E6991F729E1918B7163925230" + }, + "LedgerEntryType": "DirectoryNode", + "LedgerIndex": "79C54A4EBD69AB2EADCE313042F36092BE432423CC6A4F784C1BA999A513EF78" + } + }, { + "CreatedNode": { + "LedgerEntryType": "Offer", + "LedgerIndex": "92E235EE80D2B28A89BEE2C905D4545C2A004FD5D4097679C8A3FB25507FD9EB", + "NewFields": { + "Account": "rfCFLzNJYvvnoGHWQYACmJpTgkLUaugLEw", + "BookDirectory": "79C54A4EBD69AB2EADCE313042F36092BE432423CC6A4F784C1BA999A513EF78", + "Expiration": 508543674, + "OwnerNode": "00000000000022F4", + "Sequence": 12142920, + "TakerGets": "6537121438", + "TakerPays": { + "currency": "USD", + "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value": "50.9" + } + } + } + }, { + "DeletedNode": { + "FinalFields": { + "Account": "rfCFLzNJYvvnoGHWQYACmJpTgkLUaugLEw", + "BookDirectory": "79C54A4EBD69AB2EADCE313042F36092BE432423CC6A4F784C1BA999A513EF78", + "BookNode": "0000000000000000", + "Expiration": 508543133, + "Flags": 0, + "OwnerNode": "00000000000022F4", + "PreviousTxnID": "58B3279C2D56AAC3D9B06106E637C01E3D911E9D31E2FE4EA0D886AC9F4DEE1E", + "PreviousTxnLgrSeq": 18851945, + "Sequence": 12142889, + "TakerGets": "6537121438", + "TakerPays": { + "currency": "USD", + "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value": "50.9" + } + }, + "LedgerEntryType": "Offer", + "LedgerIndex": "D3436CE21925E1CB12C5C444963B47D7EA0CD9A0E387926DC76B23FE5CD1C15F" + } + }], + "TransactionIndex": 26, + "TransactionResult": "tesSUCCESS" + }, + "status": "closed", + "transaction": { + "Account": "rfCFLzNJYvvnoGHWQYACmJpTgkLUaugLEw", + "Expiration": 508543674, + "Fee": "11000", + "Flags": 2147483648, + "LastLedgerSequence": 18852106, + "OfferSequence": 12142889, + "Sequence": 12142920, + "SigningPubKey": "034841BF24BD72C7CC371EBD87CCBF258D8ADB05C18DE207130364A97D8A3EA524", + "TakerGets": "6537121438", + "TakerPays": { + "currency": "USD", + "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value": "50.9" + }, + "TransactionType": "OfferCreate", + "TxnSignature": "3045022100B9AD678A773FB61F8F9B565713C80CBF187A2F9EB8E9CE0DAC7B839CA6F4B04C02200613D173A0636CD9BE13F2E3EBD13A16932B5B7D8A96BB5F6D561CA5CDBC4AD3", + "date": 508543090, + "hash": "D295E2BE50E3B78AED24790D7B9096996DAF43F095BF17DB83EEACC283D14050", + "owner_funds": "3070197374272" + }, + "type": "transaction", + "validated": true } ``` diff --git a/reference-rippled.html b/reference-rippled.html index 624ecb84d3..28be290d6c 100644 --- a/reference-rippled.html +++ b/reference-rippled.html @@ -7323,6 +7323,7 @@ rippled sign sssssssssssssssssssssssssssss '{"TransactionType": "Payment", "Acco

                    sign_for

                    [Source]

                    The sign_for command provides one signature for a multi-signed transaction.

                    +

                    This command requires the MultiSign amendment to be enabled.

                    Request Format

                    An example of the request format:

                    @@ -7795,17 +7796,17 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r engine_result String -Code indicating the status of the transaction, for example tesSUCCESS +Code indicating the preliminary result of the transaction, for example tesSUCCESS engine_result_code Integer -Numeric code indicating the status of the transaction, directly correlated to engine_result +Numeric code indicating the preliminary result of the transaction, directly correlated to engine_result engine_result_message String -Human-readable explanation of the status of the transaction +Human-readable explanation of the transaction's preliminary result tx_blob @@ -7819,7 +7820,7 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r -

                    Caution: Even if the WebSocket response has "status":"success", indicating that the command was successfully received, that does not necessarily indicate that the transaction has taken place. There are many cases that can prevent a transaction from processing successfully, such as a lack of trust lines connecting the two accounts in a payment, or changes in the state of the network since the time the transaction was constructed. Even if nothing is wrong, it may take several seconds to close and validate the ledger version that includes the transaction. See the full list of transaction responses for details, and do not consider the transaction's results final until they appear in a validated ledger version.

                    +

                    Caution: Even if the WebSocket response has "status":"success", indicating that the command was successfully received, that does not indicate that the transaction executed successfully. Many situations can prevent a transaction from processing successfully, such as a lack of trust lines connecting the two accounts in a payment, or changes in the state of the ledger since the time the transaction was constructed. Even if nothing is wrong, it may take several seconds to close and validate the ledger version that includes the transaction. See the full list of transaction responses for details, and do not consider the transaction's results final until they appear in a validated ledger version.

                    Caution: If this command results in an error messages, the message can contain an account secret, if one was provided in the request. (This is not a problem if the request contained a signed tx_blob instead.) Make sure that these errors are not visible to others, including:

                    • Do not write an error including your secret to a log file that can be seen by multiple people
                      • @@ -7840,23 +7841,116 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r

                    submit_multisigned

                    [Source]

                    -

                    The submit_multisigned command applies a multi-signed transaction and sends it to the network to be included in future ledgers. (TODO: finish this)

                    +

                    The submit_multisigned command applies a multi-signed transaction and sends it to the network to be included in future ledgers. (You can also submit multi-signed transactions in binary form using the submit command in submit-only mode.)

                    +

                    This command requires the MultiSign amendment to be enabled.

                    Request Format

                    An example of the request format:

                    - -*WebSocket* - - -wzxhzdk:126 - - -*Second tab* - - -wzxhzdk:127 - - +

                    WebSocket

                    +
                    {
+    "id": "submit_multisigned_example",
+    "command": "submit_multisigned",
+    "tx_json": {
+        "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+        "Fee": "30000",
+        "Flags": 262144,
+        "LimitAmount": {
+            "currency": "USD",
+            "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+            "value": "0"
+        },
+        "Sequence": 4,
+        "Signers": [{
+            "Signer": {
+                "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+                "TxnSignature": "3045022100CC9C56DF51251CB04BB047E5F3B5EF01A0F4A8A549D7A20A7402BF54BA744064022061EF8EF1BCCBF144F480B32508B1D10FD4271831D5303F920DE41C64671CB5B7"
+            }
+        }, {
+            "Signer": {
+                "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
+                "SigningPubKey": "03398A4EDAE8EE009A5879113EAA5BA15C7BB0F612A87F4103E793AC919BD1E3C1",
+                "TxnSignature": "3045022100FEE8D8FA2D06CE49E9124567DCA265A21A9F5465F4A9279F075E4CE27E4430DE022042D5305777DA1A7801446780308897699412E4EDF0E1AEFDF3C8A0532BDE4D08"
+            }
+        }],
+        "SigningPubKey": "",
+        "TransactionType": "TrustSet",
+        "hash": "81A477E2A362D171BB16BE17B4120D9F809A327FA00242ABCA867283BEA2F4F8"
+    }
+}
+
                    +

                    JSON-RPC

                    +
                    {
+    "method": "submit_multisigned",
+    "params": [
+        {
+            "tx_json": {
+                "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+                "Fee": "30000",
+                "Flags": 262144,
+                "LimitAmount": {
+                    "currency": "USD",
+                    "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+                    "value": "0"
+                },
+                "Sequence": 4,
+                "Signers": [
+                    {
+                        "Signer": {
+                            "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                            "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+                            "TxnSignature": "3045022100CC9C56DF51251CB04BB047E5F3B5EF01A0F4A8A549D7A20A7402BF54BA744064022061EF8EF1BCCBF144F480B32508B1D10FD4271831D5303F920DE41C64671CB5B7"
+                        }
+                    },
+                    {
+                        "Signer": {
+                            "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
+                            "SigningPubKey": "03398A4EDAE8EE009A5879113EAA5BA15C7BB0F612A87F4103E793AC919BD1E3C1",
+                            "TxnSignature": "3045022100FEE8D8FA2D06CE49E9124567DCA265A21A9F5465F4A9279F075E4CE27E4430DE022042D5305777DA1A7801446780308897699412E4EDF0E1AEFDF3C8A0532BDE4D08"
+                        }
+                    }
+                ],
+                "SigningPubKey": "",
+                "TransactionType": "TrustSet",
+                "hash": "81A477E2A362D171BB16BE17B4120D9F809A327FA00242ABCA867283BEA2F4F8"
+            }
+        }
+    ]
+}
+
                    +

                    Commandline

                    +
                    #Syntax: submit_multisigned <tx_json>
+rippled submit_multisigned '{
+    "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+    "Fee": "30000",
+    "Flags": 262144,
+    "LimitAmount": {
+        "currency": "USD",
+        "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+        "value": "0"
+    },
+    "Sequence": 4,
+    "Signers": [
+        {
+            "Signer": {
+                "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+                "TxnSignature": "3045022100CC9C56DF51251CB04BB047E5F3B5EF01A0F4A8A549D7A20A7402BF54BA744064022061EF8EF1BCCBF144F480B32508B1D10FD4271831D5303F920DE41C64671CB5B7"
+            }
+        },
+        {
+            "Signer": {
+                "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
+                "SigningPubKey": "03398A4EDAE8EE009A5879113EAA5BA15C7BB0F612A87F4103E793AC919BD1E3C1",
+                "TxnSignature": "3045022100FEE8D8FA2D06CE49E9124567DCA265A21A9F5465F4A9279F075E4CE27E4430DE022042D5305777DA1A7801446780308897699412E4EDF0E1AEFDF3C8A0532BDE4D08"
+            }
+        }
+    ],
+    "SigningPubKey": "",
+    "TransactionType": "TrustSet",
+    "hash": "81A477E2A362D171BB16BE17B4120D9F809A327FA00242ABCA867283BEA2F4F8"
+}'
+

                    The request includes the following parameters:

                    @@ -7867,24 +7961,67 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r - + + + + + + + + + + + +
                    Description
                    tx_jsonObjectTransaction in JSON format with an array of Signers. To be successful, the weights of the signatures must be equal or higher than the quorum of the SignerList.
                    fail_hardBoolean(Optional) If true, (TODO) whatever fail_hard actually does.

                    Response Format

                    An example of a successful response:

                    - -*WebSocket* - - -wzxhzdk:128 - - -*Second tab* - - -wzxhzdk:129 - - +

                    WebSocket

                    +
                    //TODO: actual example here
+
                    +

                    JSON-RPC

                    +
                    200 OK
+{
+    "result": {
+        "engine_result": "tesSUCCESS",
+        "engine_result_code": 0,
+        "engine_result_message": "The transaction was applied. Only final in a validated ledger.",
+        "status": "success",
+        "tx_blob": "120014220004000024000000046380000000000000000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF74473045022100CC9C56DF51251CB04BB047E5F3B5EF01A0F4A8A549D7A20A7402BF54BA744064022061EF8EF1BCCBF144F480B32508B1D10FD4271831D5303F920DE41C64671CB5B78114204288D2E47F8EF6C99BCC457966320D12409711E1E010732103398A4EDAE8EE009A5879113EAA5BA15C7BB0F612A87F4103E793AC919BD1E3C174473045022100FEE8D8FA2D06CE49E9124567DCA265A21A9F5465F4A9279F075E4CE27E4430DE022042D5305777DA1A7801446780308897699412E4EDF0E1AEFDF3C8A0532BDE4D0881143A4C02EA95AD6AC3BED92FA036E0BBFB712C030CE1F1",
+        "tx_json": {
+            "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+            "Fee": "30000",
+            "Flags": 262144,
+            "LimitAmount": {
+                "currency": "USD",
+                "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+                "value": "0"
+            },
+            "Sequence": 4,
+            "Signers": [
+                {
+                    "Signer": {
+                        "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                        "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+                        "TxnSignature": "3045022100CC9C56DF51251CB04BB047E5F3B5EF01A0F4A8A549D7A20A7402BF54BA744064022061EF8EF1BCCBF144F480B32508B1D10FD4271831D5303F920DE41C64671CB5B7"
+                    }
+                },
+                {
+                    "Signer": {
+                        "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
+                        "SigningPubKey": "03398A4EDAE8EE009A5879113EAA5BA15C7BB0F612A87F4103E793AC919BD1E3C1",
+                        "TxnSignature": "3045022100FEE8D8FA2D06CE49E9124567DCA265A21A9F5465F4A9279F075E4CE27E4430DE022042D5305777DA1A7801446780308897699412E4EDF0E1AEFDF3C8A0532BDE4D08"
+                    }
+                }
+            ],
+            "SigningPubKey": "",
+            "TransactionType": "TrustSet",
+            "hash": "81A477E2A362D171BB16BE17B4120D9F809A327FA00242ABCA867283BEA2F4F8"
+        }
+    }
+}
+

                    The response follows the standard format, with a successful result containing the following fields:

                    @@ -7895,14 +8032,46 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r - + + + + + + + + + + + + + + + + + + + + + + + + + + +
                    Description
                    engine_resultStringCode indicating the preliminary result of the transaction, for example tesSUCCESS
                    engine_result_codeIntegerNumeric code indicating the preliminary result of the transaction, directly correlated to engine_result
                    engine_result_messageStringHuman-readable explanation of the preliminary transaction result
                    tx_blobStringThe complete transaction in hex string format
                    tx_jsonObjectThe complete transaction in JSON format

                    Possible Errors

                    +

                    TODO: confirm this list (copy-pasta from traditional submit)

                    • Any of the universal error types.
                      • +
                    • invalidTransaction - The transaction is malformed or otherwise invalid.
                    • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
                      • -
                    • actNotFound - The address specified in the account field of the request does not correspond to an account in the ledger.
                      • -
                    • lgrNotFound - The ledger specified by the ledger_hash or ledger_index does not exist, or it does exist but the server does not have it.
                      • +
                    • highFee - The fee_mult_max parameter was specified, but the server's current fee multiplier exceeds the specified one. (Sign-and-Submit mode only)
                      • +
                    • tooBusy - The transaction did not include paths, but the server is too busy to do pathfinding right now. Does not occur if you are connected as an admin. (Sign-and-Submit mode only)
                      • +
                    • noPath - The transaction did not include paths, and the server was unable to find a path by which this payment can occur. (Sign-and-Submit mode only)
                      • +
                    • internalTransaction - An internal error occurred when processing the transaction. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed.
                      • +
                    • internalSubmit - An internal error occurred when submitting the transaction. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed.
                      • +
                    • internalJson - An internal error occurred when serializing the transaction to JSON. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed.

                    book_offers

                    [Source]

                    From d50fdd7638f2a92f59b9515ec3b59342d9ebc086 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Fri, 1 Apr 2016 18:21:16 -0700 Subject: [PATCH 22/40] amendments - config file for amendment voting --- content/concept-amendments.md | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/content/concept-amendments.md b/content/concept-amendments.md index 1bd982d04f..b8dd4b8bb0 100644 --- a/content/concept-amendments.md +++ b/content/concept-amendments.md @@ -40,10 +40,31 @@ It is theoretically possible (but extremely unlikely) that a `tfLostMajority` En Operators of `rippled` validators can choose which amendments to support or reject using the [`feature` command](reference-rippled.html#feature). This decides which amendments the validator votes for in the [amendment process](#amendment-process). By default, `rippled` votes in favor of every amendment it knows about. -The operator of a `rippled` validator can "veto" an amendment using the [`feature` command](reference-rippled.html#feature). In this case, that validator never sends a vote in favor of the amendment. If enough trusted validators veto an amendment, then the amendment does not apply. +The operator of a `rippled` validator can "veto" an amendment. In this case, that validator never sends a vote in favor of the amendment. If enough servers veto an amendment, that prevents it from reaching consistent 80% support, so the amendment does not apply. As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. Currently, Ripple recommends only trusting the 5 default validators that Ripple (the company) operates. For now, trusting only those validators is sufficient to coordinate with Ripple on releasing new features. +### Configuring Amendment Voting ### + +You can temporarily configure an amendment using the [`feature` command](reference-rippled.html#feature). To make a persistent change to your server's support for an amendment, modify your server's `rippled.cfg` file. + +Use the `[veto_amendments]` stanza to list amendments you do not want the server to vote for. Each line should contains one amendment's unique ID, optionally followed by the short name for the amendment. For example: + +``` +[veto_amendments] +C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 Tickets +DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 SusPay +``` + +Use the `[amendments]` stanza to list amendments you want to vote for. (Even if you do not list them here, by default a server votes for all the amendments it knows how to apply.) Each line should contains one amendment's unique ID, optionally followed by the short name for the amendment. For example: + +``` +[amendments] +4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 MultiSign +42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE FeeEscalation +``` + + ## Testing Amendments ## If you want to see how `rippled` behaves with an amendment enabled, before that amendment gets enabled on the production network, you can run use `rippled`'s configuration file to forcibly enable a feature. This is intended for development purposes only. From e53e4581d14f1fb03e93cc7ac18791a7360801f5 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Fri, 1 Apr 2016 18:21:33 -0700 Subject: [PATCH 23/40] rippled - feature, submit_multisigned --- concept-amendments.html | 14 +- content/reference-rippled.md | 307 ++++++++++++++++++++++++++----- reference-rippled.html | 339 +++++++++++++++++++++++++++++------ 3 files changed, 563 insertions(+), 97 deletions(-) diff --git a/concept-amendments.html b/concept-amendments.html index 7a2f5af094..cd956cece5 100644 --- a/concept-amendments.html +++ b/concept-amendments.html @@ -158,8 +158,20 @@

                    It is theoretically possible (but extremely unlikely) that a tfLostMajority EnableAmendment pseudo-transaction could be included in the same ledger as the pseudo-transaction to enable an amendment. In this case, the pseudo-transaction with the tfLostMajority pseudo-transaction has no effect.

                    Amendment Voting

                    Operators of rippled validators can choose which amendments to support or reject using the feature command. This decides which amendments the validator votes for in the amendment process. By default, rippled votes in favor of every amendment it knows about.

                    -

                    The operator of a rippled validator can "veto" an amendment using the feature command. In this case, that validator never sends a vote in favor of the amendment. If enough trusted validators veto an amendment, then the amendment does not apply.

                    +

                    The operator of a rippled validator can "veto" an amendment. In this case, that validator never sends a vote in favor of the amendment. If enough servers veto an amendment, that prevents it from reaching consistent 80% support, so the amendment does not apply.

                    As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. Currently, Ripple recommends only trusting the 5 default validators that Ripple (the company) operates. For now, trusting only those validators is sufficient to coordinate with Ripple on releasing new features.

                    +

                    Configuring Amendment Voting

                    +

                    You can temporarily configure an amendment using the feature command. To make a persistent change to your server's support for an amendment, modify your server's rippled.cfg file.

                    +

                    Use the [veto_amendments] stanza to list amendments you do not want the server to vote for. Each line should contains one amendment's unique ID, optionally followed by the short name for the amendment. For example:

                    +
                    [veto_amendments]
+C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 Tickets
+DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 SusPay
+
                    +

                    Use the [amendments] stanza to list amendments you want to vote for. (Even if you do not list them here, by default a server votes for all the amendments it knows how to apply.) Each line should contains one amendment's unique ID, optionally followed by the short name for the amendment. For example:

                    +
                    [amendments]
+4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 MultiSign
+42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE FeeEscalation
+

                    Testing Amendments

                    If you want to see how rippled behaves with an amendment enabled, before that amendment gets enabled on the production network, you can run use rippled's configuration file to forcibly enable a feature. This is intended for development purposes only.

                    Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run rippled in Stand-Alone Mode.

                    diff --git a/content/reference-rippled.md b/content/reference-rippled.md index c6c3c2d592..cd85c03737 100755 --- a/content/reference-rippled.md +++ b/content/reference-rippled.md @@ -523,7 +523,9 @@ API methods for the Websocket and JSON-RPC APIs are defined by command names, an * [`server_info` - Retrieve status of the server in human-readable format](#server-info) * [`server_state` - Retrieve status of the server in machine-readable format](#server-state) * [`sign` - Cryptographically sign a transaction](#sign) +* [`sign_for` - Contribute to a multi-signature](#sign-for) * [`submit` - Send a transaction to the network](#submit) +* [`submit_multisigned` - Send a multi-signed transaction to the network](#submit-multisigned) * [`subscribe` - Listen for updates about a particular subject](#subscribe) * [`transaction_entry` - Retrieve info about a transaction from a particular ledger version](#transaction-entry) * [`tx` - Retrieve info about a transaction from all the ledgers on hand](#tx) @@ -537,6 +539,7 @@ The `owner_info` command is deprecated. Use [`account_objects`](#account-objects * [`can_delete` - Allow online deletion of ledgers up to a specific ledger](#can-delete) * [`connect` - Force the rippled server to connect to a specific peer](#connect) * [`consensus_info` - Get information about the state of consensus as it happens](#consensus-info) +* [`feature` - Get information about protocol amendments](#feature) * [`fetch_info` - Get information about the server's sync with the network](#fetch-info) * [`get_counts` - Get statistics about the server's internals and memory usage](#get-counts) * [`ledger_accept` - Close and advance the ledger in stand-alone mode](#ledger-accept) @@ -6774,35 +6777,35 @@ An example of the request format: ``` { - "id": "submit_multisigned_example", - "command": "submit_multisigned", - "tx_json": { - "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", - "Fee": "30000", - "Flags": 262144, - "LimitAmount": { - "currency": "USD", - "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", - "value": "0" - }, - "Sequence": 4, - "Signers": [{ - "Signer": { - "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", - "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", - "TxnSignature": "3045022100CC9C56DF51251CB04BB047E5F3B5EF01A0F4A8A549D7A20A7402BF54BA744064022061EF8EF1BCCBF144F480B32508B1D10FD4271831D5303F920DE41C64671CB5B7" - } - }, { - "Signer": { - "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n", - "SigningPubKey": "03398A4EDAE8EE009A5879113EAA5BA15C7BB0F612A87F4103E793AC919BD1E3C1", - "TxnSignature": "3045022100FEE8D8FA2D06CE49E9124567DCA265A21A9F5465F4A9279F075E4CE27E4430DE022042D5305777DA1A7801446780308897699412E4EDF0E1AEFDF3C8A0532BDE4D08" - } - }], - "SigningPubKey": "", - "TransactionType": "TrustSet", - "hash": "81A477E2A362D171BB16BE17B4120D9F809A327FA00242ABCA867283BEA2F4F8" - } + "id": "submit_multisigned_example" + "command": "submit_multisigned", + "tx_json": { + "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "Fee": "30000", + "Flags": 262144, + "LimitAmount": { + "currency": "USD", + "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "value": "100" + }, + "Sequence": 2, + "Signers": [{ + "Signer": { + "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + "TxnSignature": "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5" + } + }, { + "Signer": { + "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + "SigningPubKey": "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B", + "TxnSignature": "30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1" + } + }], + "SigningPubKey": "", + "TransactionType": "TrustSet", + "hash": "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6" + } } ``` @@ -6891,7 +6894,7 @@ The request includes the following parameters: | Field | Type | Description | |----------|--------|-------------| | tx\_json | Object | [Transaction in JSON format](reference-transaction-format.html) with an array of `Signers`. To be successful, the weights of the signatures must be equal or higher than the quorum of the [SignerList](reference-ledger-format.html#signerlist). | -| fail\_hard | Boolean | (Optional) If true, (TODO) whatever fail_hard actually does. | +| fail\_hard | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers. | #### Response Format #### @@ -6902,7 +6905,47 @@ An example of a successful response: *WebSocket* ``` -//TODO: actual example here +{ + "id": "submit_multisigned_example", + "status": "success", + "type": "response", + "result": { + "engine_result": "tesSUCCESS", + "engine_result_code": 0, + "engine_result_message": "The transaction was applied. Only final in a validated ledger.", + "tx_blob": "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1E0107321028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B744630440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1F1", + "tx_json": { + "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC", + "Fee": "30000", + "Flags": 262144, + "LimitAmount": { + "currency": "USD", + "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "value": "100" + }, + "Sequence": 2, + "Signers": [ + { + "Signer": { + "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF", + "TxnSignature": "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5" + } + }, + { + "Signer": { + "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + "SigningPubKey": "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B", + "TxnSignature": "30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1" + } + } + ], + "SigningPubKey": "", + "TransactionType": "TrustSet", + "hash": "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6" + } + } +} ``` *JSON-RPC* @@ -6964,17 +7007,10 @@ The response follows the [standard format](#response-formatting), with a success #### Possible Errors #### -TODO: confirm this list (copy-pasta from traditional submit) - * Any of the [universal error types](#universal-errors). -* `invalidTransaction` - The transaction is malformed or otherwise invalid. * `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing. -* `highFee` - The `fee_mult_max` parameter was specified, but the server's current fee multiplier exceeds the specified one. (Sign-and-Submit mode only) -* `tooBusy` - The transaction did not include paths, but the server is too busy to do pathfinding right now. Does not occur if you are connected as an admin. (Sign-and-Submit mode only) -* `noPath` - The transaction did not include paths, and the server was unable to find a path by which this payment can occur. (Sign-and-Submit mode only) -* `internalTransaction` - An internal error occurred when processing the transaction. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed. -* `internalSubmit` - An internal error occurred when submitting the transaction. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed. -* `internalJson` - An internal error occurred when serializing the transaction to JSON. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed. +* `srcActMalformed` - The `Account` field from the `tx_json` was invalid or missing. +* `internal` - An internal error occurred. This includes the case where a signature is not valid for the transaction JSON provided. @@ -8791,6 +8827,197 @@ The fields describing a fetch in progress are subject to change without notice. * Any of the [universal error types](#universal-errors). +## feature ## +[[Source]
                    ](https://github.com/ripple/rippled/blob/develop/src/ripple/rpc/handlers/Feature1.cpp "Source") + +The `feature` command returns information about [amendments](concept-amendments.html) this server knows about, including whether they are enabled and whether the server is voting in favor of those amendments in the [amendment process](concept-amendments.html#amendment-process). + +You can use the `feature` command to temporarily configure the server to vote against or in favor of an amendment. This change does not persist if you restart the server. To make lasting changes in amendment voting, use the `rippled.cfg` file. See [Configuring Amendment Voting](concept-amendments.html#configuring-amendment-voting) for more information. + +_The `feature` method is an [admin command](#connecting-to-rippled) that cannot be run by unpriviledged users._ + +#### Request Format #### +An example of the request format: + + + +*WebSocket - list all* + +``` +{ + "id": "list_all_features", + "command": "feature" +} +``` + +*WebSocket - reject* + +``` +{ + "id": "reject_multi_sign", + "command": "feature", + "feature": "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373", + "vetoed": true +} +``` + +*JSON-RPC* + +``` +{ + "method": "feature", + "params": [ + { + "feature": "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373", + "vetoed": false + } + ] +} +``` + +*Commandline* + +``` +#Syntax: feature [ [accept|reject]] +rippled feature 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 accept +``` + + + +The request includes the following parameters: + +| Field | Type | Description | +|---------|------|-------------| +| feature | String | (Optional) The unique ID of an amendment, as hexadecimal; or the short name of the amendment. If provided, limits the response to one amendment. Otherwise, the response lists all amendments. | +| vetoed | Boolean | (Optional; ignored unless `feature` also specified) If true, instructs the server to vote against the amendment specified by `feature`. If false, instructs the server to vote in favor of the amendment. | + +**Note:** You can configure your server to vote in favor of a new amendment, even if the server does not currently know how to apply that amendment, by specifying the amendment ID in the `feature` field. For example, you might want to do this if you plan to upgrade soon to a new `rippled` version that _does_ support the amendment. + +#### Response Format #### + +An example of a successful response: + + + +*WebSocket - list all* + +``` +{ + "id": "list_all_features", + "status": "success", + "type": "response", + "result": { + "features": { + "42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE": { + "enabled": false, + "name": "FeeEscalation", + "supported": true, + "vetoed": false + }, + "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373": { + "enabled": false, + "name": "MultiSign", + "supported": true, + "vetoed": false + }, + "6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC": { + "enabled": false, + "name": "TrustSetAuth", + "supported": true, + "vetoed": false + }, + "C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490": { + "enabled": false, + "name": "Tickets", + "supported": true, + "vetoed": false + }, + "DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13": { + "enabled": false, + "name": "SusPay", + "supported": true, + "vetoed": false + } + } + } +} +``` + +*WebSocket - reject* + +``` +{ + "id": "reject_multi_sign", + "status": "success", + "type": "response", + "result": { + "features": { + "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373": { + "enabled": false, + "name": "MultiSign", + "supported": true, + "vetoed": true + } + } + } +} +``` + +*JSON-RPC* + +``` +200 OK +{ + "result": { + "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373": { + "enabled": false, + "name": "MultiSign", + "supported": true, + "vetoed": false + }, + "status": "success" + } +} +``` + +*Commandline* + +``` +Loading: "/etc/rippled.cfg" +Connecting to 127.0.0.1:5005 +{ + "result": { + "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373": { + "enabled": false, + "name": "MultiSign", + "supported": true, + "vetoed": false + }, + "status": "success" + } +} +``` + + + +The response follows the [standard format](#response-formatting), with a successful result containing **a map of amendments** as a JSON object. The keys of the object are amendment IDs. The values for each key are _amendment objects_ that describe the status of the amendment with that ID. If the request specified a `feature`, the map contains only the requested amendment object, after applying any changes from the request. Each amendment object has the following fields: + +| Field | Type | Description | +|-----------|---------|-------------| +| enabled | Boolean | Whether this amendment is currently enabled in the latest ledger. | +| name | String | (May be omitted) The human-readable name for this amendment, if known. | +| supported | Boolean | Whether this server knows how to apply this amendment. | +| vetoed | Boolean | Whether the server has been instructed to vote against this amendment. | + +**Caution:** The `name` for an amendment does not strictly indicate what that amendment does. The name is not guaranteed to be unique or consistent across servers. + +#### Possible Errors #### + +* Any of the [universal error types](#universal-errors). +* `badFeature` - The `feature` specified was invalidly formatted, or the server does not know an amendment with that name. + + + ## get_counts ## [[Source]
                    ](https://github.com/ripple/rippled/blob/c7118a183a660648aa88a3546a6b2c5bce858440/src/ripple/rpc/handlers/GetCounts.cpp "Source") diff --git a/reference-rippled.html b/reference-rippled.html index 28be290d6c..eab1c1b1a7 100644 --- a/reference-rippled.html +++ b/reference-rippled.html @@ -756,7 +756,9 @@ Null method
                  • server_info - Retrieve status of the server in human-readable format
                  • server_state - Retrieve status of the server in machine-readable format
                  • sign - Cryptographically sign a transaction
                    • +
                  • sign_for - Contribute to a multi-signature
                  • submit - Send a transaction to the network
                    • +
                  • submit_multisigned - Send a multi-signed transaction to the network
                  • subscribe - Listen for updates about a particular subject
                  • transaction_entry - Retrieve info about a transaction from a particular ledger version
                  • tx - Retrieve info about a transaction from all the ledgers on hand
                    • @@ -769,6 +771,7 @@ Null method
                  • can_delete - Allow online deletion of ledgers up to a specific ledger
                  • connect - Force the rippled server to connect to a specific peer
                  • consensus_info - Get information about the state of consensus as it happens
                    • +
                  • feature - Get information about protocol amendments
                  • fetch_info - Get information about the server's sync with the network
                  • get_counts - Get statistics about the server's internals and memory usage
                  • ledger_accept - Close and advance the ledger in stand-alone mode
                    • @@ -7848,7 +7851,7 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r

                    WebSocket

                    {
-    "id": "submit_multisigned_example",
+    "id": "submit_multisigned_example"
     "command": "submit_multisigned",
     "tx_json": {
         "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
@@ -7857,25 +7860,25 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r
         "LimitAmount": {
             "currency": "USD",
             "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
-            "value": "0"
+            "value": "100"
         },
-        "Sequence": 4,
+        "Sequence": 2,
         "Signers": [{
             "Signer": {
                 "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
                 "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
-                "TxnSignature": "3045022100CC9C56DF51251CB04BB047E5F3B5EF01A0F4A8A549D7A20A7402BF54BA744064022061EF8EF1BCCBF144F480B32508B1D10FD4271831D5303F920DE41C64671CB5B7"
+                "TxnSignature": "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
             }
         }, {
             "Signer": {
-                "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
-                "SigningPubKey": "03398A4EDAE8EE009A5879113EAA5BA15C7BB0F612A87F4103E793AC919BD1E3C1",
-                "TxnSignature": "3045022100FEE8D8FA2D06CE49E9124567DCA265A21A9F5465F4A9279F075E4CE27E4430DE022042D5305777DA1A7801446780308897699412E4EDF0E1AEFDF3C8A0532BDE4D08"
+                "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+                "SigningPubKey": "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
+                "TxnSignature": "30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1"
             }
         }],
         "SigningPubKey": "",
         "TransactionType": "TrustSet",
-        "hash": "81A477E2A362D171BB16BE17B4120D9F809A327FA00242ABCA867283BEA2F4F8"
+        "hash": "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6"
     }
 }
                    @@ -7970,7 +7973,7 @@ rippled submit_multisigned '{ fail_hard Boolean -(Optional) If true, (TODO) whatever fail_hard actually does. +(Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers. @@ -7978,7 +7981,47 @@ rippled submit_multisigned '{

                    An example of a successful response:

                    WebSocket

                    -
                    //TODO: actual example here
+
                    {
+  "id": "submit_multisigned_example",
+  "status": "success",
+  "type": "response",
+  "result": {
+    "engine_result": "tesSUCCESS",
+    "engine_result_code": 0,
+    "engine_result_message": "The transaction was applied. Only final in a validated ledger.",
+    "tx_blob": "1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1E0107321028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B744630440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1F1",
+    "tx_json": {
+      "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
+      "Fee": "30000",
+      "Flags": 262144,
+      "LimitAmount": {
+        "currency": "USD",
+        "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+        "value": "100"
+      },
+      "Sequence": 2,
+      "Signers": [
+        {
+          "Signer": {
+            "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+            "SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
+            "TxnSignature": "30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
+          }
+        },
+        {
+          "Signer": {
+            "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+            "SigningPubKey": "028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
+            "TxnSignature": "30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1"
+          }
+        }
+      ],
+      "SigningPubKey": "",
+      "TransactionType": "TrustSet",
+      "hash": "BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6"
+    }
+  }
+}
 
                    
 
                    JSON-RPC
                    
 
                    200 OK
@@ -8061,17 +8104,11 @@ rippled submit_multisigned '{
 
 
 
                    Possible Errors
                    
-
                    TODO: confirm this list (copy-pasta from traditional submit)
                    
 
                      
 
                    • Any of the universal error types.
                      • 
-
                    • invalidTransaction - The transaction is malformed or otherwise invalid.
                      • 
 
                    • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
                      • 
-
                    • highFee - The fee_mult_max parameter was specified, but the server's current fee multiplier exceeds the specified one. (Sign-and-Submit mode only)
                      • 
-
                    • tooBusy - The transaction did not include paths, but the server is too busy to do pathfinding right now. Does not occur if you are connected as an admin. (Sign-and-Submit mode only)
                      • 
-
                    • noPath - The transaction did not include paths, and the server was unable to find a path by which this payment can occur. (Sign-and-Submit mode only)
                      • 
-
                    • internalTransaction - An internal error occurred when processing the transaction. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed.
                      • 
-
                    • internalSubmit - An internal error occurred when submitting the transaction. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed.
                      • 
-
                    • internalJson - An internal error occurred when serializing the transaction to JSON. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed.
                      • 
+
                    • srcActMalformed - The Account field from the tx_json was invalid or missing.
                      • 
+
                    • internal - An internal error occurred. This includes the case where a signature is not valid for the transaction JSON provided.
                      • 
 
                    
 
                    book_offers
                    
 
                    [Source]
                    
@@ -10338,11 +10375,201 @@ Connecting to 127.0.0.1:5005
 
+
                    feature
                    
+
                    [Source]
                    
+
                    The feature command returns information about amendments this server knows about, including whether they are enabled and whether the server is voting in favor of those amendments in the amendment process.
                    
+
                    You can use the feature command to temporarily configure the server to vote against or in favor of an amendment. This change does not persist if you restart the server. To make lasting changes in amendment voting, use the rippled.cfg file. See Configuring Amendment Voting for more information.
                    
+
                    The feature method is an admin command that cannot be run by unpriviledged users.
                    
+
                    Request Format
                    
+
                    An example of the request format:
                    
+
                    
+
                    WebSocket - list all
                    
+
                    {
+  "id": "list_all_features",
+  "command": "feature"
+}
+
                    
+
                    WebSocket - reject
                    
+
                    {
+  "id": "reject_multi_sign",
+  "command": "feature",
+  "feature": "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373",
+  "vetoed": true
+}
+
                    
+
                    JSON-RPC
                    
+
                    {
+    "method": "feature",
+    "params": [
+        {
+            "feature": "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373",
+            "vetoed": false
+        }
+    ]
+}
+
                    
+
                    Commandline
                    
+
                    #Syntax: feature [<feature_id> [accept|reject]]
+rippled feature 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 accept
+
                    
+
                    
+
                    The request includes the following parameters:
                    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                    FieldTypeDescription
                    featureString(Optional) The unique ID of an amendment, as hexadecimal; or the short name of the amendment. If provided, limits the response to one amendment. Otherwise, the response lists all amendments.
                    vetoedBoolean(Optional; ignored unless feature also specified) If true, instructs the server to vote against the amendment specified by feature. If false, instructs the server to vote in favor of the amendment.
                    
+
                    Note: You can configure your server to vote in favor of a new amendment, even if the server does not currently know how to apply that amendment, by specifying the amendment ID in the feature field. For example, you might want to do this if you plan to upgrade soon to a new rippled version that does support the amendment.
                    
+
                    Response Format
                    
+
                    An example of a successful response:
                    
+
                    
+
                    WebSocket - list all
                    
+
                    {
+  "id": "list_all_features",
+  "status": "success",
+  "type": "response",
+  "result": {
+    "features": {
+      "42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE": {
+        "enabled": false,
+        "name": "FeeEscalation",
+        "supported": true,
+        "vetoed": false
+      },
+      "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373": {
+        "enabled": false,
+        "name": "MultiSign",
+        "supported": true,
+        "vetoed": false
+      },
+      "6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC": {
+        "enabled": false,
+        "name": "TrustSetAuth",
+        "supported": true,
+        "vetoed": false
+      },
+      "C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490": {
+        "enabled": false,
+        "name": "Tickets",
+        "supported": true,
+        "vetoed": false
+      },
+      "DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13": {
+        "enabled": false,
+        "name": "SusPay",
+        "supported": true,
+        "vetoed": false
+      }
+    }
+  }
+}
+
                    
+
                    WebSocket - reject
                    
+
                    {
+    "id": "reject_multi_sign",
+    "status": "success",
+    "type": "response",
+    "result": {
+        "features": {
+            "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373": {
+                "enabled": false,
+                "name": "MultiSign",
+                "supported": true,
+                "vetoed": true
+            }
+        }
+    }
+}
+
                    
+
                    JSON-RPC
                    
+
                    200 OK
+{
+    "result": {
+        "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373": {
+            "enabled": false,
+            "name": "MultiSign",
+            "supported": true,
+            "vetoed": false
+        },
+        "status": "success"
+    }
+}
+
                    
+
                    Commandline
                    
+
                    Loading: "/etc/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+    "result": {
+        "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373": {
+            "enabled": false,
+            "name": "MultiSign",
+            "supported": true,
+            "vetoed": false
+        },
+        "status": "success"
+    }
+}
+
                    
+
                    
+
                    The response follows the standard format, with a successful result containing a map of amendments as a JSON object. The keys of the object are amendment IDs. The values for each key are amendment objects that describe the status of the amendment with that ID. If the request specified a feature, the map contains only the requested amendment object, after applying any changes from the request. Each amendment object has the following fields:
                    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                    FieldTypeDescription
                    enabledBooleanWhether this amendment is currently enabled in the latest ledger.
                    nameString(May be omitted) The human-readable name for this amendment, if known.
                    supportedBooleanWhether this server knows how to apply this amendment.
                    vetoedBooleanWhether the server has been instructed to vote against this amendment.
                    
+
                    Caution: The name for an amendment does not strictly indicate what that amendment does. The name is not guaranteed to be unique or consistent across servers.
                    
+
                    Possible Errors
                    
+
                      
+
                    • Any of the universal error types.
                      • 
+
                    • badFeature - The feature specified was invalidly formatted, or the server does not know an amendment with that name.
                      • 
+
                    
 
                    get_counts
                    
 
                    [Source]
                    
 
                    The get_counts command provides various stats about the health of the server, mostly the number of objects of different types that it currently holds in memory.
                    
 
                    The get_counts method is an admin command that cannot be run by unpriviledged users.
                    
-
                    Request Format
                    
+
                    Request Format
                    
 
                    An example of the request format:
                    
 
                    
 
                    WebSocket
                    
@@ -10384,7 +10611,7 @@ rippled get_counts 100
 
 
 
-
                    Response Format
                    
+
                    Response Format
                    
 
                    An example of a successful response:
                    
 
                    
 
                    JSON-RPC
                    
@@ -10487,7 +10714,7 @@ Connecting to 127.0.0.1:5005
 
 
 
                    For most other entries, the value indicates the number of objects of that type currently in memory.
                    
-
                    Possible Errors
                    
+
                    Possible Errors
                    
 
                      
 
                    • Any of the universal error types.
                      • 
 
                    • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
                      • 
@@ -10496,7 +10723,7 @@ Connecting to 127.0.0.1:5005
 
                      [Source]
                      
 
                      The ledger_cleaner command controls the Ledger Cleaner, an asynchronous maintenance process that can find and repair corruption in rippled's database of ledgers.
                      
 
                      The ledger_cleaner method is an admin command that cannot be run by unpriviledged users.
                      
-
                      Request Format
                      
+
                      Request Format
                      
 
                      An example of the request format:
                      
 
                      
 
                      WebSocket
                      
@@ -10555,7 +10782,7 @@ Connecting to 127.0.0.1:5005
 
 
 
-
                      Response Format
                      
+
                      Response Format
                      
 
                      An example of a successful response:
                      
 
                      
 
                      JSON-RPC
                      
@@ -10586,7 +10813,7 @@ Connecting to 127.0.0.1:5005
 
 
 
-
                      Possible Errors
                      
+
                      Possible Errors
                      
 
                        
 
                      • Any of the universal error types.
                        • 
 
                      • internal if one the parameters was specified in a way that the server couldn't interpret. (This is a bug, and it should return invalidParams instead.)
                        • 
@@ -10595,7 +10822,7 @@ Connecting to 127.0.0.1:5005
 
                        [Source]
                        
 
                        The log_level command changes the rippled server's logging verbosity, or returns the current logging level for each category (called a partition) of log messages.
                        
 
                        The log_level method is an admin command that cannot be run by unpriviledged users.
                        
-
                        Request Format
                        
+
                        Request Format
                        
 
                        An example of the request format:
                        
 
                        
 
                        WebSocket
                        
@@ -10633,7 +10860,7 @@ rippled log_level PathRequest debug
 
 
 
-
                        Response Format
                        
+
                        Response Format
                        
 
                        Examples of successful responses:
                        
 
                        
 
                        Commandline (set log level)
                        
@@ -10725,7 +10952,7 @@ Connecting to 127.0.0.1:5005
 
 
 
-
                        Possible Errors
                        
+
                        Possible Errors
                        
 
                          
 
                        • Any of the universal error types.
                          • 
 
                        • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
                          • 
@@ -10734,7 +10961,7 @@ Connecting to 127.0.0.1:5005
 
                          [Source]
                          
 
                          The logrotate command closes and reopens the log file. This is intended to facilitate log rotation on Linux file systems.
                          
 
                          The logrotate method is an admin command that cannot be run by unpriviledged users.
                          
-
                          Request Format
                          
+
                          Request Format
                          
 
                          An example of the request format:
                          
 
                          
 
                          WebSocket
                          
@@ -10748,7 +10975,7 @@ Connecting to 127.0.0.1:5005

                    The request includes no parameters.

                    -

                    Response Format

                    +

                    Response Format

                    An example of a successful response:

                    JSON-RPC

                    @@ -10790,7 +11017,7 @@ Connecting to 127.0.0.1:5005 -

                    Possible Errors

                    +

                    Possible Errors

                    @@ -10798,7 +11025,7 @@ Connecting to 127.0.0.1:5005

                    [Source]

                    Use the validation_create command to generate the keys for a rippled validating node. Similar to the wallet_propose command, this command makes no real changes, but only generates a set of keys in the proper format.

                    The validation_create method is an admin command that cannot be run by unpriviledged users.

                    -

                    Request Format

                    +

                    Request Format

                    An example of the request format:

                    WebSocket

                    @@ -10841,7 +11068,7 @@ rippled validation_create "BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIR

                    Note: The security of your validator depends on the entropy of your seed. Do not use a secret value that is not sufficiently randomized for real business purposes. We recommend omitting the secret when generating new credentials for the first time.

                    -

                    Response Format

                    +

                    Response Format

                    An example of a successful response:

                    JSON-RPC

                    @@ -10894,7 +11121,7 @@ Connecting to 127.0.0.1:5005 -

                    Possible Errors

                    +

                    Possible Errors

                    • Any of the universal error types.
                    • badSeed - The request provided an invalid seed value. This usually means that the seed value appears to be a valid string of a different format, such as an account address or validation public key.
                      • @@ -10903,7 +11130,7 @@ Connecting to 127.0.0.1:5005

                      [Source]

                      The validation_seed command temporarily sets the secret value that rippled uses to sign validations. This value resets based on the config file when you restart the server.

                      The validation_seed request is an admin command that cannot be run by unpriviledged users!

                      -

                      Request Format

                      +

                      Request Format

                      An example of the request format:

                      WebSocket

                      @@ -10935,7 +11162,7 @@ rippled validation_seed 'BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIRE' -

                      Response Format

                      +

                      Response Format

                      An example of a successful response:

                      JSON-RPC

                      @@ -10989,7 +11216,7 @@ Connecting to 127.0.0.1:5005 -

                      Possible Errors

                      +

                      Possible Errors

                      • Any of the universal error types.
                      • badSeed - The request provided an invalid secret value. This usually means that the secret value appears to be a valid string of a different format, such as an account address or validation public key.
                        • @@ -10998,7 +11225,7 @@ Connecting to 127.0.0.1:5005

                        [Source]

                        The peers command returns a list of all other rippled servers currently connected to this one, including information on their connection and sync status.

                        The peers request is an admin command that cannot be run by unpriviledged users!

                        -

                        Request Format

                        +

                        Request Format

                        An example of the request format:

                        WebSocket

                        @@ -11012,7 +11239,7 @@ Connecting to 127.0.0.1:5005

                        The request includes no additional parameters.

                        -

                        Response Format

                        +

                        Response Format

                        An example of a successful response:

                        WebSocket

                        @@ -11472,7 +11699,7 @@ Connecting to 127.0.0.1:5005 -

                        Possible Errors

                        +

                        Possible Errors

                        @@ -11480,7 +11707,7 @@ Connecting to 127.0.0.1:5005

                        [Source]

                        The print command returns the current status of various internal subsystems, including peers, the ledger cleaner, and the resource manager.

                        The print request is an admin command that cannot be run by unpriviledged users!

                        -

                        Request Format

                        +

                        Request Format

                        An example of the request format:

                        WebSocket

                        @@ -11494,7 +11721,7 @@ Connecting to 127.0.0.1:5005

                        The request includes no parameters.

                        -

                        Response Format

                        +

                        Response Format

                        An example of a successful response:

                        Commandline

                        @@ -11683,7 +11910,7 @@ Connecting to 127.0.0.1:5005

                        The response follows the standard format. Additional fields in the result depend on the internal state of the rippled server. The results of this command are subject to change without notice.

                        -

                        Possible Errors

                        +

                        Possible Errors

                        @@ -11692,7 +11919,7 @@ Connecting to 127.0.0.1:5005

                        ping

                        [Source]

                        The ping command returns an acknowledgement, so that clients can test the connection status and latency.

                        -

                        Request Format

                        +

                        Request Format

                        An example of the request format:

                        WebSocket

                        @@ -11716,7 +11943,7 @@ rippled ping

                        Try it! >

                        The request includes no parameters.

                        -

                        Response Format

                        +

                        Response Format

                        An example of a successful response:

                        WebSocket

                        @@ -11737,14 +11964,14 @@ rippled ping

                        The response follows the standard format, with a successful result containing no fields. The client can measure the round-trip time from request to response as latency.

                        -

                        Possible Errors

                        +

                        Possible Errors

                        random

                        [Source]

                        The random command provides a random number to be used as a source of entropy for random number generation by clients.

                        -

                        Request Format

                        +

                        Request Format

                        An example of the request format:

                        WebSocket

                        @@ -11767,7 +11994,7 @@ rippled random

                        The request includes no parameters.

                        -

                        Response Format

                        +

                        Response Format

                        An example of a successful response:

                        WebSocket

                        @@ -11807,14 +12034,14 @@ rippled random -

                        Possible Errors

                        +

                        Possible Errors

                        • Any of the universal error types.
                        • internal - Some internal error occurred, possibly relating to the random number generator.

                        json

                        The json method is a proxy to running other commands, and accepts the parameters for the command as a JSON value. It is exclusive to the Commandline client, and intended for cases where the commandline syntax for specifying parameters is inadequate or undesirable.

                        -

                        Request Format

                        +

                        Request Format

                        An example of the request format:

                        Commandline

                        @@ -11822,7 +12049,7 @@ rippled random rippled -q json ledger_closed '{}'
                        -

                        Response Format

                        +

                        Response Format

                        An example of a successful response:

                        WebSocket

                        @@ -11840,7 +12067,7 @@ rippled -q json ledger_closed '{}'

                        [Source]

                        The connect command forces the rippled server to connect to a specific peer rippled server.

                        The connect request is an admin command that cannot be run by unpriviledged users!

                        -

                        Request Format

                        +

                        Request Format

                        An example of the request format:

                        WebSocket

                        @@ -11888,7 +12115,7 @@ rippled connect 192.170.145.88 51235 -

                        Response Format

                        +

                        Response Format

                        An example of a successful response:

                        JSON-RPC

                        @@ -11928,7 +12155,7 @@ Connecting to 127.0.0.1:5005 -

                        Possible Errors

                        +

                        Possible Errors

                        • Any of the universal error types.
                        • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
                          • @@ -11938,7 +12165,7 @@ Connecting to 127.0.0.1:5005

                          [Source]

                          Gracefully shuts down the server.

                          The stop request is an admin command that cannot be run by unpriviledged users!

                          -

                          Request Format

                          +

                          Request Format

                          An example of the request format:

                          WebSocket

                          @@ -11960,7 +12187,7 @@ Connecting to 127.0.0.1:5005

                          The request includes no parameters.

                          -

                          Response Format

                          +

                          Response Format

                          An example of a successful response:

                          JSON-RPC

                          @@ -11999,7 +12226,7 @@ Connecting to 127.0.0.1:5005 -

                          Possible Errors

                          +

                          Possible Errors

                          From d1281f8c3b982836f09e314eda1ed63270f01147 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 4 Apr 2016 09:04:35 -0700 Subject: [PATCH 24/40] stand-alone-mode: slight edits --- concept-stand-alone-mode.html | 32 ++++++++++++++++----------- content/concept-stand-alone-mode.md | 34 +++++++++++++++++------------ 2 files changed, 39 insertions(+), 27 deletions(-) diff --git a/concept-stand-alone-mode.html b/concept-stand-alone-mode.html index 59b79a7637..deef460c17 100644 --- a/concept-stand-alone-mode.html +++ b/concept-stand-alone-mode.html @@ -146,32 +146,38 @@ 
                        rippled -a --start --conf=/path/to/rippled.cfg
                        -

                        In a genesis ledger, the genesis account holds all 100 billion XRP. The keys of the genesis account are hardcoded as follows:

                        +

                        In a genesis ledger, the genesis address holds all 100 billion XRP. The keys of the genesis address are hardcoded as follows:

                        Address: rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh

                        Secret: snoPBrXtMeMyMHUVTgbuqAfg1SUTb ("masterpassphrase")

                        -

                        Caution: If you create a new genesis ledger, the hard-coded default Reserve is 200 XRP minimum for an account, with an increment of 50 XRP per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: Fee Voting)

                        +

                        Caution: If you create a new genesis ledger, the hard-coded default Reserve is 200 XRP minimum for funding a new address, with an increment of 50 XRP per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: Fee Voting)

                        Load Saved Ledger

                        You can start with a ledger version that was saved to disk if your rippled server was previously synced with the Ripple peer-to-peer network (either the production network or the Test Net).

                        -

                        1. To retrieve existing ledgers, start rippled normally:

                        +

                        1. Start rippled normally.

                        +

                        To load an existing ledger, you must first retrieve that ledger from the network. Start rippled in networked mode as normal:

                        rippled --conf=/path/to/rippled.cfg
                        -

                        2. Wait until rippled is synced:

                        -

                        When rippled is synced with the state of the network, the response from the server_info command shows a server_state value that is full, proposing, or validating.

                        -

                        3. (Optional) Retrieve specific ledger versions:

                        +

                        2. Wait until rippled is synced.

                        +

                        Use the server_info command to check the state of your server relative to the network. Your server is synced when the server_state value shows any of the following values:

                        +
                          +
                        • full
                          • +
                        • proposing
                          • +
                        • validating.
                          • +
                        +

                        3. (Optional) Retrieve specific ledger versions.

                        If you only want the most recent ledger, you can skip this step.

                        If you want to load a specific historical ledger version, use the ledger_request command to make rippled fetch it. If rippled does not already have the ledger version, you may have to run the ledger_request command multiple times until it has finished retrieving the ledger.

                        If you want to replay a specific historical ledger version, you must fetch both the ledger version to replay and the ledger version immediately before it.

                        -

                        4. Shut down rippled:

                        +

                        4. Shut down rippled.

                        +

                        Use the stop command:

                        rippled stop --conf=/path/to/rippled.cfg
                        -

                        5. Start rippled in stand-alone mode, loading the saved ledger.

                        -

                        To load the most recent ledger version, you can use the -a and --load options:

                        +

                        5. Start rippled in stand-alone mode.

                        +

                        To load the most recent ledger version, you can use the -a and --load options when starting the server:

                        rippled -a --load --conf=/path/to/rippled.cfg
                        -

                        To instead load a specific historical ledger, use the --ledger parameter with the ledger index or identifying hash of the ledger version to load:

                        -
                        rippled -a --ledger 19860944 --conf=/path/to/rippled.cfg
+
                        To instead load a specific historical ledger, use the --load parameter along with the --ledger parameter, providing the ledger index or identifying hash of the ledger version to load:
                        
+
                        rippled -a --load --ledger 19860944 --conf=/path/to/rippled.cfg
 
                        
-
                        (TODO: test this)
                        
 
                        6. Manually advance the ledger.
                        
 
                        When you load a ledger with --ledger in stand-alone mode, it goes to the current open ledger, so you must manually advance the ledger:
                        
 
                        rippled ledger_accept --conf=/path/to/rippled.cfg
@@ -181,7 +187,7 @@
 
                        rippled ledger_accept --conf=/path/to/rippled.cfg
 
                        
 
                        In stand-alone mode, rippled makes no distinction between a "closed" ledger version and a "validated" ledger version. (For more information about the difference, see The Ripple Ledger Consensus Process.)
                        
-
                        Whenever rippled closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since different rippled servers may see transactions in a different order.) When using rippled in stand-alone mode, you should manually advance the ledger before submitting a transaction that depends on the result of a previous transaction. Otherwise, the second transaction might be executed before the first transaction when you manually advance the ledger. Note: You can safely submit multiple transactions from a single account to a single ledger, because rippled sorts transactions from the same account in ascending order by Sequence number.
                        
+
                        Whenever rippled closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since transactions may arrive at different parts of the network in different order.) When using rippled in stand-alone mode, you should manually advance the ledger before submitting a transaction that depends on the result of a previous transaction. Otherwise, the second transaction might be executed before the first transaction when you manually advance the ledger. Note: You can safely submit multiple transactions from a single address to a single ledger, because rippled sorts transactions from the same address in ascending order by Sequence number.
                        diff --git a/content/concept-stand-alone-mode.md b/content/concept-stand-alone-mode.md index 322ae60602..d652c297d9 100644 --- a/content/concept-stand-alone-mode.md +++ b/content/concept-stand-alone-mode.md @@ -20,13 +20,13 @@ 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 account](reference-rippled.html#special-addresses) holds all 100 billion XRP. The keys of the genesis account 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](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: **Address:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` **Secret:** `snoPBrXtMeMyMHUVTgbuqAfg1SUTb` ("masterpassphrase") -**Caution:** If you create a new genesis ledger, the hard-coded default [Reserve](concept-reserves.html) is **200 XRP** minimum for an account, with an increment of **50 XRP** per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: [Fee Voting](concept-fee-voting.html)) +**Caution:** If you create a new genesis ledger, the hard-coded default [Reserve](concept-reserves.html) is **200 XRP** minimum for funding a new address, with an increment of **50 XRP** per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: [Fee Voting](concept-fee-voting.html)) @@ -34,17 +34,23 @@ Load Saved Ledger ------------------------------------------------------------------------------- You can start with a ledger version that was saved to disk if your `rippled` server was previously synced with the Ripple peer-to-peer network (either the production network or the [Test Net](tutorial-rippled-setup.html#parallel-networks)). -### 1. To retrieve existing ledgers, start `rippled` normally: ### +### 1. Start `rippled` normally. ### + +To load an existing ledger, you must first retrieve that ledger from the network. Start `rippled` in networked mode as normal: ``` rippled --conf=/path/to/rippled.cfg ``` -### 2. Wait until `rippled` is synced: ### +### 2. Wait until `rippled` is synced. ### -When `rippled` is synced with the state of the network, the response from the [`server_info` command](reference-rippled.html#server-info) shows a `server_state` value that is `full`, `proposing`, or `validating`. +Use the [`server_info` command](reference-rippled.html#server-info) to check the state of your server relative to the network. Your server is synced when the `server_state` value shows any of the following values: -### 3. (Optional) Retrieve specific ledger versions: ### +* `full` +* `proposing` +* `validating`. + +### 3. (Optional) Retrieve specific ledger versions. ### If you only want the most recent ledger, you can skip this step. @@ -52,28 +58,28 @@ If you want to load a specific historical ledger version, use the [`ledger_reque If you want to replay a specific historical ledger version, you must fetch both the ledger version to replay and the ledger version immediately before it. -### 4. Shut down `rippled`: ### +### 4. Shut down `rippled`. ### + +Use the [`stop` command](reference-rippled.html#stop): ``` rippled stop --conf=/path/to/rippled.cfg ``` -### 5. Start `rippled` in stand-alone mode, loading the saved ledger. +### 5. Start `rippled` in stand-alone mode. ### -To load the most recent ledger version, you can use the `-a` and `--load` options: +To load the most recent ledger version, you can use the `-a` and `--load` options when starting the server: ``` rippled -a --load --conf=/path/to/rippled.cfg ``` -To instead load a specific historical ledger, use the ``--ledger`` parameter with the ledger index or identifying hash of the ledger version to load: +To instead load a specific historical ledger, use the `--load` parameter along with the `--ledger` parameter, providing the ledger index or identifying hash of the ledger version to load: ``` -rippled -a --ledger 19860944 --conf=/path/to/rippled.cfg +rippled -a --load --ledger 19860944 --conf=/path/to/rippled.cfg ``` -(TODO: test this) - ### 6. Manually advance the ledger. ### When you load a ledger with `--ledger` in stand-alone mode, it goes to the current open ledger, so you must [manually advance the ledger](#advancing-ledgers-in-stand-alone-mode): @@ -94,4 +100,4 @@ rippled ledger_accept --conf=/path/to/rippled.cfg In stand-alone mode, `rippled` makes no distinction between a "closed" ledger version and a "validated" ledger version. (For more information about the difference, see [The Ripple Ledger Consensus Process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/).) -Whenever `rippled` closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since different `rippled` servers may see transactions in a different order.) When using `rippled` in stand-alone mode, you should manually advance the ledger before submitting a transaction that depends on the result of a previous transaction. Otherwise, the second transaction might be executed before the first transaction when you manually advance the ledger. **Note:** You can safely submit multiple transactions from a single account to a single ledger, because `rippled` sorts transactions from the same account in ascending order by `Sequence` number. +Whenever `rippled` closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since transactions may arrive at different parts of the network in different order.) When using `rippled` in stand-alone mode, you should manually advance the ledger before submitting a transaction that depends on the result of a previous transaction. Otherwise, the second transaction might be executed before the first transaction when you manually advance the ledger. **Note:** You can safely submit multiple transactions from a single address to a single ledger, because `rippled` sorts transactions from the same address in ascending order by `Sequence` number. From 1f3eeeb5a060d4eafc6f31af11596a4872484887 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 4 Apr 2016 09:41:28 -0700 Subject: [PATCH 25/40] tx format multisign - edits from reviews --- content/reference-transaction-format.md | 20 +++++++++++--------- reference-transaction-format.html | 19 ++++++++++--------- 2 files changed, 21 insertions(+), 18 deletions(-) diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md index bf8f9d7ee8..e4644abe3e 100644 --- a/content/reference-transaction-format.md +++ b/content/reference-transaction-format.md @@ -46,13 +46,15 @@ Any signature type can authorize any type of transaction, with the following exc Sending a transaction to the Ripple Consensus Ledger involves several steps: -1. Create an unsigned transaction in JSON format. +1. Create an [unsigned transaction in JSON format](#unsigned-transaction-format). 2. Use one or more signatures to [authorize the transaction](#authorizing-transactions). 3. Submit a transaction to a `rippled` server. If the transaction is properly formed, the server provisionally applies the transaction to its current version of the ledger and relays the transaction to other members of the peer-to-peer network. 4. The [consensus process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/) determines which provisional transactions get included in the next validated ledger. 5. The `rippled` servers apply those transactions to the previous ledger in a canonical order and share their results. 6. If enough [trusted validators](tutorial-rippled-setup.html#reasons-to-run-a-validator) created the exact same ledger, that ledger is declared _validated_ and the [results of the transactions](#transaction-results) in that ledger are immutable. +### Unsigned Transaction Format ### + Here is an example of an unsigned [Payment-type transaction](#payment) in JSON: ``` @@ -71,7 +73,7 @@ Here is an example of an unsigned [Payment-type transaction](#payment) in JSON: } ``` -After doing that, you generate the signed binary format for the transaction. For transactions authorized by only a single signature, you have two options: +The Ripple Consensus Ledger only relays and executes a transaction if the transaction object has been authorized by the sending address (in the `Account`) field. For transactions authorized by only a single signature, you have two options: 1. Convert it to a binary blob and sign it offline. This is preferable, since it means that the account secret used for signing the transaction is never transmitted over any network connection. * You can use [RippleAPI](reference-rippleapi.html#sign) to perform offline signing. @@ -181,9 +183,9 @@ After a transaction has been submitted, if it gets accepted into a validated led ### Multi-Signing ### -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. +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 have any combination of authorization methods enabled for your address, including multi-signing, a master key, and a [regular key](#setregularkey). (The only requirement is that _at least one_ method must be enabled.) -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. +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 control how many signatures are needed, in which combinations, by using the quorum and weight values of the SignerList. For more information, see [How to Multi-Sign](tutorial-multisign.html). @@ -326,7 +328,7 @@ The `Signers` field contains a [multi-signature](#multi-signing), which has sign 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. -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-siganture increases the `Fee` required by the amount of the minimum transaction fee. For example, if the current minimum `Fee` value to relay a transaction to the network is `10000` drops, then a multi-signed transaction with 3 entries in the `Signers` array would cost `40000` drops to relay. +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. @@ -576,7 +578,7 @@ In addition to the master key, which is mathematically-related to an address, yo A regular key pair is generated in the same way as any other Ripple keys (for example, with [wallet_propose](reference-rippled.html#wallet-propose)), but it can be changed. A master key pair is an intrinsic part of an address's identity (the address is derived from the master public key). You can [disable](#accountset-flags) a master key but you cannot change it. -You can protect your master secret by using a regular key instead of the master key to sign transactions where possible. If your regular key is compromised, but the master key is not, you can use a SetRegularKey transaction to regain control of your address. In some cases, you can even send a [key reset transaction](concept-transaction-cost.html#key-reset-transaction) without paying the [transaction cost](#transaction-cost). +You can protect your master secret by using a regular key instead of the master key to sign transactions whenever possible. If your regular key is compromised, but the master key is not, you can use a SetRegularKey transaction to regain control of your address. In some cases, you can even send a [key reset transaction](concept-transaction-cost.html#key-reset-transaction) without paying the [transaction cost](#transaction-cost). For even greater security, you can use [multi-signing](#multi-signing), but multi-signing requires additional XRP for the [transaction cost](concept-transaction-cost.html) and [reserve](concept-reserves.html). @@ -822,7 +824,7 @@ Example SignerListSet: | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description | |-------|-----------|--------------------------------------------------------|-------------| -| SignerQuorum | Number | UInt32 | A target number for the signer weights. A multi-signature from this list is valid only if the sum weights of the signatures provided is equal or greater than this value. To delete a SignerList, use the value `0`. | +| SignerQuorum | Number | UInt32 | A target number for the signer weights. A multi-signature from this list is valid only if the sum weights of the signatures provided is greater than or equal to this value. To delete a SignerList, use the value `0`. | | SignerEntries | Array | Array | (Omitted when deleting) Array of [SignerEntry objects](reference-ledger-format.html#signerentry-object), indicating the addresses and weights of signers in this list. A SignerList must have at least 1 member and no more than 8 members. No address may appear more than once in the list, nor may the `Account` submitting the transaction appear in the list. | 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 `SignerQuorum` to `0` _and_ omit the `SignerEntries` field. Otherwise, the transaction fails with the error [temMALFORMED](#tem-codes). A transaction to delete a SignerList is considered successful even if there was no SignerList to delete. @@ -1070,7 +1072,7 @@ These codes indicate that the transaction was malformed, and cannot succeed acco | temREDUNDANT\_SEND\_MAX | _(Removed in [rippled 0.28.0][])_ | | temRIPPLE\_EMPTY | The [Payment](#payment) transaction includes an empty `Paths` field, but paths are necessary to complete this payment. | | temBAD_WEIGHT | The [SignerListSet](#signerlistset) transaction includes a `SignerWeight` that is invalid, for example a zero or negative value. | -| temBAD_SIGNER | The [SignerListSet](#signerlistset) transaction includes a signer who is invalid: for example, it might be a duplicate, or it might be the account to which the SignerList belongs. | +| temBAD_SIGNER | The [SignerListSet](#signerlistset) transaction includes a signer who is invalid. For example, there may be duplicate entries, or the owner of the SignerList may also be a member. | | temBAD_QUORUM | The [SignerListSet](#signerlistset) transaction has an invalid `SignerQuorum` value. Either the value is not greater than zero, or it is more than the sum of all signers in the list. | | temUNCERTAIN | Used internally only. This code should never be returned. | | temUNKNOWN | Used internally only. This code should never be returned. | @@ -1147,7 +1149,7 @@ These codes indicate that the transaction failed, but it was applied to a ledger | tecNO\_LINE\_REDUNDANT | 127 | The transaction failed because it attempted to set a trust line to its default state, but the trust line did not exist. | | tecPATH\_DRY | 128 | The transaction failed because the provided paths did not have enough liquidity to send anything at all. This could mean that the source and destination accounts are not linked by trust lines. | | tecUNFUNDED | 129 | **DEPRECATED.** Replaced by tecUNFUNDED\_OFFER and tecUNFUNDED\_PAYMENT. | -| 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` instead.) | +| 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`.) | | tecNO\_REGULAR\_KEY | 131 | The [AccountSet transaction](#accountset) tried to disable the master key, but the account does not have another way to [authorize transactions](#authorizing-transactions). If [multi-signing](#multi-signing) is enabled, this code is deprecated and `tecNO_ALTERNATIVE_KEY` is used instead. | | tecOWNERS | 132 | The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the [`lsfRequireAuth`](#accountset-flags) flag if it has any trust lines or available offers. | | tecNO\_ISSUER | 133 | The account specified in the `issuer` field of a currency amount does not exist. | diff --git a/reference-transaction-format.html b/reference-transaction-format.html index e760c736aa..39ce97ec44 100644 --- a/reference-transaction-format.html +++ b/reference-transaction-format.html @@ -171,13 +171,14 @@

                        Signing and Submitting Transactions

                        Sending a transaction to the Ripple Consensus Ledger involves several steps:

                          -
                        1. Create an unsigned transaction in JSON format.
                          2. +
                        2. Create an unsigned transaction in JSON format.
                        3. Use one or more signatures to authorize the transaction.
                        4. Submit a transaction to a rippled server. If the transaction is properly formed, the server provisionally applies the transaction to its current version of the ledger and relays the transaction to other members of the peer-to-peer network.
                        5. The consensus process determines which provisional transactions get included in the next validated ledger.
                        6. The rippled servers apply those transactions to the previous ledger in a canonical order and share their results.
                        7. If enough trusted validators created the exact same ledger, that ledger is declared validated and the results of the transactions in that ledger are immutable.
                        +

                        Unsigned Transaction Format

                        Here is an example of an unsigned Payment-type transaction in JSON:

                        {
   "TransactionType" : "Payment",
@@ -193,7 +194,7 @@
   "Sequence": 2,
 }
                        -

                        After doing that, you generate the signed binary format for the transaction. For transactions authorized by only a single signature, you have two options:

                        +

                        The Ripple Consensus Ledger only relays and executes a transaction if the transaction object has been authorized by the sending address (in the Account) field. For transactions authorized by only a single signature, you have two options:

                        1. Convert it to a binary blob and sign it offline. This is preferable, since it means that the account secret used for signing the transaction is never transmitted over any network connection.
                          • You can use RippleAPI to perform offline signing.
                            • @@ -299,8 +300,8 @@ }

                            Multi-Signing

                            -

                            Multi-signing in Ripple is the act of 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 to the Ripple Consensus Protocol. You can use multi-signing in addition to, or instead of, a master key, a regular key, or both.

                            -

                            The SignerListSet transaction 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.

                            +

                            Multi-signing in Ripple is the act of 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 to the Ripple Consensus Protocol. You can have any combination of authorization methods enabled for your address, including multi-signing, a master key, and a regular key. (The only requirement is that at least one method must be enabled.)

                            +

                            The SignerListSet transaction defines which addresses can authorize transactions from your address. You can include up to 8 addresses in a SignerList. You can control how many signatures are needed, in which combinations, by using the quorum and weight values of the SignerList.

                            For more information, see How to Multi-Sign.

                            Reliable Transaction Submission

                            Reliably submitting transactions is the process of achieving both of the following:

                            @@ -515,7 +516,7 @@

                            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 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-siganture increases the Fee required by the amount of the minimum transaction fee. For example, if the current minimum Fee value to relay a transaction to the network is 10000 drops, then a multi-signed transaction with 3 entries in the Signers array would cost 40000 drops to relay.

                            +

                            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 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.

                            Flags

                            The Flags 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.

                            Most flags only have meaning for a specific transaction type. The same bitwise value may be reused for flags on different transaction types, so it is important to pay attention to the TransactionType field when setting and reading flags.

                            @@ -916,7 +917,7 @@

                            In addition to the master key, which is mathematically-related to an address, you can associate at most 1 additional key pair with an address using this type of transaction. The additional key pair is called a regular key. If your address has a regular key pair defined, you can use the secret key of the regular key pair to authorize transactions.

                            A regular key pair is generated in the same way as any other Ripple keys (for example, with wallet_propose), but it can be changed. A master key pair is an intrinsic part of an address's identity (the address is derived from the master public key). You can disable a master key but you cannot change it.

                            -

                            You can protect your master secret by using a regular key instead of the master key to sign transactions where possible. If your regular key is compromised, but the master key is not, you can use a SetRegularKey transaction to regain control of your address. In some cases, you can even send a key reset transaction without paying the transaction cost.

                            +

                            You can protect your master secret by using a regular key instead of the master key to sign transactions whenever possible. If your regular key is compromised, but the master key is not, you can use a SetRegularKey transaction to regain control of your address. In some cases, you can even send a key reset transaction without paying the transaction cost.

                            For even greater security, you can use multi-signing, but multi-signing requires additional XRP for the transaction cost and reserve.

                            OfferCreate

                            [Source]

                            @@ -1251,7 +1252,7 @@ SignerQuorum Number UInt32 -A target number for the signer weights. A multi-signature from this list is valid only if the sum weights of the signatures provided is equal or greater than this value. To delete a SignerList, use the value 0. +A target number for the signer weights. A multi-signature from this list is valid only if the sum weights of the signatures provided is greater than or equal to this value. To delete a SignerList, use the value 0. SignerEntries @@ -1783,7 +1784,7 @@ temBAD_SIGNER -The SignerListSet transaction includes a signer who is invalid: for example, it might be a duplicate, or it might be the account to which the SignerList belongs. +The SignerListSet transaction includes a signer who is invalid. For example, there may be duplicate entries, or the owner of the SignerList may also be a member. temBAD_QUORUM @@ -2040,7 +2041,7 @@ tecNO_ALTERNATIVE_KEY 130 -The transaction tried to remove the only available method of authorizing transactions. This could be a SetRegularKey transaction to remove the regular key, a SignerListSet transaction to delete a SignerList, or an AccountSet transaction to disable the master key. (Prior to rippled 0.30.0, this was called tecMASTER_DISABLED instead.) +The transaction tried to remove the only available method of authorizing transactions. This could be a SetRegularKey transaction to remove the regular key, a SignerListSet transaction to delete a SignerList, or an AccountSet transaction to disable the master key. (Prior to rippled 0.30.0, this was called tecMASTER_DISABLED.) tecNO_REGULAR_KEY From 2045bc55f555b20a59c46cee4e565f68ef9bff7e Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 4 Apr 2016 10:20:29 -0700 Subject: [PATCH 26/40] multisign ledger, tx formats - edits from review --- content/reference-ledger-format.md | 45 +++++++++++++++++------------- content/tutorial-multisign.md | 4 ++- reference-ledger-format.html | 42 +++++++++++++++++----------- tutorial-multisign.html | 3 +- 4 files changed, 55 insertions(+), 39 deletions(-) diff --git a/content/reference-ledger-format.md b/content/reference-ledger-format.md index 2ad775e176..2fb0d0a4df 100644 --- a/content/reference-ledger-format.md +++ b/content/reference-ledger-format.md @@ -4,20 +4,20 @@ The point of the Ripple software is to maintain a shared, global ledger that is ![Diagram: Each ledger is the result of applying transactions to the previous ledger version.](img/ledger-process.png) -The shared global ledger is actually a series of individual ledgers, or ledger versions, which `rippled` keeps in its internal database. Every ledger version has a sequence number (also called a ledger index), starting at 1 and incrementing with each new version. Every closed ledger also has an identifying hash value, which uniquely identifies the contents of that ledger. At any given time, a `rippled` instance has an in-progress "current" open ledger, plus some number of closed ledgers that have not yet been approved by consensus, and any number of historical ledgers that have been validated by consensus. Only the validated ledgers are certain to be accurate and immutable. +The shared global ledger is actually a series of individual ledgers, or ledger versions, which `rippled` keeps in its internal database. Every ledger version has a [ledger index](#ledger-index) which identifies the order in which ledgers occur. Each closed ledger version also has an identifying hash value, which uniquely identifies the contents of that ledger. At any given time, a `rippled` instance has an in-progress "current" open ledger, plus some number of closed ledgers that have not yet been approved by consensus, and any number of historical ledgers that have been validated by consensus. Only the validated ledgers are certain to be accurate and immutable. A single ledger version consists of several components: ![Diagram: A ledger has transactions, a state node, and a header with the close time and validation info](img/ledger-components.png) -* A **header** - The ledger's unique index (sequence number), hashes of the other contents, and other metadata. +* A **header** - The [ledger index](#ledger-index), hashes of its other contents, and other metadata. * A **transaction tree** - The [transactions](reference-transaction-format.html) that were applied to the previous ledger to make this one. Transactions are the _only_ way to modify the ledger. * A **state tree** - All the [ledger nodes](#ledger-node-types) that contain the settings, balances, and objects in the ledger as of this version. ## Tree Format ## -As its name might suggest, a ledger's state tree is a tree data structure, with each node identified by a 256-bit value called an `index`. In JSON, a ledger node's index value is represented as a 64-character hexadecimal string like `"193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94"`. Every node in the state tree has an index that you can use as a key to look up the node in the state tree; every transaction has an indentifying hash that you can use to look up the transaction in the transaction tree. Do not confuse the `index` (key) of a ledger node with the `ledger_index` (sequence number) of a ledger. +As its name might suggest, a ledger's state tree is a tree data structure, with each node identified by a 256-bit value called an `index`. In JSON, a ledger node's index value is represented as a 64-character hexadecimal string like `"193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94"`. Every node in the state tree has an index that you can use as a key to look up the node in the state tree; every transaction has an indentifying hash that you can use to look up the transaction in the transaction tree. Do not confuse the `index` (key) of a ledger node with the [`ledger_index` (sequence number) of a ledger](#ledger-index). In the case of transactions, the identifying hash is based on the signed transaction instructions, but the contents of the transaction object when you look it up also contain the results and metadata of the transaction, which are not taken into account when generating the hash. @@ -33,19 +33,24 @@ Every ledger version has a unique header that describes the contents. You can lo | Field | JSON Type | [Internal Type][] | Description | |-----------------|-----------|-------------------|-------------| -| ledger\_index | String | UInt32 | The sequence number of the ledger. Some API methods display this as a quoted integer; some display it as a native JSON number. | +| [ledger\_index](#ledger-index) | String | UInt32 | The sequence number of the ledger. Some API methods display this as a quoted integer; some display it as a native JSON number. | | ledger\_hash | String | Hash256 | The SHA-512Half of the ledger header, excluding the `ledger_hash` itself. This serves as a unique identifier for this ledger and all its contents. | | account\_hash | String | Hash256 | The SHA-512Half of this ledger's state tree information. | | close\_time | Number | UInt32 | The approximate time this ledger closed, as the number of seconds since the Ripple Epoch of 2000-01-01 00:00:00. This value is rounded based on the `close_time_resolution`, so it is possible for subsequent ledgers to have the same value. | | closed | Boolean | bool | If true, this transaction is no longer accepting new transactions. (However, unless this ledger is validated, it might be replaced by a different ledger with a different set of transactions.) | -| parent\_hash | String | Hash256 | The `ledger_hash` value of the previous ledger that was used to build this one. If there are different versions of the previous ledger by sequence number, this indicates from which one the ledger was derived. | +| parent\_hash | String | Hash256 | The `ledger_hash` value of the previous ledger that was used to build this one. If there are different versions of the previous ledger index, this indicates from which one the ledger was derived. | | total\_coins | String | UInt64 | The total number of drops of XRP owned by accounts in the ledger. This subtracts XRP that has been destroyed by transaction fees. The actual amount of XRP in circulation is lower because some accounts are "black holes" whose keys are not known by anyone. | | transaction\_hash | String | Hash256 | The SHA-512Half of the transactions included in this ledger. | | close\_time\_resolution | Number | Uint8 | An integer in the range \[2,120\] indicating the maximum number of seconds by which the `close_time` could be rounded. | -| closeFlags | (Omitted) | UInt8 | A bit-map of flags relating to the closing of this ledger. | +| [closeFlags](#close-flags) | (Omitted) | UInt8 | A bit-map of flags relating to the closing of this ledger. | [Internal Type]: https://wiki.ripple.com/Binary_Format + +### Ledger Index ### +{% include 'data_types/ledger_index.md' %} +[Hash]: reference-rippled.html#hashes + ### Close Flags ### Currently, the ledger has only one flag defined for closeFlags: **sLCF_NoConsensusTime** (value `1`). If this flag is enabled, it means that validators were in conflict regarding the correct close time for the ledger, but built otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, the consensus ledger contains a `close_time` value that is 1 second after that of the previous ledger. (In this case, there is no official close time, but the actual real-world close time is probably 3-6 seconds later than the specified `close_time`.) @@ -100,7 +105,7 @@ The `AccountRoot` node has the following fields: | Balance | String | Amount | The account's current XRP balance in drops, represented as a string. | | OwnerCount | Number | UInt32 | The number of objects this account owns in the ledger, which contributes to its owner reserve. | | PreviousTxnID | String | Hash256 | The identifying hash of the transaction that most recently modified this node. | -| PreviousTxnLgrSeq | Number | UInt32 | The sequence number (`ledger_index`) of the ledger that contains the transaction that most recently modified this node. | +| PreviousTxnLgrSeq | Number | UInt32 | The [index of the ledger](#ledger-index) that contains the transaction that most recently modified this node. | | AccountTxnID | String | Hash256 | (Optional) The identifying hash of the transaction most recently submitted by this account. | | RegularKey | String | AccountID | (Optional) The address of a keypair that can be used to sign transactions for this account instead of the master key. Use a [SetRegularKey transaction](reference-transaction-format.html#setregularkey) to change this value. | | EmailHash | String | Hash128 | (Optional) The md5 hash of an email address. Clients can use this to look up an avatar through services such as [Gravatar](https://en.gravatar.com/). | @@ -127,7 +132,7 @@ AccountRoot nodes can have the following flag values: | lsfGlobalFreeze | 0x00400000 | 4194304 |　All assets issued by this account are frozen. | asfGlobalFreeze | | lsfDefaultRipple | 0x00800000 | 8388608 | Enable [rippling](https://ripple.com/knowledge_center/understanding-the-noripple-flag/) on this account's trust lines by default. Required for gateways; discouraged for other accounts. | asfDefaultRipple | -### AccountRoot index format ### +### AccountRoot Index Format ### The `index` of an AccountRoot node is the SHA-512Half of the following values put together: @@ -201,7 +206,7 @@ Example Directories: | TakerGetsCurrency | String | Hash160 | (Offer Directories only) The currency code of the TakerGets amount from the offers in this directory. | | TakerGetsIssuer | String | Hash160 | (Offer Directories only) The issuer of the TakerGets amount from the offers in this directory. | -### Directory index formats ### +### Directory Index Formats ### There are three different formulas for creating the index of a DirectoryNode, depending on whether the DirectoryNode represents: @@ -275,7 +280,7 @@ An Offer node has the following fields: | BookNode | String | UInt64 | A hint indicating which page of the offer directory links to this node, in case the directory consists of multiple nodes. | | OwnerNode | String | UInt64 | A hint indicating which page of the owner directory links to this node, in case the directory consists of multiple nodes. **Note:** The offer does not contain a direct link to the owner directory containing it, since that value can be derived from the `Account`. | | PreviousTxnID | String | Hash256 | The identifying hash of the transaction that most recently modified this node. | -| PreviousTxnLgrSeq | Number | UInt32 | The sequence number (`ledger_index`) of the ledger that contains the transaction that most recently modified this node. | +| PreviousTxnLgrSeq | Number | UInt32 | The [index of the ledger](#ledger-index) that contains the transaction that most recently modified this node. | | Expiration | Number | UInt32 | (Optional) Indicates the time after which this offer will be considered unfunded. See [Specifying Time](reference-rippled.html#specifying-time) for details. | ### Offer Flags ### @@ -289,7 +294,7 @@ Offer nodes can have the following flag values: | lsfPassive | 0x00010000 | 65536 | The node was placed as a passive offer. This has no effect on the node in the ledger. | tfPassive | | lsfSell | 0x00020000 | 131072 | The node was placed as a sell offer. This has no effect on the node in the ledger (because tfSell only matters if you get a better rate than you asked for, which cannot happen after the node enters the ledger). | tfSell | -### Offer index format ### +### Offer Index Format ### The `index` of an Offer node is the SHA-512Half of the following values put together: @@ -344,7 +349,7 @@ A RippleState node has the following fields: | 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. | -| PreviousTxnLgrSeq | Number | UInt32 | The sequence number (`ledger_index`) of the ledger that contains the transaction that most recently modified this node. | +| PreviousTxnLgrSeq | Number | UInt32 | The [index of the ledger](#ledger-index) that contains the transaction that most recently modified this node. | | LowNode | String | UInt64 | (Omitted in some historical ledgers) A hint indicating which page of the low account's owner directory links to this node, in case the directory consists of multiple nodes. | | HighNode | String | UInt64 | (Omitted in some historical ledgers) A hint indicating which page of the high account's owner directory links to this node, in case the directory consists of multiple nodes. | | LowQualityIn | Number | UInt32 | (Optional) The inbound quality set by the low account, as an integer in the implied ratio LowQualityIn:1,000,000,000. The value 0 is equivalent to 1 billion, or face value. | @@ -390,7 +395,7 @@ The default state of the two NoRipple flags depends on the state of the [lsfDefa Fortunately, `rippled` uses lazy evaluation to calculate the owner reserve. This means that even if an account changes the default state of all its trust lines by changing the DefaultRipple flag, that account's reserve stays the same initially. If an account modifies a trust line, `rippled` re-evaluates whether that individual trust line is in its default state and should contribute the owner reserve. -### RippleState index format ### +### RippleState Index Format ### The `index` of a RippleState node is the SHA-512Half of the following values put together: @@ -447,23 +452,23 @@ A SignerList node has the following fields: | OwnerNode | String | UInt64 | A hint indicating which page of the owner directory links to this node, in case the directory consists of multiple nodes. | | SignerQuorum | Number | UInt32 | A target number for signer weights. To produce a valid signature for the owner of this SignerList, the signers must provide valid signatures whose weights sum to this value or more. | | SignerEntries | Array | Array | An array of SignerEntry objects representing the parties who are part of this signer list. | -| SignerListID | Number | UInt32 | An ID for this signer list. Currently always set to `0`. If a future update allows multiple signer lists for an account, this may change. | +| SignerListID | Number | UInt32 | An ID for this signer list. Currently always set to `0`. If a future [amendment](concept-amendments.html) allows multiple signer lists for an account, this may change. | | PreviousTxnID | String | Hash256 | The identifying hash of the transaction that most recently modified this node. | -| PreviousTxnLgrSeq | Number | UInt32 | The sequence number (`ledger_index`) of the ledger that contains the transaction that most recently modified this node. | +| PreviousTxnLgrSeq | Number | UInt32 | The [index of the ledger](#ledger-index) that contains the transaction that most recently modified this node. | The `SignerEntries` may be any combination of funded and unfunded addresses that use either secp256k1 or ed25519 keys. -### SignerEntry object ### +### SignerEntry Object ### Each member of the `SignerEntries` field is an object that describes that signer in the list. A SignerEntry has the following fields: | Name | JSON Type | Internal Type | Description | |-----------------|-----------|---------------|-------------| -| Account | String | AccountID | An address whose signature contributes to the multi-signature. This does not need to be a funded Ripple account. | -| SignerWeight | Number | UInt16 | The weight of signatures from this signer. A multi-signature is only valid of the sum weight of the signatures provided meets or exceeds the SignerList's `SignerQuorum` value. | +| Account | String | AccountID | A Ripple address whose signature contributes to the multi-signature. It does not need to be a funded address in the ledger. | +| SignerWeight | Number | UInt16 | The weight of a signature from this signer. A multi-signature is only valid if the sum weight of the signatures provided meets or exceeds the SignerList's `SignerQuorum` value. | -When processing a multi-signed transaction, the server dereferences the `Account` values with respect to the ledger at the time of transaction execution. If the address _does not_ correspond to a funded [AccountRoot node](#accountroot), then only the master secret associated with that address can be used to produce a valid signature. If the account _does_ exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. Even if the account has a SignerList configured, a multi-signature cannot be used as a valid component to another multi-signature. (In other words, "multi-level" multi-signing is disallowed.) +When processing a multi-signed transaction, the server dereferences the `Account` values with respect to the ledger at the time of transaction execution. If the address _does not_ correspond to a funded [AccountRoot node](#accountroot), then only the master secret associated with that address can be used to produce a valid signature. If the account _does_ exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. A multi-signature cannot be used as a component of another multi-signature. ### SignerLists and Reserves ### -A SignerList contributes to the [Account Reserve](https://wiki.ripple.com/Reserves). The SignerList itself counts as two objects, and each member of the list counts as one, so that the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line ([RippleState](#ripplestate)) or [Offer](#offer) node in the ledger. +A SignerList contributes to its owner's [reserve requirement](concept-reserves.html). The SignerList itself counts as two objects, and each member of the list counts as one. As a result, the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line ([RippleState](#ripplestate)) or [Offer](#offer) node in the ledger. diff --git a/content/tutorial-multisign.md b/content/tutorial-multisign.md index 84eba1ca5c..f8c3160513 100644 --- a/content/tutorial-multisign.md +++ b/content/tutorial-multisign.md @@ -31,6 +31,8 @@ If you want to test multi-signing before it becomes available in the production Setting up Multi-Signing ------------------------ +Before you can set up multi-signing, first check that [multi-signing is available](#availability-of-multi-signing). + To multi-sign transactions from a particular address, you must create a list of addresses that can contribute to a multi-signature for your address. This list is stored in the Ripple Consensus Ledger as a [SignerList node](reference-ledger-format.html#signerlist). The following procedure demonstrates how to set up a SignerList for your address: @@ -232,7 +234,7 @@ 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 check that [multi-sign is available](#availability-of-multi-signing) and [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](#set-up-multi-sign) for your address. The following procedure demonstrates how to create, sign, and submit a multi-signed transaction. ### 1. Create the transaction ## diff --git a/reference-ledger-format.html b/reference-ledger-format.html index ae73cab2e0..77acdf9f2b 100644 --- a/reference-ledger-format.html +++ b/reference-ledger-format.html @@ -130,16 +130,16 @@

                            The Ledger

                            The point of the Ripple software is to maintain a shared, global ledger that is open to all, so that individual participants can trust the integrity of the ledger without having to trust any single institution to manage it. The rippled server software accomplishes this by maintaining a ledger database that can only be updated according to very specific rules. Each instance of rippled maintains a full copy of the ledger, and the peer-to-peer network of rippled servers distributes candidate transactions among themselves. The consensus process determines which transactions get applied to each new version of the ledger. See also: The Consensus Process.

                            Diagram: Each ledger is the result of applying transactions to the previous ledger version.

                            -

                            The shared global ledger is actually a series of individual ledgers, or ledger versions, which rippled keeps in its internal database. Every ledger version has a sequence number (also called a ledger index), starting at 1 and incrementing with each new version. Every closed ledger also has an identifying hash value, which uniquely identifies the contents of that ledger. At any given time, a rippled instance has an in-progress "current" open ledger, plus some number of closed ledgers that have not yet been approved by consensus, and any number of historical ledgers that have been validated by consensus. Only the validated ledgers are certain to be accurate and immutable.

                            +

                            The shared global ledger is actually a series of individual ledgers, or ledger versions, which rippled keeps in its internal database. Every ledger version has a ledger index which identifies the order in which ledgers occur. Each closed ledger version also has an identifying hash value, which uniquely identifies the contents of that ledger. At any given time, a rippled instance has an in-progress "current" open ledger, plus some number of closed ledgers that have not yet been approved by consensus, and any number of historical ledgers that have been validated by consensus. Only the validated ledgers are certain to be accurate and immutable.

                            A single ledger version consists of several components:

                            Diagram: A ledger has transactions, a state node, and a header with the close time and validation info

                              -
                            • A header - The ledger's unique index (sequence number), hashes of the other contents, and other metadata.
                              • +
                            • A header - The ledger index, hashes of its other contents, and other metadata.
                            • A transaction tree - The transactions that were applied to the previous ledger to make this one. Transactions are the only way to modify the ledger.
                            • A state tree - All the ledger nodes that contain the settings, balances, and objects in the ledger as of this version.

                            Tree Format

                            -

                            As its name might suggest, a ledger's state tree is a tree data structure, with each node identified by a 256-bit value called an index. In JSON, a ledger node's index value is represented as a 64-character hexadecimal string like "193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94". Every node in the state tree has an index that you can use as a key to look up the node in the state tree; every transaction has an indentifying hash that you can use to look up the transaction in the transaction tree. Do not confuse the index (key) of a ledger node with the ledger_index (sequence number) of a ledger.

                            +

                            As its name might suggest, a ledger's state tree is a tree data structure, with each node identified by a 256-bit value called an index. In JSON, a ledger node's index value is represented as a 64-character hexadecimal string like "193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94". Every node in the state tree has an index that you can use as a key to look up the node in the state tree; every transaction has an indentifying hash that you can use to look up the transaction in the transaction tree. Do not confuse the index (key) of a ledger node with the ledger_index (sequence number) of a ledger.

                            In the case of transactions, the identifying hash is based on the signed transaction instructions, but the contents of the transaction object when you look it up also contain the results and metadata of the transaction, which are not taken into account when generating the hash.

                            In the case of state nodes, rippled usually includes the index of the node along with its contents. However, the index itself is not part of the contents. The index is derived by hashing important contents of the node, along with a namespace identifier. The ledger node type determines which namespace identifier to use as well as which contents to include in the hash. This ensures every index is unique. For a hash function, rippled uses SHA-512 and then truncates the result to the first 256 bytes. This algorithm, informally called SHA-512Half, provides an output that has comparable security to SHA-256, but runs faster on 64-bit processors.

                            Diagram: rippled uses SHA-512Half to generate indexes for ledger nodes. The space key prevents indexes for different node types from colliding.

                            @@ -157,7 +157,7 @@ -ledger_index +ledger_index String UInt32 The sequence number of the ledger. Some API methods display this as a quoted integer; some display it as a native JSON number. @@ -190,7 +190,7 @@ parent_hash String Hash256 -The ledger_hash value of the previous ledger that was used to build this one. If there are different versions of the previous ledger by sequence number, this indicates from which one the ledger was derived. +The ledger_hash value of the previous ledger that was used to build this one. If there are different versions of the previous ledger index, this indicates from which one the ledger was derived. total_coins @@ -211,13 +211,21 @@ An integer in the range [2,120] indicating the maximum number of seconds by which the close_time could be rounded. -closeFlags +closeFlags (Omitted) UInt8 A bit-map of flags relating to the closing of this ledger. +

                            Ledger Index

                            +

                            A ledger index is a 32-bit unsigned integer used to identify a ledger. The ledger index is also known as the ledger's sequence number. The very first ledger was ledger index 1, and each subsequent ledger has a ledger index 1 higher than that of the ledger immediately before it.

                            +

                            The ledger index indicates the order of the ledgers; the Hash value identifies the exact contents of the ledger. Two ledgers with the same hash are always identical. For validated ledgers, hash values and sequence numbers are equally valid and correlate 1:1. However, this is not true for in-progress ledgers:

                            +
                              +
                            • Two different rippled servers may have different contents for a current ledger with the same ledger index, due to latency in propagating transactions throughout the network.
                              • +
                            • There may be multiple closed ledger versions competing to be validated by consensus. These ledger versions have the same sequence number but different contents (and different hashes). Only one of these closed ledgers can become validated.
                              • +
                            • A current ledger's contents change over time, which would cause its hash to change, even though its ledger index number stays the same. Therefore, the hash of a ledger is not calculated until the ledger is closed.
                              • +

                            Close Flags

                            Currently, the ledger has only one flag defined for closeFlags: sLCF_NoConsensusTime (value 1). If this flag is enabled, it means that validators were in conflict regarding the correct close time for the ledger, but built otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, the consensus ledger contains a close_time value that is 1 second after that of the previous ledger. (In this case, there is no official close time, but the actual real-world close time is probably 3-6 seconds later than the specified close_time.)

                            The closeFlags field is not included in any JSON representations of a ledger, but it is a part of the binary representation of a ledger, and is one of the fields that determine the ledger's hash.

                            @@ -307,7 +315,7 @@ PreviousTxnLgrSeq Number UInt32 -The sequence number (ledger_index) of the ledger that contains the transaction that most recently modified this node. +The index of the ledger that contains the transaction that most recently modified this node. AccountTxnID @@ -431,7 +439,7 @@ -

                            AccountRoot index format

                            +

                            AccountRoot Index Format

                            The index of an AccountRoot node is the SHA-512Half of the following values put together:

                            • The Account space key (a)
                              • @@ -561,7 +569,7 @@ -

                              Directory index formats

                              +

                              Directory Index Formats

                              There are three different formulas for creating the index of a DirectoryNode, depending on whether the DirectoryNode represents:

                              • The first page (also called the root) of an Owner Directory,
                                • @@ -687,7 +695,7 @@ PreviousTxnLgrSeq Number UInt32 -The sequence number (ledger_index) of the ledger that contains the transaction that most recently modified this node. +The index of the ledger that contains the transaction that most recently modified this node. Expiration @@ -727,7 +735,7 @@ -

                                Offer index format

                                +

                                Offer Index Format

                                The index of an Offer node is the SHA-512Half of the following values put together:

                                • The Offer space key (o)
                                  • @@ -815,7 +823,7 @@ PreviousTxnLgrSeq Number UInt32 -The sequence number (ledger_index) of the ledger that contains the transaction that most recently modified this node. +The index of the ledger that contains the transaction that most recently modified this node. LowNode @@ -967,7 +975,7 @@

                                  The lsfLowAuth and lsfHighAuth flags do not count against the default state, because they cannot be disabled.

                                  The default state of the two NoRipple flags depends on the state of the lsfDefaultRipple flag in their corresponding AccountRoot nodes. If DefaultRipple is disabled (the default), then the default state of the lsfNoRipple flag is enabled for all of an account's trust lines. If an account enables DefaultRipple, then the lsfNoRipple flag is disabled (rippling is enabled) for an account's trust lines by default. Note: Prior to the introduction of the DefaultRipple flags in rippled version 0.27.3 (March 10, 2015), the default state for all trust lines was with lsfNoRipple disabled (rippling enabled).

                                  Fortunately, rippled uses lazy evaluation to calculate the owner reserve. This means that even if an account changes the default state of all its trust lines by changing the DefaultRipple flag, that account's reserve stays the same initially. If an account modifies a trust line, rippled re-evaluates whether that individual trust line is in its default state and should contribute the owner reserve.

                                  -

                                  RippleState index format

                                  +

                                  RippleState Index Format

                                  The index of a RippleState node is the SHA-512Half of the following values put together:

                                  • The RippleState space key (r)
                                    • @@ -1043,7 +1051,7 @@ SignerListID Number UInt32 -An ID for this signer list. Currently always set to 0. If a future update allows multiple signer lists for an account, this may change. +An ID for this signer list. Currently always set to 0. If a future amendment allows multiple signer lists for an account, this may change. PreviousTxnID @@ -1055,12 +1063,12 @@ PreviousTxnLgrSeq Number UInt32 -The sequence number (ledger_index) of the ledger that contains the transaction that most recently modified this node. +The index of the ledger that contains the transaction that most recently modified this node.

                                    The SignerEntries may be any combination of funded and unfunded addresses that use either secp256k1 or ed25519 keys.

                                    -

                                    SignerEntry object

                                    +

                                    SignerEntry Object

                                    Each member of the SignerEntries field is an object that describes that signer in the list. A SignerEntry has the following fields:

                                    @@ -1088,7 +1096,7 @@

                                    When processing a multi-signed transaction, the server dereferences the Account values with respect to the ledger at the time of transaction execution. If the address does not correspond to a funded AccountRoot node, then only the master secret associated with that address can be used to produce a valid signature. If the account does exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. Even if the account has a SignerList configured, a multi-signature cannot be used as a valid component to another multi-signature. (In other words, "multi-level" multi-signing is disallowed.)

                                    SignerLists and Reserves

                                    -

                                    A SignerList contributes to the Account Reserve. The SignerList itself counts as two objects, and each member of the list counts as one, so that the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line (RippleState) or Offer node in the ledger.

                                    +

                                    A SignerList contributes to its owner's reserve requirement. The SignerList itself counts as two objects, and each member of the list counts as one, so that the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line (RippleState) or Offer node in the ledger.

                        diff --git a/tutorial-multisign.html b/tutorial-multisign.html index 572b70e63f..45c041f64f 100644 --- a/tutorial-multisign.html +++ b/tutorial-multisign.html @@ -148,6 +148,7 @@ MultiSign

                        Setting up Multi-Signing

                        +

                        Before you can set up multi-signing, first check that multi-signing is available.

                        To multi-sign transactions from a particular address, you must create a list of addresses that can contribute to a multi-signature for your address. This list is stored in the Ripple Consensus Ledger as a SignerList node. The following procedure demonstrates how to set up a SignerList for your address:

                        1. Prepare a funded address

                        You need a Ripple address that can send transactions, and has enough XRP available. Multi-signing requires more than the usual amount of XRP for the account reserve and transaction cost, increasing with the number of signers and signatures you use.

                        @@ -321,7 +322,7 @@ Connecting to 127.0.0.1:5005
                      • Remove the address's regular key (if you previously set one) by sending a SetRegularKey transaction.

                      Sending a Multi-Signed Transaction

                      -

                      Before you can multi-sign a transaction, first check that multi-sign is available and set up multi-signing 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 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, 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 increases in that time.

                      From d7d6bbaaaefcfed7dbf329b0c554ce28374b3772 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 4 Apr 2016 13:23:03 -0700 Subject: [PATCH 27/40] amendments peer review edits --- concept-amendments.html | 21 ++++++++++++--------- content/concept-amendments.md | 26 ++++++++++++++++---------- reference-ledger-format.html | 8 ++++---- 3 files changed, 32 insertions(+), 23 deletions(-) diff --git a/concept-amendments.html b/concept-amendments.html index cd956cece5..557e5eb657 100644 --- a/concept-amendments.html +++ b/concept-amendments.html @@ -135,13 +135,16 @@

                      The Amendments system provides a means of introducing new features to the decentralized Ripple consensus network without causing disruptions. The amendments system works by utilizing the core consensus process of the network to approve any changes by showing continuous support before those changes go into effect. An amendment normally requires 80% support for two weeks before it can apply.

                      When an Amendment has been enabled, it applies permanently to all ledger versions after the one that included it. You cannot disable an Amendment, unless you introduce a new Amendment to do so.

                      Background

                      -

                      Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If only a portion of validators have upgraded to a new version of the software, this could cause anything from minor inconveniences (a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot rely on their own) to serious problems: consensus might be unable to validate new ledger versions because servers are unable to reach a consensus who agree to the exact same result.

                      -

                      Amendments provide solution to this problem, so that new features can be enabled only when enough validators support those features.

                      +

                      Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If only a portion of validators have upgraded to a new version of the software, this could cause anything from minor inconveniences to full outages. In the minor case, a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot build it using the transaction processing rules they already know. In the worst case, the consensus process might be unable to validate new ledger versions because servers with different rules could not reach a consensus on the exact ledger to build.

                      +

                      Amendments provide a solution to this problem, so that new features can be enabled only when enough validators support those features.

                      Users and businesses who rely on the Ripple Consensus Ledger can also use Amendments to provide advance notice of changes in transaction processing that might affect their business. However, API changes that do not impact transaction processing or the consensus process do not require Amendments.

                      +

                      About Amendments

                      +

                      An amendment is a fully-functional feature or change, waiting to be enabled by the peer-to-peer network as a part of the consensus process. A rippled server that wants to use an amendment has code for two modes: without the amendment (previous behavior) and with the amendment (new behavior).

                      +

                      Every amendment has a unique identifying hex value and a short name. The short name is for human use, and is not used in the amendment process. Two servers can support the same amendment ID while using different names to describe it. An amendment's name is not guaranteed to be unique.

                      +

                      See also: Known Amendments

                      Amendment Process

                      -

                      An amendment is a fully-functional feature or change, ready to apply when a consensus of servers can handle it. A rippled server that wants to use an amendment has business logic for two modes: without the amendment (previous behavior) and with the amendment (new behavior). Every amendment has a unique identifying hex value and a short name. The short name is for human use, and does not affect the status of the amendment.

                      -

                      Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger: at this time, rippled validator servers submit votes in favor of specific amendments alongside their validations for that ledger. (Fee Voting also occurs around flag ledgers.)

                      -

                      In the flag ledger itself, there is nothing unusual. However, during that time, the servers look at the votes of the validators they trust, and decide whether to insert an EnableAmendment pseudo-transaction into the following ledger. The flags of an EnableAmendment pseudo-transaction indicate what the server thinks happened:

                      +

                      Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger. When rippled validator servers send validation messages for that ledger, those servers also submit votes in favor of specific amendments. (Fee Voting also occurs around flag ledgers.)

                      +

                      The flag ledger itself has no special contents. However, during that time, the servers look at the votes of the validators they trust, and decide whether to insert an EnableAmendment pseudo-transaction into the following ledger. The flags of an EnableAmendment pseudo-transaction indicate what the server thinks happened:

                      • The tfGotMajority flag means that support for the amendment has increased to at least 80% of trusted validators.
                      • The tfLostMajority flag means that support for the amendment has decreased to less than 80% of trusted validators.
                        • @@ -162,12 +165,12 @@

                        As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. Currently, Ripple recommends only trusting the 5 default validators that Ripple (the company) operates. For now, trusting only those validators is sufficient to coordinate with Ripple on releasing new features.

                        Configuring Amendment Voting

                        You can temporarily configure an amendment using the feature command. To make a persistent change to your server's support for an amendment, modify your server's rippled.cfg file.

                        -

                        Use the [veto_amendments] stanza to list amendments you do not want the server to vote for. Each line should contains one amendment's unique ID, optionally followed by the short name for the amendment. For example:

                        +

                        Use the [veto_amendments] stanza to list amendments you do not want the server to vote for. Each line should contain one amendment's unique ID, optionally followed by the short name for the amendment. For example:

                        [veto_amendments]
 C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 Tickets
 DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 SusPay
                        -

                        Use the [amendments] stanza to list amendments you want to vote for. (Even if you do not list them here, by default a server votes for all the amendments it knows how to apply.) Each line should contains one amendment's unique ID, optionally followed by the short name for the amendment. For example:

                        +

                        Use the [amendments] stanza to list amendments you want to vote for. (Even if you do not list them here, by default a server votes for all the amendments it knows how to apply.) Each line should contain one amendment's unique ID, optionally followed by the short name for the amendment. For example:

                        [amendments]
 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 MultiSign
 42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE FeeEscalation
@@ -255,8 +258,8 @@ TrustSetAuth
 
 
                        Introduces simple multi-signing as a way to authorize transactions. Creates the SignerList ledger node type and the SignerListSet transaction type. Adds the optional Signers field to all transaction types. Modifies some transaction result codes.
                        
 
                        This amendment allows addresses to have a list of signers who can authorize transactions from that address in a multi-signature. The list has a quorum and 1 to 8 weighted signers. This allows various configurations, such as "any 3-of-5" or "signature from A plus any other two signatures."
                        
-
                        Signers can be funded or unfunded addresses. Funded addresses in a signer list can sign using a regular key (if defined) or master key (unless disabled). Unfunded addresses can sign with a master key. This amendment does not allow second-level multi-signing (signers using multi-signatures to contribute to multi-signatures). Multi-signed transactions have the same permissions as transactions signed with a regular key.
                        
-
                        An address with a SignerList can disable the master key even without a regular key, or remove a regular key even if the master key is disabled. Therefore, the tecMASTER_DISABLED transaction result code is renamed tecNO_ALTERNATIVE_KEY. The tecNO_REGULAR_KEY transaction result is retired and replaced with tecNO_ALTERNATIVE_KEY. Additionally, this amendment adds the following new transaction result codes:
                        
+
                        Signers can be funded or unfunded addresses. Funded addresses in a signer list can sign using a regular key (if defined) or master key (unless disabled). Unfunded addresses can sign with a master key. Multi-signed transactions have the same permissions as transactions signed with a regular key.
                        
+
                        An address with a SignerList can disable the master key even if a regular key is not defined. An address with a SignerList can also remove a regular key even if the master key is disabled. Therefore, the tecMASTER_DISABLED transaction result code is renamed tecNO_ALTERNATIVE_KEY. The tecNO_REGULAR_KEY transaction result is retired and replaced with tecNO_ALTERNATIVE_KEY. Additionally, this amendment adds the following new transaction result codes:
                        
 
                          
 
                        • temBAD_SIGNER
                          • 
 
                        • temBAD_QUORUM
                          • 
diff --git a/content/concept-amendments.md b/content/concept-amendments.md
index b8dd4b8bb0..d2a59282a0 100644
--- a/content/concept-amendments.md
+++ b/content/concept-amendments.md
@@ -7,20 +7,26 @@ When an Amendment has been enabled, it applies permanently to all ledger version
 
 ## Background ##
 
-Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If only a portion of validators have upgraded to a new version of the software, this could cause anything from minor inconveniences (a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot rely on their own) to serious problems: consensus might be unable to validate new ledger versions because servers are unable to reach a consensus who agree to the exact same result.
+Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If only a portion of validators have upgraded to a new version of the software, this could cause anything from minor inconveniences to full outages. In the minor case, a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot build it using the transaction processing rules they already know. In the worst case, [the consensus process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/) might be unable to validate new ledger versions because servers with different rules could not reach a consensus on the exact ledger to build.
 
-Amendments provide solution to this problem, so that new features can be enabled only when enough validators support those features.
+Amendments provide a solution to this problem, so that new features can be enabled only when enough validators support those features.
 
 Users and businesses who rely on the Ripple Consensus Ledger can also use Amendments to provide advance notice of changes in transaction processing that might affect their business. However, API changes that do not impact transaction processing or [the consensus process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/) do not require Amendments.
 
 
+## About Amendments ##
+
+An amendment is a fully-functional feature or change, waiting to be enabled by the peer-to-peer network as a part of the consensus process. A `rippled` server that wants to use an amendment has code for two modes: without the amendment (previous behavior) and with the amendment (new behavior).
+
+Every amendment has a unique identifying hex value and a short name. The short name is for human use, and is not used in the amendment process. Two servers can support the same amendment ID while using different names to describe it. An amendment's name is not guaranteed to be unique.
+
+See also: [Known Amendments](#known-amendments)
+
 ## Amendment Process ##
 
-An amendment is a fully-functional feature or change, ready to apply when a consensus of servers can handle it. A `rippled` server that wants to use an amendment has business logic for two modes: without the amendment (previous behavior) and with the amendment (new behavior). Every amendment has a unique identifying hex value and a short name. The short name is for human use, and does not affect the status of the amendment.
+Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger. When `rippled` validator servers send validation messages for that ledger, those servers also submit votes in favor of specific amendments. ([Fee Voting](concept-fee-voting.html) also occurs around flag ledgers.)
 
-Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger: at this time, `rippled` validator servers submit votes in favor of specific amendments alongside their validations for that ledger. ([Fee Voting](concept-fee-voting.html) also occurs around flag ledgers.)
-
-In the flag ledger itself, there is nothing unusual. However, during that time, the servers look at the votes of the validators they trust, and decide whether to insert an [`EnableAmendment` pseudo-transaction](reference-transaction-format.html#enableamendment) into the following ledger. The flags of an EnableAmendment pseudo-transaction indicate what the server thinks happened:
+The flag ledger itself has no special contents. However, during that time, the servers look at the votes of the validators they trust, and decide whether to insert an [`EnableAmendment` pseudo-transaction](reference-transaction-format.html#enableamendment) into the following ledger. The flags of an EnableAmendment pseudo-transaction indicate what the server thinks happened:
 
 * The `tfGotMajority` flag means that support for the amendment has increased to at least 80% of trusted validators.
 * The `tfLostMajority` flag means that support for the amendment has decreased to less than 80% of trusted validators.
@@ -48,7 +54,7 @@ As with all aspects of the consensus process, amendment votes are only taken int
 
 You can temporarily configure an amendment using the [`feature` command](reference-rippled.html#feature). To make a persistent change to your server's support for an amendment, modify your server's `rippled.cfg` file.
 
-Use the `[veto_amendments]` stanza to list amendments you do not want the server to vote for. Each line should contains one amendment's unique ID, optionally followed by the short name for the amendment. For example:
+Use the `[veto_amendments]` stanza to list amendments you do not want the server to vote for. Each line should contain one amendment's unique ID, optionally followed by the short name for the amendment. For example:
 
 ```
 [veto_amendments]
@@ -56,7 +62,7 @@ C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 Tickets
 DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 SusPay
 ```
 
-Use the `[amendments]` stanza to list amendments you want to vote for. (Even if you do not list them here, by default a server votes for all the amendments it knows how to apply.) Each line should contains one amendment's unique ID, optionally followed by the short name for the amendment. For example:
+Use the `[amendments]` stanza to list amendments you want to vote for. (Even if you do not list them here, by default a server votes for all the amendments it knows how to apply.) Each line should contain one amendment's unique ID, optionally followed by the short name for the amendment. For example:
 
 ```
 [amendments]
@@ -121,9 +127,9 @@ Introduces simple [multi-signing](reference-transaction-format.html#multi-signin
 
 This amendment allows addresses to have a list of signers who can authorize transactions from that address in a multi-signature. The list has a quorum and 1 to 8 weighted signers. This allows various configurations, such as "any 3-of-5" or "signature from A plus any other two signatures."
 
-Signers can be funded or unfunded addresses. Funded addresses in a signer list can sign using a regular key (if defined) or master key (unless disabled). Unfunded addresses can sign with a master key. This amendment does not allow second-level multi-signing (signers using multi-signatures to contribute to multi-signatures). Multi-signed transactions have the same permissions as transactions signed with a regular key.
+Signers can be funded or unfunded addresses. Funded addresses in a signer list can sign using a regular key (if defined) or master key (unless disabled). Unfunded addresses can sign with a master key. Multi-signed transactions have the same permissions as transactions signed with a regular key.
 
-An address with a SignerList can disable the master key even without a regular key, or remove a regular key even if the master key is disabled. Therefore, the `tecMASTER_DISABLED` transaction result code is renamed `tecNO_ALTERNATIVE_KEY`. The `tecNO_REGULAR_KEY` transaction result is retired and replaced with `tecNO_ALTERNATIVE_KEY`. Additionally, this amendment adds the following new [transaction result codes](reference-transaction-format.html#result-categories):
+An address with a SignerList can disable the master key even if a regular key is not defined. An address with a SignerList can also remove a regular key even if the master key is disabled. Therefore, the `tecMASTER_DISABLED` transaction result code is renamed `tecNO_ALTERNATIVE_KEY`. The `tecNO_REGULAR_KEY` transaction result is retired and replaced with `tecNO_ALTERNATIVE_KEY`. Additionally, this amendment adds the following new [transaction result codes](reference-transaction-format.html#result-categories):
 
 * `temBAD_SIGNER`
 * `temBAD_QUORUM`
diff --git a/reference-ledger-format.html b/reference-ledger-format.html
index 77acdf9f2b..7082230b21 100644
--- a/reference-ledger-format.html
+++ b/reference-ledger-format.html
@@ -1084,19 +1084,19 @@
 Account
 String
 AccountID
-An address whose signature contributes to the multi-signature. This does not need to be a funded Ripple account.
+A  Ripple address whose signature contributes to the multi-signature. It does not need to be a funded address in the ledger.
 
 
 SignerWeight
 Number
 UInt16
-The weight of signatures from this signer. A multi-signature is only valid of the sum weight of the signatures provided meets or exceeds the SignerList's SignerQuorum value.
+The weight of a signature from this signer. A multi-signature is only valid if the sum weight of the signatures provided meets or exceeds the SignerList's SignerQuorum value.
 
 
 
-
                          When processing a multi-signed transaction, the server dereferences the Account values with respect to the ledger at the time of transaction execution. If the address does not correspond to a funded AccountRoot node, then only the master secret associated with that address can be used to produce a valid signature. If the account does exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. Even if the account has a SignerList configured, a multi-signature cannot be used as a valid component to another multi-signature. (In other words, "multi-level" multi-signing is disallowed.)
                          
+
                          When processing a multi-signed transaction, the server dereferences the Account values with respect to the ledger at the time of transaction execution. If the address does not correspond to a funded AccountRoot node, then only the master secret associated with that address can be used to produce a valid signature. If the account does exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. A multi-signature cannot be used as a component of another multi-signature.
                          
 
                          SignerLists and Reserves
                          
-
                          A SignerList contributes to its owner's reserve requirement. The SignerList itself counts as two objects, and each member of the list counts as one, so that the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line (RippleState) or Offer node in the ledger.
                          
+
                          A SignerList contributes to its owner's reserve requirement. The SignerList itself counts as two objects, and each member of the list counts as one. As a result, the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line (RippleState) or Offer node in the ledger.
                      From 22b6033e96fd9d858641f49eda7b4048c8d29726 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 4 Apr 2016 15:02:52 -0700 Subject: [PATCH 28/40] tx format - alphabetize errors, etc. --- content/reference-transaction-format.md | 86 ++++---- reference-transaction-format.html | 280 ++++++++++++------------ 2 files changed, 186 insertions(+), 180 deletions(-) diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md index e4644abe3e..c7b72d5f16 100644 --- a/content/reference-transaction-format.md +++ b/content/reference-transaction-format.md @@ -90,7 +90,11 @@ In either case, signing a transaction generates a binary blob that can be submit } ``` -After a transaction has been submitted, if it gets accepted into a validated ledger, you can view the final transaction using the API. For example, here is what the WebSocket API [tx command](reference-rippled.html#tx) shows for the same transaction. The field names that begin with capital letters are part of the ledger object; the fields that begin with lower-case letters are additional information generated by the server for the request: +After a transaction has been submitted, you can check its status using the API, for example using the [tx command](reference-rippled.html#tx). + +**Caution:** The success of a transaction is not final unless the transaction appears in a **validated** ledger with the result code `tesSUCCESS`. See also: [Finality of Results](#finality-of-results). + +Example response from the `tx` command: ``` { @@ -1030,12 +1034,12 @@ These codes indicate an error in the local server processing the transaction; it | Code | Explanation | |------|-------------| -| telLOCAL_ERROR | Unspecified local error. | | telBAD\_DOMAIN | The transaction specified a domain value (for example, the `Domain` field of an [AccountSet transaction](#accountset)) that cannot be used, probably because it is too long to store in the ledger. | | telBAD\_PATH_COUNT | The transaction contains too many paths for the local server to process. | | telBAD\_PUBLIC\_KEY | The transaction specified a public key value (for example, as the `MessageKey` field of an [AccountSet transaction](#accountset)) that cannot be used, probably because it is too long. | | telFAILED\_PROCESSING | An unspecified error occurred when processing the transaction. | | telINSUF\_FEE_P | The `Fee` from the transaction is not high enough to meet the server's current [transaction cost](concept-transaction-cost.html) requirement, which is derived from its load level. | +| telLOCAL_ERROR | Unspecified local error. | | telNO\_DST\_PARTIAL | The transaction is an XRP payment that would fund a new account, but the [tfPartialPayment flag](#partial-payments) was enabled. This is disallowed. | ### tem Codes ### @@ -1044,7 +1048,6 @@ These codes indicate that the transaction was malformed, and cannot succeed acco | Code | Explanation | |------|-------------| -| temMALFORMED | Unspecified problem with the format of the transaction. | | temBAD\_AMOUNT | An amount specified by the transaction (for example the destination `Amount` or `SendMax` values of a [Payment](#payment)) was invalid, possibly because it was a negative number. | | temBAD\_AUTH\_MASTER | The key used to sign this transaction does not match the master key for the account sending it, and the account does not have a [Regular Key](#setregularkey) set. | | temBAD\_CURRENCY | The transaction improperly specified a currency field. See [Specifying Currency Amounts](reference-rippled.html#specifying-currency-amounts) for the correct format. | @@ -1068,6 +1071,7 @@ These codes indicate that the transaction was malformed, and cannot succeed acco | temDST\_NEEDED | The transaction improperly omitted a destination. This could be the `Destination` field of a [Payment](#payment) transaction, or the `issuer` sub-field of the `LimitAmount` field fo a `TrustSet` transaction. | | temINVALID | The transaction is otherwise invalid. For example, the transaction ID may not be the right format, the signature may not be formed properly, or something else went wrong in understanding the transaction. | | temINVALID\_FLAG | The transaction includes a [Flag](#flags) that does not exist, or includes a contradictory combination of flags. | +| temMALFORMED | Unspecified problem with the format of the transaction. | | temREDUNDANT | The transaction would accomplish nothing; for example, it is sending a payment directly to the sending account, or creating an offer to buy and sell the same currency from the same issuer. | | temREDUNDANT\_SEND\_MAX | _(Removed in [rippled 0.28.0][])_ | | temRIPPLE\_EMPTY | The [Payment](#payment) transaction includes an empty `Paths` field, but paths are necessary to complete this payment. | @@ -1085,23 +1089,23 @@ These codes indicate that the transaction failed to apply, but the transaction c | Code | Explanation | |------|-------------| -| tefFAILURE | Unspecified failure in applying the transaction. | | tefALREADY | The same exact transaction has already been applied. | -| tefBAD\_ADD\_AUTH | Deprecated. This code should never be returned. | +| tefBAD\_ADD\_AUTH | **DEPRECATED.** | | tefBAD\_AUTH | The key used to sign this account is not authorized to modify this account. (It could be authorized if the account had the same key set as the [Regular Key](#setregularkey).) | -| tefBAD\_LEDGER | While processing the transaction, the ledger was discovered in an unexpected state. If you can reproduce this error, please [file a bug](https://ripplelabs.atlassian.net/secure/CreateIssueDetails!init.jspa?pid=10800&issuetype=1) to get it fixed. | -| tefCREATED | Deprecated. This code should never be returned. | -| tefEXCEPTION | While processing the transaction, the server entered an unexpected state. This may be caused by unexpected inputs, for example if the binary data for the transaction is grossly malformed. If you can reproduce this error, please [file a bug](https://ripplelabs.atlassian.net/secure/CreateIssueDetails!init.jspa?pid=10800&issuetype=1) to get it fixed. | -| tefINTERNAL | While attempting to apply the transaction, the server entered an unexpected state. If you can reproduce this error, please [file a bug](https://ripplelabs.atlassian.net/secure/CreateIssueDetails!init.jspa?pid=10800&issuetype=1) to get it fixed. | -| tefNO\_AUTH\_REQUIRED | The [TrustSet](#trustset) transaction attempted to mark a trustline as authorized, but the `lsfRequireAuth` flag is not enabled for the corresponding account, so authorization is not necessary. | -| tefPAST\_SEQ | The sequence number of the transaction is lower than the current sequence number of the account sending the transaction. | -| tefWRONG\_PRIOR | The transaction contained an `AccountTxnID` field (or the deprecated `PreviousTxnID` field), but the transaction specified there does not match the account's previous transaction. | +| tefBAD\_AUTH\_MASTER | The single signature provided to authorize this transaction does not match the master key, but no regular key is associated with this address. | +| tefBAD\_LEDGER | While processing the transaction, the ledger was discovered in an unexpected state. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues) to get it fixed. | +| tefBAD\_QUORUM | The transaction was [multi-signed](#multi-signing), but the total weights of all included signatures did not meet the quorum. | +| tefBAD\_SIGNATURE | The transaction was [multi-signed](#multi-signing), but contained a signature for an address not part of a SignerList associated with the sending account. | +| tefCREATED |**DEPRECATED.** | +| tefEXCEPTION | While processing the transaction, the server entered an unexpected state. This may be caused by unexpected inputs, for example if the binary data for the transaction is grossly malformed. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues) to get it fixed. | +| tefFAILURE | Unspecified failure in applying the transaction. | +| tefINTERNAL | While attempting to apply the transaction, the server entered an unexpected state. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues) to get it fixed. | | tefMASTER\_DISABLED | The transaction was signed with the account's master key, but the account has the `lsfDisableMaster` field set. | | tefMAX\_LEDGER | The transaction included a [`LastLedgerSequence`](#lastledgersequence) parameter, but the current ledger's sequence number is already higher than the specified value. | -| tefBAD\_SIGNATURE | The transaction was [multi-signed](#multi-signing), but contained a signature for an address not part of a SignerList associated with the sending account. | -| tefBAD\_QUORUM | The transaction was [multi-signed](#multi-signing), but the total weights of all included signatures did not meet the quorum. | +| tefNO\_AUTH\_REQUIRED | The [TrustSet](#trustset) transaction attempted to mark a trustline as authorized, but the `lsfRequireAuth` flag is not enabled for the corresponding account, so authorization is not necessary. | | tefNOT\_MULTI\_SIGNING | The transaction was [multi-signed](#multi-signing), but the sending account has no SignerList defined. | -| tefBAD\_AUTH\_MASTER | The single signature provided to authorize this transaction does not match the master key, but no regular key is associated with this address. | +| tefPAST\_SEQ | The sequence number of the transaction is lower than the current sequence number of the account sending the transaction. | +| tefWRONG\_PRIOR | The transaction contained an `AccountTxnID` field (or the deprecated `PreviousTxnID` field), but the transaction specified there does not match the account's previous transaction. | ### ter Codes ### @@ -1109,16 +1113,16 @@ These codes indicate that the transaction failed to apply, but it could apply su | Code | Explanation | |------|-------------| -| terRETRY | Unspecified retriable error. | -| terFUNDS\_SPENT | Deprecated. This code should never be returned. | +| terFUNDS\_SPENT | **DEPRECATED.** | | terINSUF\_FEE\_B | The account sending the transaction does not have enough XRP to pay the `Fee` specified in the transaction. | -| terNO\_ACCOUNT | The account sending the transaction does not exist in the ledger (yet). | -| terNO\_AUTH | The transaction would involve adding currency issued by an account with `lsfRequireAuth` enabled to a trustline that is not authorized. For example, you placed an offer to buy a currency you aren't authorized to hold. | +| terLAST | Used internally only. This code should never be returned. | +| terNO\_ACCOUNT | The address sending the transaction is not funded in the ledger (yet). | +| terNO\_AUTH | The transaction would involve adding currency issued by an account with `lsfRequireAuth` enabled to a trust line that is not authorized. For example, you placed an offer to buy a currency you aren't authorized to hold. | | terNO\_LINE | Used internally only. This code should never be returned. | +| terNO\_RIPPLE | Used internally only. This code should never be returned. | | terOWNERS | The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the [`lsfRequireAuth`](#accountset-flags) flag if it has any trust lines or available offers. | | terPRE\_SEQ | The `Sequence` number of the current transaction is higher than the current sequence number of the account sending the transaction. | -| terLAST | Used internally only. This code should never be returned. | -| terNO\_RIPPLE | Used internally only. This code should never be returned. | +| terRETRY | Unspecified retriable error. | ### tes Success ### @@ -1135,35 +1139,35 @@ These codes indicate that the transaction failed, but it was applied to a ledger | Code | Value | Explanation | |------|-------|-------------| | tecCLAIM | 100 | Unspecified failure, with transaction cost destroyed. | -| tecPATH\_PARTIAL | 101 | The transaction failed because the provided paths did not have enough liquidity to send the full amount. | -| tecUNFUNDED\_ADD | 102 | **DEPRECATED.** | -| tecUNFUNDED\_OFFER | 103 | The [OfferCreate transaction](#offercreate) failed because the account creating the offer does not have any of the `TakerGets` currency. | -| tecUNFUNDED\_PAYMENT | 104 | The transaction failed because the sending account is trying to send more XRP than it holds, not counting the reserve. (See: [Reserves](concept-reserves.html)) | +| tecDIR\_FULL | 121 | The address sending the transaction cannot own any more objects in the ledger. | +| tecDST\_TAG\_NEEDED | 143 | The [Payment](#payment) transaction omitted a destination tag, but the destination account has the `lsfRequireDestTag` flag enabled. _(New in [rippled 0.28.0][])_ | | tecFAILED\_PROCESSING | 105 | An unspecified error occurred when processing the transaction. | -| tecDIR\_FULL | 121 | The "owners count" of the account sending the transaction is already maxed out. | +| 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. | +| 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`.) | +| tecNO\_AUTH | 134 | The transaction failed because it needs to add a balance on a trust line to an account with the `lsfRequireAuth` flag enabled, and that trust line has not been authorized. If the trust line does not exist at all, tecNO\_LINE occurs instead. | | tecNO\_DST | 124 | The account on the receiving end of the transaction does not exist. This includes Payment and TrustSet transaction types. (It could be created if it received sufficient XRP.) | | tecNO\_DST\_INSUF_XRP | 125 | The account on the receiving end of the transaction does not exist, and the transaction is not sending enough XRP to create it. | +| tecNO\_ENTRY | 140 | Reserved for future use. | +| tecNO\_ISSUER | 133 | The account specified in the `issuer` field of a currency amount does not exist. | +| tecNO\_LINE | 135 | The `TakerPays` field of the [OfferCreate transaction](#offercreate) specifies an asset whose issuer has `lsfRequireAuth` enabled, and the account making the offer does not have a trust line for that asset. (Normally, making an offer implicitly creates a trust line if necessary, but in this case it does not bother because you cannot hold the asset without authorization.) If the trust line exists, but is not authorized, `tecNO_AUTH` occurs instead. | | tecNO\_LINE\_INSUF\_RESERVE | 126 | 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 does not have a trust line to this account for the same currency. (See tecINSUF\_RESERVE\_LINE for the other case.) | | tecNO\_LINE\_REDUNDANT | 127 | The transaction failed because it attempted to set a trust line to its default state, but the trust line did not exist. | -| tecPATH\_DRY | 128 | The transaction failed because the provided paths did not have enough liquidity to send anything at all. This could mean that the source and destination accounts are not linked by trust lines. | -| tecUNFUNDED | 129 | **DEPRECATED.** Replaced by tecUNFUNDED\_OFFER and tecUNFUNDED\_PAYMENT. | -| 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`.) | +| tecNO\_PERMISSION | 139 | Reserved for future use. | | tecNO\_REGULAR\_KEY | 131 | The [AccountSet transaction](#accountset) tried to disable the master key, but the account does not have another way to [authorize transactions](#authorizing-transactions). If [multi-signing](#multi-signing) is enabled, this code is deprecated and `tecNO_ALTERNATIVE_KEY` is used instead. | -| tecOWNERS | 132 | The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the [`lsfRequireAuth`](#accountset-flags) flag if it has any trust lines or available offers. | -| tecNO\_ISSUER | 133 | The account specified in the `issuer` field of a currency amount does not exist. | -| tecNO\_AUTH | 134 | The transaction failed because it needs to add a balance on a trust line to an account with the `lsfRequireAuth` flag enabled, and that trust line has not been authorized. If the trust line does not exist at all, tecNO\_LINE occurs instead. | -| tecNO\_LINE | 135 | The `TakerPays` field of the [OfferCreate transaction](#offercreate) specifies an asset whose issuer has `lsfRequireAuth` enabled, and the account making the offer does not have a trust line for that asset. (Normally, making an offer implicitly creates a trust line if necessary, but in this case it does not bother because you cannot hold the asset without authorization.) If the trust line exists, but is not authorized, tecNO\_AUTH occurs instead. | -| tecFROZEN | 137 | The [OfferCreate transaction](#offercreate) failed because one or both of the assets involved are subject to a [global freeze](concept-freeze.html). | -| tecNO\_TARGET | 138 | **FORTHCOMING** Reserved for future features. | -| tecNO\_PERMISSION | 139 | **FORTHCOMING** Reserved for future features. | -| tecNO\_ENTRY | 140 | **FORTHCOMING** Reserved for future features. | -| 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. | -| 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))_ | -| tecDST\_TAG\_NEEDED | 143 | The [Payment](#payment) transaction omitted a destination tag, but the destination account has the `lsfRequireDestTag` flag enabled. _(New in [rippled 0.28.0][])_ | -| tecINTERNAL | 144 | Unspecified internal error, with transaction cost applied. This error code should not normally be returned. | +| tecNO\_TARGET | 138 | Reserved for future use. | | tecOVERSIZE | 145 | This transaction could not be processed, because attempted transaction processing created an excessively large amount of metadata. _(New in [rippled 0.29.0-hf1](https://github.com/ripple/rippled/releases/tag/0.29.0-hf1) )_ | +| tecOWNERS | 132 | The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the [`lsfRequireAuth`](#accountset-flags) flag if it has any trust lines or available offers. | +| tecPATH\_DRY | 128 | The transaction failed because the provided paths did not have enough liquidity to send anything at all. This could mean that the source and destination accounts are not linked by trust lines. | +| tecPATH\_PARTIAL | 101 | The transaction failed because the provided paths did not have enough liquidity to send the full amount. | +| tecUNFUNDED | 129 | **DEPRECATED.** Replaced by tecUNFUNDED\_OFFER and tecUNFUNDED\_PAYMENT. | +| tecUNFUNDED\_ADD | 102 | **DEPRECATED.** | +| tecUNFUNDED\_PAYMENT | 104 | The transaction failed because the sending account is trying to send more XRP than it holds, not counting the reserve. (See: [Reserves](concept-reserves.html)) | +| tecUNFUNDED\_OFFER | 103 | The [OfferCreate transaction](#offercreate) failed because the account creating the offer does not have any of the `TakerGets` currency. | ### tej Codes ### diff --git a/reference-transaction-format.html b/reference-transaction-format.html index 39ce97ec44..a8518aebb8 100644 --- a/reference-transaction-format.html +++ b/reference-transaction-format.html @@ -212,7 +212,9 @@ "tx_blob" : "120000240000000461D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000F732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74483046022100982064CDD3F052D22788DB30B52EEA8956A32A51375E72274E417328EBA31E480221008F522C9DB4B0F31E695AA013843958A10DE8F6BA7D6759BEE645F71A7EB240BE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754" } -

                      After a transaction has been submitted, if it gets accepted into a validated ledger, you can view the final transaction using the API. For example, here is what the WebSocket API tx command shows for the same transaction. The field names that begin with capital letters are part of the ledger object; the fields that begin with lower-case letters are additional information generated by the server for the request:

                      +

                      After a transaction has been submitted, you can check its status using the API, for example using the tx command.

                      +

                      Caution: The success of a transaction is not final unless the transaction appears in a validated ledger with the result code tesSUCCESS. See also: Finality of Results.

                      +

                      Example response from the tx command:

                      {
   "id": 6,
   "status": "success",
@@ -1631,10 +1633,6 @@
 
 
 
-telLOCAL_ERROR
-Unspecified local error.
-
-
 telBAD_DOMAIN
 The transaction specified a domain value (for example, the Domain field of an AccountSet transaction) that cannot be used, probably because it is too long to store in the ledger.
 
@@ -1655,6 +1653,10 @@
 The Fee from the transaction is not high enough to meet the server's current transaction cost requirement, which is derived from its load level.
 
 
+telLOCAL_ERROR
+Unspecified local error.
+
+
 telNO_DST_PARTIAL
 The transaction is an XRP payment that would fund a new account, but the tfPartialPayment flag was enabled. This is disallowed.
 
@@ -1671,10 +1673,6 @@
 
 
 
-temMALFORMED
-Unspecified problem with the format of the transaction.
-
-
 temBAD_AMOUNT
 An amount specified by the transaction (for example the destination Amount or SendMax values of a Payment) was invalid, possibly because it was a negative number.
 
@@ -1767,6 +1765,10 @@
 The transaction includes a Flag that does not exist, or includes a contradictory combination of flags.
 
 
+temMALFORMED
+Unspecified problem with the format of the transaction.
+
+
 temREDUNDANT
 The transaction would accomplish nothing; for example, it is sending a payment directly to the sending account, or creating an offer to buy and sell the same currency from the same issuer.
 
@@ -1815,48 +1817,48 @@
 
 
 
-tefFAILURE
-Unspecified failure in applying the transaction.
-
-
 tefALREADY
 The same exact transaction has already been applied.
 
 
 tefBAD_ADD_AUTH
-Deprecated. This code should never be returned.
+DEPRECATED.
 
 
 tefBAD_AUTH
 The key used to sign this account is not authorized to modify this account. (It could be authorized if the account had the same key set as the Regular Key.)
 
 
+tefBAD_AUTH_MASTER
+The single signature provided to authorize this transaction does not match the master key, but no regular key is associated with this address.
+
+
 tefBAD_LEDGER
-While processing the transaction, the ledger was discovered in an unexpected state. If you can reproduce this error, please file a bug to get it fixed.
+While processing the transaction, the ledger was discovered in an unexpected state. If you can reproduce this error, please report an issue to get it fixed.
+
+
+tefBAD_QUORUM
+The transaction was multi-signed, but the total weights of all included signatures did not meet the quorum.
+
+
+tefBAD_SIGNATURE
+The transaction was multi-signed, but contained a signature for an address not part of a SignerList associated with the sending account.
 
 
 tefCREATED
-Deprecated. This code should never be returned.
+DEPRECATED.
 
 
 tefEXCEPTION
-While processing the transaction, the server entered an unexpected state. This may be caused by unexpected inputs, for example if the binary data for the transaction is grossly malformed. If you can reproduce this error, please file a bug to get it fixed.
+While processing the transaction, the server entered an unexpected state. This may be caused by unexpected inputs, for example if the binary data for the transaction is grossly malformed. If you can reproduce this error, please report an issue to get it fixed.
+
+
+tefFAILURE
+Unspecified failure in applying the transaction.
 
 
 tefINTERNAL
-While attempting to apply the transaction, the server entered an unexpected state. If you can reproduce this error, please file a bug to get it fixed.
-
-
-tefNO_AUTH_REQUIRED
-The TrustSet transaction attempted to mark a trustline as authorized, but the lsfRequireAuth flag is not enabled for the corresponding account, so authorization is not necessary.
-
-
-tefPAST_SEQ
-The sequence number of the transaction is lower than the current sequence number of the account sending the transaction.
-
-
-tefWRONG_PRIOR
-The transaction contained an AccountTxnID field (or the deprecated PreviousTxnID field), but the transaction specified there does not match the account's previous transaction.
+While attempting to apply the transaction, the server entered an unexpected state. If you can reproduce this error, please report an issue to get it fixed.
 
 
 tefMASTER_DISABLED
@@ -1867,20 +1869,20 @@
 The transaction included a LastLedgerSequence parameter, but the current ledger's sequence number is already higher than the specified value.
 
 
-tefBAD_SIGNATURE
-The transaction was multi-signed, but contained a signature for an address not part of a SignerList associated with the sending account.
-
-
-tefBAD_QUORUM
-The transaction was multi-signed, but the total weights of all included signatures did not meet the quorum.
+tefNO_AUTH_REQUIRED
+The TrustSet transaction attempted to mark a trustline as authorized, but the lsfRequireAuth flag is not enabled for the corresponding account, so authorization is not necessary.
 
 
 tefNOT_MULTI_SIGNING
 The transaction was multi-signed, but the sending account has no SignerList defined.
 
 
-tefBAD_AUTH_MASTER
-The single signature provided to authorize this transaction does not match the master key, but no regular key is associated with this address.
+tefPAST_SEQ
+The sequence number of the transaction is lower than the current sequence number of the account sending the transaction.
+
+
+tefWRONG_PRIOR
+The transaction contained an AccountTxnID field (or the deprecated PreviousTxnID field), but the transaction specified there does not match the account's previous transaction.
 
 
 
@@ -1895,30 +1897,34 @@
 
 
 
-terRETRY
-Unspecified retriable error.
-
-
 terFUNDS_SPENT
-Deprecated. This code should never be returned.
+DEPRECATED.
 
 
 terINSUF_FEE_B
 The account sending the transaction does not have enough XRP to pay the Fee specified in the transaction.
 
 
+terLAST
+Used internally only. This code should never be returned.
+
+
 terNO_ACCOUNT
-The account sending the transaction does not exist in the ledger (yet).
+The address sending the transaction is not funded in the ledger (yet).
 
 
 terNO_AUTH
-The transaction would involve adding currency issued by an account with lsfRequireAuth enabled to a trustline that is not authorized. For example, you placed an offer to buy a currency you aren't authorized to hold.
+The transaction would involve adding currency issued by an account with lsfRequireAuth enabled to a trust line that is not authorized. For example, you placed an offer to buy a currency you aren't authorized to hold.
 
 
 terNO_LINE
 Used internally only. This code should never be returned.
 
 
+terNO_RIPPLE
+Used internally only. This code should never be returned.
+
+
 terOWNERS
 The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the lsfRequireAuth flag if it has any trust lines or available offers.
 
@@ -1927,12 +1933,8 @@
 The Sequence number of the current transaction is higher than the current sequence number of the account sending the transaction.
 
 
-terLAST
-Used internally only. This code should never be returned.
-
-
-terNO_RIPPLE
-Used internally only. This code should never be returned.
+terRETRY
+Unspecified retriable error.
 
 
 
@@ -1969,24 +1971,14 @@
 Unspecified failure, with transaction cost destroyed.
 
 
-tecPATH_PARTIAL
-101
-The transaction failed because the provided paths did not have enough liquidity to send the full amount.
+tecDIR_FULL
+121
+The address sending the transaction cannot own any more objects in the ledger.
 
 
-tecUNFUNDED_ADD
-102
-DEPRECATED.
-
-
-tecUNFUNDED_OFFER
-103
-The OfferCreate transaction failed because the account creating the offer does not have any of the TakerGets currency.
-
-
-tecUNFUNDED_PAYMENT
-104
-The transaction failed because the sending account is trying to send more XRP than it holds, not counting the reserve. (See: Reserves)
+tecDST_TAG_NEEDED
+143
+The Payment transaction omitted a destination tag, but the destination account has the lsfRequireDestTag flag enabled. (New in rippled 0.28.0)
 
 
 tecFAILED_PROCESSING
@@ -1994,9 +1986,9 @@
 An unspecified error occurred when processing the transaction.
 
 
-tecDIR_FULL
-121
-The "owners count" of the account sending the transaction is already maxed out.
+tecFROZEN
+137
+The OfferCreate transaction failed because one or both of the assets involved are subject to a global freeze.
 
 
 tecINSUF_RESERVE_LINE
@@ -2009,6 +2001,31 @@
 The transaction failed because the sending account does not have enough XRP to create a new Offer. (See: Reserves)
 
 
+tecINSUFFICIENT_RESERVE
+141
+The SignerListSet or other transaction would increase the reserve requirement higher than the sending account's balance. See 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. (New in rippled 0.28.0)
+
+
+tecNO_ALTERNATIVE_KEY
+130
+The transaction tried to remove the only available method of authorizing transactions. This could be a SetRegularKey transaction to remove the regular key, a SignerListSet transaction to delete a SignerList, or an AccountSet transaction to disable the master key. (Prior to rippled 0.30.0, this was called tecMASTER_DISABLED.)
+
+
+tecNO_AUTH
+134
+The transaction failed because it needs to add a balance on a trust line to an account with the lsfRequireAuth flag enabled, and that trust line has not been authorized. If the trust line does not exist at all, tecNO_LINE occurs instead.
+
+
 tecNO_DST
 124
 The account on the receiving end of the transaction does not exist. This includes Payment and TrustSet transaction types. (It could be created if it received sufficient XRP.)
@@ -2019,6 +2036,21 @@
 The account on the receiving end of the transaction does not exist, and the transaction is not sending enough XRP to create it.
 
 
+tecNO_ENTRY
+140
+Reserved for future use.
+
+
+tecNO_ISSUER
+133
+The account specified in the issuer field of a currency amount does not exist.
+
+
+tecNO_LINE
+135
+The TakerPays field of the OfferCreate transaction specifies an asset whose issuer has lsfRequireAuth enabled, and the account making the offer does not have a trust line for that asset. (Normally, making an offer implicitly creates a trust line if necessary, but in this case it does not bother because you cannot hold the asset without authorization.) If the trust line exists, but is not authorized, tecNO_AUTH occurs instead.
+
+
 tecNO_LINE_INSUF_RESERVE
 126
 The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: Reserves) This error occurs when the counterparty does not have a trust line to this account for the same currency. (See tecINSUF_RESERVE_LINE for the other case.)
@@ -2029,19 +2061,9 @@
 The transaction failed because it attempted to set a trust line to its default state, but the trust line did not exist.
 
 
-tecPATH_DRY
-128
-The transaction failed because the provided paths did not have enough liquidity to send anything at all. This could mean that the source and destination accounts are not linked by trust lines.
-
-
-tecUNFUNDED
-129
-DEPRECATED. Replaced by tecUNFUNDED_OFFER and tecUNFUNDED_PAYMENT.
-
-
-tecNO_ALTERNATIVE_KEY
-130
-The transaction tried to remove the only available method of authorizing transactions. This could be a SetRegularKey transaction to remove the regular key, a SignerListSet transaction to delete a SignerList, or an AccountSet transaction to disable the master key. (Prior to rippled 0.30.0, this was called tecMASTER_DISABLED.)
+tecNO_PERMISSION
+139
+Reserved for future use.
 
 
 tecNO_REGULAR_KEY
@@ -2049,70 +2071,50 @@
 The AccountSet transaction tried to disable the master key, but the account does not have another way to authorize transactions. If multi-signing is enabled, this code is deprecated and tecNO_ALTERNATIVE_KEY is used instead.
 
 
-tecOWNERS
-132
-The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the lsfRequireAuth flag if it has any trust lines or available offers.
-
-
-tecNO_ISSUER
-133
-The account specified in the issuer field of a currency amount does not exist.
-
-
-tecNO_AUTH
-134
-The transaction failed because it needs to add a balance on a trust line to an account with the lsfRequireAuth flag enabled, and that trust line has not been authorized. If the trust line does not exist at all, tecNO_LINE occurs instead.
-
-
-tecNO_LINE
-135
-The TakerPays field of the OfferCreate transaction specifies an asset whose issuer has lsfRequireAuth enabled, and the account making the offer does not have a trust line for that asset. (Normally, making an offer implicitly creates a trust line if necessary, but in this case it does not bother because you cannot hold the asset without authorization.) If the trust line exists, but is not authorized, tecNO_AUTH occurs instead.
-
-
-tecFROZEN
-137
-The OfferCreate transaction failed because one or both of the assets involved are subject to a global freeze.
-
-
 tecNO_TARGET
 138
-FORTHCOMING Reserved for future features.
-
-
-tecNO_PERMISSION
-139
-FORTHCOMING Reserved for future features.
-
-
-tecNO_ENTRY
-140
-FORTHCOMING Reserved for future features.
-
-
-tecINSUFFICIENT_RESERVE
-141
-The SignerListSet or other transaction would increase the reserve requirement higher than the sending account's balance. See SignerLists and Reserves for more information.
-
-
-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. (New in rippled 0.28.0)
-
-
-tecDST_TAG_NEEDED
-143
-The Payment transaction omitted a destination tag, but the destination account has the lsfRequireDestTag flag enabled. (New in rippled 0.28.0)
-
-
-tecINTERNAL
-144
-Unspecified internal error, with transaction cost applied. This error code should not normally be returned.
+Reserved for future use.
 
 
 tecOVERSIZE
 145
 This transaction could not be processed, because attempted transaction processing created an excessively large amount of metadata. (New in rippled 0.29.0-hf1 )
 
+
+tecOWNERS
+132
+The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the lsfRequireAuth flag if it has any trust lines or available offers.
+
+
+tecPATH_DRY
+128
+The transaction failed because the provided paths did not have enough liquidity to send anything at all. This could mean that the source and destination accounts are not linked by trust lines.
+
+
+tecPATH_PARTIAL
+101
+The transaction failed because the provided paths did not have enough liquidity to send the full amount.
+
+
+tecUNFUNDED
+129
+DEPRECATED. Replaced by tecUNFUNDED_OFFER and tecUNFUNDED_PAYMENT.
+
+
+tecUNFUNDED_ADD
+102
+DEPRECATED.
+
+
+tecUNFUNDED_PAYMENT
+104
+The transaction failed because the sending account is trying to send more XRP than it holds, not counting the reserve. (See: Reserves)
+
+
+tecUNFUNDED_OFFER
+103
+The OfferCreate transaction failed because the account creating the offer does not have any of the TakerGets currency.
+
 
 
 
                      tej Codes
                      

From c1d79696ff528e1a0fd2335a08ce0f1c6356f6b6 Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Mon, 4 Apr 2016 18:44:56 -0700
Subject: [PATCH 29/40] amendments - validator link; Ripple (the company)
 redundantly

---
 concept-amendments.html       | 4 ++--
 content/concept-amendments.md | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/concept-amendments.html b/concept-amendments.html
index 557e5eb657..9c381ec58c 100644
--- a/concept-amendments.html
+++ b/concept-amendments.html
@@ -135,7 +135,7 @@
 
                      The Amendments system provides a means of introducing new features to the decentralized Ripple consensus network without causing disruptions. The amendments system works by utilizing the core consensus process of the network to approve any changes by showing continuous support before those changes go into effect. An amendment normally requires 80% support for two weeks before it can apply.
                      
 
                      When an Amendment has been enabled, it applies permanently to all ledger versions after the one that included it. You cannot disable an Amendment, unless you introduce a new Amendment to do so.
                      
 
                      Background
                      
-
                      Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If only a portion of validators have upgraded to a new version of the software, this could cause anything from minor inconveniences to full outages. In the minor case, a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot build it using the transaction processing rules they already know. In the worst case, the consensus process might be unable to validate new ledger versions because servers with different rules could not reach a consensus on the exact ledger to build.
                      
+
                      Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If only a portion of validators (rippled servers participating in consensus) have upgraded to a new version of the software, this could cause anything from minor inconveniences to full outages. In the minor case, a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot build it using the transaction processing rules they already know. In the worst case, the consensus process might be unable to validate new ledger versions because servers with different rules could not reach a consensus on the exact ledger to build.
                      
 
                      Amendments provide a solution to this problem, so that new features can be enabled only when enough validators support those features.
                      
 
                      Users and businesses who rely on the Ripple Consensus Ledger can also use Amendments to provide advance notice of changes in transaction processing that might affect their business. However, API changes that do not impact transaction processing or the consensus process do not require Amendments.
                      
 
                      About Amendments
                      
@@ -162,7 +162,7 @@
 
                      Amendment Voting
                      
 
                      Operators of rippled validators can choose which amendments to support or reject using the feature command. This decides which amendments the validator votes for in the amendment process. By default, rippled votes in favor of every amendment it knows about.
                      
 
                      The operator of a rippled validator can "veto" an amendment. In this case, that validator never sends a vote in favor of the amendment. If enough servers veto an amendment, that prevents it from reaching consistent 80% support, so the amendment does not apply.
                      
-
                      As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. Currently, Ripple recommends only trusting the 5 default validators that Ripple (the company) operates. For now, trusting only those validators is sufficient to coordinate with Ripple on releasing new features.
                      
+
                      As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. Currently, Ripple (the company) recommends only trusting the 5 default validators that Ripple (the company) operates. For now, trusting only those validators is sufficient to coordinate with Ripple (the company) on releasing new features.
                      
 
                      Configuring Amendment Voting
                      
 
                      You can temporarily configure an amendment using the feature command. To make a persistent change to your server's support for an amendment, modify your server's rippled.cfg file.
                      
 
                      Use the [veto_amendments] stanza to list amendments you do not want the server to vote for. Each line should contain one amendment's unique ID, optionally followed by the short name for the amendment. For example:
                      
diff --git a/content/concept-amendments.md b/content/concept-amendments.md
index d2a59282a0..77a7fb9732 100644
--- a/content/concept-amendments.md
+++ b/content/concept-amendments.md
@@ -7,7 +7,7 @@ When an Amendment has been enabled, it applies permanently to all ledger version
 
 ## Background ##
 
-Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If only a portion of validators have upgraded to a new version of the software, this could cause anything from minor inconveniences to full outages. In the minor case, a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot build it using the transaction processing rules they already know. In the worst case, [the consensus process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/) might be unable to validate new ledger versions because servers with different rules could not reach a consensus on the exact ledger to build.
+Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If only a portion of _validators_ (`rippled` servers [participating in consensus](tutorial-rippled-setup.html#reasons-to-run-a-validator)) have upgraded to a new version of the software, this could cause anything from minor inconveniences to full outages. In the minor case, a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot build it using the transaction processing rules they already know. In the worst case, [the consensus process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/) might be unable to validate new ledger versions because servers with different rules could not reach a consensus on the exact ledger to build.
 
 Amendments provide a solution to this problem, so that new features can be enabled only when enough validators support those features.
 
@@ -48,7 +48,7 @@ Operators of `rippled` validators can choose which amendments to support or reje
 
 The operator of a `rippled` validator can "veto" an amendment. In this case, that validator never sends a vote in favor of the amendment. If enough servers veto an amendment, that prevents it from reaching consistent 80% support, so the amendment does not apply.
 
-As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. Currently, Ripple recommends only trusting the 5 default validators that Ripple (the company) operates. For now, trusting only those validators is sufficient to coordinate with Ripple on releasing new features.
+As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. Currently, Ripple (the company) recommends only trusting the 5 default validators that Ripple (the company) operates. For now, trusting only those validators is sufficient to coordinate with Ripple (the company) on releasing new features.
 
 ### Configuring Amendment Voting ###
 

From 10d1ca76a3d66273d323ae8ae4d93cf991f5a5ce Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Wed, 6 Apr 2016 19:15:20 -0700
Subject: [PATCH 30/40] tx cost - FeeEscalation changes (in progress)

---
 concept-transaction-cost.html       | 19 +++++++++++++++++--
 content/concept-transaction-cost.md | 24 ++++++++++++++++++++++--
 2 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/concept-transaction-cost.html b/concept-transaction-cost.html
index 9790422311..42fdea76f2 100644
--- a/concept-transaction-cost.html
+++ b/concept-transaction-cost.html
@@ -139,8 +139,23 @@
 
                      You can also query rippled for the current transaction cost.
                      
 
                      Beneficiaries of the Transaction Cost
                      
 
                      The transaction cost is not paid to any party: the XRP is irrevocably destroyed. Since no new XRP can ever be created, this makes XRP more scarce, and consequently benefits all holders of XRP by making XRP more valuable.
                      
-
                      Load Scaling
                      
-
                      Each rippled server independently scales the transaction cost based on its current load. If you submit a transaction with a Fee value that is lower than current load-based transaction cost of the rippled server, that server neither applies nor relays the transaction. (Note: If you submit a transaction through an admin connection, the server applies and relays the transaction as long as the transaction cost meets the overall minimum.) A transaction is very unlikely to survive the consensus process unless its Fee value meets the requirements of a majority of servers.
                      
+
                      Load Cost and Open Ledger Cost
                      
+
                      When the FeeEscalation amendment is enabled, there are two thresholds for the transaction cost:
                      
+
                        
+
                      • If the transaction cost does not meet a rippled server's load-based transaction cost threshold, the server ignores the transaction completely. (This logic is essentially unchanged with or without the amendment.)
                        • 
+
                      • If the transaction cost does not meet a rippled server's Open Ledger cost threshold, the queues the transaction for the next ledger.
                        • 
+
                      
+
                      This divides transactions into roughly three categories:
                      
+
                        
+
                      • Transactions that specify a transaction cost so low that they get rejected by the load-based transaction cost.
                        • 
+
                      • Transactions that specify a transaction cost high enough to be included in the current open ledger.
                        • 
+
                      • Transactions in between, which get queued for the next open ledger.
                        • 
+
                      
+
                      Local Load Cost
                      
+
                      Each rippled server maintains a cost threshold based on its current load. If you submit a transaction with a Fee value that is lower than current load-based transaction cost of the rippled server, that server neither applies nor relays the transaction. (Note: If you submit a transaction through an admin connection, the server applies and relays the transaction as long as the transaction cost meets the overall minimum.) A transaction is very unlikely to survive the consensus process unless its Fee value meets the requirements of a majority of servers.
                      
+
                      Open Ledger Cost
                      
+
                      A rippled server with the FeeEscalation amendment enabled has a second mechanism for enforcing the transaction cost, called the open ledger cost. The open ledger cost increases exponentially when an in-progress ledger has more transactions than the previous one, so that only transactions which pay more than the normal transaction cost can be included in the current open ledger.
                      
+
                      The open ledger cost requirement is proportional to the normal cost of the transaction, not the absolute transaction cost. Transaction types that have a higher-than-normal requirement, such as multi-signed transactions must pay more to meet the open ledger cost than transactions which have minimum transaction cost requirements.
                      
 
                      Querying the Transaction Cost
                      
 
                      The rippled APIs have two ways to query the transaction cost: the server_info command (intended for humans) and the server_state command (intended for machines).
                      
 
                      server_info
                      
diff --git a/content/concept-transaction-cost.md b/content/concept-transaction-cost.md
index cbd5971cf1..17a8c28f56 100644
--- a/content/concept-transaction-cost.md
+++ b/content/concept-transaction-cost.md
@@ -17,9 +17,29 @@ You can also [query `rippled` for the current transaction cost](#querying-the-tr
 The transaction cost is not paid to any party: the XRP is irrevocably destroyed. Since no new XRP can ever be created, this makes XRP more scarce, and consequently benefits all holders of XRP by making XRP more valuable.
 
 
-## Load Scaling ##
+## Load Cost and Open Ledger Cost ##
 
-Each `rippled` server independently scales the transaction cost based on its current load. If you submit a transaction with a `Fee` value that is lower than current load-based transaction cost of the `rippled` server, that server neither applies nor relays the transaction. (**Note:** If you submit a transaction through an [admin connection](reference-rippled.html#connecting-to-rippled), the server applies and relays the transaction as long as the transaction cost meets the overall minimum.) A transaction is very unlikely to survive [the consensus process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/) unless its `Fee` value meets the requirements of a majority of servers.
+When the [FeeEscalation amendment](concept-amendments.html#feeescalation) is enabled, there are two thresholds for the transaction cost:
+
+* If the transaction cost does not meet a `rippled` server's load-based transaction cost threshold, the server ignores the transaction completely. (This logic is essentially unchanged with or without the amendment.)
+* If the transaction cost does not meet a `rippled` server's Open Ledger cost threshold, the queues the transaction for the next ledger.
+
+This divides transactions into roughly three categories:
+
+* Transactions that specify a transaction cost so low that they get rejected by the load-based transaction cost.
+* Transactions that specify a transaction cost high enough to be included in the current open ledger.
+* Transactions in between, which get queued for the next open ledger.
+
+
+## Local Load Cost ##
+
+Each `rippled` server maintains a cost threshold based on its current load. If you submit a transaction with a `Fee` value that is lower than current load-based transaction cost of the `rippled` server, that server neither applies nor relays the transaction. (**Note:** If you submit a transaction through an [admin connection](reference-rippled.html#connecting-to-rippled), the server applies and relays the transaction as long as the transaction cost meets the overall minimum.) A transaction is very unlikely to survive [the consensus process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/) unless its `Fee` value meets the requirements of a majority of servers.
+
+## Open Ledger Cost ##
+
+A `rippled` server with the [FeeEscalation amendment](concept-amendments.html#feeescalation) enabled has a second mechanism for enforcing the transaction cost, called the _open ledger cost_. The open ledger cost increases exponentially when an in-progress ledger has more transactions than the previous one, so that only transactions which pay more than the normal transaction cost can be included in the current open ledger.
+
+The open ledger cost requirement is proportional to the normal cost of the transaction, not the absolute transaction cost. Transaction types that have a higher-than-normal requirement, such as [multi-signed transactions](reference-transaction-format.html#multi-signing) must pay more to meet the open ledger cost than transactions which have minimum transaction cost requirements.
 
 
 ## Querying the Transaction Cost ##

From d5a2928e748d906d715a05e02e29dc78135236e8 Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Fri, 8 Apr 2016 14:03:09 -0700
Subject: [PATCH 31/40] rippled - fee command

---
 content/reference-rippled.md | 173 ++++++++++++++++++++-
 reference-rippled.html       | 292 ++++++++++++++++++++++++++++++-----
 2 files changed, 425 insertions(+), 40 deletions(-)

diff --git a/content/reference-rippled.md b/content/reference-rippled.md
index cd85c03737..d18f7d94a5 100755
--- a/content/reference-rippled.md
+++ b/content/reference-rippled.md
@@ -8791,7 +8791,7 @@ Connecting to 127.0.0.1:5005
                "3ACB84BEE2C45556351FF60FD787D235C9CF5623FB8A35B01446B773598E7CC0",
                "0DD3A8DF69874148057F1F2BF305442FF2E89A76A08B4CC8C051E2ED69B874F3",
                "4AE9A9C4F12A5BD0355037DA40A0B145420A2168A9FEDE43E643BD13062F8ECE",
-               "08CBF8CFFEC207F5AC4E4F24BC447011FD8C79D25B344281FBFB4732D7058ED4",
+su               "08CBF8CFFEC207F5AC4E4F24BC447011FD8C79D25B344281FBFB4732D7058ED4",
                "779B2577C5C4BAED6657421448EA506BBF50F86BE363E0924127C4EA17A58BBE"
             ],
             "peers" : 2,
@@ -9018,6 +9018,176 @@ The response follows the [standard format](#response-formatting), with a success
 
 
 
+## fee ##
+[[Source]
                      ](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` method is an [admin command](#connecting-to-rippled) that cannot be run by unpriviledged users._
+
+#### Request Format ####
+An example of the request format:
+
+
+
+*WebSocket*
+
+```
+{
+  "id": "fee_websocket_example",
+  "command": "fee"
+}
+```
+
+*JSON-RPC*
+
+```
+{
+	"method": "fee",
+	"params": [{}]
+}
+```
+
+*Commandline*
+
+```
+#Syntax: fee
+rippled fee
+```
+
+
+
+The request does not include any parameters.
+
+#### Response Format ####
+
+An example of a successful response:
+
+
+
+*WebSocket*
+
+```
+{
+  "id": "fee_websocket_example",
+  "status": "success",
+  "type": "response",
+  "result": {
+    "current_ledger_size": "14",
+    "current_queue_size": "0",
+    "drops": {
+      "base_fee": "10",
+      "median_fee": "11000",
+      "minimum_fee": "10",
+      "open_ledger_fee": "10"
+    },
+    "expected_ledger_size": "24",
+    "levels": {
+      "median_level": "281600",
+      "minimum_level": "256",
+      "open_ledger_level": "256",
+      "reference_level": "256"
+    },
+    "max_queue_size": "480"
+  }
+}
+```
+
+*JSON-RPC*
+
+```
+200 OK
+{
+	"result": {
+		"current_ledger_size": "56",
+		"current_queue_size": "11",
+		"drops": {
+			"base_fee": "10",
+			"median_fee": "10000",
+			"minimum_fee": "10",
+			"open_ledger_fee": "2653937"
+		},
+		"expected_ledger_size": "55",
+		"levels": {
+			"median_level": "256000",
+			"minimum_level": "256",
+			"open_ledger_level": "67940792",
+			"reference_level": "256"
+		},
+		"max_queue_size": "1100",
+		"status": "success"
+	}
+}
+```
+
+*Commandline*
+
+```
+Loading: "/etc/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "current_ledger_size" : "16",
+      "current_queue_size" : "2",
+      "drops" : {
+         "base_fee" : "10",
+         "median_fee" : "11000",
+         "minimum_fee" : "10",
+         "open_ledger_fee" : "3203982"
+      },
+      "expected_ledger_size" : "15",
+      "levels" : {
+         "median_level" : "281600",
+         "minimum_level" : "256",
+         "open_ledger_level" : "82021944",
+         "reference_level" : "256"
+      },
+      "max_queue_size" : "300",
+      "status" : "success"
+   }
+}
+```
+
+
+
+The response follows the [standard format](#response-formatting), with a successful result containing the following fields:
+
+| Field                      | Type   | Description |
+|----------------------------|--------|-------------|
+| 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.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. |
+| drops.open\_ledger\_fee    | String (Integer) | The minimum transaction cost that a [reference transaction](#reference-transaction-cost) must pay to be included in the current open ledger. |
+| expected\_ledger\_size     | String (Integer) | The approximate number of transactions expected to be included in the current ledger. This is based on the number of transactions in the previous ledger. |
+| levels                     | Object | Various information about the transaction cost, in _fee levels_. The ratio in fee levels applies to any transaction relative to the minimum cost of that particular transaction. |
+| levels.median\_level       | String (Integer) | The median transaction cost among transactions in the previous validated ledger, represented in fee levels. |
+| levels.minimum\_level      | String (Integer) | The minimum transaction cost required to be queued for a future ledger.
+| levels.open\_ledger\_level | String (Integer) |
+| levels.reference\_level    | String (Integer) | The equivalent of the minimum transaction cost, represented in fee levels. |
+| max\_queue\_size           | String (Integer) |
+
+### Reference Transaction Cost ###
+
+The "Reference Transaction" is the cheapest possible transaction, in terms of the necessary [transaction cost](concept-transaction-cost.html). Most transactions have the same cost as the reference transaction. Some transactions, such as [multi-signed transactions](reference-transaction-format.html#multi-signing) require a multiple of this cost instead. When the open ledger cost escalates, the requirement is proportional to the basic cost of the transaction.
+
+### Fee Levels ###
+
+_Fee levels_ represent the proportional difference between the minimum cost and the actual cost of a transaction. See the following table for a comparison:
+
+|   | Fee Level | Reference Transaction (Most transactions) | Multi-signed transaction with 4 signatures |
+|---|-------------------------------------------|----------------------------------------------|
+| Minimum cost | 256 | 10 | 50 |
+| Double cost  | 512 | 20 | 100 |
+
+#### Possible Errors ####
+
+* Any of the [universal error types](#universal-errors).
+
+
+
 ## get_counts ##
 [[Source]
                      ](https://github.com/ripple/rippled/blob/c7118a183a660648aa88a3546a6b2c5bce858440/src/ripple/rpc/handlers/GetCounts.cpp "Source")
 
@@ -10681,3 +10851,4 @@ The response follows the [standard format](#response-formatting), with a success
 [version 0.29.0]: https://wiki.ripple.com/Rippled-0.29.0
 [version 0.30.0]: https://wiki.ripple.com/Rippled-0.30.0
 [version 0.30.1]: https://wiki.ripple.com/Rippled-0.30.1
+[version 0.31.0]: https://wiki.ripple.com/Rippled-0.31.0
diff --git a/reference-rippled.html b/reference-rippled.html
index eab1c1b1a7..103bd918c3 100644
--- a/reference-rippled.html
+++ b/reference-rippled.html
@@ -10300,7 +10300,7 @@ Connecting to 127.0.0.1:5005
                "3ACB84BEE2C45556351FF60FD787D235C9CF5623FB8A35B01446B773598E7CC0",
                "0DD3A8DF69874148057F1F2BF305442FF2E89A76A08B4CC8C051E2ED69B874F3",
                "4AE9A9C4F12A5BD0355037DA40A0B145420A2168A9FEDE43E643BD13062F8ECE",
-               "08CBF8CFFEC207F5AC4E4F24BC447011FD8C79D25B344281FBFB4732D7058ED4",
+su               "08CBF8CFFEC207F5AC4E4F24BC447011FD8C79D25B344281FBFB4732D7058ED4",
                "779B2577C5C4BAED6657421448EA506BBF50F86BE363E0924127C4EA17A58BBE"
             ],
             "peers" : 2,
@@ -10565,11 +10565,225 @@ Connecting to 127.0.0.1:5005
 
                    • Any of the universal error types.
                      • 
 
                    • badFeature - The feature specified was invalidly formatted, or the server does not know an amendment with that name.
                      •
                    +

                    fee

                    +

                    [Source]

                    +

                    The fee command reports the current state of the open-ledger requirements for the transaction cost. This requires the FeeEscalation amendment to be enabled. (New in version 0.31.0)

                    +

                    The fee method is an admin command that cannot be run by unpriviledged users.

                    +

                    Request Format

                    +

                    An example of the request format:

                    +
                    +

                    WebSocket

                    +
                    {
+  "id": "fee_websocket_example",
+  "command": "fee"
+}
+
                    +

                    JSON-RPC

                    +
                    {
+    "method": "fee",
+    "params": [{}]
+}
+
                    +

                    Commandline

                    +
                    #Syntax: fee
+rippled fee
+
                    +
                    +

                    The request does not include any parameters.

                    +

                    Response Format

                    +

                    An example of a successful response:

                    +
                    +

                    WebSocket

                    +
                    {
+  "id": "fee_websocket_example",
+  "status": "success",
+  "type": "response",
+  "result": {
+    "current_ledger_size": "14",
+    "current_queue_size": "0",
+    "drops": {
+      "base_fee": "10",
+      "median_fee": "11000",
+      "minimum_fee": "10",
+      "open_ledger_fee": "10"
+    },
+    "expected_ledger_size": "24",
+    "levels": {
+      "median_level": "281600",
+      "minimum_level": "256",
+      "open_ledger_level": "256",
+      "reference_level": "256"
+    },
+    "max_queue_size": "480"
+  }
+}
+
                    +

                    JSON-RPC

                    +
                    200 OK
+{
+    "result": {
+        "current_ledger_size": "56",
+        "current_queue_size": "11",
+        "drops": {
+            "base_fee": "10",
+            "median_fee": "10000",
+            "minimum_fee": "10",
+            "open_ledger_fee": "2653937"
+        },
+        "expected_ledger_size": "55",
+        "levels": {
+            "median_level": "256000",
+            "minimum_level": "256",
+            "open_ledger_level": "67940792",
+            "reference_level": "256"
+        },
+        "max_queue_size": "1100",
+        "status": "success"
+    }
+}
+
                    +

                    Commandline

                    +
                    Loading: "/etc/rippled.cfg"
+Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "current_ledger_size" : "16",
+      "current_queue_size" : "2",
+      "drops" : {
+         "base_fee" : "10",
+         "median_fee" : "11000",
+         "minimum_fee" : "10",
+         "open_ledger_fee" : "3203982"
+      },
+      "expected_ledger_size" : "15",
+      "levels" : {
+         "median_level" : "281600",
+         "minimum_level" : "256",
+         "open_ledger_level" : "82021944",
+         "reference_level" : "256"
+      },
+      "max_queue_size" : "300",
+      "status" : "success"
+   }
+}
+
                    +
                    +

                    The response follows the standard format, with a successful result containing the following fields:

                    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
                    FieldTypeDescription
                    current_ledger_sizeString (Integer)Number of transactions provisionally included in the in-progress ledger.
                    current_queue_sizeString (Integer)Number of transactions currently queued for the next ledger.
                    dropsObjectVarious information about the transaction cost (the Fee field of a transaction), in drops of xrp.
                    drops.base_feeString (Integer)The transaction cost required for a reference transaction to be included in a ledger under minimum load.
                    drops.median_feeString (Integer)An approximation of the median transaction cost among transactions included in the previous validated ledger.
                    drops.minimum_feeString (Integer)The minimum transaction cost for a reference transaction to be queued for a later ledger. If greater than base_fee, the transaction queue is full.
                    drops.open_ledger_feeString (Integer)The minimum transaction cost that a reference transaction must pay to be included in the current open ledger.
                    expected_ledger_sizeString (Integer)The approximate number of transactions expected to be included in the current ledger. This is based on the number of transactions in the previous ledger.
                    levelsObjectVarious information about the transaction cost, in fee levels. The ratio in fee levels applies to any transaction relative to the minimum cost of that particular transaction.
                    levels.median_levelString (Integer)The median transaction cost among transactions in the previous validated ledger, represented in fee levels.
                    levels.minimum_levelString (Integer)The minimum transaction cost required to be queued for a future ledger.
                    levels.open_ledger_levelString (Integer)
                    levels.reference_levelString (Integer)The equivalent of the minimum transaction cost, represented in fee levels.
                    max_queue_sizeString (Integer)
                    +

                    Reference Transaction Cost

                    +

                    The "Reference Transaction" is the cheapest possible transaction, in terms of the necessary transaction cost. Most transactions have the same cost as the reference transaction. Some transactions, such as multi-signed transactions require a multiple of this cost instead. When the open ledger cost escalates, the requirement is proportional to the basic cost of the transaction.

                    +

                    Fee Levels

                    +

                    Fee levels represent the proportional difference between the minimum cost and the actual cost of a transaction. See the following table for a comparison:

                    + + + + + + + + + + + + + + + + + + + + +
                    Fee LevelReference Transaction (Most transactions)
                    Minimum cost25610
                    Double cost51220
                    +

                    Possible Errors

                    +

                    get_counts

                    [Source]

                    The get_counts command provides various stats about the health of the server, mostly the number of objects of different types that it currently holds in memory.

                    The get_counts method is an admin command that cannot be run by unpriviledged users.

                    -

                    Request Format

                    +

                    Request Format

                    An example of the request format:

                    WebSocket

                    @@ -10611,7 +10825,7 @@ rippled get_counts 100 -

                    Response Format

                    +

                    Response Format

                    An example of a successful response:

                    JSON-RPC

                    @@ -10714,7 +10928,7 @@ Connecting to 127.0.0.1:5005

                    For most other entries, the value indicates the number of objects of that type currently in memory.

                    -

                    Possible Errors

                    +

                    Possible Errors

                    • Any of the universal error types.
                    • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
                      • @@ -10723,7 +10937,7 @@ Connecting to 127.0.0.1:5005

                      [Source]

                      The ledger_cleaner command controls the Ledger Cleaner, an asynchronous maintenance process that can find and repair corruption in rippled's database of ledgers.

                      The ledger_cleaner method is an admin command that cannot be run by unpriviledged users.

                      -

                      Request Format

                      +

                      Request Format

                      An example of the request format:

                      WebSocket

                      @@ -10782,7 +10996,7 @@ Connecting to 127.0.0.1:5005 -

                      Response Format

                      +

                      Response Format

                      An example of a successful response:

                      JSON-RPC

                      @@ -10813,7 +11027,7 @@ Connecting to 127.0.0.1:5005 -

                      Possible Errors

                      +

                      Possible Errors

                      • Any of the universal error types.
                      • internal if one the parameters was specified in a way that the server couldn't interpret. (This is a bug, and it should return invalidParams instead.)
                        • @@ -10822,7 +11036,7 @@ Connecting to 127.0.0.1:5005

                        [Source]

                        The log_level command changes the rippled server's logging verbosity, or returns the current logging level for each category (called a partition) of log messages.

                        The log_level method is an admin command that cannot be run by unpriviledged users.

                        -

                        Request Format

                        +

                        Request Format

                        An example of the request format:

                        WebSocket

                        @@ -10860,7 +11074,7 @@ rippled log_level PathRequest debug -

                        Response Format

                        +

                        Response Format

                        Examples of successful responses:

                        Commandline (set log level)

                        @@ -10952,7 +11166,7 @@ Connecting to 127.0.0.1:5005 -

                        Possible Errors

                        +

                        Possible Errors

                        • Any of the universal error types.
                        • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
                          • @@ -10961,7 +11175,7 @@ Connecting to 127.0.0.1:5005

                          [Source]

                          The logrotate command closes and reopens the log file. This is intended to facilitate log rotation on Linux file systems.

                          The logrotate method is an admin command that cannot be run by unpriviledged users.

                          -

                          Request Format

                          +

                          Request Format

                          An example of the request format:

                          WebSocket

                          @@ -10975,7 +11189,7 @@ Connecting to 127.0.0.1:5005

                          The request includes no parameters.

                          -

                          Response Format

                          +

                          Response Format

                          An example of a successful response:

                          JSON-RPC

                          @@ -11017,7 +11231,7 @@ Connecting to 127.0.0.1:5005 -

                          Possible Errors

                          +

                          Possible Errors

                          @@ -11025,7 +11239,7 @@ Connecting to 127.0.0.1:5005

                          [Source]

                          Use the validation_create command to generate the keys for a rippled validating node. Similar to the wallet_propose command, this command makes no real changes, but only generates a set of keys in the proper format.

                          The validation_create method is an admin command that cannot be run by unpriviledged users.

                          -

                          Request Format

                          +

                          Request Format

                          An example of the request format:

                          WebSocket

                          @@ -11068,7 +11282,7 @@ rippled validation_create "BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIR

                          Note: The security of your validator depends on the entropy of your seed. Do not use a secret value that is not sufficiently randomized for real business purposes. We recommend omitting the secret when generating new credentials for the first time.

                          -

                          Response Format

                          +

                          Response Format

                          An example of a successful response:

                          JSON-RPC

                          @@ -11121,7 +11335,7 @@ Connecting to 127.0.0.1:5005 -

                          Possible Errors

                          +

                          Possible Errors

                          • Any of the universal error types.
                          • badSeed - The request provided an invalid seed value. This usually means that the seed value appears to be a valid string of a different format, such as an account address or validation public key.
                            • @@ -11130,7 +11344,7 @@ Connecting to 127.0.0.1:5005

                            [Source]

                            The validation_seed command temporarily sets the secret value that rippled uses to sign validations. This value resets based on the config file when you restart the server.

                            The validation_seed request is an admin command that cannot be run by unpriviledged users!

                            -

                            Request Format

                            +

                            Request Format

                            An example of the request format:

                            WebSocket

                            @@ -11162,7 +11376,7 @@ rippled validation_seed 'BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIRE' -

                            Response Format

                            +

                            Response Format

                            An example of a successful response:

                            JSON-RPC

                            @@ -11216,7 +11430,7 @@ Connecting to 127.0.0.1:5005 -

                            Possible Errors

                            +

                            Possible Errors

                            • Any of the universal error types.
                            • badSeed - The request provided an invalid secret value. This usually means that the secret value appears to be a valid string of a different format, such as an account address or validation public key.
                              • @@ -11225,7 +11439,7 @@ Connecting to 127.0.0.1:5005

                              [Source]

                              The peers command returns a list of all other rippled servers currently connected to this one, including information on their connection and sync status.

                              The peers request is an admin command that cannot be run by unpriviledged users!

                              -

                              Request Format

                              +

                              Request Format

                              An example of the request format:

                              WebSocket

                              @@ -11239,7 +11453,7 @@ Connecting to 127.0.0.1:5005

                              The request includes no additional parameters.

                              -

                              Response Format

                              +

                              Response Format

                              An example of a successful response:

                              WebSocket

                              @@ -11699,7 +11913,7 @@ Connecting to 127.0.0.1:5005 -

                              Possible Errors

                              +

                              Possible Errors

                              @@ -11707,7 +11921,7 @@ Connecting to 127.0.0.1:5005

                              [Source]

                              The print command returns the current status of various internal subsystems, including peers, the ledger cleaner, and the resource manager.

                              The print request is an admin command that cannot be run by unpriviledged users!

                              -

                              Request Format

                              +

                              Request Format

                              An example of the request format:

                              WebSocket

                              @@ -11721,7 +11935,7 @@ Connecting to 127.0.0.1:5005

                              The request includes no parameters.

                              -

                              Response Format

                              +

                              Response Format

                              An example of a successful response:

                              Commandline

                              @@ -11910,7 +12124,7 @@ Connecting to 127.0.0.1:5005

                              The response follows the standard format. Additional fields in the result depend on the internal state of the rippled server. The results of this command are subject to change without notice.

                              -

                              Possible Errors

                              +

                              Possible Errors

                              @@ -11919,7 +12133,7 @@ Connecting to 127.0.0.1:5005

                              ping

                              [Source]

                              The ping command returns an acknowledgement, so that clients can test the connection status and latency.

                              -

                              Request Format

                              +

                              Request Format

                              An example of the request format:

                              WebSocket

                              @@ -11943,7 +12157,7 @@ rippled ping

                              Try it! >

                              The request includes no parameters.

                              -

                              Response Format

                              +

                              Response Format

                              An example of a successful response:

                              WebSocket

                              @@ -11964,14 +12178,14 @@ rippled ping

                              The response follows the standard format, with a successful result containing no fields. The client can measure the round-trip time from request to response as latency.

                              -

                              Possible Errors

                              +

                              Possible Errors

                              random

                              [Source]

                              The random command provides a random number to be used as a source of entropy for random number generation by clients.

                              -

                              Request Format

                              +

                              Request Format

                              An example of the request format:

                              WebSocket

                              @@ -11994,7 +12208,7 @@ rippled random

                              The request includes no parameters.

                              -

                              Response Format

                              +

                              Response Format

                              An example of a successful response:

                              WebSocket

                              @@ -12034,14 +12248,14 @@ rippled random -

                              Possible Errors

                              +

                              Possible Errors

                              • Any of the universal error types.
                              • internal - Some internal error occurred, possibly relating to the random number generator.

                              json

                              The json method is a proxy to running other commands, and accepts the parameters for the command as a JSON value. It is exclusive to the Commandline client, and intended for cases where the commandline syntax for specifying parameters is inadequate or undesirable.

                              -

                              Request Format

                              +

                              Request Format

                              An example of the request format:

                              Commandline

                              @@ -12049,7 +12263,7 @@ rippled random rippled -q json ledger_closed '{}'
                              -

                              Response Format

                              +

                              Response Format

                              An example of a successful response:

                              WebSocket

                              @@ -12067,7 +12281,7 @@ rippled -q json ledger_closed '{}'

                              [Source]

                              The connect command forces the rippled server to connect to a specific peer rippled server.

                              The connect request is an admin command that cannot be run by unpriviledged users!

                              -

                              Request Format

                              +

                              Request Format

                              An example of the request format:

                              WebSocket

                              @@ -12115,7 +12329,7 @@ rippled connect 192.170.145.88 51235 -

                              Response Format

                              +

                              Response Format

                              An example of a successful response:

                              JSON-RPC

                              @@ -12155,7 +12369,7 @@ Connecting to 127.0.0.1:5005 -

                              Possible Errors

                              +

                              Possible Errors

                              • Any of the universal error types.
                              • invalidParams - One or more fields are specified incorrectly, or one or more required fields are missing.
                                • @@ -12165,7 +12379,7 @@ Connecting to 127.0.0.1:5005

                                [Source]

                                Gracefully shuts down the server.

                                The stop request is an admin command that cannot be run by unpriviledged users!

                                -

                                Request Format

                                +

                                Request Format

                                An example of the request format:

                                WebSocket

                                @@ -12187,7 +12401,7 @@ Connecting to 127.0.0.1:5005

                                The request includes no parameters.

                                -

                                Response Format

                                +

                                Response Format

                                An example of a successful response:

                                JSON-RPC

                                @@ -12226,7 +12440,7 @@ Connecting to 127.0.0.1:5005 -

                                Possible Errors

                                +

                                Possible Errors

                                From 2e999d183d2bab35325b3d48b1d100775ce8bb55 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Fri, 8 Apr 2016 15:49:31 -0700 Subject: [PATCH 32/40] tx cost - feeescalation changes --- concept-transaction-cost.html | 19 ++++++++++++++----- content/concept-transaction-cost.md | 28 +++++++++++++++++++++++----- 2 files changed, 37 insertions(+), 10 deletions(-) diff --git a/concept-transaction-cost.html b/concept-transaction-cost.html index 42fdea76f2..50a592e578 100644 --- a/concept-transaction-cost.html +++ b/concept-transaction-cost.html @@ -142,22 +142,31 @@

                                Load Cost and Open Ledger Cost

                                When the FeeEscalation amendment is enabled, there are two thresholds for the transaction cost:

                                  -
                                • If the transaction cost does not meet a rippled server's load-based transaction cost threshold, the server ignores the transaction completely. (This logic is essentially unchanged with or without the amendment.)
                                  • -
                                • If the transaction cost does not meet a rippled server's Open Ledger cost threshold, the queues the transaction for the next ledger.
                                  • +
                                • If the transaction cost does not meet a rippled server's load-based transaction cost threshold, the server ignores the transaction completely. (This logic is essentially unchanged with or without the amendment.)
                                  • +
                                • If the transaction cost does not meet a rippled server's open ledger cost threshold, the queues the transaction for the next ledger.

                                This divides transactions into roughly three categories:

                                • Transactions that specify a transaction cost so low that they get rejected by the load-based transaction cost.
                                • Transactions that specify a transaction cost high enough to be included in the current open ledger.
                                  • -
                                • Transactions in between, which get queued for the next open ledger.
                                  • +
                                • Transactions in between, which get queued for the next open ledger.

                                Local Load Cost

                                Each rippled server maintains a cost threshold based on its current load. If you submit a transaction with a Fee value that is lower than current load-based transaction cost of the rippled server, that server neither applies nor relays the transaction. (Note: If you submit a transaction through an admin connection, the server applies and relays the transaction as long as the transaction cost meets the overall minimum.) A transaction is very unlikely to survive the consensus process unless its Fee value meets the requirements of a majority of servers.

                                Open Ledger Cost

                                -

                                A rippled server with the FeeEscalation amendment enabled has a second mechanism for enforcing the transaction cost, called the open ledger cost. The open ledger cost increases exponentially when an in-progress ledger has more transactions than the previous one, so that only transactions which pay more than the normal transaction cost can be included in the current open ledger.

                                +

                                A rippled server with the FeeEscalation amendment enabled has a second mechanism for enforcing the transaction cost, called the open ledger cost. The open ledger cost starts out equal to the minimum transaction cost, but increases exponentially when an in-progress ledger has more transactions than the previous one. Only transactions which pay more than the open ledger cost can be included in the current open ledger. +Transactions that do not meet the open ledger cost are queued for a following ledger instead.

                                The open ledger cost requirement is proportional to the normal cost of the transaction, not the absolute transaction cost. Transaction types that have a higher-than-normal requirement, such as multi-signed transactions must pay more to meet the open ledger cost than transactions which have minimum transaction cost requirements.

                                +

                                See also: Fee Escalation explanation in rippled repository.

                                +

                                Queued Transactions

                                +

                                (Requires the FeeEscalation amendment)

                                +

                                When rippled receives a transaction that meet the server's local load cost but not the open ledger cost, the server checks the transaction to see if it is "likely to succeed" in the following ledger. If so, the transaction goes into the transaction queue. Transactions that are "likely to succeed" are properly-formed and are authorized with valid signatures.

                                +

                                When the current open ledger closes and the server starts a new open ledger, the server starts taking transactions from the queue to include in the new open ledger. The transaction queue is sorted with the transactions that would pay the highest transaction cost first. Transactions that pay the same transaction cost are queued in the order the server receives them.

                                +

                                Note: As of rippled version 0.31.0, the transaction queue supports at most 1 transaction per sending address. This is expected to change in later versions.

                                +

                                Caution: The current implementation does not allow transactions with an AccountTxnID field in the transaction queue.

                                Querying the Transaction Cost

                                -

                                The rippled APIs have two ways to query the transaction cost: the server_info command (intended for humans) and the server_state command (intended for machines).

                                +

                                The rippled APIs have two ways to query the local load-based transaction cost: the server_info command (intended for humans) and the server_state command (intended for machines).

                                +

                                If the FeeEscalation amendment is enabled, you can use the fee command to check the open ledger cost.

                                server_info

                                The server_info command reports the unscaled minimum XRP cost, as of the previous ledger, as validated_ledger.base_fee_xrp, in the form of decimal XRP. The actual cost necessary to relay a transaction is scaled by multiplying that base_fee_xrp value by the load_factor parameter in the same response, which represents the server's current load level. In other words:

                                Current Transaction Cost in XRP = base_fee_xrp × load_factor

                                diff --git a/content/concept-transaction-cost.md b/content/concept-transaction-cost.md index 17a8c28f56..cc33214816 100644 --- a/content/concept-transaction-cost.md +++ b/content/concept-transaction-cost.md @@ -21,14 +21,14 @@ The transaction cost is not paid to any party: the XRP is irrevocably destroyed. When the [FeeEscalation amendment](concept-amendments.html#feeescalation) is enabled, there are two thresholds for the transaction cost: -* If the transaction cost does not meet a `rippled` server's load-based transaction cost threshold, the server ignores the transaction completely. (This logic is essentially unchanged with or without the amendment.) -* If the transaction cost does not meet a `rippled` server's Open Ledger cost threshold, the queues the transaction for the next ledger. +* If the transaction cost does not meet a `rippled` server's [load-based transaction cost threshold](#local-load-cost), the server ignores the transaction completely. (This logic is essentially unchanged with or without the amendment.) +* If the transaction cost does not meet a `rippled` server's [open ledger cost threshold](#open-ledger-cost), the queues the transaction for the next ledger. This divides transactions into roughly three categories: * Transactions that specify a transaction cost so low that they get rejected by the load-based transaction cost. * Transactions that specify a transaction cost high enough to be included in the current open ledger. -* Transactions in between, which get queued for the next open ledger. +* Transactions in between, which get [queued for the next open ledger](#queued-transactions). ## Local Load Cost ## @@ -37,14 +37,32 @@ Each `rippled` server maintains a cost threshold based on its current load. If y ## Open Ledger Cost ## -A `rippled` server with the [FeeEscalation amendment](concept-amendments.html#feeescalation) enabled has a second mechanism for enforcing the transaction cost, called the _open ledger cost_. The open ledger cost increases exponentially when an in-progress ledger has more transactions than the previous one, so that only transactions which pay more than the normal transaction cost can be included in the current open ledger. +A `rippled` server with the [FeeEscalation amendment](concept-amendments.html#feeescalation) enabled has a second mechanism for enforcing the transaction cost, called the _open ledger cost_. The open ledger cost starts out equal to the minimum transaction cost, but increases exponentially when an in-progress ledger has more transactions than the previous one. Only transactions which pay more than the open ledger cost can be included in the current open ledger. +Transactions that do not meet the open ledger cost are [queued for a following ledger](#queued-transactions) instead. The open ledger cost requirement is proportional to the normal cost of the transaction, not the absolute transaction cost. Transaction types that have a higher-than-normal requirement, such as [multi-signed transactions](reference-transaction-format.html#multi-signing) must pay more to meet the open ledger cost than transactions which have minimum transaction cost requirements. +See also: [Fee Escalation explanation in `rippled` repository](https://github.com/ripple/rippled/blob/release/src/ripple/app/misc/FeeEscalation.md). + +### Queued Transactions ### + +(Requires the [FeeEscalation amendment](concept-amendments.html#feeescalation)) + +When `rippled` receives a transaction that meet the server's local load cost but not the open ledger cost, the server checks the transaction to see if it is "likely to succeed" in the following ledger. If so, the transaction goes into the transaction queue. Transactions that are "likely to succeed" are properly-formed and are [authorized](reference-transaction-format.html#authorizing-transactions) with valid signatures. + +When the current open ledger closes and the server starts a new open ledger, the server starts taking transactions from the queue to include in the new open ledger. The transaction queue is sorted with the transactions that would pay the highest transaction cost first. Transactions that pay the same transaction cost are queued in the order the server receives them. + +**Note:** As of `rippled` **version 0.31.0**, the transaction queue supports at most 1 transaction per sending address. This is expected to change in later versions. + +**Caution:** The current implementation does not allow transactions with an `AccountTxnID` field in the transaction queue. + + ## Querying the Transaction Cost ## -The `rippled` APIs have two ways to query the transaction cost: the `server_info` command (intended for humans) and the `server_state` command (intended for machines). +The `rippled` APIs have two ways to query the local load-based transaction cost: the `server_info` command (intended for humans) and the `server_state` command (intended for machines). + +If the [FeeEscalation amendment](concept-amendments.html#feeescalation) is enabled, you can use the [`fee` command](reference-rippled.html#fee) to check the open ledger cost. ### server_info ### From 2a18ed14f696e42a118ec6ab4b08269dfc996a3c Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Fri, 8 Apr 2016 16:00:58 -0700 Subject: [PATCH 33/40] fix broken links --- concept-freeze.html | 2 +- content/concept-freeze.md | 2 +- content/reference-rippled.md | 4 ++-- content/reference-transaction-format.md | 8 ++++---- content/tutorial-multisign.md | 6 +++--- reference-rippled.html | 4 ++-- reference-transaction-format.html | 8 ++++---- tutorial-multisign.html | 6 +++--- 8 files changed, 20 insertions(+), 20 deletions(-) diff --git a/concept-freeze.html b/concept-freeze.html index 698212cc31..82a83f75f6 100644 --- a/concept-freeze.html +++ b/concept-freeze.html @@ -222,7 +222,7 @@ -

                                Set the Fee, Sequence, and LastLedgerSequence parameters in the typical way.

                                +

                                Set the Fee, Sequence, and LastLedgerSequence parameters in the typical way.

                                Example of submitting a TrustSet transaction to enable an individual freeze using the WebSocket API:

                                {
   "id": 12,
diff --git a/content/concept-freeze.md b/content/concept-freeze.md
index dfbcf5124c..bf3025deb7 100644
--- a/content/concept-freeze.md
+++ b/content/concept-freeze.md
@@ -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):
 
diff --git a/content/reference-rippled.md b/content/reference-rippled.md
index d18f7d94a5..1ec13b0ee3 100755
--- a/content/reference-rippled.md
+++ b/content/reference-rippled.md
@@ -9021,7 +9021,7 @@ The response follows the [standard format](#response-formatting), with a success
 ## fee ##
 [[Source]
                                ](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. |
diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md
index c7b72d5f16..69734c2288 100644
--- a/content/reference-transaction-format.md
+++ b/content/reference-transaction-format.md
@@ -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`.) |
diff --git a/content/tutorial-multisign.md b/content/tutorial-multisign.md
index f8c3160513..99dbc4dce0 100644
--- a/content/tutorial-multisign.md
+++ b/content/tutorial-multisign.md
@@ -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:
 
diff --git a/reference-rippled.html b/reference-rippled.html
index 103bd918c3..f65356d15b 100644
--- a/reference-rippled.html
+++ b/reference-rippled.html
@@ -10567,7 +10567,7 @@ Connecting to 127.0.0.1:5005

                              fee

                              [Source]

                              -

                              The fee command reports the current state of the open-ledger requirements for the transaction cost. This requires the FeeEscalation amendment 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. This requires the FeeEscalation amendment to be enabled. (New in version 0.31.0)

                              The fee method is an admin command that cannot be run by unpriviledged users.

                              Request Format

                              An example of the request format:

                              @@ -10691,7 +10691,7 @@ Connecting to 127.0.0.1:5005 drops Object -Various information about the transaction cost (the Fee field of a transaction), in drops of xrp. +Various information about the transaction cost (the Fee field of a transaction), in drops of xrp. drops.base_fee diff --git a/reference-transaction-format.html b/reference-transaction-format.html index a8518aebb8..5ac0fdd818 100644 --- a/reference-transaction-format.html +++ b/reference-transaction-format.html @@ -160,7 +160,7 @@
                              • 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.
                              • 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.
                                • -
                              • A multi-signature that matches a list of signers owned by the address. You can add, remove, or replace a list of signers using a SignerListSet transaction.
                                • +
                              • A multi-signature that matches a list of signers owned by the address. You can add, remove, or replace a list of signers using a SignerListSet transaction.

                              Any signature type can authorize any type of transaction, with the following exceptions:

                                @@ -517,7 +517,7 @@ -

                                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 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 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 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.

                                Flags

                                The Flags 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.

                                @@ -1267,7 +1267,7 @@

                                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 SignerQuorum to 0 and omit the SignerEntries field. Otherwise, the transaction fails with the error temMALFORMED. A transaction to delete a SignerList is considered successful even if there was no SignerList to delete.

                                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 SignerWeight values in the list. Otherwise, the transaction fails with the error temMALFORMED.

                                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 enabled) and the account does not have a Regular Key configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error tecNO_ALTERNATIVE_KEY.

                                +

                                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 enabled) and the account does not have a Regular Key configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error tecNO_ALTERNATIVE_KEY.

                                Pseudo-Transactions

                                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.

                                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:

                                @@ -2003,7 +2003,7 @@ tecINSUFFICIENT_RESERVE 141 -The SignerListSet or other transaction would increase the reserve requirement higher than the sending account's balance. See SignerLists and Reserves for more information. +The SignerListSet or other transaction would increase the reserve requirement higher than the sending account's balance. See SignerLists and Reserves for more information. tecINTERNAL diff --git a/tutorial-multisign.html b/tutorial-multisign.html index 45c041f64f..4cfb396ed5 100644 --- a/tutorial-multisign.html +++ b/tutorial-multisign.html @@ -138,7 +138,7 @@

                                To use multi-signing:

                                1. The Ripple peer-to-peer network must have multi-signing enabled.
                                  2. -
                                2. Set up a list of signers on your account.
                                  3. +
                                3. Set up a list of signers on your account.
                                4. Send transactions using multiple signatures.

                                Availability of Multi-Signing

                                @@ -322,10 +322,10 @@ Connecting to 127.0.0.1:5005
                              • Remove the address's regular key (if you previously set one) by sending a SetRegularKey transaction.

                              Sending a Multi-Signed Transaction

                              -

                              Before you can multi-sign a transaction, first set up multi-signing 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 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, 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 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, 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 increases in that time.

                              Here's an example transaction ready to be multi-signed:

                              {
     "TransactionType": "TrustSet",

From fd961521b8c8846fa0d7b58c950e960fbde9d49c Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Fri, 8 Apr 2016 16:07:47 -0700
Subject: [PATCH 34/40] rippled - fix errant 'su' chars

---
 content/reference-rippled.md | 2 +-
 reference-rippled.html       | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/content/reference-rippled.md b/content/reference-rippled.md
index 1ec13b0ee3..4d8a9ab8db 100755
--- a/content/reference-rippled.md
+++ b/content/reference-rippled.md
@@ -8791,7 +8791,7 @@ Connecting to 127.0.0.1:5005
                "3ACB84BEE2C45556351FF60FD787D235C9CF5623FB8A35B01446B773598E7CC0",
                "0DD3A8DF69874148057F1F2BF305442FF2E89A76A08B4CC8C051E2ED69B874F3",
                "4AE9A9C4F12A5BD0355037DA40A0B145420A2168A9FEDE43E643BD13062F8ECE",
-su               "08CBF8CFFEC207F5AC4E4F24BC447011FD8C79D25B344281FBFB4732D7058ED4",
+               "08CBF8CFFEC207F5AC4E4F24BC447011FD8C79D25B344281FBFB4732D7058ED4",
                "779B2577C5C4BAED6657421448EA506BBF50F86BE363E0924127C4EA17A58BBE"
             ],
             "peers" : 2,
diff --git a/reference-rippled.html b/reference-rippled.html
index f65356d15b..8e53a57891 100644
--- a/reference-rippled.html
+++ b/reference-rippled.html
@@ -10300,7 +10300,7 @@ Connecting to 127.0.0.1:5005
                "3ACB84BEE2C45556351FF60FD787D235C9CF5623FB8A35B01446B773598E7CC0",
                "0DD3A8DF69874148057F1F2BF305442FF2E89A76A08B4CC8C051E2ED69B874F3",
                "4AE9A9C4F12A5BD0355037DA40A0B145420A2168A9FEDE43E643BD13062F8ECE",
-su               "08CBF8CFFEC207F5AC4E4F24BC447011FD8C79D25B344281FBFB4732D7058ED4",
+               "08CBF8CFFEC207F5AC4E4F24BC447011FD8C79D25B344281FBFB4732D7058ED4",
                "779B2577C5C4BAED6657421448EA506BBF50F86BE363E0924127C4EA17A58BBE"
             ],
             "peers" : 2,

From fd94152c4fee865b9b53b757c32f6a7a01054b22 Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Fri, 8 Apr 2016 16:19:29 -0700
Subject: [PATCH 35/40] stand-alone mode - edit for tech review

---
 concept-stand-alone-mode.html       | 2 +-
 content/concept-stand-alone-mode.md | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/concept-stand-alone-mode.html b/concept-stand-alone-mode.html
index deef460c17..fe489e3c20 100644
--- a/concept-stand-alone-mode.html
+++ b/concept-stand-alone-mode.html
@@ -132,7 +132,7 @@
 
                              
 
                              
 
                              Stand-Alone Mode
                              
-
                              You can run rippled in stand-alone mode without a consensus of trusted servers. In stand-alone mode, rippled does not communicate with any other servers in the Ripple peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing rippled behavior, including the effects of Amendments before those Amendments have gone into effect across the decentralized network.
                              
+
                              You can run rippled in stand-alone mode without a consensus of trusted servers. In stand-alone mode, rippled does not communicate with any other servers in the Ripple peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing rippled behavior without being tied to the live network. For example, you can test the effects of Amendments before those Amendments have gone into effect across the decentralized network.
                              
 
                              When you run rippled in stand-alone mode, you have to tell it what ledger version to start from:
                              
 
                                
 
                              • Create a new genesis ledger from scratch.
                                • 
diff --git a/content/concept-stand-alone-mode.md b/content/concept-stand-alone-mode.md
index d652c297d9..f7ed2c06e8 100644
--- a/content/concept-stand-alone-mode.md
+++ b/content/concept-stand-alone-mode.md
@@ -1,7 +1,7 @@
 Stand-Alone Mode
 ===============================================================================
 
-You can run `rippled` in stand-alone mode without a consensus of trusted servers. In stand-alone mode, `rippled` does not communicate with any other servers in the Ripple peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing `rippled` behavior, including the effects of [Amendments](concept-amendments.html) before those Amendments have gone into effect across the decentralized network.
+You can run `rippled` in stand-alone mode without a consensus of trusted servers. In stand-alone mode, `rippled` does not communicate with any other servers in the Ripple peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing `rippled` behavior without being tied to the live network. For example, you can [test the effects of Amendments](concept-amendments.html#testing-amendments) before those Amendments have gone into effect across the decentralized network.
 
 When you run `rippled` in stand-alone mode, you have to tell it what ledger version to start from:
 

From 2db8f5800a4fa6cfcf38bc17fbee87b61954c6ae Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Fri, 8 Apr 2016 16:45:48 -0700
Subject: [PATCH 36/40] mark 0.31.0 features as new

---
 concept-amendments.html                 | 6 ++++--
 content/concept-amendments.md           | 8 ++++++--
 content/reference-ledger-format.md      | 2 +-
 content/reference-rippled.md            | 6 +++---
 content/reference-transaction-format.md | 2 +-
 content/tutorial-multisign.md           | 2 +-
 reference-ledger-format.html            | 2 +-
 reference-rippled.html                  | 6 +++---
 reference-transaction-format.html       | 2 +-
 tutorial-multisign.html                 | 2 +-
 10 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/concept-amendments.html b/concept-amendments.html
index 9c381ec58c..042c15e7d3 100644
--- a/concept-amendments.html
+++ b/concept-amendments.html
@@ -132,6 +132,7 @@
 
                                
 
                                
 
                                Amendments
                                
+
                                (New in version 0.31.0)
                                
 
                                The Amendments system provides a means of introducing new features to the decentralized Ripple consensus network without causing disruptions. The amendments system works by utilizing the core consensus process of the network to approve any changes by showing continuous support before those changes go into effect. An amendment normally requires 80% support for two weeks before it can apply.
                                
 
                                When an Amendment has been enabled, it applies permanently to all ledger versions after the one that included it. You cannot disable an Amendment, unless you introduce a new Amendment to do so.
                                
 
                                Background
                                
@@ -212,15 +213,16 @@ TrustSetAuth
 
 MultiSign
 v0.31.0
-Expected 2016-04-18
+TBD
 
 
 FeeEscalation
 v0.31.0
-Expected 2016-04-11
+TBD
 
 
 
+
                                Note: In many cases, an incomplete version of the code for an amendment is present in previous versions of the software. The "Introduced" version in the table above is the first stable version.
                                
 
                                FeeEscalation
                                
 
diff --git a/content/concept-amendments.md b/content/concept-amendments.md
index 77a7fb9732..5598a11146 100644
--- a/content/concept-amendments.md
+++ b/content/concept-amendments.md
@@ -1,5 +1,7 @@
 # Amendments #
 
+_(New in [version 0.31.0](https://wiki.ripple.com/Rippled-0.31.0))_
+
 The Amendments system provides a means of introducing new features to the decentralized Ripple consensus network without causing disruptions. The amendments system works by utilizing the core consensus process of the network to approve any changes by showing continuous support before those changes go into effect. An amendment normally requires **80% support for two weeks** before it can apply.
 
 When an Amendment has been enabled, it applies permanently to all ledger versions after the one that included it. You cannot disable an Amendment, unless you introduce a new Amendment to do so.
@@ -96,8 +98,10 @@ The following is a comprehensive list of all known amendments and their status o
 | [Tickets](#tickets)             | v0.31.0    | TBD |
 | [SusPay](#suspay)               | v0.31.0    | TBD |
 | [TrustSetAuth](#trustsetauth)   | v0.30.0    | TBD |
-| [MultiSign](#multisign)         | v0.31.0    | Expected 2016-04-18 |
-| [FeeEscalation](#feeescalation) | v0.31.0    | Expected 2016-04-11 |
+| [MultiSign](#multisign)         | v0.31.0    | TBD |
+| [FeeEscalation](#feeescalation) | v0.31.0    | TBD |
+
+**Note:** In many cases, an incomplete version of the code for an amendment is present in previous versions of the software. The "Introduced" version in the table above is the first stable version.
 
 ## FeeEscalation ##
 
diff --git a/content/reference-ledger-format.md b/content/reference-ledger-format.md
index 2fb0d0a4df..1f323f4dd8 100644
--- a/content/reference-ledger-format.md
+++ b/content/reference-ledger-format.md
@@ -408,7 +408,7 @@ The `index` of a RippleState node is the SHA-512Half of the following values put
 ## SignerList ##
 [[Source]
                                ](https://github.com/ripple/rippled/blob/6d2e3da30696bd10e3bb11a5ff6d45d2c4dae90f/src/ripple/protocol/impl/LedgerFormats.cpp#L127 "Source")
 
-The `SignerList` node type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account.
+The `SignerList` node type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. This node type is introduced by the [MultiSign amendment](concept-amendments.html#multisign). _(New in [version 0.31.0][])_
 
 Example SignerList node:
 
diff --git a/content/reference-rippled.md b/content/reference-rippled.md
index 4d8a9ab8db..fc573f4cb7 100755
--- a/content/reference-rippled.md
+++ b/content/reference-rippled.md
@@ -6304,7 +6304,7 @@ __*Caution:*__ If this command results in an error messages, the message can con
 
 The `sign_for` command provides one signature for a [multi-signed transaction](reference-transaction-format.html#multi-signing).
 
-This command requires the [MultiSign amendment](concept-amendments.html#multisign) to be enabled.
+This command requires the [MultiSign amendment](concept-amendments.html#multisign) to be enabled. _(New in [version 0.31.0][])_
 
 #### Request Format ####
 An example of the request format:
@@ -6766,7 +6766,7 @@ __*Caution:*__ If this command results in an error messages, the message can con
 
 The `submit_multisigned` command applies a [multi-signed](reference-transaction-format.html#multi-signing) transaction and sends it to the network to be included in future ledgers. (You can also submit multi-signed transactions in binary form using the [`submit` command in submit-only mode](#submit-only-mode).)
 
-This command requires the [MultiSign amendment](concept-amendments.html#multisign) to be enabled.
+This command requires the [MultiSign amendment](concept-amendments.html#multisign) to be enabled. _(New in [version 0.31.0][])_
 
 #### Request Format ####
 An example of the request format:
@@ -8830,7 +8830,7 @@ The fields describing a fetch in progress are subject to change without notice.
 ## feature ##
 [[Source]
                                ](https://github.com/ripple/rippled/blob/develop/src/ripple/rpc/handlers/Feature1.cpp "Source")
 
-The `feature` command returns information about [amendments](concept-amendments.html) this server knows about, including whether they are enabled and whether the server is voting in favor of those amendments in the [amendment process](concept-amendments.html#amendment-process).
+The `feature` command returns information about [amendments](concept-amendments.html) this server knows about, including whether they are enabled and whether the server is voting in favor of those amendments in the [amendment process](concept-amendments.html#amendment-process). _(New in [version 0.31.0][])_
 
 You can use the `feature` command to temporarily configure the server to vote against or in favor of an amendment. This change does not persist if you restart the server. To make lasting changes in amendment voting, use the `rippled.cfg` file. See [Configuring Amendment Voting](concept-amendments.html#configuring-amendment-voting) for more information.
 
diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md
index 69734c2288..0153d5adb4 100644
--- a/content/reference-transaction-format.md
+++ b/content/reference-transaction-format.md
@@ -792,7 +792,7 @@ Transactions of the TrustSet type support additional values in the [`Flags` fiel
 ## SignerListSet ##
 [[Source]
                                ](https://github.com/ripple/rippled/blob/ef511282709a6a0721b504c6b7703f9de3eecf38/src/ripple/app/tx/impl/SetSignerList.cpp "Source")
 
-The SignerListSet transaction creates, modifies, or removes a list of signers that can be used to [multi-sign](#multi-signing) a transaction.
+The SignerListSet transaction creates, replaces, or removes a list of signers that can be used to [multi-sign](#multi-signing) a transaction. This transaction type is introduced by the [MultiSign amendment](concept-amendments.html#multisign). _(New in [version 0.31.0][])_
 
 Example SignerListSet:
 
diff --git a/content/tutorial-multisign.md b/content/tutorial-multisign.md
index 99dbc4dce0..700b2dba84 100644
--- a/content/tutorial-multisign.md
+++ b/content/tutorial-multisign.md
@@ -20,7 +20,7 @@ To use multi-signing:
 Availability of Multi-Signing
 -----------------------------
 
-Multi-signing is built into `rippled` starting with version **0.31.0**. Because multi-signing is a change in transaction processing, the change is due to be enabled by an **Amendment** to the Ripple Consensus Protocol. This Amendment must be approved by a consensus of validators showing consistent support for the feature over a period of time. For more information, see [Amendments](concept-amendments.html).
+Multi-signing is built into `rippled` starting with [version 0.31.0](https://wiki.ripple.com/Rippled-0.31.0). Because multi-signing is a change in transaction processing, the change is due to be enabled by an **Amendment** to the Ripple Consensus Protocol. This Amendment must be approved by a consensus of validators showing consistent support for the feature over a period of time. For more information, see [Amendments](concept-amendments.html).
 
 If you want to test multi-signing before it becomes available in the production network, or without risking real money, you can do so by running `rippled` in [stand-alone mode](concept-stand-alone-mode.html) with the MultiSign feature enabled. To enable multi-signing for testing, add the following stanza to your `rippled.cfg`:
 
diff --git a/reference-ledger-format.html b/reference-ledger-format.html
index 7082230b21..2d4e79b3ae 100644
--- a/reference-ledger-format.html
+++ b/reference-ledger-format.html
@@ -985,7 +985,7 @@
 
                                SignerList
                                [Source]
                                
-
                                The SignerList node type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account.
                                
+
                                The SignerList node type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. This node type is introduced by the MultiSign amendment. (New in [version 0.31.0][])
                                Example SignerList node:
                                {
     "Flags": 0,
diff --git a/reference-rippled.html b/reference-rippled.html
index 8e53a57891..d2a322d6ba 100644
--- a/reference-rippled.html
+++ b/reference-rippled.html
@@ -7326,7 +7326,7 @@ rippled sign sssssssssssssssssssssssssssss '{"TransactionType": "Payment", "Acco
 
                                sign_for
                                
 
                                [Source]
                                
 
                                The sign_for command provides one signature for a multi-signed transaction.
                                
-
                                This command requires the MultiSign amendment to be enabled.
                                
+
                                This command requires the MultiSign amendment to be enabled. (New in version 0.31.0)
                                
 
                                Request Format
                                
 
                                An example of the request format:
                                
 
                                
@@ -7845,7 +7845,7 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r
 
                                submit_multisigned
                                
 
                                [Source]
                                
 
                                The submit_multisigned command applies a multi-signed transaction and sends it to the network to be included in future ledgers. (You can also submit multi-signed transactions in binary form using the submit command in submit-only mode.)
                                
-
                                This command requires the MultiSign amendment to be enabled.
                                
+
                                This command requires the MultiSign amendment to be enabled. (New in version 0.31.0)
                                
 
                                Request Format
                                
 
                                An example of the request format:
                                
 
                                
@@ -10377,7 +10377,7 @@ Connecting to 127.0.0.1:5005
 
 
                                feature
                                
 
                                [Source]
                                
-
                                The feature command returns information about amendments this server knows about, including whether they are enabled and whether the server is voting in favor of those amendments in the amendment process.
                                
+
                                The feature command returns information about amendments this server knows about, including whether they are enabled and whether the server is voting in favor of those amendments in the amendment process. (New in version 0.31.0)
                                
 
                                You can use the feature command to temporarily configure the server to vote against or in favor of an amendment. This change does not persist if you restart the server. To make lasting changes in amendment voting, use the rippled.cfg file. See Configuring Amendment Voting for more information.
                                
 
                                The feature method is an admin command that cannot be run by unpriviledged users.
                                
 
                                Request Format
                                
diff --git a/reference-transaction-format.html b/reference-transaction-format.html
index 5ac0fdd818..b34b094c43 100644
--- a/reference-transaction-format.html
+++ b/reference-transaction-format.html
@@ -1210,7 +1210,7 @@
 
                                
 
 
 
 
 
                                
 
                                SignerListSet
                                
 
                                [Source]
                                
-
                                The SignerListSet transaction creates, modifies, or removes a list of signers that can be used to multi-sign a transaction.
                                
+
                                The SignerListSet transaction creates, replaces, or removes a list of signers that can be used to multi-sign a transaction. This transaction type is introduced by the MultiSign amendment. (New in [version 0.31.0][])
                                
 
                                Example SignerListSet:
                                
 
                                {
     "Flags": 0,
diff --git a/tutorial-multisign.html b/tutorial-multisign.html
index 4cfb396ed5..5477428e40 100644
--- a/tutorial-multisign.html
+++ b/tutorial-multisign.html
@@ -142,7 +142,7 @@
 
                              • Send transactions using multiple signatures.
                                • 
 
 
                                Availability of Multi-Signing
                                
-
                                Multi-signing is built into rippled starting with version 0.31.0. Because multi-signing is a change in transaction processing, the change is due to be enabled by an Amendment to the Ripple Consensus Protocol. This Amendment must be approved by a consensus of validators showing consistent support for the feature over a period of time. For more information, see Amendments.
                                
+
                                Multi-signing is built into rippled starting with version 0.31.0. Because multi-signing is a change in transaction processing, the change is due to be enabled by an Amendment to the Ripple Consensus Protocol. This Amendment must be approved by a consensus of validators showing consistent support for the feature over a period of time. For more information, see Amendments.
                                
 
                                If you want to test multi-signing before it becomes available in the production network, or without risking real money, you can do so by running rippled in stand-alone mode with the MultiSign feature enabled. To enable multi-signing for testing, add the following stanza to your rippled.cfg:
                                
 
                                [features]
 MultiSign

From 2c806eed1fad5e16f80d2610c52a273bf81c21e3 Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Tue, 12 Apr 2016 13:49:40 -0700
Subject: [PATCH 37/40] tx cost - fee escalation revisions

---
 concept-transaction-cost.html       | 35 +++++++++++++++++++++++++----
 content/concept-transaction-cost.md | 23 +++++++++++++++----
 2 files changed, 50 insertions(+), 8 deletions(-)

diff --git a/concept-transaction-cost.html b/concept-transaction-cost.html
index 50a592e578..a40c17002d 100644
--- a/concept-transaction-cost.html
+++ b/concept-transaction-cost.html
@@ -135,15 +135,39 @@
 
                                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 transaction cost is designed to increase along with the load on the network, making it very expensive to deliberately or inadvertently overload the network.
                                
 
                                Every transaction must specify how much XRP it will destroy in order to pay the transaction cost.
                                
 
                                Current Transaction Cost
                                
-
                                The current transaction cost required by the network is typically 0.01 XRP (10,000 drops), although it sometimes increases due to network load.
                                
+
                                The current transaction cost required by the network for a standard transaction is typically 0.01 XRP (10,000 drops), although it sometimes increases due to network load.
                                
 
                                You can also query rippled for the current transaction cost.
                                
+
                                Special Transaction Costs
                                
+
                                Some transactions have different transaction costs:
                                
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                TransactionCost Before Load Scaling
                                Reference Transaction (Standard cost of most transactions)10 drops
                                Key Reset Transaction0
                                Multi-signed transaction10 drops × (1 + Number of Signatures Provided)
                                
 
                                Beneficiaries of the Transaction Cost
                                
 
                                The transaction cost is not paid to any party: the XRP is irrevocably destroyed. Since no new XRP can ever be created, this makes XRP more scarce, and consequently benefits all holders of XRP by making XRP more valuable.
                                
 
                                Load Cost and Open Ledger Cost
                                
 
                                When the FeeEscalation amendment is enabled, there are two thresholds for the transaction cost:
                                
 
                                  
 
                                • If the transaction cost does not meet a rippled server's load-based transaction cost threshold, the server ignores the transaction completely. (This logic is essentially unchanged with or without the amendment.)
                                  • 
-
                                • If the transaction cost does not meet a rippled server's open ledger cost threshold, the queues the transaction for the next ledger.
                                  • 
+
                                • If the transaction cost does not meet a rippled server's open ledger cost threshold, the server queues the transaction for a later ledger.
                                  • 
 
                                
 
                                This divides transactions into roughly three categories:
                                
 
                                  
@@ -160,7 +184,8 @@ Transactions that do not meet the open ledger cost are Fee Escalation explanation in rippled repository.
                                  
 
                                  Queued Transactions
                                  
 
                                  (Requires the FeeEscalation amendment)
                                  
-
                                  When rippled receives a transaction that meet the server's local load cost but not the open ledger cost, the server checks the transaction to see if it is "likely to succeed" in the following ledger. If so, the transaction goes into the transaction queue. Transactions that are "likely to succeed" are properly-formed and are authorized with valid signatures.
                                  
+
                                  When rippled receives a transaction that meet the server's local load cost but not the open ledger cost, the server checks the transaction to see if it is "likely to be included" in a later ledger. If so, the server adds the transaction to the transaction queue and relays the transaction to other members of the network. Otherwise, the server discards the transaction. The server tries minimize the amount of network load caused by transactions that would not pay a transaction cost, since the transaction cost only applies when a transaction is included in a validated ledger.
                                  
+
                                  The rippled server uses a variety of heuristics to determine which transactions are "likely to be included in a ledger."  Most importantly, those transactions must be properly-formed and authorized with valid signatures.
                                  
 
                                  When the current open ledger closes and the server starts a new open ledger, the server starts taking transactions from the queue to include in the new open ledger. The transaction queue is sorted with the transactions that would pay the highest transaction cost first. Transactions that pay the same transaction cost are queued in the order the server receives them.
                                  
 
                                  Note: As of rippled version 0.31.0, the transaction queue supports at most 1 transaction per sending address. This is expected to change in later versions.
                                  
 
                                  Caution: The current implementation does not allow transactions with an AccountTxnID field in the transaction queue.
                                  
@@ -185,10 +210,11 @@ Transactions that do not meet the open ledger cost are sign command to set a limit to the load scaling you are willing to sign.
+
                                • If you are using rippled, you can also use the fee_mult_max and fee_div_max parameters of the sign command to set a limit to the load scaling you are willing to sign.
                                  • 
 
                                
 
 
                              • You cannot look up the current transaction cost from an offline machine.
                                • 
+
                              • You cannot automatically specify the transaction cost when multi-signing.
                                • 
 
                              
 
                              Transaction Costs and Failed Transactions
                              
 
                              Since the purpose of the transaction cost is to protect the peer-to-peer Ripple network from excessive load, it should apply to any transaction that gets distributed to the network, regardless of whether or not that transaction succeeds. However, in order to affect the shared global ledger, a transaction must be included in a validated ledger. Thus, rippled servers attempt to include failed transactions in ledgers, with tec status codes ("tec" stands for "Transaction Engine - Claimed fee only").
                              
@@ -201,6 +227,7 @@ Transactions that do not meet the open ledger cost are SetRegularKey transaction with a transaction cost of 0, as long as the account's lsfPasswordSpent flag is disabled. This transaction must be signed by the account's master key. Sending this transaction enables the lsfPasswordSpent flag.
                              
 
                              This feature is designed to allow you to recover an account if the regular key is compromised, without worrying about whether the compromised account has any XRP available. This way, you can regain control of the account before you send additional XRP to it.
                              
 
                              The lsfPasswordSpent flag starts out disabled. If enabled, it gets disabled again when the account receives a Payment of XRP.
                              
+
                              When the FeeEscalation amendment is enabled, rippled prioritizes key reset transactions above other transactions even though the nominal transaction cost of a key reset transaction is zero.
                              
 
                              Changing the Transaction Cost
                              
 
                              In addition to short-term scaling to account for load, the Ripple Consensus Ledger has a mechanism for changing the minimum transaction cost in order to account for long-term changes in the value of XRP. Any changes have to be approved by the consensus process. See Fee Voting for more information.
                              
 
                              
diff --git a/content/concept-transaction-cost.md b/content/concept-transaction-cost.md
index cc33214816..359f19cef5 100644
--- a/content/concept-transaction-cost.md
+++ b/content/concept-transaction-cost.md
@@ -7,10 +7,20 @@ Every transaction must [specify how much XRP it will destroy](#specifying-the-tr
 
 ## Current Transaction Cost ##
 
-The current transaction cost required by the network is typically **0.01 XRP** (10,000 drops), although it sometimes increases due to network load.
+The current transaction cost required by the network for a standard transaction is typically **0.01 XRP** (10,000 drops), although it sometimes increases due to network load.
 
 You can also [query `rippled` for the current transaction cost](#querying-the-transaction-cost).
 
+### Special Transaction Costs ###
+
+Some transactions have different transaction costs:
+
+| Transaction           | Cost Before Load Scaling |
+|-----------------------|--------------------------|
+| Reference Transaction (Standard cost of most transactions) | 10 drops |
+| [Key Reset Transaction](#key-reset-transaction) | 0 |
+| [Multi-signed transaction](reference-transaction-format.html#multi-signing) | 10 drops × (1 + Number of Signatures Provided) |
+
 
 ## Beneficiaries of the Transaction Cost ##
 
@@ -22,7 +32,7 @@ The transaction cost is not paid to any party: the XRP is irrevocably destroyed.
 When the [FeeEscalation amendment](concept-amendments.html#feeescalation) is enabled, there are two thresholds for the transaction cost:
 
 * If the transaction cost does not meet a `rippled` server's [load-based transaction cost threshold](#local-load-cost), the server ignores the transaction completely. (This logic is essentially unchanged with or without the amendment.)
-* If the transaction cost does not meet a `rippled` server's [open ledger cost threshold](#open-ledger-cost), the queues the transaction for the next ledger.
+* If the transaction cost does not meet a `rippled` server's [open ledger cost threshold](#open-ledger-cost), the server queues the transaction for a later ledger.
 
 This divides transactions into roughly three categories:
 
@@ -48,7 +58,9 @@ See also: [Fee Escalation explanation in `rippled` repository](https://github.co
 
 (Requires the [FeeEscalation amendment](concept-amendments.html#feeescalation))
 
-When `rippled` receives a transaction that meet the server's local load cost but not the open ledger cost, the server checks the transaction to see if it is "likely to succeed" in the following ledger. If so, the transaction goes into the transaction queue. Transactions that are "likely to succeed" are properly-formed and are [authorized](reference-transaction-format.html#authorizing-transactions) with valid signatures.
+When `rippled` receives a transaction that meet the server's local load cost but not the open ledger cost, the server checks the transaction to see if it is "likely to be included" in a later ledger. If so, the server adds the transaction to the transaction queue and relays the transaction to other members of the network. Otherwise, the server discards the transaction. The server tries minimize the amount of network load caused by transactions that would not pay a transaction cost, since [the transaction cost only applies when a transaction is included in a validated ledger](#transaction-costs-and-failed-transactions).
+
+ The `rippled` server uses a variety of heuristics to determine which transactions are "likely to be included in a ledger."  Most importantly, those transactions must be properly-formed and [authorized](reference-transaction-format.html#authorizing-transactions) with valid signatures.
 
 When the current open ledger closes and the server starts a new open ledger, the server starts taking transactions from the queue to include in the new open ledger. The transaction queue is sorted with the transactions that would pay the highest transaction cost first. Transactions that pay the same transaction cost are queued in the order the server receives them.
 
@@ -95,8 +107,9 @@ When you sign a transaction online, you can omit the `Fee` field. In this case,
 * If the network's transaction cost goes up between signing and distributing the transaction, the transaction may not be confirmed.
     * In the worst case, the transaction may be stuck in a state of being neither definitively confirmed or rejected, unless it included a `LastLedgerSequence` parameter or until you cancel it with a new transaction that uses the same `Sequence` number. See [reliable transaction submission](tutorial-reliable-transaction-submission.html) for best practices.
 * You do not know in advance exactly what value you are signing for the `Fee` field.
-    * If you are using `rippled`, you can also use the `fee_mult_max` parameter of the [`sign` command](reference-rippled.html#sign) to set a limit to the load scaling you are willing to sign.
+    * If you are using `rippled`, you can also use the `fee_mult_max` and `fee_div_max` parameters of the [`sign` command](reference-rippled.html#sign) to set a limit to the load scaling you are willing to sign.
 * You cannot look up the current transaction cost from an offline machine.
+* You cannot automatically specify the transaction cost when [multi-signing](reference-transaction-format.html#multi-signing).
 
 
 
@@ -123,6 +136,8 @@ This feature is designed to allow you to recover an account if the regular key i
 
 The [lsfPasswordSpent flag](reference-ledger-format.html#accountroot-flags) starts out disabled. If enabled, it gets disabled again when the account receives a [Payment](reference-transaction-format.html#payment) of XRP.
 
+When the [FeeEscalation amendment](concept-amendments.html#feeescalation) is enabled, `rippled` prioritizes key reset transactions above other transactions even though the nominal transaction cost of a key reset transaction is zero.
+
 
 ## Changing the Transaction Cost ##
 

From 103a8f157c111632b8c04e33dbadd686c2425ca4 Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Tue, 12 Apr 2016 14:03:41 -0700
Subject: [PATCH 38/40] rippled - fee RPC edits

---
 content/reference-rippled.md | 23 ++++++++++----------
 reference-rippled.html       | 41 ++++++++++++++++++++++++------------
 2 files changed, 39 insertions(+), 25 deletions(-)

diff --git a/content/reference-rippled.md b/content/reference-rippled.md
index fc573f4cb7..f89e309979 100755
--- a/content/reference-rippled.md
+++ b/content/reference-rippled.md
@@ -9157,17 +9157,17 @@ 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-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. |
-| drops.open\_ledger\_fee    | String (Integer) | The minimum transaction cost that a [reference transaction](#reference-transaction-cost) must pay to be included in the current open ledger. |
+| 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, represented in drops of XRP. |
+| drops.median\_fee          | String (Integer) | An approximation of the median transaction cost among transactions included in the previous validated ledger, represented in drops of XRP. |
+| drops.minimum\_fee         | String (Integer) | The minimum transaction cost for a [reference transaction](#reference-transaction-cost) to be queued for a later ledger, represented in drops of XRP. If greater than `base_fee`, the transaction queue is full. |
+| drops.open\_ledger\_fee    | String (Integer) | The minimum transaction cost that a [reference transaction](#reference-transaction-cost) must pay to be included in the current open ledger, represented in drops of XRP. |
 | expected\_ledger\_size     | String (Integer) | The approximate number of transactions expected to be included in the current ledger. This is based on the number of transactions in the previous ledger. |
 | levels                     | Object | Various information about the transaction cost, in _fee levels_. The ratio in fee levels applies to any transaction relative to the minimum cost of that particular transaction. |
 | levels.median\_level       | String (Integer) | The median transaction cost among transactions in the previous validated ledger, represented in fee levels. |
-| levels.minimum\_level      | String (Integer) | The minimum transaction cost required to be queued for a future ledger.
-| levels.open\_ledger\_level | String (Integer) |
+| levels.minimum\_level      | String (Integer) | The minimum transaction cost required to be queued for a future ledger, represented in fee levels. |
+| levels.open\_ledger\_level | String (Integer) | The minimum transaction cost required to be included in the current open ledger, represented in fee levels. |
 | levels.reference\_level    | String (Integer) | The equivalent of the minimum transaction cost, represented in fee levels. |
-| max\_queue\_size           | String (Integer) |
+| max\_queue\_size           | String (Integer) | The maximum number of transactions that the [transaction queue](concept-transaction-cost.html#queued-transactions) can currently hold. |
 
 ### Reference Transaction Cost ###
 
@@ -9177,10 +9177,11 @@ The "Reference Transaction" is the cheapest possible transaction, in terms of th
 
 _Fee levels_ represent the proportional difference between the minimum cost and the actual cost of a transaction. See the following table for a comparison:
 
-|   | Fee Level | Reference Transaction (Most transactions) | Multi-signed transaction with 4 signatures |
-|---|-------------------------------------------|----------------------------------------------|
-| Minimum cost | 256 | 10 | 50 |
-| Double cost  | 512 | 20 | 100 |
+| Transaction | Minimum cost in drops | Minimum cost in Fee levels | Double cost in drops | Double cost in fee levels |
+|-------------|-----------------------|----------------------------|----------------------|---------------------------|
+| Reference transaction (most transactions) | 10 | 256 | 20 | 512 |
+| [Multi-signed transaction](reference-transaction-format.html#multi-signing) with 4 signatures | 50 | 256 | 100 | 512 |
+| [Key reset transaction](concept-transaction-cost.html#key-reset-transaction) | 0 | (Effectively infinite) | N/A | (Effectively infinite) |
 
 #### Possible Errors ####
 
diff --git a/reference-rippled.html b/reference-rippled.html
index d2a322d6ba..9e60715aeb 100644
--- a/reference-rippled.html
+++ b/reference-rippled.html
@@ -10696,22 +10696,22 @@ Connecting to 127.0.0.1:5005
 
 drops.base_fee
 String (Integer)
-The transaction cost required for a reference transaction to be included in a ledger under minimum load.
+The transaction cost required for a reference transaction to be included in a ledger under minimum load, represented in drops of XRP.
 
 
 drops.median_fee
 String (Integer)
-An approximation of the median transaction cost among transactions included in the previous validated ledger.
+An approximation of the median transaction cost among transactions included in the previous validated ledger, represented in drops of XRP.
 
 
 drops.minimum_fee
 String (Integer)
-The minimum transaction cost for a reference transaction to be queued for a later ledger. If greater than base_fee, the transaction queue is full.
+The minimum transaction cost for a reference transaction to be queued for a later ledger, represented in drops of XRP. If greater than base_fee, the transaction queue is full.
 
 
 drops.open_ledger_fee
 String (Integer)
-The minimum transaction cost that a reference transaction must pay to be included in the current open ledger.
+The minimum transaction cost that a reference transaction must pay to be included in the current open ledger, represented in drops of XRP.
 
 
 expected_ledger_size
@@ -10731,12 +10731,12 @@ Connecting to 127.0.0.1:5005
 
 levels.minimum_level
 String (Integer)
-The minimum transaction cost required to be queued for a future ledger.
+The minimum transaction cost required to be queued for a future ledger, represented in fee levels.
 
 
 levels.open_ledger_level
 String (Integer)
-
+The minimum transaction cost required to be included in the current open ledger, represented in fee levels.
 
 
 levels.reference_level
@@ -10746,7 +10746,7 @@ Connecting to 127.0.0.1:5005
 
 max_queue_size
 String (Integer)
-
+The maximum number of transactions that the transaction queue can currently hold.
 
 
 
@@ -10757,21 +10757,34 @@ Connecting to 127.0.0.1:5005
 
-
-
-
+
+
+
+
+
-
-
+
+
+
+
-
+
+
+
+
-
+
+
+
+
+
+
+
                              
 
 
                              Fee LevelReference Transaction (Most transactions)TransactionMinimum cost in dropsMinimum cost in Fee levelsDouble cost in dropsDouble cost in fee levels
 
                              
                               
 
 
                              Minimum cost256Reference transaction (most transactions)
 1025620512
 
                              
 
                              Double costMulti-signed transaction with 4 signatures50256100
 51220
                              Key reset transaction0(Effectively infinite)N/A(Effectively infinite)
 
                              
                               
 
                              

From be15bc4d02c6ba3a54d820ac06b5eb416f06b7ff Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Tue, 12 Apr 2016 14:04:08 -0700
Subject: [PATCH 39/40] multisign - tx&ledger format improvements

---
 content/reference-ledger-format.md      |  2 +-
 content/reference-transaction-format.md | 11 +++++++++++
 reference-ledger-format.html            |  2 +-
 reference-transaction-format.html       | 11 +++++++++++
 4 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/content/reference-ledger-format.md b/content/reference-ledger-format.md
index 1f323f4dd8..4ec642e406 100644
--- a/content/reference-ledger-format.md
+++ b/content/reference-ledger-format.md
@@ -408,7 +408,7 @@ The `index` of a RippleState node is the SHA-512Half of the following values put
 ## SignerList ##
 [[Source]
                              ](https://github.com/ripple/rippled/blob/6d2e3da30696bd10e3bb11a5ff6d45d2c4dae90f/src/ripple/protocol/impl/LedgerFormats.cpp#L127 "Source")
 
-The `SignerList` node type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. This node type is introduced by the [MultiSign amendment](concept-amendments.html#multisign). _(New in [version 0.31.0][])_
+The `SignerList` node type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. You can create, replace, or remove a SignerList using the [SignerListSet transaction type](reference-transaction-format.html#signerlistset) This node type is introduced by the [MultiSign amendment](concept-amendments.html#multisign). _(New in [version 0.31.0][])_
 
 Example SignerList node:
 
diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md
index 0153d5adb4..5bc199974a 100644
--- a/content/reference-transaction-format.md
+++ b/content/reference-transaction-format.md
@@ -191,6 +191,17 @@ Multi-signing in Ripple is the act of [authorizing transactions](#authorizing-tr
 
 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 control how many signatures are needed, in which combinations, by using the quorum and weight values of the SignerList.
 
+To successfully submit a multi-signed transaction, you must do all of the following:
+
+* The address sending the transaction (specified in the `Account` field) must own a [`SignerList` in the ledger](reference-ledger-format.html#signerlist).
+* The transaction must include the `SigningPubKey` field as an empty string.
+* The transaction must include a [`Signers` field](#signers-field) containing an array of signatures.
+* The signatures present in the `Signers` array must match signers defined in the SignerList.
+* For the provided signatures, the total `weight` associated with those signers must be equal or greater than the `quorum` for the SignerList.
+* The [transaction cost](concept-transaction-cost.html) (specified in the `Fee` field) must be at least (N+1) times the normal transaction cost, where N is the number of signatures provided.
+* All fields of the transaction must be defined before collecting signatures. You cannot [auto-fill](#auto-fillable-fields) any fields.
+* If presented in binary form, the `Signers` array must be sorted based on the numeric value of the signer addresses, with the lowest value first. (If submitted as JSON, the [`submit_multisigned` command](reference-rippled.html#submit-multisigned) handles this automatically.)
+
 For more information, see [How to Multi-Sign](tutorial-multisign.html).
 
 
diff --git a/reference-ledger-format.html b/reference-ledger-format.html
index 2d4e79b3ae..beed515048 100644
--- a/reference-ledger-format.html
+++ b/reference-ledger-format.html
@@ -985,7 +985,7 @@

                            SignerList

                            [Source]

                            -

                            The SignerList node type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. This node type is introduced by the MultiSign amendment. (New in [version 0.31.0][])

                            +

                            The SignerList node type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. You can create, replace, or remove a SignerList using the SignerListSet transaction type This node type is introduced by the MultiSign amendment. (New in [version 0.31.0][])

                            Example SignerList node:

                            {
     "Flags": 0,
diff --git a/reference-transaction-format.html b/reference-transaction-format.html
index b34b094c43..206b7ba4e3 100644
--- a/reference-transaction-format.html
+++ b/reference-transaction-format.html
@@ -304,6 +304,17 @@
 
                            Multi-Signing
                            
 
                            Multi-signing in Ripple is the act of 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 to the Ripple Consensus Protocol. You can have any combination of authorization methods enabled for your address, including multi-signing, a master key, and a regular key. (The only requirement is that at least one method must be enabled.)
                            
 
                            The SignerListSet transaction defines which addresses can authorize transactions from your address. You can include up to 8 addresses in a SignerList. You can control how many signatures are needed, in which combinations, by using the quorum and weight values of the SignerList.
                            
+
                            To successfully submit a multi-signed transaction, you must do all of the following:
                            
+
                              
+
                            • The address sending the transaction (specified in the Account field) must own a SignerList in the ledger.
                              • 
+
                            • The transaction must include the SigningPubKey field as an empty string.
                              • 
+
                            • The transaction must include a Signers field containing an array of signatures.
                              • 
+
                            • The signatures present in the Signers array must match signers defined in the SignerList.
                              • 
+
                            • For the provided signatures, the total weight associated with those signers must be equal or greater than the quorum for the SignerList.
                              • 
+
                            • The transaction cost (specified in the Fee field) must be at least (N+1) times the normal transaction cost, where N is the number of signatures provided.
                              • 
+
                            • All fields of the transaction must be defined before collecting signatures. You cannot auto-fill any fields.
                              • 
+
                            • If presented in binary form, the Signers array must be sorted based on the numeric value of the signer addresses, with the lowest value first. (If submitted as JSON, the submit_multisigned command handles this automatically.)
                              • 
+
                            
 
                            For more information, see How to Multi-Sign.
                            
 
                            Reliable Transaction Submission
                            
 
                            Reliably submitting transactions is the process of achieving both of the following:
                            

From ae07e94f743d8176fca106ae1e5a92432d3e15f5 Mon Sep 17 00:00:00 2001
From: mDuo13 
Date: Tue, 12 Apr 2016 15:34:12 -0700
Subject: [PATCH 40/40] tx cost - more wording precision!

---
 concept-transaction-cost.html       | 4 ++--
 content/concept-transaction-cost.md | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/concept-transaction-cost.html b/concept-transaction-cost.html
index a40c17002d..0fa0efff1b 100644
--- a/concept-transaction-cost.html
+++ b/concept-transaction-cost.html
@@ -173,7 +173,7 @@
 
                              
 
                            • Transactions that specify a transaction cost so low that they get rejected by the load-based transaction cost.
                              • 
 
                            • Transactions that specify a transaction cost high enough to be included in the current open ledger.
                              • 
-
                            • Transactions in between, which get queued for the next open ledger.
                              • 
+
                            • Transactions in between, which get queued for a later ledger version.
                              • 
 
                            
 
                            Local Load Cost
                            
 
                            Each rippled server maintains a cost threshold based on its current load. If you submit a transaction with a Fee value that is lower than current load-based transaction cost of the rippled server, that server neither applies nor relays the transaction. (Note: If you submit a transaction through an admin connection, the server applies and relays the transaction as long as the transaction cost meets the overall minimum.) A transaction is very unlikely to survive the consensus process unless its Fee value meets the requirements of a majority of servers.
                            
@@ -186,7 +186,7 @@ Transactions that do not meet the open ledger cost are FeeEscalation amendment)
                            
 
                            When rippled receives a transaction that meet the server's local load cost but not the open ledger cost, the server checks the transaction to see if it is "likely to be included" in a later ledger. If so, the server adds the transaction to the transaction queue and relays the transaction to other members of the network. Otherwise, the server discards the transaction. The server tries minimize the amount of network load caused by transactions that would not pay a transaction cost, since the transaction cost only applies when a transaction is included in a validated ledger.
                            
 
                            The rippled server uses a variety of heuristics to determine which transactions are "likely to be included in a ledger."  Most importantly, those transactions must be properly-formed and authorized with valid signatures.
                            
-
                            When the current open ledger closes and the server starts a new open ledger, the server starts taking transactions from the queue to include in the new open ledger. The transaction queue is sorted with the transactions that would pay the highest transaction cost first. Transactions that pay the same transaction cost are queued in the order the server receives them.
                            
+
                            When the current open ledger closes and the server starts a new open ledger, the server starts taking transactions from the queue to include in the new open ledger. The transaction queue is sorted with the transactions that would pay the highest transaction cost first, proportional to the un-scaled cost of those transactions. Transactions that pay the same transaction cost are queued in the order the server receives them.
                            
 
                            Note: As of rippled version 0.31.0, the transaction queue supports at most 1 transaction per sending address. This is expected to change in later versions.
                            
 
                            Caution: The current implementation does not allow transactions with an AccountTxnID field in the transaction queue.
                            
 
                            Querying the Transaction Cost
                            
diff --git a/content/concept-transaction-cost.md b/content/concept-transaction-cost.md
index 359f19cef5..35831eec2b 100644
--- a/content/concept-transaction-cost.md
+++ b/content/concept-transaction-cost.md
@@ -38,7 +38,7 @@ This divides transactions into roughly three categories:
 
 * Transactions that specify a transaction cost so low that they get rejected by the load-based transaction cost.
 * Transactions that specify a transaction cost high enough to be included in the current open ledger.
-* Transactions in between, which get [queued for the next open ledger](#queued-transactions).
+* Transactions in between, which get [queued for a later ledger version](#queued-transactions).
 
 
 ## Local Load Cost ##
@@ -62,7 +62,7 @@ When `rippled` receives a transaction that meet the server's local load cost but
 
  The `rippled` server uses a variety of heuristics to determine which transactions are "likely to be included in a ledger."  Most importantly, those transactions must be properly-formed and [authorized](reference-transaction-format.html#authorizing-transactions) with valid signatures.
 
-When the current open ledger closes and the server starts a new open ledger, the server starts taking transactions from the queue to include in the new open ledger. The transaction queue is sorted with the transactions that would pay the highest transaction cost first. Transactions that pay the same transaction cost are queued in the order the server receives them.
+When the current open ledger closes and the server starts a new open ledger, the server starts taking transactions from the queue to include in the new open ledger. The transaction queue is sorted with the transactions that would pay the highest transaction cost first, proportional to the un-scaled cost of those transactions. Transactions that pay the same transaction cost are queued in the order the server receives them.
 
 **Note:** As of `rippled` **version 0.31.0**, the transaction queue supports at most 1 transaction per sending address. This is expected to change in later versions.