From f6700b2903ba8671c158c3d18720d7aef45a03a2 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Thu, 28 Dec 2017 18:23:56 -0800 Subject: [PATCH] Split Known Amendments to separate page --- content/concept-amendments.md | 354 +---------------------- content/concept-escrow.md | 2 +- content/concept-transaction-cost.md | 6 +- content/reference-amendments.md | 365 ++++++++++++++++++++++++ content/reference-ledger-format.md | 10 +- content/reference-rippled.md | 18 +- content/reference-transaction-format.md | 22 +- content/tutorial-escrow.md | 2 +- dactyl-config.yml | 8 + 9 files changed, 416 insertions(+), 371 deletions(-) create mode 100644 content/reference-amendments.md diff --git a/content/concept-amendments.md b/content/concept-amendments.md index 6497d0fc45..7ab62c0afd 100644 --- a/content/concept-amendments.md +++ b/content/concept-amendments.md @@ -1,4 +1,4 @@ -# Amendments # +# Amendments [Introduced in: rippled 0.31.0][New in: rippled 0.31.0] @@ -6,17 +6,20 @@ The Amendments system provides a means of introducing new features to the decent 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. +For a complete list of known amendments, their statuses, and IDs, see: [Known Amendments](reference-amendments.html). -## Background ## +## Background -Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If some _validators_ (`rippled` servers [participating in consensus](tutorial-rippled-setup.html#reasons-to-run-a-validator)) have upgraded to a new version of the software while other validators use the old version, 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/build/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 some _validators_ (`rippled` servers [participating in consensus](tutorial-rippled-setup.html#reasons-to-run-a-validator)) have upgraded to a new version of the software while other validators use the old version, 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 solve this problem, so that new features can be enabled only when enough validators support those features. -Users and businesses who rely on the XRP 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/build/ripple-ledger-consensus-process/) do not need Amendments. +Users and businesses who rely on the XRP 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 need Amendments. + +[the consensus process]: concept-consensus.html -## About 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 (old behavior) and with the amendment (new behavior). @@ -24,9 +27,8 @@ Every amendment has a unique identifying hex value and a short name. The short n By convention, Ripple's developers use the SHA-512Half hash of the amendment name as the amendment ID. -See also: [Known Amendments](#known-amendments) -## Amendment Process ## +## 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. When `rippled` validator servers send validation messages for that ledger, those servers also submit votes in favor of specific amendments. If a validator does not vote in favor of an amendment, that is the same as voting against the amendment. ([Fee Voting](concept-fee-voting.html) also occurs around flag ledgers.) @@ -46,7 +48,7 @@ A server only inserts the pseudo-transaction to enable an amendment if all of th Theoretically, 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 ## +## Amendment Voting Each version of `rippled` is compiled with a list of known amendments and the code to implement those amendments. By default, `rippled` supports known amendments and opposes unknown amendments. Operators of `rippled` validators can [configure their servers](#configuring-amendment-voting) to explicitly support or oppose certain amendments, even if those amendments are not known to their `rippled` versions. @@ -54,7 +56,7 @@ To become enabled, an amendment must be supported by at least 80% of trusted val As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. At this time, Ripple (the company) recommends only trusting the default validators that Ripple operates. For now, trusting only those validators is enough to coordinate with Ripple on releasing new features. -### Configuring Amendment Voting ### +### 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, change your server's `rippled.cfg` file. @@ -75,7 +77,7 @@ Use the `[amendments]` stanza to list amendments you want to vote for. (Even if ``` -### Amendment Blocked ### +### Amendment Blocked When an amendment gets enabled for the network after the voting process, servers running earlier versions of `rippled` that do not know about the amendment become "amendment blocked" because they no longer understand the rules of the network. Servers that are amendment blocked: @@ -91,7 +93,7 @@ The amendments that a `rippled` server is configured to vote for or against have If your server is amendment blocked, you must [upgrade to a new version](tutorial-rippled-setup.html#updating-rippled) to sync with the network. -## Testing Amendments ## +## 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. @@ -106,336 +108,6 @@ TrustSetAuth ``` -# Known Amendments # -[[Source]
](https://github.com/ripple/rippled/blob/release/src/ripple/app/main/Amendments.cpp "Source") - -The following is a comprehensive list of all known amendments and their status on the production XRP Ledger: - -| Name | Introduced | Status | -|:--------------------------------------|:-----------|:------------------------| -| [Checks](#checks) | v0.90.0 | [Planned: TBD]( "BADGE_LIGHTGREY") | -| [DepositAuth](#depositauth) | v0.90.0 | [Planned: TBD]( "BADGE_LIGHTGREY") | -| [FlowCross](#flowcross) | v0.70.0 | [Planned: TBD]( "BADGE_LIGHTGREY") | -| [SHAMapV2](#shamapv2) | v0.33.0 | [Planned: TBD]( "BADGE_LIGHTGREY") | -| [CryptoConditionsSuite](#cryptoconditionssuite) | N/A | [Planned: TBD]( "BADGE_LIGHTGREY") | -| [OwnerPaysFee](#ownerpaysfee) | N/A | [Planned: TBD]( "BADGE_LIGHTGREY") | -| [Tickets](#tickets) | N/A | [Planned: TBD]( "BADGE_LIGHTGREY") | -| [SortedDirectories](#sorteddirectories) | v0.80.0 | [Enabled: 2017-11-14](https://xrpcharts.ripple.com/#/transactions/6E2309C156EBF94D03B83D282A3914671BF9168FB26463CFECD068C63FFFAB29 "BADGE_GREEN") | -| [fix1201](#fix1201) | v0.80.0 | [Enabled: 2017-11-14](https://xrpcharts.ripple.com/#/transactions/B1157116DDDDA9D9B1C4A95C029AC335E05DB052CECCC5CA90118A4D46C77C5E "BADGE_GREEN") | -| [fix1512](#fix1512) | v0.80.0 | [Enabled: 2017-11-14](https://xrpcharts.ripple.com/#/transactions/63F69F59BEFDC1D79DBF1E4060601E05960683AA784926FB74BC55074C4F6647 "BADGE_GREEN") | -| [fix1523](#fix1523) | v0.80.0 | [Enabled: 2017-11-14](https://xrpcharts.ripple.com/#/transactions/97FD0E35654F4B6714010D3CBBAC4038F60D64AD0292693C28A1DF4B796D8469 "BADGE_GREEN") | -| [fix1528](#fix1528) | v0.80.0 | [Enabled: 2017-11-14](https://xrpcharts.ripple.com/#/transactions/27AEE02DA4FE22B6BB479F850FBBC873FDC7A09A8594753A91B53098D726397E "BADGE_GREEN") | -| [EnforceInvariants](#enforceinvariants) | v0.70.0 | [Enabled: 2017-07-07](https://xrpcharts.ripple.com/#/transactions/17593B03F7D3283966F3C0ACAF4984F26E9D884C9A202097DAED0523908E76C6 "BADGE_GREEN") | -| [fix1373](#fix1373) | v0.70.0 | [Enabled: 2017-07-07](https://xrpcharts.ripple.com/#/transactions/7EBA3852D111EA19D03469F6870FAAEBF84C64F1B9BAC13B041DDD26E28CA399 "BADGE_GREEN") | -| [fix1368](#fix1368) | v0.60.0 | [Enabled: 2017-03-31](https://xrpcharts.ripple.com/#/transactions/3D20DE5CD19D5966865A7D0405FAC7902A6F623659667D6CB872DF7A94B6EF3F "BADGE_GREEN") | -| [PayChan](#paychan) | v0.33.0 | [Enabled: 2017-03-31](https://xrpcharts.ripple.com/#/transactions/16135C0B4AB2419B89D4FB4569B8C37FF76B9EF9CE0DD99CCACB5734445AFD7E "BADGE_GREEN") | -| [Escrow](#escrow) | v0.60.0 | [Enabled: 2017-03-31](https://xrpcharts.ripple.com/#/transactions/C581E0A3F3832FFFEEB13C497658F475566BD7695B0BBA531A774E6739801515 "BADGE_GREEN") | -| [TickSize](#ticksize) | v0.50.0 | [Enabled: 2017-02-21](https://xrpcharts.ripple.com/#/transactions/A12430E470BE5C846759EAE3C442FF03374D5D73ECE5815CF4906894B769565E "BADGE_GREEN") | -| [SusPay](#suspay) | v0.31.0 | [Vetoed: Removed in v0.60.0](https://ripple.com/dev-blog/ticksize-amendment-open-voting/#upcoming-features "BADGE_RED") | -| [CryptoConditions](#cryptoconditions) | v0.50.0 | [Enabled: 2017-01-03](https://xrpcharts.ripple.com/#/transactions/8EB00131E1C3DB35EDFF45C155D941E18C3E86BC1934FF987D2DA204F4065F15 "BADGE_GREEN") | -| [Flow](#flow) | v0.33.0 | [Enabled: 2016-10-21](https://xrpcharts.ripple.com/#/transactions/C06CE3CABA3907389E4DD296C5F31C73B1548CC20BD7B83416C78CD7D4CD38FC "BADGE_GREEN") | -| [FlowV2](#flowv2) | v0.32.1 | [Vetoed: Removed in v0.33.0](https://ripple.com/dev-blog/flowv2-amendment-vetoed/ "BADGE_RED") | -| [TrustSetAuth](#trustsetauth) | v0.30.0 | [Enabled: 2016-07-19](https://xrpcharts.ripple.com/#/transactions/0E589DE43C38AED63B64FF3DA87D349A038F1821212D370E403EB304C76D70DF "BADGE_GREEN") | -| [MultiSign](#multisign) | v0.31.0 | [Enabled: 2016-06-27](https://xrpcharts.ripple.com/#/transactions/168F8B15F643395E59B9977FC99D6310E8708111C85659A9BAF8B9222EEAC5A7 "BADGE_GREEN") | -| [FeeEscalation](#feeescalation) | v0.31.0 | [Enabled: 2016-05-19](https://xrpcharts.ripple.com/#/transactions/5B1F1E8E791A9C243DD728680F108FEF1F28F21BA3B202B8F66E7833CA71D3C3 "BADGE_GREEN") | - -**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. The value "N/A" indicates that the amendment is not yet considered stable. - -## Checks - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:--------| -| 157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1 | In Development | - -Introduces "checks" to the XRP Ledger. Checks work similarly to actual bank checks in real life. The sender signs a transaction to create a Check for a specific maximum amount and destination. Later, the destination can cash the Check to receive up to the specified amount. The actual movement of money only occurs when the Check is cashed, so cashing the Check may fail depending on the sender's current balance and the available liquidity. - -The sender or the receiver can cancel a Check at any time before it is cashed. A Check can also have an expiration time, after which it cannot be cashed, and anyone can cancel it. - -Introduces three new transaction types: CheckCreate, CheckCancel, and CheckCash, and a new ledger object type, Check. Adds a new transaction result code, `tecEXPIRED`, which occurs when trying to create a Check whose expiration time is in the past. - -This amendment also changes the OfferCreate transaction to return `tecEXPIRED` when trying to create an Offer whose expiration time is in the past. Without this amendment, an OfferCreate whose expiration time is in the past returns `tesSUCCESS` but does not create or execute an Offer. - -## DepositAuth - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:--------| -| F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064 | In Development | - -Adds a new account flag, `DepositAuth`, which lets an account strictly reject any incoming payments that are not signed by the receiver. This includes payments of XRP and of issued currencies. This also includes EscrowFinish and PaymentChannelClaim transactions not sent by the destination account. Businesses can use this flag to comply with strict regulations that require due diligence before receiving money from any source. As an exception, accounts with `DepositAuth` enabled can receive small amounts of XRP (equal or less than the minimum [account reserve](concept-reserves.html)) if their current XRP balance is below the account reserve. - -## CryptoConditions - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:--------| -| 1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146 | Enabled | - -Although this amendment is enabled, it has no effect unless the [SusPay](#suspay) amendment is also enabled. Ripple does not expect SusPay to become enabled. Instead, Ripple plans to incorporate crypto-conditions in the [Escrow](#escrow) amendment. - -## CryptoConditionsSuite - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:--------| -| 86E83A7D2ECE3AD5FA87AB2195AE015C950469ABF0B72EAACED318F74886AE90 | In Development | - -Implements several types of crypto-conditions from the official [crypto-conditions specification](https://tools.ietf.org/html/draft-thomas-crypto-conditions-03) for use in [EscrowCreate][] and [EscrowFinish][] transactions. Without this amendment, only the PREIMAGE-SHA-256 type is supported. - -**Caution:** This amendment is still [in development](https://github.com/ripple/rippled/pull/2170). The version from `rippled` v0.60.0 to present does not implement the full functionality. - - -## EnforceInvariants - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:--------| -| DC9CA96AEA1DCF83E527D1AFC916EFAF5D27388ECA4060A88817C1238CAEE0BF | Enabled | - -Adds sanity checks to transaction processing to ensure that certain conditions are always met. This provides an extra, independent layer of protection against bugs in transaction processing that could otherwise cause exploits and vulnerabilities in the XRP Ledger. Ripple expects to add more invariant checks in future versions of `rippled` without additional amendments. - -Introduces two new transaction error codes, `tecINVARIANT_FAILED` and `tefINVARIANT_FAILED`. Changes transaction processing to add the new checks. - -Examples of invariant checks: - -- The total amount of XRP destroyed by a transaction must match the [transaction cost](concept-transaction-cost.html) exactly. -- XRP cannot be created. -- [`AccountRoot` objects in the ledger](reference-ledger-format.html#accountroot) cannot be deleted. (See also: [Permanence of Accounts](concept-accounts.html#permanence-of-accounts).) -- [An object in the ledger](reference-ledger-format.html#ledger-object-types) cannot change its type. (The `LedgerEntryType` field is immutable.) -- There cannot be a trust line for XRP. - - -## Escrow - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:--------| -| 07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104 | Enabled | - -Replaces the [SusPay](#suspay) and [CryptoConditions](#cryptoconditions) amendments. - -Provides "suspended payments" for XRP for escrow within the XRP Ledger, including support for [Interledger Protocol Crypto-Conditions](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02). Creates a new ledger object type for suspended payments and new transaction types to create, execute, and cancel suspended payments. - - - -## FeeEscalation - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:--------| -| 42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE | Enabled | - -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. - -## fix1201 - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| B4D44CC3111ADD964E846FC57760C8B50FFCD5A82C86A72756F6B058DDDF96AD | Enabled | - -Correctly implements a limit on [transfer fees](concept-transfer-fees.html) to a 100% fee, represented by a maximum `TransferRate` value of `2000000000`. (A 100% fee in this case means you must send 2 units of the issued currency for every 1 unit you want to deliver.) Without the amendment, the effective limit is a `TransferRate` value of 232-1, for approximately a 329% fee. - -With this amendment enabled, an [AccountSet][] transaction that attempts to set `TransferRate` higher than `2000000000` fails with the result code `temBAD_TRANSFER_RATE`. Any existing `TransferRate` which was set to a higher value under the previous rules continues to apply at the higher rate. - - -## fix1368 - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| E2E6F2866106419B88C50045ACE96368558C345566AC8F2BDF5A5B5587F0E6FA | Enabled | - -Fixes a minor bug in transaction processing that causes some payments to fail when they should be valid. Specifically, during payment processing, some payment steps that are expected to produce a certain amount of currency may produce a microscopically different amount, due to a loss of precision related to floating-point number representation. When this occurs, those payments fail because they cannot deliver the exact amount intended. The fix1368 amendment corrects transaction processing so payments can no longer fail in this manner. - -## fix1373 - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| 42EEA5E28A97824821D4EF97081FE36A54E9593C6E4F20CBAE098C69D2E072DC | Enabled | - -Fixes a minor bug in transaction processing that causes failures when trying to prepare certain [payment paths](concept-paths.html) for processing. As a result, payments could not use certain paths that should have been valid but were invalidly prepared. Without this amendment, those payments are forced to use less-preferable paths or may even fail. - -The fix1373 amendment corrects the issue so that the paths are properly prepared and payments can use them. It also disables some inappropriate paths that are currently allowed, including paths whose [steps](concept-paths.html#path-specifications) include conflicting fields and paths that loop through the same object more than once. - -## fix1512 - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| 6C92211186613F9647A89DFFBAB8F94C99D4C7E956D495270789128569177DA1 | Enabled | - -Fixes a bug in transaction processing that causes some invalid [PaymentChannelClaim][] transactions to fail with the wrong error code. Without this amendment, the transactions have a `tec`-class result code despite not being included in a ledger and therefore not paying the [transaction cost](concept-transaction-cost.html). - -With this amendment, the transactions fail with a more appropriate result code, `temBAD_AMOUNT`, instead. - -## fix1523 - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| B9E739B8296B4A1BB29BE990B17D66E21B62A300A909F25AC55C22D6C72E1F9D | Enabled | - -Adds tracking by destination account to [escrows](concept-escrow.html). Without this amendment, pending escrows are only tracked by sender. This amendment makes it possible to look up pending escrows by the destination address using the [`account_objects` command](reference-rippled.html#account-objects), excluding any pending escrows that were created before this amendment became enabled. This amendment also makes [EscrowCreate transactions][] appear in the destination's transaction history, as viewed with the [`account_tx` command](reference-rippled.html#account-tx). - -With this amendment, new escrows are added to the [owner directories](reference-ledger-format.html#directorynode) of both the sender and receiver. This amendment also adds a new `DestinationNode` field to [Escrow ledger objects](reference-ledger-format.html#escrow), indicating which page of the destination's owner directory contains the escrow. - - -## fix1528 - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| 1D3463A5891F9E589C5AE839FFAC4A917CE96197098A1EF22304E1BC5B98A454 | Enabled | - -Fixes a bug where validators could build consensus ledgers with different timestamps, potentially delaying the process of declaring validated ledgers. The circumstances for this to occur require precise timing, so validators are unlikely to encounter this bug outside of controlled test conditions. - -This amendment changes how validators negotiate the close time of the consensus ledger so that they cannot reach a consensus on ledger contents but build ledger versions with different timestamps. - - -## Flow - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| 740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11 | Enabled | - -Replaces the payment processing engine with a more robust and efficient rewrite called the Flow engine. The new version of the payment processing engine is intended to follow the same rules as the old one, but occasionally produces different results due to floating point rounding. This Amendment supersedes the [FlowV2](https://ripple.com/dev-blog/flowv2-amendment-vetoed/) amendment. - -The Flow Engine also makes it easier to improve and expand the payment engine with further Amendments. - - -## FlowCross - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| 3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC | Released but not enabled | - -Streamlines the offer crossing logic in the XRP Ledger's decentralized exchange. Uses the updated code from the [Flow](#flow) amendment to power offer crossing, so [OfferCreate transactions][] and [Payment transactions][] share more code. This has subtle differences in how offers are processed: - -- Rounding is slightly different in some cases. -- Due to differences in rounding, some combinations of offers may be ranked higher or lower than by the old logic, and taken preferentially. -- The new logic may delete more or fewer offers than the old logic. (This includes cases caused by differences in rounding and offers that were incorrectly removed as unfunded by the old logic.) - - -## FlowV2 - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| 5CC22CFF2864B020BD79E0E1F048F63EF3594F95E650E43B3F837EF1DF5F4B26 | Withdrawn | - -This is a previous version of the [Flow](#flow) amendment. It was [rejected due to a bug](https://ripple.com/dev-blog/flowv2-amendment-vetoed/) and removed in version 0.33.0. - - -## MultiSign - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:--------| -| 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 | Enabled | - -Introduces [multi-signing](reference-transaction-format.html#multi-signing) as a way to authorize transactions. Creates the [`SignerList` ledger object 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. 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. 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` - - -## OwnerPaysFee - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| 9178256A980A86CF3D70D0260A7DA6402AAFE43632FDBCB88037978404188871 | In development | - -Fixes an inconsistency in the way [transfer fees](concept-transfer-fees.html) are calculated between [OfferCreate](reference-transaction-format.html#offercreate) and [Payment](reference-transaction-format.html#payment) transaction types. Without this amendment, the holder of the issuances pays the transfer fee if an offer is executed in offer placement, but the initial sender of a transaction pays the transfer fees for offers that are executed as part of payment processing. With this amendment, the holder of the issuances always pays the transfer fee, regardless of whether the offer is executed as part of a Payment or an OfferCreate transaction. Offer processing outside of payments is unaffected. - -This Amendment requires the [Flow Amendment](#flow) to be enabled. - -**Note:** An incomplete version of this amendment was introduced in v0.33.0 and removed in v0.80.0. (It was never enabled.) Ripple plans to re-add the amendment when the code is stable enough. - - -## PayChan - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| 08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647 | Enabled | - -Creates "Payment Channels" for XRP. Payment channels are a tool for facilitating repeated, unidirectional payments or temporary credit between two parties. Ripple expects this feature to be useful for the [Interledger Protocol](https://interledger.org/). One party creates a Payment Channel and sets aside some XRP in that channel for a predetermined expiration. Then, through off-ledger secure communications, the sender can send "Claim" messages to the receiver. The receiver can redeem the Claim messages before the expiration, or choose not to in case the payment is not needed. The receiver can verify Claims individually without actually distributing them to the network and waiting for the consensus process to redeem them, then redeem the batched content of many small Claims later, as long as it is within the expiration. - -Creates three new transaction types:[PaymentChannelCreate][], [PaymentChannelClaim][], and [PaymentChannelFund][]. Creates a new ledger object type, [PayChannel](reference-ledger-format.html#paychannel). Defines an off-ledger data structure called a `Claim`, used in the ChannelClaim transaction. Creates new `rippled` API methods: [`channel_authorize`](reference-rippled.html#channel-authorize) (creates a signed Claim), [`channel_verify`](reference-rippled.html#channel-verify) (verifies a signed Claim), and [`account_channels`](reference-rippled.html#account-channels) (lists Channels associated with an account). - -For more information, see the [Payment Channels Tutorial](tutorial-paychan.html). - - -## SortedDirectories - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| CC5ABAE4F3EC92E94A59B1908C2BE82D2228B6485C00AFF8F22DF930D89C194E | Enabled | - -Sorts the entries in [DirectoryNode ledger objects](reference-ledger-format.html#directorynode) and fixes a bug that occasionally caused pages of owner directories not to be deleted when they should have been. - -**Warning:** Older versions of `rippled` that do not know about this amendment may crash when they encounter a DirectoryNode sorted by the new rules. To avoid this problem, [upgrade](tutorial-rippled-setup.html#updating-rippled) to `rippled` version 0.80.0 or later. - - - -## SHAMapV2 - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| C6970A8B603D8778783B61C0D445C23D1633CCFAEF0D43E7DBCD1521D34BD7C3 | Released but not enabled | - -Changes the hash tree structure that `rippled` uses to represent a ledger. The new structure is more compact and efficient than the previous version. This affects how ledger hashes are calculated, but has no other user-facing consequences. - -When this amendment is activated, the XRP Ledger will undergo a brief scheduled unavailability while the network calculates the changes to the hash tree structure. - - -## SusPay - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 |Enabled on TestNet; not intended for production. | - -This amendment is currently enabled on the [Ripple Test Net](https://ripple.com/build/ripple-test-net/). In production, Ripple expects to enable similar functionality with the [Escrow](#escrow) amendment instead. - - -## TrustSetAuth ## - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:--------| -| 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC | Enabled | - -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 object](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, depending on whether the sender of the transaction is considered the low node or the high node. The sender of the transaction must have already enabled [`lsfRequireAuth`](reference-ledger-format.html#accountroot-flags) by sending an [AccountSet transaction](reference-transaction-format.html#accountset) with the [asfRequireAuth flag enabled](reference-transaction-format.html#accountset-flags). - -## TickSize - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| 532651B4FD58DF8922A49BA101AB3E996E5BFBF95A913B3E392504863E63B164 | Enabled | - -Changes the way [Offers](reference-transaction-format.html#lifecycle-of-an-offer) are ranked in order books, so that currency issuers can configure how many significant digits are taken into account when ranking Offers by exchange rate. With this amendment, the exchange rates of Offers are rounded to the configured number of significant digits, so that more Offers have the same exact exchange rate. The intent of this change is to require a meaningful improvement in price to outrank a previous Offer. If used by major issuers, this should reduce the incentive to spam the ledger with Offers that are only a tiny fraction of a percentage point better than existing offers. It may also increase the efficiency of order book storage in the ledger, because Offers can be grouped into fewer exchange rates. - -Introduces a `TickSize` field to accounts, which can be set with the [AccountSet transaction type](reference-transaction-format.html#accountset). If a currency issuer sets the `TickSize` field, the XRP Ledger truncates the exchange rate (ratio of funds in to funds out) of Offers to trade the issuer's currency, and adjusts the amounts of the Offer to match the truncated exchange rate. If only one currency in the trade has a `TickSize` set, that number of significant digits applies. When trading two currencies that have different `TickSize` values, whichever `TickSize` indicates the fewest significant digits applies. XRP does not have a `TickSize`. - - -## Tickets ## - -| Amendment ID | Status | -|:-----------------------------------------------------------------|:----------| -| C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 | In development | - -Introduces Tickets as a way to reserve a transaction sequence number for later execution. Creates the `Ticket` ledger object type and the transaction types `TicketCreate` and `TicketCancel`. - -**Caution:** This amendment is still in development. {% include 'snippets/rippled_versions.md' %} {% include 'snippets/tx-type-links.md' %} diff --git a/content/concept-escrow.md b/content/concept-escrow.md index 5cfd9fa016..f1947bc740 100644 --- a/content/concept-escrow.md +++ b/content/concept-escrow.md @@ -41,7 +41,7 @@ Escrow provides strong guarantees that are best suited for high-value, low-quant ## Availability of Escrow -Conditional payments have been enabled by the ["Escrow" Amendment](concept-amendments.html#escrow) to the XRP Ledger Consensus Protocol since 2017-03-31. A previous version of the same functionality was available on the [Ripple Test Net](https://ripple.com/build/ripple-test-net/) by the name "Suspended Payments" (SusPay) in 2016. +Conditional payments have been enabled by the ["Escrow" Amendment](reference-amendments.html#escrow) to the XRP Ledger Consensus Protocol since 2017-03-31. A previous version of the same functionality was available on the [Ripple Test Net](https://ripple.com/build/ripple-test-net/) by the name "Suspended Payments" (SusPay) in 2016. When testing in [stand-alone mode](concept-stand-alone-mode.html), you can force the Escrow feature to be enabled locally regardless of the amendment status. Add the following stanza to your `rippled.cfg`: diff --git a/content/concept-transaction-cost.md b/content/concept-transaction-cost.md index 6a032daa85..5ee2bd8ea0 100644 --- a/content/concept-transaction-cost.md +++ b/content/concept-transaction-cost.md @@ -30,7 +30,7 @@ The transaction cost is not paid to any party: the XRP is irrevocably destroyed. ## Load Cost and Open Ledger Cost -When the [FeeEscalation amendment](concept-amendments.html#feeescalation) is enabled, there are two thresholds for the transaction cost: +When the [FeeEscalation amendment](reference-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 server queues the transaction for a later ledger. @@ -109,7 +109,7 @@ _Fee levels_ represent the proportional difference between the minimum cost and 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. +If the [FeeEscalation amendment](reference-amendments.html#feeescalation) is enabled, you can use the [`fee` command](reference-rippled.html#fee) to check the open ledger cost. ### server_info @@ -171,7 +171,7 @@ 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. It gets enabled when you send a SetRegularKey transaction signed by the master key pair. 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. +When the [FeeEscalation amendment](reference-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 diff --git a/content/reference-amendments.md b/content/reference-amendments.md new file mode 100644 index 0000000000..dc9e5cb8ab --- /dev/null +++ b/content/reference-amendments.md @@ -0,0 +1,365 @@ +# Known Amendments +[[Source]
](https://github.com/ripple/rippled/blob/release/src/ripple/app/main/Amendments.cpp "Source") + +The following is a comprehensive list of all known amendments and their status on the production XRP Ledger: + +| Name | Introduced | Status | +|:--------------------------|:-----------|:------------------------------------| +| [Checks][] | TBD | [Planned: TBD]( "BADGE_LIGHTGREY") | +| [DepositAuth][] | TBD | [Planned: TBD]( "BADGE_LIGHTGREY") | +| [FlowCross][] | v0.70.0 | [Planned: TBD]( "BADGE_LIGHTGREY") | +| [SHAMapV2][] | v0.33.0 | [Planned: TBD]( "BADGE_LIGHTGREY") | +| [CryptoConditionsSuite][] | TBD | [Planned: TBD]( "BADGE_LIGHTGREY") | +| [OwnerPaysFee][] | TBD | [Planned: TBD]( "BADGE_LIGHTGREY") | +| [Tickets][] | TBD | [Planned: TBD]( "BADGE_LIGHTGREY") | +| [SortedDirectories][] | v0.80.0 | [Enabled: 2017-11-14](https://xrpcharts.ripple.com/#/transactions/6E2309C156EBF94D03B83D282A3914671BF9168FB26463CFECD068C63FFFAB29 "BADGE_GREEN") | +| [fix1201][] | v0.80.0 | [Enabled: 2017-11-14](https://xrpcharts.ripple.com/#/transactions/B1157116DDDDA9D9B1C4A95C029AC335E05DB052CECCC5CA90118A4D46C77C5E "BADGE_GREEN") | +| [fix1512][] | v0.80.0 | [Enabled: 2017-11-14](https://xrpcharts.ripple.com/#/transactions/63F69F59BEFDC1D79DBF1E4060601E05960683AA784926FB74BC55074C4F6647 "BADGE_GREEN") | +| [fix1523][] | v0.80.0 | [Enabled: 2017-11-14](https://xrpcharts.ripple.com/#/transactions/97FD0E35654F4B6714010D3CBBAC4038F60D64AD0292693C28A1DF4B796D8469 "BADGE_GREEN") | +| [fix1528][] | v0.80.0 | [Enabled: 2017-11-14](https://xrpcharts.ripple.com/#/transactions/27AEE02DA4FE22B6BB479F850FBBC873FDC7A09A8594753A91B53098D726397E "BADGE_GREEN") | +| [EnforceInvariants][] | v0.70.0 | [Enabled: 2017-07-07](https://xrpcharts.ripple.com/#/transactions/17593B03F7D3283966F3C0ACAF4984F26E9D884C9A202097DAED0523908E76C6 "BADGE_GREEN") | +| [fix1373][] | v0.70.0 | [Enabled: 2017-07-07](https://xrpcharts.ripple.com/#/transactions/7EBA3852D111EA19D03469F6870FAAEBF84C64F1B9BAC13B041DDD26E28CA399 "BADGE_GREEN") | +| [fix1368][] | v0.60.0 | [Enabled: 2017-03-31](https://xrpcharts.ripple.com/#/transactions/3D20DE5CD19D5966865A7D0405FAC7902A6F623659667D6CB872DF7A94B6EF3F "BADGE_GREEN") | +| [PayChan][] | v0.33.0 | [Enabled: 2017-03-31](https://xrpcharts.ripple.com/#/transactions/16135C0B4AB2419B89D4FB4569B8C37FF76B9EF9CE0DD99CCACB5734445AFD7E "BADGE_GREEN") | +| [Escrow][] | v0.60.0 | [Enabled: 2017-03-31](https://xrpcharts.ripple.com/#/transactions/C581E0A3F3832FFFEEB13C497658F475566BD7695B0BBA531A774E6739801515 "BADGE_GREEN") | +| [TickSize][] | v0.50.0 | [Enabled: 2017-02-21](https://xrpcharts.ripple.com/#/transactions/A12430E470BE5C846759EAE3C442FF03374D5D73ECE5815CF4906894B769565E "BADGE_GREEN") | +| [SusPay][] | v0.31.0 | [Vetoed: Removed in v0.60.0](https://ripple.com/dev-blog/ticksize-amendment-open-voting/#upcoming-features "BADGE_RED") | +| [CryptoConditions][] | v0.50.0 | [Enabled: 2017-01-03](https://xrpcharts.ripple.com/#/transactions/8EB00131E1C3DB35EDFF45C155D941E18C3E86BC1934FF987D2DA204F4065F15 "BADGE_GREEN") | +| [Flow][] | v0.33.0 | [Enabled: 2016-10-21](https://xrpcharts.ripple.com/#/transactions/C06CE3CABA3907389E4DD296C5F31C73B1548CC20BD7B83416C78CD7D4CD38FC "BADGE_GREEN") | +| [FlowV2][] | v0.32.1 | [Vetoed: Removed in v0.33.0](https://ripple.com/dev-blog/flowv2-amendment-vetoed/ "BADGE_RED") | +| [TrustSetAuth][] | v0.30.0 | [Enabled: 2016-07-19](https://xrpcharts.ripple.com/#/transactions/0E589DE43C38AED63B64FF3DA87D349A038F1821212D370E403EB304C76D70DF "BADGE_GREEN") | +| [MultiSign][] | v0.31.0 | [Enabled: 2016-06-27](https://xrpcharts.ripple.com/#/transactions/168F8B15F643395E59B9977FC99D6310E8708111C85659A9BAF8B9222EEAC5A7 "BADGE_GREEN") | +| [FeeEscalation][] | v0.31.0 | [Enabled: 2016-05-19](https://xrpcharts.ripple.com/#/transactions/5B1F1E8E791A9C243DD728680F108FEF1F28F21BA3B202B8F66E7833CA71D3C3 "BADGE_GREEN") | + +**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. The value "TBD" indicates that the amendment is not yet considered stable. + + +## Checks +[Checks]: #checks + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:--------| +| 157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1 | In Development | + +Introduces "checks" to the XRP Ledger. Checks work similarly to actual bank checks in real life. The sender signs a transaction to create a Check for a specific maximum amount and destination. Later, the destination can cash the Check to receive up to the specified amount. The actual movement of money only occurs when the Check is cashed, so cashing the Check may fail depending on the sender's current balance and the available liquidity. + +The sender or the receiver can cancel a Check at any time before it is cashed. A Check can also have an expiration time, after which it cannot be cashed, and anyone can cancel it. + +Introduces three new transaction types: CheckCreate, CheckCancel, and CheckCash, and a new ledger object type, Check. Adds a new transaction result code, `tecEXPIRED`, which occurs when trying to create a Check whose expiration time is in the past. + +This amendment also changes the OfferCreate transaction to return `tecEXPIRED` when trying to create an Offer whose expiration time is in the past. Without this amendment, an OfferCreate whose expiration time is in the past returns `tesSUCCESS` but does not create or execute an Offer. + +**Caution:** This amendment is [in development](https://github.com/ripple/rippled/pull/2245) and is expected for `rippled` v0.90.0. + +## CryptoConditions +[CryptoConditions]: #cryptoconditions + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:--------| +| 1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146 | Enabled | + +Although this amendment is enabled, it has no effect unless the [SusPay](#suspay) amendment is also enabled. Ripple does not expect SusPay to become enabled. Instead, Ripple plans to incorporate crypto-conditions in the [Escrow](#escrow) amendment. + + +## CryptoConditionsSuite +[CryptoConditionsSuite]: #cryptoconditionssuite + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:--------| +| 86E83A7D2ECE3AD5FA87AB2195AE015C950469ABF0B72EAACED318F74886AE90 | In Development | + +Implements several types of crypto-conditions from the official [crypto-conditions specification](https://tools.ietf.org/html/draft-thomas-crypto-conditions-03) for use in [EscrowCreate][] and [EscrowFinish][] transactions. Without this amendment, only the PREIMAGE-SHA-256 type is supported. + +**Caution:** This amendment is still [in development](https://github.com/ripple/rippled/pull/2170). The version from `rippled` v0.60.0 to present does not implement the full functionality. + + +## DepositAuth +[DepositAuth]: #depositauth + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:--------| +| F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064 | In Development | + +Adds a new account flag, `DepositAuth`, which lets an account strictly reject any incoming payments that are not signed by the receiver. This includes payments of XRP and of issued currencies. This also includes EscrowFinish and PaymentChannelClaim transactions not sent by the destination account. Businesses can use this flag to comply with strict regulations that require due diligence before receiving money from any source. As an exception, accounts with `DepositAuth` enabled can receive small amounts of XRP (equal or less than the minimum [account reserve](concept-reserves.html)) if their current XRP balance is below the account reserve. + +**Caution:** This amendment is [in development](https://github.com/ripple/rippled/pull/2239) and is expected for `rippled` v0.90.0. + +## EnforceInvariants +[EnforceInvariants]: #enforceinvariants + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:--------| +| DC9CA96AEA1DCF83E527D1AFC916EFAF5D27388ECA4060A88817C1238CAEE0BF | Enabled | + +Adds sanity checks to transaction processing to ensure that certain conditions are always met. This provides an extra, independent layer of protection against bugs in transaction processing that could otherwise cause exploits and vulnerabilities in the XRP Ledger. Ripple expects to add more invariant checks in future versions of `rippled` without additional amendments. + +Introduces two new transaction error codes, `tecINVARIANT_FAILED` and `tefINVARIANT_FAILED`. Changes transaction processing to add the new checks. + +Examples of invariant checks: + +- The total amount of XRP destroyed by a transaction must match the [transaction cost](concept-transaction-cost.html) exactly. +- XRP cannot be created. +- [`AccountRoot` objects in the ledger](reference-ledger-format.html#accountroot) cannot be deleted. (See also: [Permanence of Accounts](concept-accounts.html#permanence-of-accounts).) +- [An object in the ledger](reference-ledger-format.html#ledger-object-types) cannot change its type. (The `LedgerEntryType` field is immutable.) +- There cannot be a trust line for XRP. + + +## Escrow +[Escrow]: #escrow + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:--------| +| 07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104 | Enabled | + +Replaces the [SusPay](#suspay) and [CryptoConditions](#cryptoconditions) amendments. + +Provides "suspended payments" for XRP for escrow within the XRP Ledger, including support for [Interledger Protocol Crypto-Conditions](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02). Creates a new ledger object type for suspended payments and new transaction types to create, execute, and cancel suspended payments. + + + +## FeeEscalation +[FeeEscalation]: #feeescalation + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:--------| +| 42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE | Enabled | + +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. + +## fix1201 +[fix1201]: #fix1201 + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| B4D44CC3111ADD964E846FC57760C8B50FFCD5A82C86A72756F6B058DDDF96AD | Enabled | + +Correctly implements a limit on [transfer fees](concept-transfer-fees.html) to a 100% fee, represented by a maximum `TransferRate` value of `2000000000`. (A 100% fee in this case means you must send 2 units of the issued currency for every 1 unit you want to deliver.) Without the amendment, the effective limit is a `TransferRate` value of 232-1, for approximately a 329% fee. + +With this amendment enabled, an [AccountSet][] transaction that attempts to set `TransferRate` higher than `2000000000` fails with the result code `temBAD_TRANSFER_RATE`. Any existing `TransferRate` which was set to a higher value under the previous rules continues to apply at the higher rate. + + +## fix1368 +[fix1368]: #fix1368 + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| E2E6F2866106419B88C50045ACE96368558C345566AC8F2BDF5A5B5587F0E6FA | Enabled | + +Fixes a minor bug in transaction processing that causes some payments to fail when they should be valid. Specifically, during payment processing, some payment steps that are expected to produce a certain amount of currency may produce a microscopically different amount, due to a loss of precision related to floating-point number representation. When this occurs, those payments fail because they cannot deliver the exact amount intended. The fix1368 amendment corrects transaction processing so payments can no longer fail in this manner. + +## fix1373 +[fix1373]: #fix1373 + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| 42EEA5E28A97824821D4EF97081FE36A54E9593C6E4F20CBAE098C69D2E072DC | Enabled | + +Fixes a minor bug in transaction processing that causes failures when trying to prepare certain [payment paths](concept-paths.html) for processing. As a result, payments could not use certain paths that should have been valid but were invalidly prepared. Without this amendment, those payments are forced to use less-preferable paths or may even fail. + +The fix1373 amendment corrects the issue so that the paths are properly prepared and payments can use them. It also disables some inappropriate paths that are currently allowed, including paths whose [steps](concept-paths.html#path-specifications) include conflicting fields and paths that loop through the same object more than once. + +## fix1512 +[fix1512]: #fix1512 + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| 6C92211186613F9647A89DFFBAB8F94C99D4C7E956D495270789128569177DA1 | Enabled | + +Fixes a bug in transaction processing that causes some invalid [PaymentChannelClaim][] transactions to fail with the wrong error code. Without this amendment, the transactions have a `tec`-class result code despite not being included in a ledger and therefore not paying the [transaction cost](concept-transaction-cost.html). + +With this amendment, the transactions fail with a more appropriate result code, `temBAD_AMOUNT`, instead. + +## fix1523 +[fix1523]: #fix1523 + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| B9E739B8296B4A1BB29BE990B17D66E21B62A300A909F25AC55C22D6C72E1F9D | Enabled | + +Adds tracking by destination account to [escrows](concept-escrow.html). Without this amendment, pending escrows are only tracked by sender. This amendment makes it possible to look up pending escrows by the destination address using the [`account_objects` command](reference-rippled.html#account-objects), excluding any pending escrows that were created before this amendment became enabled. This amendment also makes [EscrowCreate transactions][] appear in the destination's transaction history, as viewed with the [`account_tx` command](reference-rippled.html#account-tx). + +With this amendment, new escrows are added to the [owner directories](reference-ledger-format.html#directorynode) of both the sender and receiver. This amendment also adds a new `DestinationNode` field to [Escrow ledger objects](reference-ledger-format.html#escrow), indicating which page of the destination's owner directory contains the escrow. + + +## fix1528 +[fix1528]: #fix1528 + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| 1D3463A5891F9E589C5AE839FFAC4A917CE96197098A1EF22304E1BC5B98A454 | Enabled | + +Fixes a bug where validators could build consensus ledgers with different timestamps, potentially delaying the process of declaring validated ledgers. The circumstances for this to occur require precise timing, so validators are unlikely to encounter this bug outside of controlled test conditions. + +This amendment changes how validators negotiate the close time of the consensus ledger so that they cannot reach a consensus on ledger contents but build ledger versions with different timestamps. + + +## Flow +[Flow]: #flow + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| 740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11 | Enabled | + +Replaces the payment processing engine with a more robust and efficient rewrite called the Flow engine. The new version of the payment processing engine is intended to follow the same rules as the old one, but occasionally produces different results due to floating point rounding. This Amendment supersedes the [FlowV2](https://ripple.com/dev-blog/flowv2-amendment-vetoed/) amendment. + +The Flow Engine also makes it easier to improve and expand the payment engine with further Amendments. + + +## FlowCross +[FlowCross]: #flowcross + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| 3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC | Released but not enabled | + +Streamlines the offer crossing logic in the XRP Ledger's decentralized exchange. Uses the updated code from the [Flow](#flow) amendment to power offer crossing, so [OfferCreate transactions][] and [Payment transactions][] share more code. This has subtle differences in how offers are processed: + +- Rounding is slightly different in some cases. +- Due to differences in rounding, some combinations of offers may be ranked higher or lower than by the old logic, and taken preferentially. +- The new logic may delete more or fewer offers than the old logic. (This includes cases caused by differences in rounding and offers that were incorrectly removed as unfunded by the old logic.) + + +## FlowV2 +[FlowV2]: #flowv2 + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| 5CC22CFF2864B020BD79E0E1F048F63EF3594F95E650E43B3F837EF1DF5F4B26 | Withdrawn | + +This is a previous version of the [Flow](#flow) amendment. It was [rejected due to a bug](https://ripple.com/dev-blog/flowv2-amendment-vetoed/) and removed in version 0.33.0. + + +## MultiSign +[MultiSign]: #multisign + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:--------| +| 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 | Enabled | + +Introduces [multi-signing](reference-transaction-format.html#multi-signing) as a way to authorize transactions. Creates the [`SignerList` ledger object 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. 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. 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` + + +## OwnerPaysFee +[OwnerPaysFee]: #ownerpaysfee + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| 9178256A980A86CF3D70D0260A7DA6402AAFE43632FDBCB88037978404188871 | In development | + +Fixes an inconsistency in the way [transfer fees](concept-transfer-fees.html) are calculated between [OfferCreate](reference-transaction-format.html#offercreate) and [Payment](reference-transaction-format.html#payment) transaction types. Without this amendment, the holder of the issuances pays the transfer fee if an offer is executed in offer placement, but the initial sender of a transaction pays the transfer fees for offers that are executed as part of payment processing. With this amendment, the holder of the issuances always pays the transfer fee, regardless of whether the offer is executed as part of a Payment or an OfferCreate transaction. Offer processing outside of payments is unaffected. + +This Amendment requires the [Flow Amendment](#flow) to be enabled. + +**Note:** An incomplete version of this amendment was introduced in v0.33.0 and removed in v0.80.0. (It was never enabled.) Ripple plans to re-add the amendment when the code is stable enough. + + +## PayChan +[PayChan]: #paychan + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| 08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647 | Enabled | + +Creates "Payment Channels" for XRP. Payment channels are a tool for facilitating repeated, unidirectional payments or temporary credit between two parties. Ripple expects this feature to be useful for the [Interledger Protocol](https://interledger.org/). One party creates a Payment Channel and sets aside some XRP in that channel for a predetermined expiration. Then, through off-ledger secure communications, the sender can send "Claim" messages to the receiver. The receiver can redeem the Claim messages before the expiration, or choose not to in case the payment is not needed. The receiver can verify Claims individually without actually distributing them to the network and waiting for the consensus process to redeem them, then redeem the batched content of many small Claims later, as long as it is within the expiration. + +Creates three new transaction types:[PaymentChannelCreate][], [PaymentChannelClaim][], and [PaymentChannelFund][]. Creates a new ledger object type, [PayChannel](reference-ledger-format.html#paychannel). Defines an off-ledger data structure called a `Claim`, used in the ChannelClaim transaction. Creates new `rippled` API methods: [`channel_authorize`](reference-rippled.html#channel-authorize) (creates a signed Claim), [`channel_verify`](reference-rippled.html#channel-verify) (verifies a signed Claim), and [`account_channels`](reference-rippled.html#account-channels) (lists Channels associated with an account). + +For more information, see the [Payment Channels Tutorial](tutorial-paychan.html). + + +## SortedDirectories +[SortedDirectories]: #sorteddirectories + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| CC5ABAE4F3EC92E94A59B1908C2BE82D2228B6485C00AFF8F22DF930D89C194E | Enabled | + +Sorts the entries in [DirectoryNode ledger objects](reference-ledger-format.html#directorynode) and fixes a bug that occasionally caused pages of owner directories not to be deleted when they should have been. + +**Warning:** Older versions of `rippled` that do not know about this amendment may crash when they encounter a DirectoryNode sorted by the new rules. To avoid this problem, [upgrade](tutorial-rippled-setup.html#updating-rippled) to `rippled` version 0.80.0 or later. + + + +## SHAMapV2 +[SHAMapV2]: #shamapv2 + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| C6970A8B603D8778783B61C0D445C23D1633CCFAEF0D43E7DBCD1521D34BD7C3 | Released but not enabled | + +Changes the hash tree structure that `rippled` uses to represent a ledger. The new structure is more compact and efficient than the previous version. This affects how ledger hashes are calculated, but has no other user-facing consequences. + +When this amendment is activated, the XRP Ledger will undergo a brief scheduled unavailability while the network calculates the changes to the hash tree structure. + + +## SusPay +[SusPay]: #suspay + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 |Enabled on TestNet; not intended for production. | + +This amendment is currently enabled on the [Ripple Test Net](https://ripple.com/build/ripple-test-net/). In production, Ripple expects to enable similar functionality with the [Escrow](#escrow) amendment instead. + + +## TrustSetAuth +[TrustSetAuth]: #trustsetauth + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:--------| +| 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC | Enabled | + +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 object](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, depending on whether the sender of the transaction is considered the low node or the high node. The sender of the transaction must have already enabled [`lsfRequireAuth`](reference-ledger-format.html#accountroot-flags) by sending an [AccountSet transaction](reference-transaction-format.html#accountset) with the [asfRequireAuth flag enabled](reference-transaction-format.html#accountset-flags). + +## TickSize +[TickSize]: #ticksize + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| 532651B4FD58DF8922A49BA101AB3E996E5BFBF95A913B3E392504863E63B164 | Enabled | + +Changes the way [Offers](reference-transaction-format.html#lifecycle-of-an-offer) are ranked in order books, so that currency issuers can configure how many significant digits are taken into account when ranking Offers by exchange rate. With this amendment, the exchange rates of Offers are rounded to the configured number of significant digits, so that more Offers have the same exact exchange rate. The intent of this change is to require a meaningful improvement in price to outrank a previous Offer. If used by major issuers, this should reduce the incentive to spam the ledger with Offers that are only a tiny fraction of a percentage point better than existing offers. It may also increase the efficiency of order book storage in the ledger, because Offers can be grouped into fewer exchange rates. + +Introduces a `TickSize` field to accounts, which can be set with the [AccountSet transaction type](reference-transaction-format.html#accountset). If a currency issuer sets the `TickSize` field, the XRP Ledger truncates the exchange rate (ratio of funds in to funds out) of Offers to trade the issuer's currency, and adjusts the amounts of the Offer to match the truncated exchange rate. If only one currency in the trade has a `TickSize` set, that number of significant digits applies. When trading two currencies that have different `TickSize` values, whichever `TickSize` indicates the fewest significant digits applies. XRP does not have a `TickSize`. + + +## Tickets +[Tickets]: #tickets + +| Amendment ID | Status | +|:-----------------------------------------------------------------|:----------| +| C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 | In development | + +Introduces Tickets as a way to reserve a transaction sequence number for later execution. Creates the `Ticket` ledger object type and the transaction types `TicketCreate` and `TicketCancel`. + +**Caution:** This amendment is still in development. + + +{% include 'snippets/rippled_versions.md' %} +{% include 'snippets/tx-type-links.md' %} diff --git a/content/reference-ledger-format.md b/content/reference-ledger-format.md index 30a9caa3d9..e2c61e4ff5 100644 --- a/content/reference-ledger-format.md +++ b/content/reference-ledger-format.md @@ -123,7 +123,7 @@ The `AccountRoot` object has the following fields: | `WalletLocator` | String | Hash256 | (Optional) **DEPRECATED**. Do not use. | | `WalletSize` | Number | UInt32 | (Optional) **DEPRECATED**. Do not use. | | `MessageKey` | String | VariableLength | (Optional) A public key that may be used to send encrypted messages to this account. In JSON, uses hexadecimal. No more than 33 bytes. | -| `TickSize` | Number | UInt8 | (Optional) How many significant digits to use for exchange rates of Offers involving currencies issued by this address. Valid values are `3` to `15`, inclusive. _(Requires the [TickSize amendment](concept-amendments.html#ticksize).)_ | +| `TickSize` | Number | UInt8 | (Optional) How many significant digits to use for exchange rates of Offers involving currencies issued by this address. Valid values are `3` to `15`, inclusive. _(Requires the [TickSize amendment](reference-amendments.html#ticksize).)_ | | `TransferRate` | Number | UInt32 | (Optional) A [transfer fee](https://ripple.com/knowledge_center/transfer-fees/) to charge other users for sending currency issued by this account to each other. | | `Domain` | String | VariableLength | (Optional) A domain associated with this account. In JSON, this is the hexadecimal for the ASCII representation of the domain. | @@ -309,7 +309,7 @@ The lower 64 bits of an Offer Directory's ID represent the TakerPays amount divi ## Escrow [[Source]
](https://github.com/ripple/rippled/blob/c6b6d82a754fe449cc533e18659df483c10a5c98/src/ripple/protocol/impl/LedgerFormats.cpp#L90-L101 "Source") -_(Requires the [Escrow Amendment](concept-amendments.html#paychan).)_ +_(Requires the [Escrow Amendment](reference-amendments.html#escrow).)_ The `Escrow` object type represents a held payment of XRP waiting to be executed or canceled. An [EscrowCreate transaction][] creates an `Escrow` object in the ledger. A successful [EscrowFinish][] or [EscrowCancel][] transaction deletes the object. If the ``Escrow`` object has a [_crypto-condition_](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02), the payment can only succeed if an EscrowFinish transaction provides the corresponding _fulfillment_ that satisfies the condition. (The only supported crypto-condition type is [PREIMAGE-SHA-256](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1).) If the `Escrow` object has a `FinishAfter` time, the held payment can only execute after that time. @@ -354,7 +354,7 @@ An `Escrow` object has the following fields: | `SourceTag` | Number | UInt32 | _(Optional)_ An arbitrary tag to further specify the source for this held payment, such as a hosted recipient at the owner's address. | | `DestinationTag` | Number | UInt32 | _(Optional)_ An arbitrary tag to further specify the destination for this held payment, such as a hosted recipient at the destination address. | | `OwnerNode` | String | UInt64 | A hint indicating which page of the owner directory links to this object, in case the directory consists of multiple pages. **Note:** The object does not contain a direct link to the owner directory containing it, since that value can be derived from the `Account`. | -| `DestinationNode` | String | UInt64 | _(Optional)_ A hint indicating which page of the destination's owner directory links to this object, in case the directory consists of multiple pages. Omitted on escrows created before enabling the [fix1523 amendment](concept-amendments.html#fix1523). | +| `DestinationNode` | String | UInt64 | _(Optional)_ A hint indicating which page of the destination's owner directory links to this object, in case the directory consists of multiple pages. Omitted on escrows created before enabling the [fix1523 amendment](reference-amendments.html#fix1523). | | `PreviousTxnID` | String | Hash256 | The identifying hash of the transaction that most recently modified this object. | | `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger](#ledger-index) that contains the transaction that most recently modified this object. | @@ -552,7 +552,7 @@ The ID of an `Offer` object is the [SHA-512Half](#sha512half) of the following v ## PayChannel [[Source]
](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/LedgerFormats.cpp#L134 "Source") -_(Requires the [PayChan Amendment](concept-amendments.html#paychan).)_ +_(Requires the [PayChan Amendment](reference-amendments.html#paychan).)_ The `PayChannel` object type represents a payment channel. Payment channels enable small, rapid off-ledger payments of XRP that can be later reconciled with the consensus ledger. A payment channel holds a balance of XRP that can only be paid out to a specific destination address until the channel is closed. Any unspent XRP is returned to the channel's owner (the source address that created and funded it) when the channel closes. @@ -756,7 +756,7 @@ The ID of a RippleState object is the [SHA-512Half](#sha512half) of the followin ## SignerList [[Source]
](https://github.com/ripple/rippled/blob/6d2e3da30696bd10e3bb11a5ff6d45d2c4dae90f/src/ripple/protocol/impl/LedgerFormats.cpp#L127 "Source") -The `SignerList` object 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 object type is introduced by the [MultiSign amendment](concept-amendments.html#multisign). [New in: rippled 0.31.0][] +The `SignerList` object 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 object type is introduced by the [MultiSign amendment](reference-amendments.html#multisign). [New in: rippled 0.31.0][] Example SignerList object: diff --git a/content/reference-rippled.md b/content/reference-rippled.md index f91d0ab938..c3f90e32c7 100755 --- a/content/reference-rippled.md +++ b/content/reference-rippled.md @@ -756,7 +756,7 @@ The response follows the [standard format](#response-formatting), with a success ## account_channels [[Source]
](https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/AccountChannels.cpp "Source") -_(Requires the [PayChan amendment](concept-amendments.html#paychan) to be enabled. [New in: rippled 0.33.0][])_ +_(Requires the [PayChan amendment](reference-amendments.html#paychan) to be enabled. [New in: rippled 0.33.0][])_ The `account_channels` method returns information about an account's Payment Channels. This includes only channels where the specified account is the channel's source, not the destination. (A channel's "source" and "owner" are the same.) All information retrieved is relative to a particular version of the ledger. @@ -987,8 +987,8 @@ The request contains the following parameters: | `strict` | Boolean | (Optional, defaults to False) If set to True, then the `account` field only accepts a public key or XRP Ledger address. | | `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. (See [Specifying a Ledger](#specifying-ledgers)) | | `ledger_index` | String or Unsigned Integer | _(Optional)_ The sequence number of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-ledgers)) | -| `queue` | Boolean | _(Optional)_ If `true`, and the [FeeEscalation amendment](concept-amendments.html#feeescalation) is enabled, also returns stats about queued transactions associated with this account. Can only be used when querying for the data from the current open ledger. [New in: rippled 0.33.0][] | -| `signer_lists` | Boolean | _(Optional)_ If `true`, and the [MultiSign amendment](concept-amendments.html#multisign) is enabled, also returns any [SignerList objects](reference-ledger-format.html#signerlist) associated with this account. [New in: rippled 0.31.0][] | +| `queue` | Boolean | _(Optional)_ If `true`, and the [FeeEscalation amendment](reference-amendments.html#feeescalation) is enabled, also returns stats about queued transactions associated with this account. Can only be used when querying for the data from the current open ledger. [New in: rippled 0.33.0][] | +| `signer_lists` | Boolean | _(Optional)_ If `true`, and the [MultiSign amendment](reference-amendments.html#multisign) is enabled, also returns any [SignerList objects](reference-ledger-format.html#signerlist) associated with this account. [New in: rippled 0.31.0][] | The following fields are deprecated and should not be provided: `ident`, `ledger`. @@ -3486,7 +3486,7 @@ The response follows the [standard format](#response-formatting), with a success | `ledger.transactions` | Array | (Omitted unless requested) Transactions applied in this ledger version. By default, members are the transactions' identifying [Hash][] strings. If the request specified `expand` as true, members are full representations of the transactions instead, in either JSON or binary depending on whether the request specified `binary` as true. | | `ledger_hash` | String | Unique identifying hash of the entire ledger. | | `ledger_index` | Number | The [Ledger Index][] of this ledger. | -| `queue_data` | Array | (Omitted unless requested with the `queue` parameter) Array of objects describing queued transactions, in the same order as the queue. If the request specified `expand` as true, members contain full representations of the transactions, in either JSON or binary depending on whether the request specified `binary` as true. Requires the [FeeEscalation amendment](concept-amendments.html#known-amendments). [New in: rippled 0.70.0][] | +| `queue_data` | Array | (Omitted unless requested with the `queue` parameter) Array of objects describing queued transactions, in the same order as the queue. If the request specified `expand` as true, members contain full representations of the transactions, in either JSON or binary depending on whether the request specified `binary` as true. Requires the [FeeEscalation amendment](reference-amendments.html#feeescalation). [New in: rippled 0.70.0][] | The following fields are deprecated and may be removed without further notice: `accepted`, `hash`, `seqNum`, `totalCoins`. @@ -6826,7 +6826,7 @@ The response follows the [standard format](#response-formatting), with a success 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. [New in: rippled 0.31.0][] +This command requires the [MultiSign amendment](reference-amendments.html#multisign) to be enabled. [New in: rippled 0.31.0][] #### Request Format An example of the request format: @@ -7342,7 +7342,7 @@ The response follows the [standard format](#response-formatting), with a success 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. [New in: rippled 0.31.0][] +This command requires the [MultiSign amendment](reference-amendments.html#multisign) to be enabled. [New in: rippled 0.31.0][] #### Request Format An example of the request format: @@ -7778,7 +7778,7 @@ In addition to the standard Offer fields, the following fields may be included i ## channel_authorize [[Source]
](https://github.com/ripple/rippled/blob/d4a56f223a3b80f64ff70b4e90ab6792806929ca/src/ripple/rpc/handlers/PayChanClaim.cpp#L41 "Source") -_(Requires the [PayChan amendment](concept-amendments.html#paychan) to be enabled. [New in: rippled 0.33.0][])_ +_(Requires the [PayChan amendment](reference-amendments.html#paychan) to be enabled. [New in: rippled 0.33.0][])_ The `channel_authorize` method creates a signature that can be used to redeem a specific amount of XRP from a payment channel. @@ -7896,7 +7896,7 @@ The response follows the [standard format](#response-formatting), with a success ## channel_verify [[Source]
](https://github.com/ripple/rippled/blob/d4a56f223a3b80f64ff70b4e90ab6792806929ca/src/ripple/rpc/handlers/PayChanClaim.cpp#L89 "Source") -_(Requires the [PayChan amendment](concept-amendments.html#paychan) to be enabled. [New in: rippled 0.33.0][])_ +_(Requires the [PayChan amendment](reference-amendments.html#paychan) to be enabled. [New in: rippled 0.33.0][])_ The `channel_verify` method checks the validity of a signature that can be used to redeem a specific amount of XRP from a payment channel. @@ -9927,7 +9927,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#feeescalation) to be enabled. [New in: rippled 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](reference-amendments.html#feeescalation) to be enabled. [New in: rippled 0.31.0][] This is a public command available to unprivileged users. [Updated in: rippled 0.32.0][New in: rippled 0.32.0] diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md index 4bc0d99d3c..de47d1aa13 100644 --- a/content/reference-transaction-format.md +++ b/content/reference-transaction-format.md @@ -409,7 +409,7 @@ Example AccountSet: | MessageKey | String | PubKey | _(Optional)_ Public key for sending encrypted messages to this account. | | [SetFlag](#accountset-flags) | Unsigned Integer | UInt32 | _(Optional)_ Integer flag to enable for this account. | | [TransferRate](#transferrate) | Unsigned Integer | UInt32 | _(Optional)_ The fee to charge when users transfer this account's issued currencies, represented as billionths of a unit. Cannot be more than `2000000000` or less than `1000000000`, except for the special case `0` meaning no fee. | -| [TickSize](#ticksize) | Unsigned Integer | UInt8 | _(Optional)_ Tick size to use for offers involving a currency issued by this address. The exchange rates of those offers is rounded to this many significant digits. Valid values are `3` to `15` inclusive, or `0` to disable. _(Requires the [TickSize amendment](concept-amendments.html#ticksize).)_ | +| [TickSize](#ticksize) | Unsigned Integer | UInt8 | _(Optional)_ Tick size to use for offers involving a currency issued by this address. The exchange rates of those offers is rounded to this many significant digits. Valid values are `3` to `15` inclusive, or `0` to disable. _(Requires the [TickSize amendment](reference-amendments.html#ticksize).)_ | | WalletLocator | String | Hash256 | _(Optional)_ Not used. | | WalletSize | Unsigned Integer | UInt32 | _(Optional)_ Not used. | @@ -483,7 +483,7 @@ In `rippled`'s WebSocket and JSON-RPC APIs, the TransferRate is represented as a [[Source]
](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/Escrow.cpp "Source") -_Requires the [Escrow Amendment](concept-amendments.html#escrow)._ +_Requires the [Escrow Amendment](reference-amendments.html#escrow)._ Return escrowed XRP to the sender. @@ -514,7 +514,7 @@ Any account may submit an EscrowCancel transaction. [[Source]
](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/Escrow.cpp "Source") -_Requires the [Escrow Amendment](concept-amendments.html#escrow)._ +_Requires the [Escrow Amendment](reference-amendments.html#escrow)._ Sequester XRP until the escrow process either finishes or is canceled. @@ -552,7 +552,7 @@ Either `CancelAfter` or `FinishAfter` must be specified. If both are included, t [[Source]
](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/Escrow.cpp "Source") -_Requires the [Escrow Amendment](concept-amendments.html#escrow)._ +_Requires the [Escrow Amendment](reference-amendments.html#escrow)._ Deliver XRP from a held payment to the recipient. @@ -693,7 +693,7 @@ When offers of the same exchange rate are placed in the same ledger version, the #### TickSize -_Requires the [TickSize amendment](concept-amendments.html#ticksize)._ +_Requires the [TickSize amendment](reference-amendments.html#ticksize)._ When an Offer is placed into an order book, its exchange rate is truncated based on the `TickSize` values set by the issuers of the currencies involved in the Offer. When a trader offers to exchange XRP and an issued currency, the `TickSize` from the issuer of the currency applies. When a trader offers to exchange two issued currencies, the offer uses the smaller `TickSize` value (that is, the one with fewer significant digits). If neither currency has a `TickSize` set, the default behavior applies. @@ -848,7 +848,7 @@ In the above example with a ¥95/$15 offer and a ¥5/$2 offer, the situation is ## PaymentChannelClaim [[Source]
](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/PayChan.cpp "Source") -_Requires the [PayChan Amendment](concept-amendments.html#paychan)._ +_Requires the [PayChan Amendment](reference-amendments.html#paychan)._ Claim XRP from a payment channel, adjust the payment channel's expiration, or both. This transaction can be used differently depending on the transaction sender's role in the specified channel: @@ -905,7 +905,7 @@ Transactions of the PaymentChannelClaim type support additional values in the [` ## PaymentChannelCreate [[Source]
](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/PayChan.cpp "Source") -_Requires the [PayChan Amendment](concept-amendments.html#paychan)._ +_Requires the [PayChan Amendment](reference-amendments.html#paychan)._ Create a unidirectional channel and fund it with XRP. The address sending this transaction becomes the "source address" of the payment channel. @@ -940,7 +940,7 @@ Example PaymentChannelCreate: ## PaymentChannelFund [[Source]
](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/PayChan.cpp "Source") -_Requires the [PayChan Amendment](concept-amendments.html#paychan)._ +_Requires the [PayChan Amendment](reference-amendments.html#paychan)._ Add additional XRP to an open payment channel, update the expiration time of the channel, or both. Only the source address of the channel can use this transaction. (Transactions from other addresses fail with the error `tecNO_PERMISSION`.) @@ -999,7 +999,7 @@ For even greater security, you can use [multi-signing](#multi-signing), but mult ## SignerListSet [[Source]
](https://github.com/ripple/rippled/blob/ef511282709a6a0721b504c6b7703f9de3eecf38/src/ripple/app/tx/impl/SetSignerList.cpp "Source") -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 was introduced by the [MultiSign amendment](concept-amendments.html#multisign). [New in: rippled 0.31.0][] +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 was introduced by the [MultiSign amendment](reference-amendments.html#multisign). [New in: rippled 0.31.0][] Example SignerListSet: @@ -1381,7 +1381,7 @@ These codes indicate that the transaction failed and was not included in a ledge | `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` | When trying 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. | -| `tefINVARIANT_FAILED` | An invariant check failed when trying to claim the [transaction cost](concept-transaction-cost.html). Requires the [EnforceInvariants amendment](concept-amendments.html#enforceinvariants). If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). | +| `tefINVARIANT_FAILED` | An invariant check failed when trying to claim the [transaction cost](concept-transaction-cost.html). Requires the [EnforceInvariants amendment](reference-amendments.html#enforceinvariants). If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). | | `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. | | `tefNO_AUTH_REQUIRED` | The [TrustSet transaction][] tried to mark a trustline as authorized, but the `lsfRequireAuth` flag is not enabled for the corresponding account, so authorization is not necessary. | @@ -1431,7 +1431,7 @@ These codes indicate that the transaction failed, but it was applied to a ledger | `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 transaction would increase the [reserve requirement](concept-reserves.html) higher than the sending account's balance. [SignerListSet][], [PaymentChannelCreate][], [PaymentChannelFund][], and [EscrowCreate][] can return this error code. 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. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). | -| `tecINVARIANT_FAILED` | 147 | An invariant check failed when trying to execute this transaction. Requires the [EnforceInvariants amendment](concept-amendments.html#enforceinvariants). If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). | +| `tecINVARIANT_FAILED` | 147 | An invariant check failed when trying to execute this transaction. Requires the [EnforceInvariants amendment](reference-amendments.html#enforceinvariants). If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). | | `tecNEED_MASTER_KEY` | 142 | This transaction tried 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][] | | `tecNO_ALTERNATIVE_KEY` | 130 | The transaction tried to remove the only available method of [authorizing transactions](#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. | diff --git a/content/tutorial-escrow.md b/content/tutorial-escrow.md index abd9b2d5e0..05a525fe4c 100644 --- a/content/tutorial-escrow.md +++ b/content/tutorial-escrow.md @@ -557,7 +557,7 @@ _Websocket_ You can use the [`account_objects`](reference-rippled.html#account-objects) method to look up escrow objects by destination address. -**Note:** You can only look up pending escrow objects by destination address if those escrows were created after the [fix1523 amendment](concept-amendments.html#fix1523) was enabled on 2017-11-14. +**Note:** You can only look up pending escrow objects by destination address if those escrows were created after the [fix1523 amendment](reference-amendments.html#fix1523) was enabled on 2017-11-14. Let's say that you want to look up all pending escrow objects with a destination address of `rfztBskAVszuS3s5Kq7zDS74QtHrw893fm`. You can do this using the following example request, where the destination address is the `account` value. diff --git a/dactyl-config.yml b/dactyl-config.yml index a6f50fec7a..e2c1e10277 100644 --- a/dactyl-config.yml +++ b/dactyl-config.yml @@ -50,6 +50,7 @@ targets: "reference-transaction-format.html": https://ripple.com/build/transactions/ "reference-ledger-format.html": https://ripple.com/build/ledger-format/ "reference-data-api.html": https://ripple.com/build/data-api-v2/ + "reference-amendments.html": https://ripple.com/build/known-amendments/ "tutorial-multisign.html": https://ripple.com/build/how-to-multi-sign/ "concept-issuing-and-operational-addresses.html": https://ripple.com/build/issuing-operational-addresses/ "tutorial-reliable-transaction-submission.html": https://ripple.com/build/reliable-transaction-submission/ @@ -173,6 +174,13 @@ pages: - local - ripple.com + - md: reference-amendments.md + category: References + html: reference-amendments.html + targets: + - local + - ripple.com + # Tutorials are step-by-step guides to a specific goal - name: How to Multi-Sign category: Tutorials