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

Merge branch 'master' into rippled_180

Browse Source
This commit is contained in:
mDuo13
2021-11-24 14:34:50 -08:00
parent b4037f2774 4cbc7f55f4
commit 74ef376816
30 changed files with 424 additions and 259 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
.github/workflows/link-checker-pr.yml vendored
View File

@@ -1,14 +1,16 @@
name: Link Checker (PR Build)
on:
# Note: this job runs with in-repo permissions so it can comment and commit
# on stuff in the repo even when the PR is coming from a PR. This means that
# it can, potentially, wreak havoc on the repository by running arbitrary
# code. Be sure to ONLY approve job runs AFTER you have confirmed that the
# commits in question do not contain malicious or suspicious code (especially
# to the .sh or .py files in the tool/ directory.)
pull_request_target:
types: [opened, edited, synchronize]
# Disabled. GitHub doesn't actually stop these jobs from running automatically
# even when they come from untrusted contributors, so this is insecure.
# on:
# # Note: this job runs with in-repo permissions so it can comment and commit
# # on stuff in the repo even when the PR is coming from a PR. This means that
# # it can, potentially, wreak havoc on the repository by running arbitrary
# # code. Be sure to ONLY approve job runs AFTER you have confirmed that the
# # commits in question do not contain malicious or suspicious code (especially
# # to the .sh or .py files in the tool/ directory.)
# pull_request_target:
# types: [opened, edited, synchronize]
jobs:
build:

2
content/_code-samples/get-started/js/get-acct-info.js
View File

