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.
+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.
Caution: This method may return a very large amount of data (more than 1 megabyte), which may cause poor performance in your client application.
+Caution: This method may return a very large amount of data (more than 1 megabyte), which may cause poor performance in your client application.
Request:
GET /v2/reports/2015-08-19T00:00:00Z?accounts=true&payments=true
@@ -4195,7 +4198,7 @@
Get Validator Validations
Retrieve validation votes signed by a specified validator, including votes for ledger versions that are outside the main ledger chain. (New in v2.2.0)
-Note: The Data API does not have a comprehensive record of all validations. The response only includes data that the Data API has recorded. Some ledger versions, especially older ledgers, may have no validations even if they were validated by consensus.
+Note: The Data API does not have a comprehensive record of all validations. The response only includes data that the Data API has recorded. Some ledger versions, especially older ledgers, may have no validations even if they were validated by consensus.
Request Format
@@ -4334,7 +4337,7 @@
Get Validations
Retrieve validation votes, including votes for ledger versions that are outside the main ledger chain. (New in v2.2.0)
-Note: The Data API does not have a comprehensive record of all validations. The response only includes data that the Data API has recorded. Some ledger versions, especially older ledgers, may have no validations even if they were validated by consensus.
+Note: The Data API does not have a comprehensive record of all validations. The response only includes data that the Data API has recorded. Some ledger versions, especially older ledgers, may have no validations even if they were validated by consensus.
Request Format
@@ -7404,7 +7407,7 @@ Content-Type: image/svg+xml
Hexadecimal character set: 0-9 and A-F.
Typically written in upper case.
-Note: SHA-512Half has similar security to the officially-defined SHA-512/256 hash function. However, Ripple's usage predates SHA-512/256 and is also easier to implement on top of an existing SHA-512 function. (As of this writing, SHA-512 support in cryptographic libraries is much more common than for SHA-512/256.)
+Note: SHA-512Half has similar security to the officially-defined SHA-512/256 hash function. However, Ripple's usage predates SHA-512/256 and is also easier to implement on top of an existing SHA-512 function. (As of this writing, SHA-512 support in cryptographic libraries is much more common than for SHA-512/256.)
Timestamps
All dates and times are written in ISO 8601 Timestamp Format, using UTC. This format is summarized as:
YYYY-MM-DDThh:mm:ssZ
@@ -7575,7 +7578,7 @@ Content-Type: image/svg+xml
Note: Ledger close times are approximate, typically rounded to about 10 seconds. Two ledgers could have the same close_time values, when their actual close times were several seconds apart. The sequence number (ledger_index) of the ledger makes it unambiguous which ledger closed first.
Note: Ledger close times are approximate, typically rounded to about 10 seconds. Two ledgers could have the same close_time values, when their actual close times were several seconds apart. The sequence number (ledger_index) of the ledger makes it unambiguous which ledger closed first.
Due to a mishap early in Ripple's history, ledgers 1 through 32569 were lost. Thus, ledger #32570 is the earliest ledger available anywhere. For purposes of the Data API v2, ledger #32570 is considered the genesis ledger.
A Validation Object represents one vote from a validator to mark a ledger version as validated. (A ledger is only validated by the consensus process if a quorum of trusted validators votes for the same exact ledger version.)
-Note: The Data API retain only about 6 months of validation vote data.
+Note: The Data API retain only about 6 months of validation vote data.
A Validation Object has the following fields:
Caution: Ripple uses decimal math with different precision than typical floating-point numbers, so currency amounts are always presented as strings.
+Caution: Ripple uses decimal math with different precision than typical floating-point numbers, so currency amounts are always presented as strings.
Some API methods require you to specify an amount of currency. Depending on whether you are dealing in the network's native XRP currency or other currency units (called issuances), the style for specifying it is very different.
Caution: These field names are case-sensitive.
+Caution: These field names are case-sensitive.
For example, to represent $153.75 US dollars issued by account r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59, you would specify:
{
"currency": "USD",
@@ -840,7 +843,7 @@ Null method
Note: The distinction between full, validating, and proposing is based on synchronization with the rest of the global network, and it is normal for a server to fluctuate between these states as a course of general operation.
Note: The distinction between full, validating, and proposing is based on synchronization with the rest of the global network, and it is normal for a server to fluctuate between these states as a course of general operation.
Some methods return more data than can efficiently fit into one response. When there are more results than contained, the response includes a marker field. You can use this to retrieve more pages of data across multiple calls. In each request, pass the marker value from the previous response to resume from the point where you left off. If the marker is omitted from a response, then you have reached the end of the data set.
The format of the marker field is intentionally undefined. Each server can define a marker field as desired, so it may take the form of a string, a nested object, or another type. Different servers, and different methods provided by the same server, can have different marker definitions. Each marker is ephemeral, and may not work as expected after 10 minutes.
Note: The currencies that an account can send or receive are defined based on a check of its trust lines. If an account has a trust line for a currency and enough room to increase its balance, it can receive that currency. If the trust line's balance can go down, the account can send that currency. This method doesn't check whether the trust line is frozen or authorized.
+Note: The currencies that an account can send or receive are defined based on a check of its trust lines. If an account has a trust line for a currency and enough room to increase its balance, it can receive that currency. If the trust line's balance can go down, the account can send that currency. This method doesn't check whether the trust line is frozen or authorized.
account_tx metho
Note: The server may respond with different values of ledger_index_min and ledger_index_max than you provided in the request, for example if it did not have the versions you specified on hand.
Note: The server may respond with different values of ledger_index_min and ledger_index_max than you provided in the request, for example if it did not have the versions you specified on hand.
Each transaction object includes the following fields, depending on whether it was requested in JSON or hex string ("binary":true) format.
The commandline version of this command cannot generate Ed25519 keys.
Caution: For most cases, you should use a seed value generated from a strong source of randomness. Anyone who knows the seed value for an address has full power to send transactions signed by that address. Generally, running this command with no parameters is a good way to generate a random seed.
+Caution: For most cases, you should use a seed value generated from a strong source of randomness. Anyone who knows the seed value for an address has full power to send transactions signed by that address. Generally, running this command with no parameters is a good way to generate a random seed.
Cases where you would specify a known seed include:
Note: There is no commandline syntax for ledger_data. You can use the json command to access this method from the commandline instead.
Note: There is no commandline syntax for ledger_data. You can use the json command to access this method from the commandline instead.
A request can include the following fields:
Note: When you close a ledger, rippled determines the canonical order of transactions in that ledger and replays them. This can change the outcome of transactions that were provisionally applied to the current ledger.
Note: When you close a ledger, rippled determines the canonical order of transactions in that ledger and replays them. This can change the outcome of transactions that were provisionally applied to the current ledger.
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.
An example of a successful response:
The tx_history method retrieves some of the most recent transactions made.
Caution: This method is deprecated, and may be removed without further notice.
+Caution: This method is deprecated, and may be removed without further notice.
An example of the request format:
The ripple_path_find method is a simplified version of path_find that provides a single response with a payment path you can use right away. It is available in both the WebSocket and JSON-RPC APIs. However, the results tend to become outdated as time passes. Instead of making multiple calls to stay updated, you should use path_find instead where possible.
Although the rippled server tries to find the cheapest path or combination of paths for making a payment, it is not guaranteed that the paths returned by this method are, in fact, the best paths.
Caution: Be careful with the pathfinding results from untrusted servers. A server could be modified to return less-than-optimal paths to earn money for its operators. A server may also return poor results when under heavy load. If you do not have your own server that you can trust with pathfinding, you should compare the results of pathfinding from multiple servers run by different parties, to minimize the risk of a single server returning poor results.
+Caution: Be careful with the pathfinding results from untrusted servers. A server could be modified to return less-than-optimal paths to earn money for its operators. A server may also return poor results when under heavy load. If you do not have your own server that you can trust with pathfinding, you should compare the results of pathfinding from multiple servers run by different parties, to minimize the risk of a single server returning poor results.
An example of the request format:
The sign method takes a transaction in JSON format and a secret key, and returns a signed binary representation of the transaction. The result is always different, even when you provide the same transaction JSON and secret key. To contribute one signature to a multi-signed transaction, use the sign_for command instead.
Caution: Unless you run the rippled server yourself, you should do local signing with RippleAPI instead of using this command. An untrustworthy server could change the transaction before signing it, or use your secret key to sign additional arbitrary transactions as if they came from you.
Caution: Unless you run the rippled server yourself, you should do local signing with RippleAPI instead of using this command. An untrustworthy server could change the transaction before signing it, or use your secret key to sign additional arbitrary transactions as if they came from you.
An example of the request format:
The server automatically tries to fill in certain fields in tx_json (the Transaction object) automatically if you omit them. The server provides the following fields before signing, unless the request specified offline as true:
Sequence - The server automatically uses the next Sequence number from the sender's account information.Fee - If you omit the Fee parameter, the server tries to fill in an appropriate transaction cost automatically. On the production Ripple Consensus Ledger, this fails with rpcHIGH_FEE unless you provide an appropriate fee_mult_max value.fee_mult_max and fee_div_max parameters limit how high the automatically-provided transaction cost can be, in terms of the load-scaling multiplier that gets applied to the reference transaction cost. The default settings return an error if the automatically-provided value would use greater than a 10× multiplier. However, the production Ripple Consensus Ledger typically has a 1000× load multiplier.fee_mult_max and fee_div_max. For the production Ripple Consensus Ledger, you must provide a Fee value.fee_mult_max and fee_div_max.fee_mult_max and fee_div_max.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.Caution: If this command results in an error messages, the message can contain the secret key from the request. Make sure that these errors are not visible to others.
+Caution: If this command results in an error messages, the message can contain the secret key from the request. Make sure that these errors are not visible to others.
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 the secret key from 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.
+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 the secret key from 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.
noPermission - The request included the url field, but you are not connected as an admin.malformedStream - The streams field of the request was not formatted properly.malformedAccount - One of the addresses in the accounts or accounts_proposed fields of the request is not a properly-formatted Ripple address.srcCurMalformed - One or more taker_pays sub-fields of the books field in the request is not formatted properly.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.
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.
An example of a successful response:
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.
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.
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.
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.
An example of a successful response:
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.
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,
@@ -494,7 +497,7 @@
-Note: The deprecated PreviousTxnID transaction parameter was removed entirely in rippled 0.28.0. Use AccountTxnID instead.
+Note: The deprecated PreviousTxnID transaction parameter was removed entirely in rippled 0.28.0. Use AccountTxnID instead.
Auto-fillable Fields
Some fields can be automatically filled in before the transaction is signed, either by a rippled server or by the library used for offline signing. Both ripple-lib and rippled can automatically provide the following values:
@@ -506,7 +509,7 @@
Transaction Cost
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.
+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 the replacement transaction to do anything, send an AccountSet transaction with no options.
@@ -1097,7 +1100,7 @@
Expiration
Since transactions can take time to propagate and confirm, the timestamp of a ledger is used to determine offer validity. An offer only expires when its Expiration time is before the most-recently validated ledger. In other words, an offer with an Expiration field is still considered "active" if its expiration time is later than the timestamp of the most-recently validated ledger, regardless of what your local clock says.
You can determine the final disposition of an offer with an Expiration as soon as you see a fully-validated ledger with a close time equal to or greater than the expiration time.
-Note: Since only new transactions can modify the ledger, an expired offer can stay on the ledger after it becomes inactive. The offer is treated as unfunded and has no effect, but it can continue to appear in results (for example, from the ledger_entry command). Later on, the expired offer can get finally deleted as a result of another transaction (such as another OfferCreate) if the server finds it while processing.
+Note: Since only new transactions can modify the ledger, an expired offer can stay on the ledger after it becomes inactive. The offer is treated as unfunded and has no effect, but it can continue to appear in results (for example, from the ledger_entry command). Later on, the expired offer can get finally deleted as a result of another transaction (such as another OfferCreate) if the server finds it while processing.
If an OfferCreate transaction has an Expiration time that has already passed when the transaction first gets included in a ledger, the transaction does not execute the offer but still results in a tesSUCCESS transaction code. (This is because such a transaction could still successfully cancel another offer.)
Auto-Bridging
Any OfferCreate that would exchange two non-XRP currencies could potentially use XRP as an intermediary currency in a synthetic order book. This is because of auto-bridging, which serves to improve liquidity across all currency pairs by using XRP as a vehicle currency. This works because of XRP's nature as a native cryptocurrency to the Ripple Consensus Ledger. Offer execution can use a combination of direct and auto-bridged offers to achieve the best total exchange rate.
@@ -1176,7 +1179,7 @@
-Tip: To remove an old offer and replace it with a new one, you can use an OfferCreate transaction with an OfferSequence parameter, instead of using OfferCancel and another OfferCreate.
+Tip: To remove an old offer and replace it with a new one, you can use an OfferCreate transaction with an OfferSequence parameter, instead of using OfferCancel and another OfferCreate.
The OfferCancel method returns tesSUCCESS even if it did not find an offer with the matching sequence number.
TrustSet
@@ -1390,7 +1393,7 @@
SetFee
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 find one when processing ledgers.
+Note: You cannot send a pseudo-transaction, but you may find one when processing ledgers.
{
"Account": "rrrrrrrrrrrrrrrrrrrrrhoLvTp",
"BaseFee": "000000000000000A",
@@ -1450,7 +1453,7 @@
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 find one when processing ledgers.
+Note: You cannot send a pseudo-transaction, but you may find one when processing ledgers.
@@ -1537,7 +1540,7 @@
"engine_result_code": 0,
"engine_result_message": "The transaction was applied. Only final in a validated ledger."
-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.
+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.
diff --git a/tool/dactyl-config.yml b/tool/dactyl-config.yml
index f7a44923cf..a4a21ba8a3 100644
--- a/tool/dactyl-config.yml
+++ b/tool/dactyl-config.yml
@@ -29,6 +29,7 @@ targets:
- multicode_tabs
- standardize_header_ids
- buttonize
+ - callouts
- name: ripple.com
filters:
diff --git a/tool/filter_callouts.py b/tool/filter_callouts.py
new file mode 100644
index 0000000000..5175e280ef
--- /dev/null
+++ b/tool/filter_callouts.py
@@ -0,0 +1,27 @@
+################################################################################
+## Callouts filter ##
+## Author: Rome Reginelli ##
+## Copyright: Ripple Labs, Inc. 2016 ##
+## ##
+## Looks for sections starting **Note:** or **Caution:** and gives them CSS ##
+## classes like "callout note" so they can be styled accordinglyselfselfself. ##
+################################################################################
+import re
+
+CALLOUT_CLASS_MAPPING = {
+ "note": "devportal-callout note",
+ "warning": "devportal-callout warning",
+ "caution": "devportal-callout caution",
+ "tip": "devportal-callout tip",
+}
+
+def filter_soup(soup, target=None, page=None):
+ """replace underscores with dashes in h1,h2,etc. for backwards compatibility"""
+ callout_intro = re.compile(r"(Note|Warning|Tip|Caution):?$", re.I)
+ callouts = soup.find_all(name=["strong","em"], string=callout_intro)
+ for c in callouts:
+ if not c.previous_sibling: #This callout starts a block
+ callout_type = c.string.replace(":","").lower()
+ if callout_type in CALLOUT_CLASS_MAPPING:
+ c.parent["class"] = CALLOUT_CLASS_MAPPING[callout_type]
+ #c.parent["class"] = "callout %s" % callout_type
diff --git a/tool/template-doc.html b/tool/template-doc.html
index 7c4eb4f396..02d25922b5 100644
--- a/tool/template-doc.html
+++ b/tool/template-doc.html
@@ -2,7 +2,7 @@
{% block head %}
-
+
@@ -17,6 +17,9 @@
+
+
+
{% endblock %}
{% block sidebar %}
diff --git a/tutorial-gateway-guide.html b/tutorial-gateway-guide.html
index 539db5321c..147feb84a5 100644
--- a/tutorial-gateway-guide.html
+++ b/tutorial-gateway-guide.html
@@ -23,7 +23,7 @@
-
+
@@ -39,6 +39,9 @@
+
+
+
@@ -408,7 +411,7 @@
]
}
-(Reminder: Don't send your secret to a server you do not control.)
+Caution: Never submit a secret key to a server you do not control. Do not send a secret key unencrypted over the network.
Response:
{
"result": {
@@ -460,7 +463,7 @@
]
}
-(Reminder: Don't send your secret to a server you do not control.)
+Caution: Never submit a secret key to a server you do not control. Do not send a secret key unencrypted over the network.
Response:
{
"result": {
@@ -506,7 +509,7 @@ Content-Type: application/json
]
}
-(Reminder: Don't send your secret to a server you do not control.)
+Caution: Never submit a secret key to a server you do not control. Do not send a secret key unencrypted over the network.
Response:
200 OK
{
@@ -555,7 +558,7 @@ Content-Type: application/json
]
}
-(Reminder: Don't send your secret to a server you do not control.)
+Caution: Never submit a secret key to a server you do not control. Do not send a secret key unencrypted over the network.
Authorizing Trust Lines
If you are using the Authorized Accounts feature, customers cannot hold balances you issue unless you first authorize their accounting relationships to you in the RCL.
To authorize an accounting relationship, submit a TrustSet transaction from your issuing address, with the user to trust as the issuer of the LimitAmount. Leave the value (the amount to trust them for) as 0, and enable the tfSetfAuth flag for the transaction.
@@ -582,7 +585,7 @@ Content-Type: application/json
]
}
-(Reminder: Don't send your secret to a server you do not control.)
+Caution: Never submit a secret key to a server you do not control. Do not send a secret key unencrypted over the network.
Robustly Monitoring for Payments
To robustly check for incoming payments, gateways should do the following:
@@ -650,7 +653,7 @@ Content-Type: application/json
- In
rippled's APIs, you should set the SendMax transaction parameter higher than the destination Amount parameter.
- In RippleAPI, you should set the
source.maxAmount parameter higher than the destination.amount parameter; or, set the source.amount parameter higher than the destination.minAmount parameter.
-Note: The TransferRate does not apply when sending issuances directly to the issuing address. The issuing address must always accept its issuances at face value in the RCL. This means that customers don't have to pay the TransferRate if they send payments to the issuing address directly, but they do when sending to an operational address. If you accept payments at both addresses, you may want to adjust the amount you credit customers in your system of record when customers send payments to the operational address, to compensate for the TransferRate the customer pays.
+Note: The TransferRate does not apply when sending issuances directly to the issuing address. The issuing address must always accept its issuances at face value in the RCL. This means that customers don't have to pay the TransferRate if they send payments to the issuing address directly, but they do when sending to an operational address. If you accept payments at both addresses, you may want to adjust the amount you credit customers in your system of record when customers send payments to the operational address, to compensate for the TransferRate the customer pays.
For example: If ACME sets a transfer fee of 1%, a Ripple payment to deliver 5 EUR.ACME from a customer address to ACME's issuing address would cost exactly 5 EUR.ACME. However, the customer would need to send 5.05 EUR.ACME to deliver 5 EUR.ACME to ACME's operational address. (The issuing address's total obligations in the RCL decrease by 0.05 EUR.ACME.) When ACME credits customers for payments to ACME's operational address, ACME credits the customer for the amount delivered to the operational address and the transfer fee, giving the customer €5,05 in ACME's systems.
Sending Payments to Customers
When you build an automated system to send payments into Ripple for your customers, you must make sure that it constructs payments carefully. Malicious actors are constantly trying to find ways to trick a system into paying them more money than it should.
diff --git a/tutorial-multisign.html b/tutorial-multisign.html
index e46ed7afbd..6d5bb3a902 100644
--- a/tutorial-multisign.html
+++ b/tutorial-multisign.html
@@ -23,7 +23,7 @@
-
+
@@ -39,6 +39,9 @@
+
+
+
@@ -212,7 +215,25 @@ Connecting to 127.0.0.1:5005
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 send a secret key unencrypted over the network.
+<<<<<<< HEAD
+Caution: Never submit a secret key to a server you do not control. Do not send a secret key unencrypted over the network.
+=======
+Caution: Never submit a secret key to a server you do not control. Do not send a secret key unencrypted over the network.
+
+
+
+
+
+
+
+callouts
+
+
+
+
+
+
+
$ rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{
> "Flags": 0,
> "TransactionType": "SignerListSet",
@@ -284,7 +305,7 @@ Connecting to 127.0.0.1:5005
}
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.
+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:
@@ -350,8 +371,8 @@ Connecting to 127.0.0.1:5005
6. Further steps
At this point, your address is ready to send a multi-signed transaction. You may also want to:
-- Disable the address's master key by sending an AccountSet transaction using the
asfDisableMaster flag.
-- Remove the address's regular key (if you previously set one) by sending a SetRegularKey transaction.
+- Disable the address's master key pair by sending an AccountSet transaction using the
asfDisableMaster flag.
+- Remove the address's regular key pair (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.
@@ -376,7 +397,25 @@ Connecting to 127.0.0.1:5005
(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 send a secret key unencrypted over the network.
+<<<<<<< HEAD
+Caution: Never submit a secret key to a server you do not control. Do not send a secret key unencrypted over the network.
+=======
+Caution: Never submit a secret key to a server you do not control. Do not send a secret key unencrypted over the network.
+
+
+
+
+
+
+
+callouts
+
+
+
+
+
+
+
$ rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW <rsA2L..'s secret> '{
> "TransactionType": "TrustSet",
> "Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
@@ -429,7 +468,25 @@ Connecting to 127.0.0.1:5005
- 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 send a secret key unencrypted over the network.
+<<<<<<< HEAD
+Caution: Never submit a secret key to a server you do not control. Do not send a secret key unencrypted over the network.
+=======
+Caution: Never submit a secret key to a server you do not control. Do not send a secret key unencrypted over the network.
+
+
+
+
+
+
+
+callouts
+
+
+
+
+
+
+
$ rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v <rUpy..'s secret> '{
> "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
> "Fee" : "30000",
diff --git a/tutorial-reliable-transaction-submission.html b/tutorial-reliable-transaction-submission.html
index 427b872e53..c9924aecbc 100644
--- a/tutorial-reliable-transaction-submission.html
+++ b/tutorial-reliable-transaction-submission.html
@@ -23,7 +23,7 @@
-
+
@@ -39,6 +39,9 @@
+
+
+
@@ -184,7 +187,7 @@
- The validated ledger includes the transaction, and its effects are reflected in the ledger state.
- Transaction results are no longer provisional, success or failure is now final and immutable.
-Note: When submitting a transaction via rippled, a successful status code returned from a submit command indicates the rippled server has received the candidate transaction. The transaction may or may not be applied to a validated ledger.
+Note: When submitting a transaction via rippled, a successful status code returned from a submit command indicates the rippled server has received the candidate transaction. The transaction may or may not be applied to a validated ledger.
APIs may return provisional results based on the result of applying candidate transactions to the current, in-progress ledger. Applications must not confuse these with the final, immutable, results of a transaction. Immutable results are found only in validated ledgers. Applications may need to query the status of a transaction repeatedly, until the ledger containing the transaction results is validated.
While applying transactions, rippled servers use the last validated ledger, a snapshot of the ledger state based on transactions the entire network has validated. The process of consensus and validation apply a set of new transactions to the last validated ledger in canonical order, resulting in a new validated ledger. This new validated ledger instance and the ones that preceded it form the ledger history.
Each validated ledger instance has a sequence number, which is one greater than the sequence number of the preceding instance. Each ledger also has an identifying hash value, which is uniquely determined from its contents. There may be many different versions of in-progress ledgers, which have the same sequence number but different hash values. Only one version can ever be validated.
diff --git a/tutorial-rippleapi-beginners-guide.html b/tutorial-rippleapi-beginners-guide.html
index 507933f15a..623a73f0b7 100644
--- a/tutorial-rippleapi-beginners-guide.html
+++ b/tutorial-rippleapi-beginners-guide.html
@@ -23,7 +23,7 @@
-
+
@@ -39,6 +39,9 @@
+
+
+
diff --git a/tutorial-rippled-setup.html b/tutorial-rippled-setup.html
index 72855b08ef..8f0cb5f716 100644
--- a/tutorial-rippled-setup.html
+++ b/tutorial-rippled-setup.html
@@ -23,7 +23,7 @@
-
+
@@ -39,6 +39,9 @@
+
+
+
@@ -417,7 +420,7 @@ ssdecohJMDPFuUPDkmG1w4objZyp4
Parallel Networks
Most of the time, we describe the Ripple peer-to-peer network as one collective, singular entity -- and that's mostly true. There is one production Ripple peer-to-peer network, and all business that takes place on Ripple occurs within the production network.
However, sometimes you may want to do tests and experiments without interacting with the core network. That's why Ripple started the Ripple Test Net, an "alternate universe" network, which can act as a testing ground for applications and the rippled server itself, without impacting the business operations of everyday Ripple users. The Ripple Test Net (also known as the AltNet) has a separate supply of TestNet-only XRP, which Ripple gives away for free to parties interested in developing applications on the Test Net.
-Caution: Ripple makes no guarantees about the stability of the test network. It has been and continues to be used to test various properties of server configuration, network topology, and network performance.
+Caution: Ripple makes no guarantees about the stability of the test network. It has been and continues to be used to test various properties of server configuration, network topology, and network performance.
Over time, there may also be smaller, temporary test networks for specific purposes.
Parallel Networks and Consensus
There is no rippled setting that defines which network it uses. Instead, it uses the consensus of validators it trusts to know which ledger to accept as the truth. When different consensus groups of rippled instances only trust other members of the same group, each group continues as a parallel network. Even if malicious or misbehaving computers connect to both networks, the consensus process overrides the confusion as long as the members of each network are not configured to trust members of another network in excess of their quorum settings.
@@ -440,7 +443,7 @@ ssdecohJMDPFuUPDkmG1w4objZyp4
-
Generate a unique seed (using the validation_create command) for each of your servers, and configure it under the [node_seed] section. The rippled server uses this key to sign its messages to other servers in the peer-to-peer network.
-- Note: This is a different key than the validation seed
rippled uses to sign ledger proposals for consensus, in the same format.
+- Note: This is a different key than the validation seed
rippled uses to sign ledger proposals for consensus, in the same format.
- Add the public keys (for peer communication) of each of your other servers under the
[cluster_nodes] section.