@@ -10,7 +10,7 @@ async function main() {
await client.connect()
// Create a wallet and fund it with the Testnet faucet:
const fund_result = await client.fundWallet(test_wallet)
const fund_result = await client.fundWallet()
const test_wallet = fund_result.wallet
console.log(fund_result)

2
content/_snippets/data_types/account_sequence.ja.md
View File

@@ -2,7 +2,7 @@
すべての[XRP Ledgerアカウント](accounts.html)には、`Sequence`フィールドに1つのシーケンス番号があり、アカウントがトランザクションを送信し、そのトランザクションが[検証済みレジャー](ledgers.html)に記録されるたびに、1ずつ増加します。シーケンス番号は各[トランザクション](transaction-basics.html)の`Sequence`フィールドにもあり、そのトランザクションが実行される際にアカウントの現在のシーケンス番号と一致している必要があります。各アカウントで、各シーケンス番号は番号順に一度だけ使用できます。
[DeletableAccounts Amendment](known-amendments.html#deletableaccounts) :not_enabled: を適用する場合、アカウントの`Sequence`番号の始まりが、アカウントが作成されたレジャーバージョンの[レジャーインデックス][]と一致します。DeletableAccountsを適用しない場合、どのアカウントの`Sequence`番号も1で始まります。
[DeletableAccounts Amendment](known-amendments.html#deletableaccounts) を適用する場合、アカウントの`Sequence`番号の始まりが、アカウントが作成されたレジャーバージョンの[レジャーインデックス][]と一致します。DeletableAccountsを適用しない場合、どのアカウントの`Sequence`番号も1で始まります。
トランザクションがレジャーに記録されると、トランザクションの実行が成功したか[`tec`クラスのエラーコード](tec-codes.html)で失敗したかを問わず、シーケンス番号が1つ消費されます。トランザクションのその他の失敗についてはレジャーに記録されないため、送金元のシーケンス番号は変更されません（その他の影響もありません）。

2
content/_snippets/data_types/account_sequence.md
View File

@@ -2,7 +2,7 @@ A sequence number is a 32-bit unsigned integer that is used to make sure transac
Every [account in the XRP Ledger](accounts.html) has a sequence number in its `Sequence` field, which increases by 1 whenever that account sends a transaction and that transaction gets included in a [validated ledger](ledgers.html). Each [transaction](transaction-basics.html) also has a sequence number in its `Sequence` field, which must match the account's current sequence number when the transaction executes. For each account, each sequence number can only be used once, in numerical order.
[Tickets](tickets.html) :not_enabled: make some exceptions from these rules so that it is possible to send transactions out of the normal order. Tickets represent sequence numbers reserved for later use; a transaction can use a Ticket instead of a normal sequence number.
[Tickets](tickets.html) make some exceptions from these rules so that it is possible to send transactions out of the normal order. Tickets represent sequence numbers reserved for later use; a transaction can use a Ticket instead of a normal sequence number.
With the [DeletableAccounts amendment](known-amendments.html#deletableaccounts), the starting `Sequence` number for an account matches the [Ledger Index][] of the ledger version where the account was created. Before DeletableAccounts, every account started with `Sequence` number 1.

35
content/concepts/consensus-network/amendments/known-amendments.ja.md
View File

@@ -14,13 +14,14 @@ labels:
| 名前 | 導入済み | ステータス |
|:--------------------------------|:-----------|:------------------------------------|
| [CheckCashMakesTrustLine][] | v1.8.0 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [CryptoConditionsSuite][] | 未定 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [OwnerPaysFee][] | 未定 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [NegativeUNL][] | v1.7.3 | [投票中: 未定](https://xrpl.org/blog/2021/rippled-1.7.3.html "BADGE_80d0e0") |
| [fixRmSmallIncreasedQOffers][] | v1.7.2 | [投票中: 未定](https://xrpl.org/blog/2021/rippled-1.7.2.html "BADGE_80d0e0") |
| [fixSTAmountCanonicalize][] | v1.7.0 | [投票中: 未定](https://xrpl.org/blog/2021/rippled-1.7.0.html "BADGE_80d0e0") |
| [FlowSortStrands][] | v1.7.0 | [投票中: 未定](https://xrpl.org/blog/2021/rippled-1.7.0.html "BADGE_80d0e0") |
| [TicketBatch][] | v1.7.0 | [投票中: 未定](https://xrpl.org/blog/2021/rippled-1.7.0.html "BADGE_80d0e0") |
| [NegativeUNL][] | v1.7.3 | [有効: 2021/11/21](https://livenet.xrpl.org/transactions/1500FADB73E7148191216C53040990E829C7110788B26E7F3246CB3660769EBA "BADGE_GREEN") |
| [fixRmSmallIncreasedQOffers][] | v1.7.2 | [有効: 2021/11/18](https://livenet.xrpl.org/transactions/1F37BA0502576DD7B5464F47641FA95DEB55735EC2663269DFD47810505478E7 "BADGE_GREEN") |
| [TicketBatch][] | v1.7.0 | [有効: 2021/11/18](https://livenet.xrpl.org/transactions/111B32EDADDE916206E7315FBEE2DA1521B229F207F65DD314829F13C8D9CA36 "BADGE_GREEN") |
| [fixSTAmountCanonicalize][] | v1.7.0 | [有効: 2021/11/11](https://livenet.xrpl.org/transactions/AFF17321A012C756B64FCC3BA0FDF79109F28E244D838A28D5AE8A0384C7C532 "BADGE_GREEN") |
| [FlowSortStrands][] | v1.7.0 | [有効: 2021/11/11](https://livenet.xrpl.org/transactions/1C3D3BD2AFDAF326EBFEA54579A89B024856609DB4310F7140086AAB262D09A1 "BADGE_GREEN") |
| [fix1781][] | v1.6.0 | [有効: 2021/04/08](https://livenet.xrpl.org/transactions/DA59F10201D651B544F65896330AFACA8CA4198904265AD279D56781F655FAFB "BADGE_GREEN") |
| [fixAmendmentMajorityCalc][] | v1.6.0 | [有効: 2021/04/08](https://livenet.xrpl.org/transactions/5B3ACE6CAC9C56D2008410F1B0881A0A4A8866FB99D2C2B2261C86C760DC95EF "BADGE_GREEN") |
| [HardenedValidations][] | v1.6.0 | [有効: 2021/04/08](https://livenet.xrpl.org/transactions/3A45DCF055B68DCBBFE034240F9359FB22E8A64B1BF7113304535BF5BB8144BF "BADGE_GREEN") |
@@ -65,6 +66,20 @@ labels:
**注記:** 多くの場合、旧バージョンのソフトウェアには不完全バージョンの修正用コードが存在します。上の表内の「導入済み」バージョンは最初の安定バージョンです。「未定」は、修正がまだ安定していないと見なされていることを示します。
## CheckCashMakesTrustLine
[CheckCashMakesTrustLine]: #checkcashmakestrustline
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:---------|
| 98DECF327BF79997AEC178323AD51A830E457BFC6D454DAF3E46E5EC42DC619F | 開発中 |
Adjusts the [CheckCash transaction][] so that cashing a [Check](checks.html) for an issued token automatically creates a [trust line](trust-lines-and-issuing.html) to hold the token. The new behavior is similar to how the [OfferCreate transaction][] behaves when users purchase tokens in the decentralized exchange: the automatic trust line has a limit value of 0. This removes the setup step of setting up a trust line before receiving a token via a Check. (Checks that send XRP are unaffected.)
Without this amendment, users have to separately send a [TrustSet transaction][] before they can cash a Check for an issued token.
This amendment does not change the fact that you cannot force anyone to hold tokens they don't want in the XRP Ledger.
## Checks
[Checks]: #checks
@@ -417,7 +432,7 @@ This amendment has no known impact on transaction processing.
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:---------|
| B6B3EEDC0267AB50491FDC450A398AF30DBCD977CECED8BEF2499CAB5DAC19E2 | 投票中 |
| B6B3EEDC0267AB50491FDC450A398AF30DBCD977CECED8BEF2499CAB5DAC19E2 | 有効 |
<!-- TODO: translate amendment description -->
This amendment fixes an issue where certain Offers, when almost completely consumed, have a much lower exchange rate than when they were first placed. This occurs when the remaining amounts of one or both assets are so small that they cannot be rounded to a similar ratio as when the Offer was placed.
@@ -432,7 +447,7 @@ With this amendment, payments and trades can remove these types of Offers the sa
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:----------|
| 452F5906C46D46F407883344BFDD90E672B672C5E9943DB4891E3A34FEEEB9DB | 投票中 |
| 452F5906C46D46F407883344BFDD90E672B672C5E9943DB4891E3A34FEEEB9DB | 有効 |
<!-- TODO: translate amendment description -->
Fixes an edge case in [deserializing](serialization.html) Amount-type fields. Without this amendment, in some rare cases the operation could result in otherwise valid serialized amounts overflowing during deserialization. With this amendment, the XRP Ledger detects error conditions more quickly and eliminates the problematic corner cases.
@@ -482,7 +497,7 @@ XRP Ledgerの分散型取引所において、オファーの掛け合わせの
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:---------|
| AF8DF7465C338AE64B1E937D6C8DA138C0D63AD5134A68792BBBE1F63356C422 | 投票中 |
| AF8DF7465C338AE64B1E937D6C8DA138C0D63AD5134A68792BBBE1F63356C422 | 有効 |
<!-- TODO: translate amendment description -->
Improves the payment engine's calculations for finding the most cost-efficient way to execute a cross-currency transaction.
@@ -554,7 +569,7 @@ XRP Ledgerアカウントが[マルチ署名](multi-signing.html) SignerListを
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:---------|
| B4E4F5D2D6FB84DF7399960A732309C9FD530EAE5941838160042833625A6076 | 投票中 |
| B4E4F5D2D6FB84DF7399960A732309C9FD530EAE5941838160042833625A6076 | 有効 |
<!-- TODO: translate amendment description -->
Implements a "Negative UNL" system, where the network can track which validators are temporarily offline and disregard those validators for quorum calculations. This can improve the liveness of the network during periods of network instability.
@@ -640,7 +655,7 @@ For more information, see [`rippled` issue #3042](https://github.com/ripple/ripp
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:---------|
| 955DF3FA5891195A9DAEFA1DDC6BB244B545DDE1BAA84CBB25D5F12A8DA68A0C | 投票中 |
| 955DF3FA5891195A9DAEFA1DDC6BB244B545DDE1BAA84CBB25D5F12A8DA68A0C | 有効 |
<!-- TODO: translate amendment description -->
This amendment adds [Tickets](tickets.html) as a way of sending transactions out of the typical sequence number order.

456
content/concepts/consensus-network/amendments/known-amendments.md
View File

@@ -14,13 +14,14 @@ The following is a comprehensive list of all known [amendments](amendments.html)
| Name | Introduced | Status |
|:--------------------------------|:-----------|:------------------------------|
| [CheckCashMakesTrustLine][] | v1.8.0 | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [CryptoConditionsSuite][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [OwnerPaysFee][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [NegativeUNL][] | v1.7.3 | [Open for Voting: TBD](https://xrpl.org/blog/2021/rippled-1.7.3.html "BADGE_80d0e0") |
| [fixRmSmallIncreasedQOffers][] | v1.7.2 | [Open for Voting: TBD](https://xrpl.org/blog/2021/rippled-1.7.2.html "BADGE_80d0e0") |
| [fixSTAmountCanonicalize][] | v1.7.0 | [Open for Voting: TBD](https://xrpl.org/blog/2021/rippled-1.7.0.html "BADGE_80d0e0") |
| [FlowSortStrands][] | v1.7.0 | [Open for Voting: TBD](https://xrpl.org/blog/2021/rippled-1.7.0.html "BADGE_80d0e0") |
| [TicketBatch][] | v1.7.0 | [Open for Voting: TBD](https://xrpl.org/blog/2021/rippled-1.7.0.html "BADGE_80d0e0") |
| [NegativeUNL][] | v1.7.3 | [Enabled: 2021-11-21](https://livenet.xrpl.org/transactions/1500FADB73E7148191216C53040990E829C7110788B26E7F3246CB3660769EBA "BADGE_GREEN") |
| [fixRmSmallIncreasedQOffers][] | v1.7.2 | [Enabled: 2021-11-18](https://livenet.xrpl.org/transactions/1F37BA0502576DD7B5464F47641FA95DEB55735EC2663269DFD47810505478E7 "BADGE_GREEN") |
| [TicketBatch][] | v1.7.0 | [Enabled: 2021-11-18](https://livenet.xrpl.org/transactions/111B32EDADDE916206E7315FBEE2DA1521B229F207F65DD314829F13C8D9CA36 "BADGE_GREEN") |
| [fixSTAmountCanonicalize][] | v1.7.0 | [Enabled: 2021-11-11](https://livenet.xrpl.org/transactions/AFF17321A012C756B64FCC3BA0FDF79109F28E244D838A28D5AE8A0384C7C532 "BADGE_GREEN") |
| [FlowSortStrands][] | v1.7.0 | [Enabled: 2021-11-11](https://livenet.xrpl.org/transactions/1C3D3BD2AFDAF326EBFEA54579A89B024856609DB4310F7140086AAB262D09A1 "BADGE_GREEN") |
| [fix1781][] | v1.6.0 | [Enabled: 2021-04-08](https://livenet.xrpl.org/transactions/DA59F10201D651B544F65896330AFACA8CA4198904265AD279D56781F655FAFB "BADGE_GREEN") |
| [fixAmendmentMajorityCalc][] | v1.6.0 | [Enabled: 2021-04-08](https://livenet.xrpl.org/transactions/5B3ACE6CAC9C56D2008410F1B0881A0A4A8866FB99D2C2B2261C86C760DC95EF "BADGE_GREEN") |
| [HardenedValidations][] | v1.6.0 | [Enabled: 2021-04-08](https://livenet.xrpl.org/transactions/3A45DCF055B68DCBBFE034240F9359FB22E8A64B1BF7113304535BF5BB8144BF "BADGE_GREEN") |
@@ -65,12 +66,32 @@ The following is a comprehensive list of all known [amendments](amendments.html)
**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.
## CheckCashMakesTrustLine
[CheckCashMakesTrustLine]: #checkcashmakestrustline
| Amendment | CheckCashMakesTrustLine |
|:----------|:-----------|
| Amendment ID | 98DECF327BF79997AEC178323AD51A830E457BFC6D454DAF3E46E5EC42DC619F |
| Status | In Development |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
Adjusts the [CheckCash transaction][] so that cashing a [Check](checks.html) for an issued token automatically creates a [trust line](trust-lines-and-issuing.html) to hold the token. The new behavior is similar to how the [OfferCreate transaction][] behaves when users purchase tokens in the decentralized exchange: the automatic trust line has a limit value of 0. This removes the setup step of setting up a trust line before receiving a token via a Check. (Checks that send XRP are unaffected.)
Without this amendment, users have to separately send a [TrustSet transaction][] before they can cash a Check for an issued token.
This amendment does not change the fact that you cannot force anyone to hold tokens they don't want in the XRP Ledger.
## Checks
[Checks]: #checks
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1 | Enabled |
| Amendment | Checks |
|:----------|:-----------|
| Amendment ID | 157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Introduces "Checks" to the XRP Ledger. Checks work similarly to personal paper checks. 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. If cashing the Check fails, the Check object remains in the ledger so it may be successfully cashed later.
@@ -84,9 +105,12 @@ This amendment also changes the OfferCreate transaction to return `tecEXPIRED` w
## CryptoConditions
[CryptoConditions]: #cryptoconditions
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146 | Enabled |
| Amendment | CryptoConditions |
|:----------|:-----------|
| Amendment ID | 1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
Although this amendment is enabled, it has no effect unless the [SusPay](#suspay) amendment is also enabled. The SusPay amendment was replaced by the [Escrow](#escrow) amendment, so the CryptoConditions amendment has no effect.
@@ -94,9 +118,12 @@ Although this amendment is enabled, it has no effect unless the [SusPay](#suspay
## CryptoConditionsSuite
[CryptoConditionsSuite]: #cryptoconditionssuite
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 86E83A7D2ECE3AD5FA87AB2195AE015C950469ABF0B72EAACED318F74886AE90 | In Development |
| Amendment | CryptoConditionsSuite |
|:----------|:-----------|
| Amendment ID | 86E83A7D2ECE3AD5FA87AB2195AE015C950469ABF0B72EAACED318F74886AE90 |
| Status | In Development |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
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.
@@ -106,9 +133,12 @@ Implements several types of crypto-conditions from the official [crypto-conditio
## DeletableAccounts
[DeletableAccounts]: #deletableaccounts
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 30CD365592B8EE40489BA01AE2F7555CAC9C983145871DC82A42A31CF5BAE7D9 | Enabled |
| Amendment | DeletableAccounts |
|:----------|:-----------|
| Amendment ID | 30CD365592B8EE40489BA01AE2F7555CAC9C983145871DC82A42A31CF5BAE7D9 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Makes it possible to delete [accounts](accounts.html).
@@ -120,9 +150,12 @@ With this amendment, new accounts start with their `Sequence` numbers equal to t
## DepositAuth
[DepositAuth]: #depositauth
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064 | Enabled |
| Amendment | DepositAuth |
|:----------|:-----------|
| Amendment ID | F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Adds a new account flag, `DepositAuth`, which lets an account strictly reject any incoming money from transactions sent by other accounts. Businesses can use this flag to comply with strict regulations that require due diligence before receiving money from any source.
@@ -136,9 +169,12 @@ Also fixes a bug in the EscrowCreate and PaymentChannelCreate transactions where
## DepositPreauth
[DepositPreauth]: #depositpreauth
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 3CBC5C4E630A1B82380295CDA84B32B49DD066602E74E39B85EF64137FA65194 | Enabled |
| Amendment | DepositPreauth |
|:----------|:-----------|
| Amendment ID | 3CBC5C4E630A1B82380295CDA84B32B49DD066602E74E39B85EF64137FA65194 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Provides users of [deposit authorization](depositauth.html) with a way to preauthorize specific senders so those senders are allowed to send payments directly.
@@ -150,9 +186,12 @@ Also changes the behavior of cross-currency Payments from an account to itself w
## EnforceInvariants
[EnforceInvariants]: #enforceinvariants
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| DC9CA96AEA1DCF83E527D1AFC916EFAF5D27388ECA4060A88817C1238CAEE0BF | Enabled |
| Amendment | EnforceInvariants |
|:----------|:-----------|
| Amendment ID | DC9CA96AEA1DCF83E527D1AFC916EFAF5D27388ECA4060A88817C1238CAEE0BF |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
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. Future versions of `rippled` may add more invariants without additional amendments.
@@ -170,9 +209,12 @@ Examples of invariant checks:
## Escrow
[Escrow]: #escrow
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104 | Enabled |
| Amendment | Escrow |
|:----------|:-----------|
| Amendment ID | 07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
Replaces the [SusPay](#suspay) and [CryptoConditions](#cryptoconditions) amendments.
@@ -182,9 +224,12 @@ Provides "suspended payments" for XRP for escrow within the XRP Ledger, includin
## FeeEscalation
[FeeEscalation]: #feeescalation
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE | Enabled |
| Amendment | FeeEscalation |
|:----------|:-----------|
| Amendment ID | 42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
Changes the way the [transaction cost](transaction-cost.html) applies to proposed transactions. Modifies the consensus process to prioritize transactions that pay a higher transaction cost. <!-- STYLE_OVERRIDE: prioritize -->
@@ -202,9 +247,12 @@ A transaction remains in the queue until one of the following happens:
## fix1201
[fix1201]: #fix1201
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| B4D44CC3111ADD964E846FC57760C8B50FFCD5A82C86A72756F6B058DDDF96AD | Enabled |
| Amendment | fix1201 |
|:----------|:-----------|
| Amendment ID | B4D44CC3111ADD964E846FC57760C8B50FFCD5A82C86A72756F6B058DDDF96AD |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
Correctly implements a limit on [transfer fees](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 2<sup>32</sup>-1, for approximately a 329% fee.
@@ -214,9 +262,12 @@ With this amendment enabled, an [AccountSet][] transaction that attempts to set
## fix1368
[fix1368]: #fix1368
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| E2E6F2866106419B88C50045ACE96368558C345566AC8F2BDF5A5B5587F0E6FA | Enabled |
| Amendment | fix1368 |
|:----------|:-----------|
| Amendment ID | E2E6F2866106419B88C50045ACE96368558C345566AC8F2BDF5A5B5587F0E6FA |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
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.
@@ -224,9 +275,12 @@ Fixes a minor bug in transaction processing that causes some payments to fail wh
## fix1373
[fix1373]: #fix1373
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 42EEA5E28A97824821D4EF97081FE36A54E9593C6E4F20CBAE098C69D2E072DC | Enabled |
| Amendment | fix1373 |
|:----------|:-----------|
| Amendment ID | 42EEA5E28A97824821D4EF97081FE36A54E9593C6E4F20CBAE098C69D2E072DC |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
Fixes a minor bug in transaction processing that causes failures when trying to prepare certain [payment paths](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.
@@ -236,9 +290,12 @@ The fix1373 amendment corrects the issue so that the paths are properly prepared
## fix1512
[fix1512]: #fix1512
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 6C92211186613F9647A89DFFBAB8F94C99D4C7E956D495270789128569177DA1 | Enabled |
| Amendment | fix1512 |
|:----------|:-----------|
| Amendment ID | 6C92211186613F9647A89DFFBAB8F94C99D4C7E956D495270789128569177DA1 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
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](transaction-cost.html).
@@ -248,9 +305,12 @@ With this amendment, the transactions fail with a more appropriate result code,
## fix1513
[fix1513]: #fix1513
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172 | Enabled |
| Amendment | fix1513 |
|:----------|:-----------|
| Amendment ID | 67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Fixes a bug that resulted in transaction processing not using new `STAmountCalcSwitchovers` code when the `FeeEscalation` amendment is enabled.
@@ -260,9 +320,12 @@ With this amendment, the new `STAmountCalcSwitchovers` code applies, which may c
## fix1515
[fix1515]: #fix1515
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 5D08145F0A4983F23AFFFF514E83FAD355C5ABFBB6CAB76FB5BC8519FF5F33BE | Enabled |
| Amendment | fix1515 |
|:----------|:-----------|
| Amendment ID | 5D08145F0A4983F23AFFFF514E83FAD355C5ABFBB6CAB76FB5BC8519FF5F33BE |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Changes how Payment transactions consume offers to remove a minor difference in how payment processing and offer processing consume liquidity. (Also affects how OfferCreate transactions are processed if [FlowCross][] is enabled.)
@@ -276,9 +339,12 @@ In both cases, transaction processing can still complete by using liquidity from
## fix1523
[fix1523]: #fix1523
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| B9E739B8296B4A1BB29BE990B17D66E21B62A300A909F25AC55C22D6C72E1F9D | Enabled |
| Amendment | fix1523 |
|:----------|:-----------|
| Amendment ID | B9E739B8296B4A1BB29BE990B17D66E21B62A300A909F25AC55C22D6C72E1F9D |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
Adds tracking by destination account to [escrows](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 method][], 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 method][].
@@ -288,9 +354,12 @@ With this amendment, new escrows are added to the [owner directories](directoryn
## fix1528
[fix1528]: #fix1528
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 1D3463A5891F9E589C5AE839FFAC4A917CE96197098A1EF22304E1BC5B98A454 | Enabled |
| Amendment | fix1528 |
|:----------|:-----------|
| Amendment ID | 1D3463A5891F9E589C5AE839FFAC4A917CE96197098A1EF22304E1BC5B98A454 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
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.
@@ -300,9 +369,12 @@ This amendment changes how validators negotiate the close time of the consensus
## fix1543
[fix1543]: #fix1543
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| CA7C02118BA27599528543DFE77BA6838D1B0F43B447D4D7F53523CE6A0E9AC2 | Enabled |
| Amendment | fix1543 |
|:----------|:-----------|
| Amendment ID | CA7C02118BA27599528543DFE77BA6838D1B0F43B447D4D7F53523CE6A0E9AC2 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Enforces reserved flag ranges on some transaction types that did not correctly enforce them already. Transactions of the affected types are now considered invalid if they enable undefined or unknown flags, or flags from the reserved range. (Transactions unaffected by this change already correctly enforce the same rules.)
@@ -317,9 +389,12 @@ The affected transaction types are:
## fix1571
[fix1571]: #fix1571
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 7117E2EC2DBF119CA55181D69819F1999ECEE1A0225A7FD2B9ED47940968479C | Enabled |
| Amendment | fix1571 |
|:----------|:-----------|
| Amendment ID | 7117E2EC2DBF119CA55181D69819F1999ECEE1A0225A7FD2B9ED47940968479C |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Changes Escrow to fix the following issues:
@@ -330,9 +405,12 @@ Changes Escrow to fix the following issues:
## fix1578
[fix1578]: #fix1578
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| FBD513F1B893AC765B78F250E6FFA6A11B573209D1842ADC787C850696741288 | Enabled |
| Amendment | fix1578 |
|:----------|:-----------|
| Amendment ID | FBD513F1B893AC765B78F250E6FFA6A11B573209D1842ADC787C850696741288 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Changes the result codes returned by two transaction types:
@@ -343,9 +421,12 @@ Changes the result codes returned by two transaction types:
## fix1623
[fix1623]: #fix1623
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 58BE9B5968C4DA7C59BA900961828B113E5490699B21877DEF9A31E9D0FE5D5F | Enabled |
| Amendment | fix1623 |
|:----------|:-----------|
| Amendment ID | 58BE9B5968C4DA7C59BA900961828B113E5490699B21877DEF9A31E9D0FE5D5F |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Adds delivered amount to metadata for CheckCash transactions cashed for a flexible amount. (Has no effect unless the [Checks](#checks) amendment is enabled.)
@@ -357,9 +438,12 @@ The fix1623 amendment has no effect on [CheckCash transactions][] for a fixed am
## fix1781
[fix1781]: #fix1781
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 25BA44241B3BD880770BFA4DA21C7180576831855368CBEC6A3154FDE4A7676E | Enabled |
| Amendment | fix1781 |
|:----------|:-----------|
| Amendment ID | 25BA44241B3BD880770BFA4DA21C7180576831855368CBEC6A3154FDE4A7676E |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Fixes a bug where certain XRP endpoints were not checked when detecting circular paths.
@@ -371,9 +455,12 @@ With this amendment, those payments fail with the [`temBAD_PATH_LOOP` result cod
## fixAmendmentMajorityCalc
[fixAmendmentMajorityCalc]: #fixamendmentmajoritycalc
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 4F46DF03559967AC60F2EB272FEFE3928A7594A45FF774B87A7E540DB0F8F068 | Enabled |
| Amendment | fixAmendmentMajorityCalc |
|:----------|:-----------|
| Amendment ID | 4F46DF03559967AC60F2EB272FEFE3928A7594A45FF774B87A7E540DB0F8F068 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Fixes a bug that could cause an amendment to achieve a majority and later activate with support of slightly less than 80% of trusted validators due to rounding semantics.
@@ -383,9 +470,12 @@ Without this amendment, the minimum threshold for amendment activation is any va
## fixCheckThreading
[fixCheckThreading]: #fixcheckthreading
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 8F81B066ED20DAECA20DF57187767685EEF3980B228E0667A650BAF24426D3B4 | Enabled |
| Amendment | fixCheckThreading |
|:----------|:-----------|
| Amendment ID | 8F81B066ED20DAECA20DF57187767685EEF3980B228E0667A650BAF24426D3B4 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Changes the way Checks transactions affect account metadata, so that Checks are properly added to the [account](accounts.html) history of the receiving account. (Specifically, they update the `PreviousTxnID` and `PreviousTxnLedgerSeq` fields of the receiving account's [AccountRoot object](accountroot.html), which can be used to trace the "thread" of transactions that affected the account and the objects it owns.)
@@ -395,9 +485,12 @@ Without this amendment, Checks transactions ([CheckCreate][], [CheckCash][], and
## fixMasterKeyAsRegularKey
[fixMasterKeyAsRegularKey]: #fixmasterkeyasregularkey
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| C4483A1896170C66C098DEA5B0E024309C60DC960DE5F01CD7AF986AA3D9AD37 | Enabled |
| Amendment | fixMasterKeyAsRegularKey |
|:----------|:-----------|
| Amendment ID | C4483A1896170C66C098DEA5B0E024309C60DC960DE5F01CD7AF986AA3D9AD37 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Fixes a bug where accounts can set their regular key pair to match their master key pair, but cannot send transactions signed by the key if the master key is disabled.
@@ -409,9 +502,12 @@ With this amendment enabled, a SetRegularKey transaction cannot set the regular
## fixPayChanRecipientOwnerDir
[fixPayChanRecipientOwnerDir]: #fixpaychanrecipientownerdir
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 621A0B264970359869E3C0363A899909AAB7A887C8B73519E4ECF952D33258A8 | Enabled |
| Amendment | fixPayChanRecipientOwnerDir |
|:----------|:-----------|
| Amendment ID | 621A0B264970359869E3C0363A899909AAB7A887C8B73519E4ECF952D33258A8 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Changes the [PaymentChannelCreate transaction][] type so that it adds new [payment channels](payment-channels.html) to the recipient's [owner directory](directorynode.html). Without this amendment, new payment channels are added only to the sender's owner directory; with this amendment enabled, newly-created payment channels are added to both owner directories. Existing payment channels are unchanged.
@@ -421,9 +517,12 @@ This change prevents accounts from being deleted if they are the recipient for o
## fixQualityUpperBound
[fixQualityUpperBound]: #fixqualityupperbound
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 89308AF3B8B10B7192C4E613E1D2E4D9BA64B2EE2D5232402AE82A6A7220D953 | Enabled |
| Amendment | fixQualityUpperBound |
|:----------|:-----------|
| Amendment ID | 89308AF3B8B10B7192C4E613E1D2E4D9BA64B2EE2D5232402AE82A6A7220D953 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Fixes a bug in unused code for estimating the ratio of input to output of individual steps in cross-currency payments.
@@ -433,9 +532,12 @@ This amendment has no known impact on transaction processing.
## fixRmSmallIncreasedQOffers
[fixRmSmallIncreasedQOffers]: #fixrmsmallincreasedqoffers
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| B6B3EEDC0267AB50491FDC450A398AF30DBCD977CECED8BEF2499CAB5DAC19E2 | Open for Voting |
| Amendment | fixRmSmallIncreasedQOffers |
|:----------|:-----------|
| Amendment ID | B6B3EEDC0267AB50491FDC450A398AF30DBCD977CECED8BEF2499CAB5DAC19E2 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
This amendment fixes an issue where certain Offers, when almost completely consumed, have a much lower exchange rate than when they were first placed. This occurs when the remaining amounts of one or both assets are so small that they cannot be rounded to a similar ratio as when the Offer was placed.
@@ -447,9 +549,12 @@ With this amendment, payments and trades can remove these types of Offers the sa
## fixSTAmountCanonicalize
[fixSTAmountCanonicalize]: #fixstamountcanonicalize
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 452F5906C46D46F407883344BFDD90E672B672C5E9943DB4891E3A34FEEEB9DB | Open for Voting |
| Amendment | fixSTAmountCanonicalize |
|:----------|:-----------|
| Amendment ID | 452F5906C46D46F407883344BFDD90E672B672C5E9943DB4891E3A34FEEEB9DB |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Fixes an edge case in [deserializing](serialization.html) Amount-type fields. Without this amendment, in some rare cases the operation could result in otherwise valid serialized amounts overflowing during deserialization. With this amendment, the XRP Ledger detects error conditions more quickly and eliminates the problematic corner cases.
@@ -457,9 +562,12 @@ Fixes an edge case in [deserializing](serialization.html) Amount-type fields. Wi
## fixTakerDryOfferRemoval
[fixTakerDryOfferRemoval]: #fixtakerdryofferremoval
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 2CD5286D8D687E98B41102BDD797198E81EA41DF7BD104E6561FEB104EFF2561 | Enabled |
| Amendment | fixTakerDryOfferRemoval |
|:----------|:-----------|
| Amendment ID | 2CD5286D8D687E98B41102BDD797198E81EA41DF7BD104E6561FEB104EFF2561 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Fixes a bug in [auto-bridging](autobridging.html) that can leave a dry offer in the XRP Ledger. A dry offer is an offer that, if crossed, cannot yield any funds.
@@ -471,9 +579,12 @@ With this amendment enabled, the XRP Ledger removes these dry offers when they'r
## Flow
[Flow]: #flow
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11 | Enabled |
| Amendment | Flow |
|:----------|:-----------|
| Amendment ID | 740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
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://xrpl.org/blog/2016/flowv2-vetoed.html) amendment.
@@ -483,9 +594,12 @@ The Flow Engine also makes it easier to improve and expand the payment engine wi
## FlowCross
[FlowCross]: #flowcross
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC | Enabled |
| Amendment | FlowCross |
|:----------|:-----------|
| Amendment ID | 3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
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:
@@ -497,9 +611,12 @@ Streamlines the offer crossing logic in the XRP Ledger's decentralized exchange.
## FlowSortStrands
[FlowSortStrands]: #flowsortstrands
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| AF8DF7465C338AE64B1E937D6C8DA138C0D63AD5134A68792BBBE1F63356C422 | Open for Voting |
| Amendment | FlowSortStrands |
|:----------|:-----------|
| Amendment ID | AF8DF7465C338AE64B1E937D6C8DA138C0D63AD5134A68792BBBE1F63356C422 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Improves the payment engine's calculations for finding the most cost-efficient way to execute a cross-currency transaction.
@@ -509,9 +626,11 @@ Without this change, the engine simulates a payment through each possible path t
## FlowV2
[FlowV2]: #flowv2
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 5CC22CFF2864B020BD79E0E1F048F63EF3594F95E650E43B3F837EF1DF5F4B26 | Vetoed |
| Amendment | FlowV2 |
|:----------|:-----------|
| Amendment ID | 5CC22CFF2864B020BD79E0E1F048F63EF3594F95E650E43B3F837EF1DF5F4B26 |
| Status | Vetoed |
| Pre-amendment functionality retired? | No |
This is a previous version of the [Flow](#flow) amendment. It was [rejected due to a bug](https://xrpl.org/blog/2016/flowv2-vetoed.html) and removed in version 0.33.0.
@@ -519,9 +638,12 @@ This is a previous version of the [Flow](#flow) amendment. It was [rejected due
## HardenedValidations
[HardenedValidations]: #hardenedvalidations
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 1F4AFA8FA1BC8827AD4C0F682C03A8B671DCDF6B5C4DE36D44243A684103EF88 | Enabled |
| Amendment | HardenedValidations |
|:----------|:-----------|
| Amendment ID | 1F4AFA8FA1BC8827AD4C0F682C03A8B671DCDF6B5C4DE36D44243A684103EF88 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Allows validators to include a new optional field in their validations to attest to the hash of
the latest ledger that the validator considers to be fully validated. The consensus process can use this information to increase the robustness of consensus.
@@ -530,9 +652,12 @@ the latest ledger that the validator considers to be fully validated. The consen
## MultiSign
[MultiSign]: #multisign
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 | Enabled |
| Amendment | MultiSign |
|:----------|:-----------|
| Amendment ID | 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
Introduces [multi-signing](multi-signing.html) as a way to authorize transactions. Creates the [`SignerList` ledger object type](signerlist.html) and the [`SignerListSet` transaction type](signerlistset.html). Adds the optional `Signers` field to all transaction types. Modifies some transaction result codes.
@@ -554,9 +679,12 @@ An address with a SignerList can disable the master key even if a regular key is
## MultiSignReserve
[MultiSignReserve]: #multisignreserve
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 586480873651E106F1D6339B0C4A8945BA705A777F3F4524626FF1FC07EFE41D | Enabled |
| Amendment | MultiSignReserve |
|:----------|:-----------|
| Amendment ID | 586480873651E106F1D6339B0C4A8945BA705A777F3F4524626FF1FC07EFE41D |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Reduces the [owner reserve](reserves.html#owner-reserves) counted against your XRP Ledger account when it owns a [multi-signing](multi-signing.html) SignerList.
@@ -568,9 +696,12 @@ With this amendment enabled, the owner reserve for a new SignerList is 5 XRP, re
## NegativeUNL
[NegativeUNL]: #negativeunl
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| B4E4F5D2D6FB84DF7399960A732309C9FD530EAE5941838160042833625A6076 | Open for Voting |
| Amendment | NegativeUNL |
|:----------|:-----------|
| Amendment ID | B4E4F5D2D6FB84DF7399960A732309C9FD530EAE5941838160042833625A6076 |
| Status | Enabled |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
Implements a "Negative UNL" system, where the network can track which validators are temporarily offline and disregard those validators for quorum calculations. This can improve the ability of the network to make progress during periods of network instability.
@@ -578,9 +709,12 @@ Implements a "Negative UNL" system, where the network can track which validators
## OwnerPaysFee
[OwnerPaysFee]: #ownerpaysfee
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 9178256A980A86CF3D70D0260A7DA6402AAFE43632FDBCB88037978404188871 | In Development |
| Amendment | OwnerPaysFee |
|:----------|:-----------|
| Amendment ID | 9178256A980A86CF3D70D0260A7DA6402AAFE43632FDBCB88037978404188871 |
| Status | In Development |
| Default Vote (Latest stable release) | N/A |
| Pre-amendment functionality retired? | No |
Fixes an inconsistency in the way [transfer fees](transfer-fees.html) are calculated between [OfferCreate](offercreate.html) and [Payment](payment.html) transaction types. Without this amendment, the holder of the issued currency 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 issued currency 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.
@@ -592,9 +726,12 @@ This Amendment requires the [Flow Amendment](#flow) to be enabled.
## PayChan
[PayChan]: #paychan
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647 | Enabled |
| Amendment | PayChan |
|:----------|:-----------|
| Amendment ID | 08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
Creates "Payment Channels" for XRP. Payment channels are a tool for facilitating repeated, unidirectional payments or temporary credit between two parties. This feature is expected 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 combined content of many small Claims later, as long as it is within the expiration.
@@ -606,9 +743,12 @@ For more information, see the [Payment Channels Tutorial](use-payment-channels.h
## RequireFullyCanonicalSig
[RequireFullyCanonicalSig]: #requirefullycanonicalsig
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 00C1FC4A53E60AB02C864641002B3172F38677E29C26C5406685179B37E1EDAC | Enabled |
| Amendment | RequireFullyCanonicalSig |
|:----------|:-----------|
| Amendment ID | 00C1FC4A53E60AB02C864641002B3172F38677E29C26C5406685179B37E1EDAC |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid in any case. This protects against [transaction malleability](transaction-malleability.html) on _all_ transactions, instead of only transactions with the [`tfFullyCanonicalSig` flag](transaction-common-fields.html#global-flags) enabled.
@@ -622,9 +762,11 @@ For more information, see [`rippled` issue #3042](https://github.com/ripple/ripp
## SHAMapV2
[SHAMapV2]: #shamapv2
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| C6970A8B603D8778783B61C0D445C23D1633CCFAEF0D43E7DBCD1521D34BD7C3 | Vetoed |
| Amendment | SHAMapV2 |
|:----------|:-----------|
| Amendment ID | C6970A8B603D8778783B61C0D445C23D1633CCFAEF0D43E7DBCD1521D34BD7C3 |
| Status | Vetoed |
| Pre-amendment functionality retired? | No |
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.
@@ -634,9 +776,12 @@ When this amendment is activated, the XRP Ledger will undergo a brief scheduled
## SortedDirectories
[SortedDirectories]: #sorteddirectories
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| CC5ABAE4F3EC92E94A59B1908C2BE82D2228B6485C00AFF8F22DF930D89C194E | Enabled |
| Amendment | SortedDirectories |
|:----------|:-----------|
| Amendment ID | CC5ABAE4F3EC92E94A59B1908C2BE82D2228B6485C00AFF8F22DF930D89C194E |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
Sorts the entries in [DirectoryNode ledger objects](directorynode.html) and fixes a bug that occasionally caused pages of owner directories not to be deleted when they should have been.
@@ -646,9 +791,11 @@ Sorts the entries in [DirectoryNode ledger objects](directorynode.html) and fixe
## SusPay
[SusPay]: #suspay
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 | Vetoed |
| Amendment | SusPay |
|:----------|:-----------|
| Amendment ID | DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 |
| Status | Vetoed |
| Pre-amendment functionality retired? | No |
This amendment was replaced by the [Escrow](escrow-object.html) amendment.
@@ -656,9 +803,12 @@ This amendment was replaced by the [Escrow](escrow-object.html) amendment.
## TicketBatch
[TicketBatch]: #ticketbatch
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 955DF3FA5891195A9DAEFA1DDC6BB244B545DDE1BAA84CBB25D5F12A8DA68A0C | Open for Voting |
| Amendment | TicketBatch |
|:----------|:-----------|
| Amendment ID | 955DF3FA5891195A9DAEFA1DDC6BB244B545DDE1BAA84CBB25D5F12A8DA68A0C |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
This amendment adds [Tickets](tickets.html) as a way of sending transactions out of the typical sequence number order.
@@ -668,9 +818,11 @@ Standards Draft: [XLS-13d](https://github.com/XRPLF/XRPL-Standards/issues/16). <
## Tickets
[Tickets]: #tickets
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 | Vetoed |
| Amendment | Tickets |
|:----------|:-----------|
| Amendment ID | C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 |
| Status | Vetoed |
| Pre-amendment functionality retired? | No |
This amendment was replaced by the [TicketBatch][] amendment.
@@ -678,9 +830,12 @@ This amendment was replaced by the [TicketBatch][] amendment.
## TickSize
[TickSize]: #ticksize
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 532651B4FD58DF8922A49BA101AB3E996E5BFBF95A913B3E392504863E63B164 | Enabled |
| Amendment | TickSize |
|:----------|:-----------|
| Amendment ID | 532651B4FD58DF8922A49BA101AB3E996E5BFBF95A913B3E392504863E63B164 |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
Changes the way [Offers](offers.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.
@@ -690,9 +845,12 @@ Introduces a `TickSize` field to accounts, which can be set with the [AccountSet
## TrustSetAuth
[TrustSetAuth]: #trustsetauth
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC | Enabled |
| Amendment | TrustSetAuth |
|:----------|:-----------|
| Amendment ID | 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
Allows pre-authorization of accounting relationships (zero-balance trust lines) when using [Authorized Trust Lines](authorized-trust-lines.html).

3
content/concepts/consensus-network/negative-unl.md
View File

@@ -1,14 +1,13 @@
---
html: negative-unl.html
parent: consensus-network.html
status: not_enabled
blurb: Understand how Negative UNL improves the ledger's resilience during partial outages.
labels:
- Blockchain
---
# Negative UNL
_The Negative UNL feature has a preliminary implementation in `rippled` 1.6.0 so that it can be used in test networks, but is not yet available as an [amendment](amendments.html) to the XRP Ledger protocol. A `NegativeUNL` amendment :not_enabled: may be included in a future XRP Ledger release based on acceptance testing of the preliminary implementation._
_Added by the [NegativeUNL Amendment](known-amendments.html#negativeunl)._
The _Negative UNL_ is a feature of the XRP Ledger [consensus protocol](consensus.html) that improves _liveness_, the network's ability to make forward progress during a partial outage. Using the Negative UNL, servers adjust their effective UNLs based on which validators are currently online and operational, so that a new [ledger version](ledgers.html) can be declared _validated_ even if several trusted validators are offline.

6
content/concepts/payment-system-basics/accounts/tickets.md
View File

@@ -2,14 +2,13 @@
html: tickets.html
parent: accounts.html
blurb: Send transactions in non-sequential order.
status: not_enabled
labels:
- Accounts
- Transaction Sending
---
# Tickets
_(Requires the [TicketBatch amendment][] :not_enabled:)_
_(Added by the [TicketBatch amendment][].)_
A Ticket in the XRP Ledger is a way of setting aside a [sequence number][Sequence Number] for a transaction without sending it right away. Tickets allow transactions to be sent outside of the normal sequence order. One use case for this is to allow for [multi-signed transactions](multi-signing.html) where it may take a while to collect the necessary signatures: while collecting signatures for a transaction that uses a Ticket, you can still send other transactions.
@@ -59,10 +58,11 @@ Any account can create and use Tickets on any type of transaction. However, some
## See Also
<!-- TODO: add a tutorial for creating & using a Ticket -->
- **Concepts:**
- [Multi-Signing](multi-signing.html)
- **Tutorials:**
- [Use Tickets](use-tickets.html)
- **References:**
- [TicketCreate transaction][]
- [Transaction Common Fields](transaction-common-fields.html)

2
content/concepts/payment-types/direct-xrp-payments.ja.md
View File

@@ -71,7 +71,7 @@ XRP Ledgerでは、支払いを受け取ることができるアドレスは永
- **XRPによる直接支払**は、単一のトランザクションでXRPを送受信する唯一の方法です。この方法は、速度、シンプルさ、低コストの面でバランスが取れています。
- [通貨間の支払い](cross-currency-payments.html)でも[Payment][]トランザクションタイプを使用しますが、XRPとXRP以外の[発行済み通貨](issued-currencies.html)を組み合わせて送金できます。ただし、XRP間の支払いは除きます。また、[Partial Payment](partial-payments.html)でも使用できます。通貨間の支払いは、XRPで指定されていない支払いや、[分散型取引所](decentralized-exchange.html)で裁定取引の機会を得るのに適しています。
- [Checks](checks.html) :not_enabled: すぐに送金せずに送金元に債務を設定してもらいます。受取人は有効期間内であればいつでも換金できますが、その金額は保証されません。Checksでは、XRPまたは発行済み通貨のいずれかを送金できます。Checksは、受取人に支払いを請求する自律性を与えるのに適しています。
- [Checks](checks.html)すぐに送金せずに送金元に債務を設定してもらいます。受取人は有効期間内であればいつでも換金できますが、その金額は保証されません。Checksでは、XRPまたは発行済み通貨のいずれかを送金できます。Checksは、受取人に支払いを請求する自律性を与えるのに適しています。
- [Escrow](escrow.html)では、特定の条件が満たされたときに、意図した受取人が要求できるXRPを確保します。XRPの金額は完全に保証されており、Escrowの有効期限が切れない限り、送金元が使用することはできません。Escrowは、巨額のスマートコントラクトに適しています。
- [Payment Channel](payment-channels.html)では、XRPが確保されます。受取人は、署名による認証を使用して、チャネルから一括でXRPを要求できます。XRP Ledgerの全トランザクションを送信せずに、認証を個々に確認できます。Payment Channelは、極めて大量の小口決済または「ストリーミング」支払いに適しています。

2
content/references/protocol-reference/ledger-data/ledger-object-types/accountroot.md
View File

@@ -51,7 +51,7 @@ The `AccountRoot` object has the following fields:
| `EmailHash` | String | Hash128 | _(Optional)_ The md5 hash of an email address. Clients can use this to look up an avatar through services such as [Gravatar](https://en.gravatar.com/). |
| `MessageKey` | String | Blob | _(Optional)_ A public key that may be used to send encrypted messages to this account. In JSON, uses hexadecimal. Must be exactly 33 bytes, with the first byte indicating the key type: `0x02` or `0x03` for secp256k1 keys, `0xED` for Ed25519 keys. |
| `RegularKey` | String | AccountID | _(Optional)_ The address of a [key pair](cryptographic-keys.html) that can be used to sign transactions for this account instead of the master key. Use a [SetRegularKey transaction][] to change this value. |
| `TicketCount` | Number | UInt32 | _(Optional)_ How many [Tickets](tickets.html) this account owns in the ledger. This is updated automatically to ensure that the account stays within the hard limit of 250 Tickets at a time. This field is omitted if the account has zero Tickets. _(Added by the [TicketBatch amendment][] :not_enabled:)_ |
| `TicketCount` | Number | UInt32 | _(Optional)_ How many [Tickets](tickets.html) this account owns in the ledger. This is updated automatically to ensure that the account stays within the hard limit of 250 Tickets at a time. This field is omitted if the account has zero Tickets. _(Added by the [TicketBatch amendment][].)_ |
| `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. _(Added by the [TickSize amendment][].)_ |
| `TransferRate` | Number | UInt32 | _(Optional)_ A [transfer fee](transfer-fees.html) to charge other users for sending currency issued by this account to each other. |
| `WalletLocator` | String | Hash256 | _(Optional)_ **DEPRECATED**. Do not use. |

3
content/references/protocol-reference/ledger-data/ledger-object-types/negativeunl.md
View File

@@ -1,14 +1,13 @@
---
html: negativeunl.html
parent: ledger-object-types.html
status: not_enabled
blurb: List of validators currently believed to be offline.
labels:
- Blockchain
---
# NegativeUNL
_(Requires the [NegativeUNL amendment][] :not_enabled:)_
_(Added by the [NegativeUNL amendment][].)_
The `NegativeUNL` object type contains the current status of the [Negative UNL](negative-unl.html), a list of trusted validators currently believed to be offline.

3
content/references/protocol-reference/ledger-data/ledger-object-types/ticket.md
View File

@@ -2,7 +2,6 @@
html: ticket.html
parent: ledger-object-types.html
blurb: A Ticket tracks an account sequence number that has been set aside for future use.
status: not_enabled
labels:
- Transaction Sending
---
@@ -10,7 +9,7 @@ labels:
[[Source]](https://github.com/ripple/rippled/blob/76a6956138c4ecd156c5c408f136ed3d6ab7d0c1/src/ripple/protocol/impl/LedgerFormats.cpp#L155-L164)
_(Requires the [TicketBatch amendment][] :not_enabled:)_
_(Added by the [TicketBatch amendment][].)_
The `Ticket` object type represents a [Ticket](tickets.html), which tracks an account [sequence number][Sequence Number] that has been set aside for future use. You can create new tickets with a [TicketCreate transaction][]. [New in: rippled 1.7.0][]

3
content/references/protocol-reference/transactions/pseudo-transaction-types/unlmodify.md
View File

@@ -1,14 +1,13 @@
---
html: unlmodify.html
parent: pseudo-transaction-types.html
status: not_enabled
blurb: Change the list of trusted validators currently considered offline.
labels:
- Blockchain
---
# UNLModify
_(Requires the [NegativeUNL amendment][] :not_enabled:)_
_(Added by the [NegativeUNL amendment][].)_
A `UNLModify` [pseudo-transaction](pseudo-transaction-types.html) marks a change to the [Negative UNL](negative-unl.html), indicating that a trusted validator has gone offline or come back online.

4
content/references/protocol-reference/transactions/transaction-common-fields.md
View File

@@ -14,7 +14,7 @@ Every transaction has the same set of common fields, plus additional fields base
| `Account` | String | AccountID | _(Required)_ The unique address of the [account](accounts.html) that initiated the transaction. |
| `TransactionType` | String | UInt16 | _(Required)_ The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, `AccountSet`, `AccountDelete`, `SetRegularKey`, `SignerListSet`, `EscrowCreate`, `EscrowFinish`, `EscrowCancel`, `PaymentChannelCreate`, `PaymentChannelFund`, `PaymentChannelClaim`, and `DepositPreauth`. |
| `Fee` | String | Amount | _(Required; [auto-fillable][])_ Integer amount of XRP, in drops, to be destroyed as a cost for distributing this transaction to the network. Some transaction types have different minimum requirements. See [Transaction Cost][] for details. |
| `Sequence` | Number | UInt32 | _(Required; [auto-fillable][])_ The [sequence number](basic-data-types.html#account-sequence) of the account sending the transaction. A transaction is only valid if the `Sequence` number is exactly 1 greater than the previous transaction from the same account. The special case `0` means the transaction is using a [Ticket](tickets.html) instead _(Requires the [TicketBatch amendment][] :not_enabled:)_. |
| `Sequence` | Number | UInt32 | _(Required; [auto-fillable][])_ The [sequence number](basic-data-types.html#account-sequence) of the account sending the transaction. A transaction is only valid if the `Sequence` number is exactly 1 greater than the previous transaction from the same account. The special case `0` means the transaction is using a [Ticket](tickets.html) instead _(Added by the [TicketBatch amendment][].)_. |
| [`AccountTxnID`](#accounttxnid) | String | Hash256 | _(Optional)_ Hash value identifying another transaction. If provided, this transaction is only valid if the sending account's previously-sent transaction matches the provided hash. |
| [`Flags`](#flags-field) | Number | UInt32 | _(Optional)_ Set of bit-flags for this transaction. |
| `LastLedgerSequence` | Number | UInt32 | _(Optional; strongly recommended)_ Highest ledger index this transaction can appear in. Specifying this field places a strict upper limit on how long the transaction can wait to be validated or rejected. See [Reliable Transaction Submission](reliable-transaction-submission.html) for more details. |
@@ -40,7 +40,7 @@ Unlike the `PreviousTxnID` field, which tracks the last transaction to _modify_
One situation in which this is useful is if you have a primary system for submitting transactions and a passive backup system. If the passive backup system becomes disconnected from the primary, but the primary is not fully dead, and they both begin operating at the same time, you could potentially have serious problems like some transactions sending twice and others not at all. Chaining your transactions together with `AccountTxnID` ensures that, even if both systems are active, only one of them can submit valid transactions at a time.
The `AccountTxnID` field cannot be used on transactions that use [Tickets](tickets.html) :not_enabled:. Transactions that use `AccountTxnID` cannot be placed in the [transaction queue](transaction-queue.html).
The `AccountTxnID` field cannot be used on transactions that use [Tickets](tickets.html). Transactions that use `AccountTxnID` cannot be placed in the [transaction queue](transaction-queue.html).

2
content/references/protocol-reference/transactions/transaction-types/accountdelete.ja.md
View File

@@ -9,7 +9,7 @@ labels:
[[ソース]](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/DeleteAccount.cpp "Source")
_[DeletableAccounts Amendment](known-amendments.html#deletableaccounts)が必要です :not_enabled:_
_[DeletableAccounts Amendment](known-amendments.html#deletableaccounts)が必要です_
AccountDeleteトランザクションは、XRP Ledgerで[アカウント](accountroot.html)と、アカウントが所有するオブジェクトを削除し、可能であれば、アカウントの残りのXRPを指定された送金先アカウントに送信します。アカウントを削除する要件については、[アカウントの削除](accounts.html#アカウントの削除)を参照してください。

2
content/references/protocol-reference/transactions/transaction-types/escrowcancel.md
View File

@@ -31,7 +31,7 @@ Return escrowed XRP to the sender.
| Field | JSON Type | [Internal Type][] | Description |
|:----------------|:----------|:------------------|:---------------------------|
| `Owner` | String | AccountID | Address of the source account that funded the escrow payment. |
| `OfferSequence` | Number | UInt32 | Transaction sequence (or [Ticket](tickets.html) :not_enabled: number) of [EscrowCreate transaction][] that created the escrow to cancel. |
| `OfferSequence` | Number | UInt32 | Transaction sequence (or [Ticket](tickets.html) number) of [EscrowCreate transaction][] that created the escrow to cancel. |
Any account may submit an EscrowCancel transaction.

2
content/references/protocol-reference/transactions/transaction-types/offercancel.md
View File

@@ -31,7 +31,7 @@ An OfferCancel transaction removes an Offer object from the XRP Ledger.
| Field | JSON Type | [Internal Type][] | Description |
|:----------------|:----------|:------------------|:-----------------------------|
| `OfferSequence` | Number | UInt32 | The sequence number (or [Ticket](tickets.html) :not_enabled: number) of a previous OfferCreate transaction. If specified, cancel any offer object in the ledger that was created by that transaction. It is not considered an error if the offer specified does not exist. |
| `OfferSequence` | Number | UInt32 | The sequence number (or [Ticket](tickets.html) number) of a previous OfferCreate transaction. If specified, cancel any offer object in the ledger that was created by that transaction. It is not considered an error if the offer specified does not exist. |
*Tip:* To remove an old offer and replace it with a new one, you can use an [OfferCreate transaction][] with an `OfferSequence` parameter, instead of using OfferCancel and another OfferCreate.

2
content/references/protocol-reference/transactions/transaction-types/paymentchannelclaim.ja.md
View File

@@ -54,7 +54,7 @@ Channelの**宛先アドレス**は以下の操作を実行できます。
| `Signature` | 文字列 | Blob | _（省略可）_ クレームの署名です（16進数）。署名付きメッセージには、Channel IDとクレームの額が含まれています。トランザクションの送信者がChannelの支払元アドレスでない場合には必須です。 |
| `PublicKey` | 文字列 | Blob | _（省略可）_ 署名に使用する公開鍵（16進数）。公開鍵はレジャーに保管されているこのChannelの`PublicKey`と一致している必要があります。トランザクションの送信者がChannelの支払元アドレスでない場合には必須です。また`Signature`フィールドは省略されます。（`rippled`がトランザクションをレジャーに適用する前に署名の有効性をチェックできるように、トランザクションにPubKeyが指定されています。） |
[DeletableAccounts Amendment](known-amendments.html#deletableaccounts) :not_enabledが有効であり、 _かつ_ Payment Channelの作成時に[fixPayChanRecipientOwnerDir Amendment](known-amendments.html#fixpaychanrecipientownerdir) :not_enabled:が有効でなかった場合は、Payment Channelの送金先が[削除](accounts.html#アカウントの削除)され、現在レジャーに存在しない可能性があります。宛先が削除されている場合、支払元アカウントはチャネルから宛先にXRPを送金できません。トランザクションは`tecNO_DST`で失敗します。（もちろん、削除されたアカウントがトランザクションを送信することはできません。）宛先アカウントが削除されている場合に、このトランザクションタイプを他の用途（チャネルの有効期限の調整、XRPのないチャネルのクローズ、有効期限を過ぎたチャネルの削除など）で使用しても影響はありません。
[DeletableAccounts Amendment](known-amendments.html#deletableaccounts) :not_enabledが有効であり、 _かつ_ Payment Channelの作成時に[fixPayChanRecipientOwnerDir Amendment](known-amendments.html#fixpaychanrecipientownerdir)が有効でなかった場合は、Payment Channelの送金先が[削除](accounts.html#アカウントの削除)され、現在レジャーに存在しない可能性があります。宛先が削除されている場合、支払元アカウントはチャネルから宛先にXRPを送金できません。トランザクションは`tecNO_DST`で失敗します。（もちろん、削除されたアカウントがトランザクションを送信することはできません。）宛先アカウントが削除されている場合に、このトランザクションタイプを他の用途（チャネルの有効期限の調整、XRPのないチャネルのクローズ、有効期限を過ぎたチャネルの削除など）で使用しても影響はありません。
## PaymentChannelClaimフラグ

3
content/references/protocol-reference/transactions/transaction-types/ticketcreate.md
View File

@@ -2,7 +2,6 @@
html: ticketcreate.html
parent: transaction-types.html
blurb: Set aside one or more sequence numbers as Tickets.
status: not_enabled
labels:
- Transaction Sending
---
@@ -10,7 +9,7 @@ labels:
[[Source]](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/CreateTicket.cpp "Source")
_(Requires the [TicketBatch amendment][] :not_enabled:)_
_(Added by the [TicketBatch amendment][].)_
A TicketCreate transaction sets aside one or more [sequence numbers][Sequence Number] as [Tickets](tickets.html).

4
content/references/rippled-api/public-rippled-methods/account-methods/account_lines.md
View File

@@ -429,8 +429,8 @@ Each trust line object has some combination of the following fields:
| `limit_peer` | String | The maximum amount of currency that the counterparty account is willing to owe the perspective account |
| `quality_in` | Unsigned Integer | Rate at which the account values incoming balances on this trust line, as a ratio of this value per 1 billion units. (For example, a value of 500 million represents a 0.5:1 ratio.) As a special case, 0 is treated as a 1:1 ratio. |
| `quality_out` | Unsigned Integer | Rate at which the account values outgoing balances on this trust line, as a ratio of this value per 1 billion units. (For example, a value of 500 million represents a 0.5:1 ratio.) As a special case, 0 is treated as a 1:1 ratio. |
| `no_ripple` | Boolean | _(May be omitted)_ If `true`, this account has enabled the [No Ripple flag](rippling.html) for this trust line. If present and `false`, this account has disabled the No Ripple flag, but, because the account also has the Default Ripple flag enabled, that is not considered [the default state](ripplestate.html#contributing-to-the-owner-reserve). If omitted, the account has the No Ripple flag disabled for this trust line and Default Ripple disabled. [Updated in: rippled 1.7.0][] |
| `no_ripple_peer` | Boolean | _(May be omitted)_ If `true`, the peer account has enabled the [No Ripple flag](rippling.html) for this trust line. If present and `false`, this account has disabled the No Ripple flag, but, because the account also has the Default Ripple flag enabled, that is not considered [the default state](ripplestate.html#contributing-to-the-owner-reserve). If omitted, the account has the No Ripple flag disabled for this trust line and Default Ripple disabled. [Updated in: rippled 1.7.0][] |
| `no_ripple` | Boolean | _(May be omitted)_ If `true`, this account has enabled the [No Ripple flag](rippling.html) for this trust line. If present and `false`, this account has disabled the No Ripple flag, but, because the account also has the Default Ripple flag disabled, that is not considered [the default state](ripplestate.html#contributing-to-the-owner-reserve). If omitted, the account has the No Ripple flag disabled for this trust line and Default Ripple enabled. [Updated in: rippled 1.7.0][] |
| `no_ripple_peer` | Boolean | _(May be omitted)_ If `true`, the peer account has enabled the [No Ripple flag](rippling.html) for this trust line. If present and `false`, this account has disabled the No Ripple flag, but, because the account also has the Default Ripple flag disabled, that is not considered [the default state](ripplestate.html#contributing-to-the-owner-reserve). If omitted, the account has the No Ripple flag disabled for this trust line and Default Ripple enabled. [Updated in: rippled 1.7.0][] |
| `authorized` | Boolean | _(May be omitted)_ If `true`, this account has [authorized this trust line](authorized-trust-lines.html). The default is `false`. |
| `peer_authorized`| Boolean | _(May be omitted)_ If `true`, the peer account has [authorized this trust line](authorized-trust-lines.html). The default is `false`. |
| `freeze` | Boolean | _(May be omitted)_ If `true`, this account has [frozen](freezes.html) this trust line. The default is `false`. |

4
content/references/rippled-api/public-rippled-methods/account-methods/account_objects.md
View File

@@ -20,7 +20,7 @@ The types of objects that may appear in the `account_objects` response for an ac
- [PayChannel objects](paychannel.html) for open payment channels.
- [Check objects](check.html) for pending Checks.
- [DepositPreauth objects](depositpreauth-object.html) for deposit preauthorizations. [New in: rippled 1.1.0][]
- [Ticket objects](known-amendments.html#tickets) :not_enabled: for Tickets.
- [Ticket objects](known-amendments.html#tickets) for Tickets.
## Request Format
@@ -74,7 +74,7 @@ The request includes the following parameters:
| `Field` | Type | Description |
|:-------------------------|:-----------------|:-------------------------------|
| `account` | String | A unique identifier for the account, most commonly the account's address. |
| `type` | String | _(Optional)_ If included, filter results to include only this type of ledger object. The valid types are: `check` :not_enabled:, `deposit_preauth`, `escrow`, `offer`, `payment_channel`, `signer_list`, `ticket` :not_enabled:, and `state` (trust line). <!-- Author's note: Omitted types that can't be owned by an account --> |
| `type` | String | _(Optional)_ If included, filter results to include only this type of ledger object. The valid types are: `check`, `deposit_preauth`, `escrow`, `offer`, `payment_channel`, `signer_list`, `ticket`, and `state` (trust line). <!-- Author's note: Omitted types that can't be owned by an account --> |
| `deletion_blockers_only` | Boolean | _(Optional)_ If `true`, the response only includes objects that would block this account from [being deleted](accounts.html#deletion-of-accounts). The default is `false`. [New in: rippled 1.4.0][] |
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. (See [Specifying Ledgers][]) |
| `ledger_index` | String or Number | _(Optional)_ The [ledger index][] of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying Ledgers][]) |

4
content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_entry.md
View File

@@ -92,7 +92,7 @@ rippled json ledger_entry '{ "index": "7DB0788C020F02780A673DC74757F23823FA3014C
> - [`Amendments`](amendments-object.html) - `7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4`
> - [`FeeSettings`](feesettings.html) - `4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651`
> - [Recent History `LedgerHashes`](ledgerhashes.html) - `B4979A36CDC7F3D3D5C31A4EAE2AC7D7209DDA877588B9AFC66799692AB0D66B`
> - [`NegativeUNL`](negativeunl.html) :not_enabled: - `2E8A59AA9D3B5B186B0B9E0F62E6C02587CA74A4D778938E957B6357D364B244`
> - [`NegativeUNL`](negativeunl.html) - `2E8A59AA9D3B5B186B0B9E0F62E6C02587CA74A4D778938E957B6357D364B244`
@@ -510,7 +510,7 @@ rippled json ledger_entry '{ "deposit_preauth": { "owner": "rf1BiGeXwwQoi8Z2ueFY
### Get Ticket Object
Retrieve a [Ticket object](ticket.html), which represents a [sequence number][] set aside for future use. Can be provided as string (object ID of the Ticket) or as an object. _(Requires the [TicketBatch amendment][])_ :not_enabled:
Retrieve a [Ticket object](ticket.html), which represents a [sequence number][] set aside for future use. Can be provided as string (object ID of the Ticket) or as an object. _(Added by the [TicketBatch amendment][])_
| `Field` | Type | Description |
|:------------------------|:---------------------------|:----------------------|

2
content/tutorials/get-started/monitor-incoming-payments-with-websocket.ja.md
View File

@@ -348,7 +348,7 @@ WS_HANDLERS["transaction"] = log_tx
**警告:** 代わりに`transaction.Amount`フィールドを使用すると、[Partial Paymentの悪用](partial-payments.html#partial-paymentの悪用)に対して脆弱になる可能性があります。不正使用者はこの悪用を行ってあなたをだまし、あなたが支払ったよりも多くの金額を交換または引き出すことができます。
- **[CheckCashトランザクション][]** :not_enabled: では、アカウントは別のアカウントの[CheckCreateトランザクション][]によって承認された金額を受け取ることができます。**CheckCashトランザクション**のメタデータを確認すると、アカウントが受け取った通貨の額を確認できます。
- **[CheckCashトランザクション][]**では、アカウントは別のアカウントの[CheckCreateトランザクション][]によって承認された金額を受け取ることができます。**CheckCashトランザクション**のメタデータを確認すると、アカウントが受け取った通貨の額を確認できます。
- **[EscrowFinishトランザクション][]** は、以前の[EscrowCreateトランザクション][]によって作成された[Escrow](escrow.html)を終了することでXRPを送金できます。**EscrowFinishトランザクション**のメタデータを確認すると、escrowからXRPを受け取ったアカウントと、その額を確認できます。

2
content/tutorials/manage-account-settings/offline-account-setup.ja.md
View File

@@ -94,7 +94,7 @@ Loading: "/etc/opt/ripple/rippled.cfg"
結果の`account_data`の`Sequence`フィールドにある、アカウントのシーケンス番号をメモします。この後のステップでアカウントのトランザクションに署名するために、このシーケンス番号を把握しておく必要があります。
[DeletableAccounts Amendment](known-amendments.html#deletableaccounts) :not_enabled:がenabledになっている場合、新しく資金を供給したアカウントの`Sequence`番号は、資金を供給したときの[レジャーインデックス][]と一致します。enabledになっていない場合、新しく資金を供給したアカウントの`Sequence`番号は常に1です。
[DeletableAccounts Amendment](known-amendments.html#deletableaccounts)がenabledになっている場合、新しく資金を供給したアカウントの`Sequence`番号は、資金を供給したときの[レジャーインデックス][]と一致します。enabledになっていない場合、新しく資金を供給したアカウントの`Sequence`番号は常に1です。
<!-- MULTICODE_BLOCK_START -->

7
content/tutorials/manage-account-settings/use-tickets.md
View File

@@ -3,7 +3,6 @@ html: use-tickets.html
parent: manage-account-settings.html
blurb: Use Tickets to send a transaction outside of normal Sequence order.
embed_xrpl_js: true
status: not_enabled
filters:
- interactive_steps
- include_code
@@ -12,22 +11,18 @@ labels:
---
# Use Tickets
_(Requires the [TicketBatch amendment][] :not_enabled:)_
[Tickets](tickets.html) provide a way to send transactions out of the normal order. This tutorial walks through the steps of creating a Ticket, then using it to send another transaction.
## Prerequisites
<!-- Source for this specific tutorial's interactive bits: -->
<script type="application/javascript" src="assets/js/tutorials/use-tickets.js"></script>
{% set use_network = "Devnet" %}<!--TODO: change to Testnet eventually -->
{% set use_network = "Devnet" %}<!--TODO: change to Testnet eventually. NOTE, Testnet is a few days behind Mainnet in getting the amendment one enabled -->
This page provides JavaScript examples that use the [xrpl.js](https://js.xrpl.org/) library. See [Get Started Using JavaScript](get-started-using-javascript.html) for setup instructions.
Since JavaScript works in the web browser, you can read along and use the interactive steps without any setup.
Tickets must be enabled. At this time, the [TicketBatch amendment][] :not_enabled: is only available on Devnet.
## Steps

4
content/tutorials/manage-the-rippled-server/configuration/configure-full-history.md
View File

@@ -50,8 +50,8 @@ To configure your server to acquire and store full history, complete the followi
0. Set the `[ips_fixed]` stanza of your server's config file to explicitly peer with at least one server that has full history available.
[ips_fixed]
169.55.164.20
50.22.123.215
169.55.164.20 51235
50.22.123.215 51235
Your server can only download historical data from the peer-to-peer network if one its direct peers has the data available. The easiest way to ensure you can download full history is to peer with a server that already has full history.

38
content/tutorials/manage-the-rippled-server/installation/build-run-rippled-macos.ja.md
View File

@@ -17,19 +17,19 @@ labels:
0. Xcodeコマンドラインツールをインストールします。
$ xcode-select --install
xcode-select --install
0. [Homebrew](https://brew.sh/)をインストールします。
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
0. Homebrewをアップデートします。
$ brew update
brew update
0. Homebrewを使用して依存関係をインストールします。
$ brew install git cmake pkg-config protobuf openssl ninja
brew install git cmake pkg-config protobuf openssl ninja
0. Boost 1.75.0以降をインストールします。`rippled`1.7.2はBoost 1.75.0以降と互換性があります。HomebrewのリポジトリにあるBoostの最新バージョンでは不十分であるため、Boostを手動でインストールする必要があります。
@@ -49,54 +49,54 @@ labels:
2. 以下のコードをBoostディレクトリーの場所に編集して実行し、Boost環境変数が`.bash_profile`ファイルに追加されるようにします。そうすることで、ログイン時にこの環境変数が自動的に設定されます。
$ echo $"export BOOST_ROOT=/Users/my_user/boost_1_75_0" >> ~/.bash_profile
echo $"export BOOST_ROOT=/Users/my_user/boost_1_75_0" >> ~/.bash_profile
0. 前のステップで`.bash_profile`ファイルをアップデートした場合には、新しいターミナルウィンドウでそれを読み込みます。例:
$ source .bash_profile
source .bash_profile
0. 希望の場所に`rippled`ソースコードをクローンし、`rippled`ディレクトリーにアクセスします。これを行うには、Git（Homebrewを使用して前にインストール済み）とGitHubを設定する必要があります。例えば、GitHubアカウントを作成し、SSHキーを設定します。詳細は、[Set up git](https://docs.github.com/en/get-started/quickstart/set-up-git/)を参照してください。
$ git clone git@github.com:ripple/rippled.git
$ cd rippled
git clone git@github.com:ripple/rippled.git
cd rippled
0. デフォルトでは、クローンを実行すると`develop`ブランチに移動します。開発作業をしていて、未テストの機能の最新セットを使用したい場合にはこのブランチを使用します。
最新の安定したリリースを使用したい場合には、`master`ブランチをチェックアウトします。
$ git checkout master
git checkout master
最新のリリース候補をテストしたい場合には、`release`ブランチをチェックアウトします。
$ git checkout release
git checkout release
または、[GitHub](https://github.com/ripple/rippled/releases)にリストされたタグ付きのリリースをチェックアウトすることもできます。
0. クローンしたばかりの`rippled`ディレクトリー内にビルドディレクトリーを作成し、そこにアクセスします。例:
$ mkdir my_build
$ cd my_build
mkdir my_build
cd my_build
0. `rippled`を構築します。ハードウェアの仕様にもよりますが、これには約5分ほどかかります。
$ cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
`CMAKE_BUILD_TYPE`を`Debug`または`Release`ビルドタイプに設定できます。標準的な4つの[`CMAKE_BUILD_TYPE`](https://cmake.org/cmake/help/v3.0/variable/CMAKE_BUILD_TYPE.html)の値がすべてサポートされています。
0. CMakeを使用してビルドを実行します。ハードウェアの仕様にもよりますが、これには約10分ほどかかります。
$ cmake --build .-- -j 4
cmake --build .-- -j 4
**ヒント:** この例では、`-j`パラメーターが`4`に設定されています。これにより、4つのプロセスを使用し、並行してビルドします。使用する最適なプロセス数は、お使いのハードウェアで使用可能なCPUコア数によって異なります。`sysctl -n hw.ncpu`を使用して、CPUのコア数を調べてください。
0. サーバー実行可能ファイルに組み込まれたユニットテストを実行します。ハードウェアの仕様にもよりますが、これには約5分ほどかかります。（省略可能ですが、推奨します）
$ ./rippled --unittest
./rippled --unittest
0. `rippled`は、`rippled.cfg`構成ファイルの実行を必要とします。`rippled/cfg`に、サンプル構成ファイルの`rippled-example.cfg`があります。このファイルをコピーし、`rippled`を非ルートユーザーとして実行できる場所に`rippled.cfg`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
$ mkdir -p $HOME/.config/ripple
$ cp cfg/rippled-example.cfg $HOME/.config/ripple/rippled.cfg
mkdir -p $HOME/.config/ripple
cp cfg/rippled-example.cfg $HOME/.config/ripple/rippled.cfg
0. `rippled.cfg`を編集し、必要なファイルパスを設定します。`rippled`を実行するユーザーは、ここで指定するすべてのパスへの書き込み権限を持っている必要があります。
@@ -110,13 +110,13 @@ labels:
0. `rippled`は、`validators.txt`ファイルの実行を必要とします。`rippled/cfg/`に、サンプルバリデータファイルの`validators-example.txt`があります。このファイルをコピーし、`rippled.cfg`ファイルと同じフォルダーに`validators.txt`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
$ cp cfg/validators-example.txt $HOME/.config/ripple/validators.txt
cp cfg/validators-example.txt $HOME/.config/ripple/validators.txt
**警告:** `validators.txt`のファイルはあなたのサーバーがレジャーを検証する判断の為の設定を含まれています。　バリデータの設定に注意しない変更を加えると、サーバーがネットワークから分岐し、古い、不完全、または正しくないデータについて報告する原因となることがあります。そのようなデータを使用すると、経費の無駄になります。
0. ビルドディレクトリー（`my_build`など）にアクセスし、`rippled`サービスを開始します。
$ ./rippled
./rippled
以下は、ターミナルに表示される内容の抜粋です。

52
content/tutorials/manage-the-rippled-server/installation/build-run-rippled-macos.md
View File

@@ -17,19 +17,19 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
0. Install Xcode command line tools.
$ xcode-select --install
xcode-select --install
0. Install [Homebrew](https://brew.sh/).
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
0. Update Homebrew.
$ brew update
brew update
0. Use Homebrew to install dependencies.
$ brew install git cmake pkg-config protobuf openssl ninja
brew install git cmake pkg-config protobuf openssl ninja
0. Install a compatible version of Boost. `rippled` 1.7.2 is compatible with Boost 1.75.0. To compile Boost yourself, complete the following steps:
@@ -39,9 +39,9 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
3. In a terminal, run:
$ cd /LOCATION/OF/YOUR/BOOST/DIRECTORY
$ ./bootstrap.sh
$ ./b2 cxxflags="-std=c++14"
cd /LOCATION/OF/YOUR/BOOST/DIRECTORY
./bootstrap.sh
./b2 cxxflags="-std=c++14"
0. Ensure that your `BOOST_ROOT` environment points to the directory created by the Boost installation:
@@ -50,67 +50,67 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
2. Edit the code below with your Boost directory location and run it to add Boost environment variable to your `.zshrc` or `.bash_profile` file so it's automatically set when you log in.
# for zsh
$ echo "export BOOST_ROOT=/Users/my_user/boost_1_75_0" >> ~/.zshrc
echo "export BOOST_ROOT=/Users/my_user/boost_1_75_0" >> ~/.zshrc
# for bash
$ echo "export BOOST_ROOT=/Users/my_user/boost_1_75_0" >> ~/.bash_profile
echo "export BOOST_ROOT=/Users/my_user/boost_1_75_0" >> ~/.bash_profile
0. If you updated your `.bash_profile` file in the previous step, be sure to source it in a new Terminal window. For example:
# zsh
$ source ~/.zshrc
source ~/.zshrc
# bash
$ source ~/.bash_profile
source ~/.bash_profile
0. Clone the `rippled` source code into your desired location and access the `rippled` directory. To do this, you'll need to set up Git (installed earlier using Homebrew) and GitHub. For example, you'll need to create a GitHub account and set up your SSH key. For more information, see [Set up git](https://docs.github.com/en/get-started/quickstart/set-up-git/).
$ git clone https://github.com/ripple/rippled.git
$ cd rippled
git clone https://github.com/ripple/rippled.git
cd rippled
0. Switch to the appropriate branch for the software version you want:
For the latest stable release, use the `master` branch.
$ git checkout master
git checkout master
For the latest release candidate, use the `release` branch:
$ git checkout release
git checkout release
For the latest in-progress version, use the `develop` branch:
$ git checkout develop
git checkout develop
Or, you can checkout one of the tagged releases listed on [GitHub](https://github.com/ripple/rippled/releases).
0. Check the commit log to be sure you're compiling the right code. The most recent commit should be signed by a well-known Ripple developer and should set the version number to the latest released version. The [release announcements for `rippled`](https://xrpl.org/blog/label/rippled-release-notes.html) generally show the exact commit to expect for that release.
$ git log -1
git log -1
0. In the `rippled` directory you cloned, create your build directory and access it. For example:
$ mkdir my_build
$ cd my_build
mkdir my_build
cd my_build
0. Build `rippled`. This could take about 5 minutes, depending on your hardware specs.
$ cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
You can set `CMAKE_BUILD_TYPE` to the `Debug` or `Release` build type. All four standard [`CMAKE_BUILD_TYPE`](https://cmake.org/cmake/help/v3.0/variable/CMAKE_BUILD_TYPE.html) values are supported.
0. Run the build using CMake. This could take about 10 minutes, depending on your hardware specs.
$ cmake --build . -- -j 4
cmake --build . -- -j 4
**Tip:** This example uses a `-j` parameter set to `4`, which uses four processes to build in parallel. The best number of processes to use depends on how many CPU cores your hardware has available. Use `sysctl -n hw.ncpu` to get your CPU core count.
0. Run unit tests built into the server executable. This could take about 5 minutes, depending on your hardware specs. (optional, but recommended)
$ ./rippled --unittest
./rippled --unittest
0. `rippled` requires the `rippled.cfg` config file to run. You can find an example config file, `rippled-example.cfg` in `rippled/cfg`. Make a copy and save it as `rippled.cfg` in a location that enables you to run `rippled` as a non-root user. Access the `rippled` directory and run:
$ mkdir -p $HOME/.config/ripple
$ cp cfg/rippled-example.cfg $HOME/.config/ripple/rippled.cfg
mkdir -p $HOME/.config/ripple
cp cfg/rippled-example.cfg $HOME/.config/ripple/rippled.cfg
0. Edit `rippled.cfg` to set necessary file paths. The user you plan to run `rippled` as must have write permissions to all of the paths you specify here.
@@ -124,13 +124,13 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
0. `rippled` requires the `validators.txt` file to run. You can find an example validators file, `validators-example.txt`, in `rippled/cfg/`. Make a copy and save it as `validators.txt` in the same folder as your `rippled.cfg` file. Access the `rippled` directory and run:
$ cp cfg/validators-example.txt $HOME/.config/ripple/validators.txt
cp cfg/validators-example.txt $HOME/.config/ripple/validators.txt
**Warning:** The `validators.txt` file contains settings that determine how your server declares a ledger to be validated. If you are not careful, changes to this file could cause your server to diverge from the rest of the network and report out of date, incomplete, or inaccurate data. Acting on such data can cause you to lose money.
0. Access your build directory, `my_build` for example, and start the `rippled` service.
$ ./rippled
./rippled
Here's an excerpt of what you can expect to see in your terminal:

10
content/tutorials/manage-the-rippled-server/installation/system-requirements.md
View File

@@ -16,7 +16,7 @@ A `rippled` server should run comfortably on commodity hardware, to make it inex
- Development: Mac OS X, Windows (64-bit), or most Linux distributions
- CPU: 64-bit x86_64, 2+ cores
- Disk: Minimum 50 GB for the database partition. SSD strongly recommended (minimum 1000 IOPS, more is better)
- RAM: 8 GB+
- RAM: 16 GB+
<!-- SPELLING_IGNORE: iops, ntp, x86_64, ec2 -->
@@ -25,12 +25,12 @@ Amazon EC2's `m3.large` VM size may be appropriate depending on your workload. A
## Recommended Specifications
For best performance in enterprise production environments, Ripple recommends running `rippled` on bare metal with the following characteristics:
For best performance in enterprise production environments, it is recommended to run `rippled` on bare metal with the following characteristics:
- Operating System: Ubuntu (LTS) or CentOS or RedHat Enterprise Linux (latest release)
- CPU: Intel Xeon 3+ GHz processor with 4 cores and hyperthreading enabled
- Disk: SSD (10,000 IOPS or better)
- RAM: 32 GB
- CPU: Intel Xeon 3+ GHz processor with 8 cores and hyperthreading enabled
- Disk: SSD / NVMe(10,000 IOPS or better)
- RAM: 64 GB
- Network: Enterprise data center network with a gigabit network interface on the host
## System Time

2
content/tutorials/production-readiness/look-up-transaction-results.ja.md
View File

@@ -361,7 +361,7 @@ Escrowトランザクションでは、関係する送金元の所有者準備
Payment Channelの作成時に、LedgerEntryTypeが`PayChannel`の`CreatedNode`を探します。また、送金元の残高の減少を示す、LedgerEntryTypeが`AccountRoot`の`ModifiedNode`も探す必要があります。アドレスが送金元に一致することを確認するために`FinalFields`の`Account`フィールドを探し、XRP残高の変化を確認するために`Balance`フィールドの差異を確認します。
[fixPayChanRecipientOwnerDir Amendment](known-amendments.html#fixpaychanrecipientownerdir) :not_enabled: が有効な場合は、メタデータは宛先のアカウントの[所有者ディレクトリー](directorynode.html)を変更して、新しく作成されるPayment Channelをリストで示す必要もあります。これにより、アカウントがオープンPayment Channelの受取人である場合に、そのアカウントが[削除される](accounts.html#アカウントの削除)ことを防ぎます。（fixPayChanRecipientOwnerDir Amendmentが有効になる前にPayment Channelが作成された場合は、アカウントを削除できます。）
[fixPayChanRecipientOwnerDir Amendment](known-amendments.html#fixpaychanrecipientownerdir)が有効な場合は、メタデータは宛先のアカウントの[所有者ディレクトリー](directorynode.html)を変更して、新しく作成されるPayment Channelをリストで示す必要もあります。これにより、アカウントがオープンPayment Channelの受取人である場合に、そのアカウントが[削除される](accounts.html#アカウントの削除)ことを防ぎます。（fixPayChanRecipientOwnerDir Amendmentが有効になる前にPayment Channelが作成された場合は、アカウントを削除できます。）
Payment Channelの閉鎖を要求する方法は、Payment Channelの不変の`CancelAfter`時刻（作成時にのみ設定されます）以外にもいくつかあります。トランザクションでChannelの閉鎖をスケジュールする場合は、そのChannel用にLedgerEntryTypeが`PayChannel`の`ModifiedNode`エントリーがあり、`FinalFields`の`Expiration`フィールドには閉鎖時刻が新たに追加されています。以下の例は、送金元がクレームを清算せずにChannelを閉鎖するよう要求した場合に`PayChannel`に対して行われる変更を示します。