Merge pull request #1844 from develoQ/ja-multisig

[JA] MultiSig

content/concepts/consensus-network/amendments/known-amendments.ja.md

@@ -826,11 +826,11 @@ XRP Ledgerの分散型取引所において、オファーの掛け合わせの
 | デフォルトの投票(最新の安定版) | はい |
 | Amendment前の機能は廃止? | はい |
 
-トランザクションの承認方法として[マルチ署名](multi-signing.html)を導入します。[`SignerList`レジャーオブジェクトタイプ](signerlist.html)と[`SignerListSet`トランザクションタイプ](signerlistset.html)を作成します。省略可能な`Signers`フィールドをすべてのトランザクションタイプに追加します。一部のトランザクション結果コードを変更します。
+トランザクションの承認方法として[マルチシグ](multi-signing.html)を導入します。[`SignerList`レジャーオブジェクトタイプ](signerlist.html)と[`SignerListSet`トランザクションタイプ](signerlistset.html)を作成します。省略可能な`Signers`フィールドをすべてのトランザクションタイプに追加します。一部のトランザクション結果コードを変更します。
 
-この修正により、マルチ署名のアドレスからトランザクションを承認できる署名者のリストをそのアドレスに保持できるようになります。このリストには定数があり、1から8で重み付けされた署名者が記載されています。これにより、「5人のうち任意の3人」や「Aの署名とその他任意の2人の署名」などの多様な設定が可能になります。
+この修正により、マルチシグのアドレスからトランザクションを承認できる署名者のリストをそのアドレスに保持できるようになります。このリストには定数があり、1から8で重み付けされた署名者が記載されています。これにより、「5人のうち任意の3人」や「Aの署名とその他任意の2人の署名」などの多様な設定が可能になります。
 
-署名者は資金供給のあるアドレスでも資金供給のないアドレスでも可能です。署名者リストのうち資金供給のあるアドレスは、レギュラーキー（定義済みの場合）またはマスターキー（無効でない場合）を使用して署名できます。資金供給のないアドレスは、マスターキーを使用して署名できます。マルチ署名済みトランザクションは、レギュラーキーで署名されたトランザクションと同じ権限を持ちます。
+署名者は資金供給のあるアドレスでも資金供給のないアドレスでも可能です。署名者リストのうち資金供給のあるアドレスは、レギュラーキー（定義済みの場合）またはマスターキー（無効でない場合）を使用して署名できます。資金供給のないアドレスは、マスターキーを使用して署名できます。マルチシグトランザクションは、レギュラーキーで署名されたトランザクションと同じ権限を持ちます。
 
 SignerListを持つアドレスは、レギュラーキーが定義されていなくてもマスターキーを無効にすることができます。また、SignerListを持つアドレスは、マスターキーが無効な場合でもレギュラーキーを削除することができます。`tecMASTER_DISABLED`トランザクション結果コードは`tecNO_ALTERNATIVE_KEY`に名前が変更されます。`tecNO_REGULAR_KEY`トランザクション結果コードは廃止となり、`tecNO_ALTERNATIVE_KEY`に代わります。さらに、この修正は以下の新しい[トランザクション結果コード](transaction-results.html)を追加します。
 
@@ -853,7 +853,7 @@ SignerListを持つアドレスは、レギュラーキーが定義されてい
 | デフォルトの投票(最新の安定版) | はい |
 | Amendment前の機能は廃止? | いいえ |
 
-XRP Ledgerアカウントが[マルチ署名](multi-signing.html) SignerListを所有する場合、アカウントに加算される[所有者準備金](reserves.html#所有者準備金)を削減します。
+XRP Ledgerアカウントが[マルチシグ](multi-signing.html) SignerListを所有する場合、アカウントに加算される[所有者準備金](reserves.html#所有者準備金)を削減します。
 
 この修正を行わない場合、SignerListの所有者準備金は、リスト内の署名者数に応じて15～50 XRPの範囲となります。
 
@@ -974,7 +974,7 @@ XRP Ledgerプロトコルの署名要件を変更し、いかなる場合にも
 
 この修正が適用されない場合、トランザクションがsecp256k1署名を使用し、tfFullyCanonicalSigが有効でない場合は、変更可能となります。ほとんどの署名ユーティリティは、デフォルトでtfFullyCanonicalSigを有効にしていますが、例外もあります。
 
-この修正により、単独署名のトランザクションは展性になりません。(署名者が必要以上の署名を提供した場合、[マルチ署名のトランザクションはまだ展性であるかもしれません](transaction-malleability.html#マルチ署名の展性))。すべてのトランザクションは、tfFullyCanonicalSigフラグに関係なく、署名の完全な正規の形式を使用する必要があります。完全に正規化された署名を作成しない署名ユーティリティはサポートされていません。Ripple社が提供するすべての署名ユーティリティは、少なくとも2014年以降、完全に正規化された署名のみを提供するようになっています。
+この修正により、単独署名のトランザクションは展性になりません。(署名者が必要以上の署名を提供した場合、[マルチシグのトランザクションはまだ展性であるかもしれません](transaction-malleability.html#マルチシグの展性))。すべてのトランザクションは、tfFullyCanonicalSigフラグに関係なく、署名の完全な正規の形式を使用する必要があります。完全に正規化された署名を作成しない署名ユーティリティはサポートされていません。Ripple社が提供するすべての署名ユーティリティは、少なくとも2014年以降、完全に正規化された署名のみを提供するようになっています。
 
 詳しくは、[`rippled` issue #3042](https://github.com/ripple/rippled/issues/3042)を参照してください。
 

content/concepts/consensus-network/transaction-malleability.ja.md

@@ -18,9 +18,9 @@ labels:
 
     **[tfFullyCanonicalSigフラグ](transaction-common-fields.html#グローバルフラグ)を使用** して、トランザクションに展性がないことを保証します。[Ed25519キーで署名されている](cryptographic-keys.html#署名アルゴリズム)トランザクションはこの問題に対して脆弱ではありませんが、 _すべての_ トランザクションにこのフラグを使用しても **特に不都合はありません** 。
 
-2. トランザクションが[マルチ署名済み](multi-signing.html)であり、署名の数が必要以上に多い場合。元々トランザクションに必要な数を上回る署名がされていなかった場合でも、権限のある署名者が追加の署名を提供すると、このトランザクションが展性を得ることがあります。
+2. トランザクションが[マルチシグ](multi-signing.html)であり、署名の数が必要以上に多い場合。元々トランザクションに必要な数を上回る署名がされていなかった場合でも、権限のある署名者が追加の署名を提供すると、このトランザクションが展性を得ることがあります。
 
-    適切な運用セキュリティ対策を導入することで、このような問題を防ぐことができます。ガイドラインについては、[マルチ署名の展性の緩和対策](#マルチ署名の展性の緩和対策)を参照してください。
+    適切な運用セキュリティ対策を導入することで、このような問題を防ぐことができます。ガイドラインについては、[マルチシグの展性の緩和対策](#マルチシグの展性の緩和対策)を参照してください。
 
 
 ## 背景
@@ -58,12 +58,12 @@ Rippleが公開しているすべてのXRP Ledgerソフトウェア（`rippled`
 次の2つの状況においては、RippleのXRP Ledgerの署名実装によってtfFullyCanonicalSigフラグが自動的に有効になりません。次の状況では、フラグを慎重に設定する必要があります。
 
 - ユーザーがトランザクションの`Flags`フィールドを明示的に指定している場合。ビット単位のORを使用してtfFullyCanonicalSig _と_ その他の必要なすべてのフラグを適用します。
-- ユーザーがトランザクションにマルチ署名を提供する場合。マルチ署名の複数の参加者は _厳密に_ 同一のデータに署名する必要があるので、署名コードはtfFullyCanonicalSigフラグを追加するというトランザクションの指示を事前に処理しません。マルチ署名済みトランザクションでは、常にtfFullyCanonicalSigフラグを明示的に有効にしてください。
+- ユーザーがトランザクションにマルチシグを提供する場合。マルチシグの複数の参加者は _厳密に_ 同一のデータに署名する必要があるので、署名コードはtfFullyCanonicalSigフラグを追加するというトランザクションの指示を事前に処理しません。マルチシグトランザクションでは、常にtfFullyCanonicalSigフラグを明示的に有効にしてください。
 
 
-### マルチ署名の展性
+### マルチシグの展性
 
-マルチ署名の明示的で重要な機能として、さまざまな設定によってトランザクションを有効にできるという機能があげられます。たとえば、5人の署名者のうち3人の署名者の署名によってトランザクションを承認できるようにアカウントを設定できます。ただしこの場合、有効なトランザクションにはいくつかのバリエーションが存在する可能性があり、識別用ハッシュは各バリエーションごとに異なります。
+マルチシグの明示的で重要な機能として、さまざまな設定によってトランザクションを有効にできるという機能があげられます。たとえば、5人の署名者のうち3人の署名者の署名によってトランザクションを承認できるようにアカウントを設定できます。ただしこの場合、有効なトランザクションにはいくつかのバリエーションが存在する可能性があり、識別用ハッシュは各バリエーションごとに異なります。
 
 以下のケースはすべて、トランザクション展性の問題につながる可能性があります。
 
@@ -73,16 +73,16 @@ Rippleが公開しているすべてのXRP Ledgerソフトウェア（`rippled`
 
 権限のある署名者に意図的な悪意がない場合でも、混乱や不適切な調整が原因で、複数の署名者が同じトランザクションの異なる有効バージョンを送信することがあります。
 
-#### マルチ署名の展性の緩和対策
+#### マルチシグの展性の緩和対策
 
-**適切な運用セキュリティ対策を導入することで、このような問題を防ぐことができます。** 通常、以下のような適切な運用セキュリティ対策に従っていれば、マルチ署名でのトランザクション展性の問題を防ぐことができます。
+**適切な運用セキュリティ対策を導入することで、このような問題を防ぐことができます。** 通常、以下のような適切な運用セキュリティ対策に従っていれば、マルチシグでのトランザクション展性の問題を防ぐことができます。
 
 - 必要な数以上の署名を収集しない。
 - 必要な数の署名を収集した後でトランザクションを作成する当事者を任命するか、または署名者が事前に定義された順序でトランザクション指示に署名して次に渡せるように「チェーン」を指定する。
-- マルチ署名リストに不要な署名者または信頼できない署名者を追加しない。これは、これらの署名者のキーに関連付けられている`weight`の値が、トランザクションの承認には不十分である場合にも該当する。
+- マルチシグリストに不要な署名者または信頼できない署名者を追加しない。これは、これらの署名者のキーに関連付けられている`weight`の値が、トランザクションの承認には不十分である場合にも該当する。
 - トランザクションが異なるハッシュまたは想定外の署名セットを使用して実行される可能性に対処できるよう備える。アカウントから送信されたトランザクションを注意深く監視する（[account_txメソッド][]などを使用）。
 - アカウントの`Sequence`番号を監視する（[account_infoメソッド][]などを使用）。この番号は、アカウントがトランザクションを正常に送信するたびに1ずつ増えますが、それ以外の状況で増えることはありません。番号が想定した番号と一致しない場合は、最近のトランザクションを調べてその原因を確認します。（展性のあるトランザクションの他にも、このような状況が発生することがあります。たとえばトランザクションを送信するように別のアプリケーションを設定する場合などです。不正使用者が秘密鍵にアクセスした可能性もあります。あるいは、アプリケーションでデータが失われ、送信済みのトランザクションが忘れられた可能性もあります。）
-- トランザクションを再度作成してマルチ署名済みにする場合は、目的の処理がまだ実行されていないことを手動で確認している場合を除き、`Sequence`番号を変更 _しないでください_ 。
+- トランザクションを再度作成してマルチシグにする場合は、目的の処理がまだ実行されていないことを手動で確認している場合を除き、`Sequence`番号を変更 _しないでください_ 。
 - 署名前にtfFullyCanonicalSigフラグが有効であることを確認する。
 
 セキュリティ強化のため、上記のガイドラインにより何重もの保護対策が講じられます。
@@ -92,7 +92,7 @@ Rippleが公開しているすべてのXRP Ledgerソフトウェア（`rippled`
 
 XRP Ledgerとのインフターフェイスに使用するソフトウェアから展性のあるトランザクションが送信されると、不正使用者がソフトウェアをだましてトランザクションの最終結果を確認できなくし、（最悪の場合）同額の支払いを複数回送金させることが可能になります。
 
-シングルシグネチャーを使用していて、tfFullyCanonicalSigフラグを常に有効にしている場合には、このような悪用に対し脆弱ではありません。マルチ署名を使用していて、署名者が必要な数を超える署名を提供する場合には脆弱になります。
+シングルシグネチャーを使用していて、tfFullyCanonicalSigフラグを常に有効にしている場合には、このような悪用に対し脆弱ではありません。マルチシグを使用していて、署名者が必要な数を超える署名を提供する場合には脆弱になります。
 
 ### 悪用シナリオの流れ
 
@@ -103,10 +103,10 @@ XRP Ledgerとのインフターフェイスに使用するソフトウェアか
     トランザクションでtfFullyCanonicalSigフラグが有効に設定されない状況として以下の3つがあります。
 
     - システムが`Flags`フィールドを明示的に指定し、このフィールドでtfFullyCanonicalSigビットが有効になっていない。
-    - トランザクションがマルチ署名済みであり、tfFullyCanonicalSigフラグが明示的に有効にされていない。
+    - トランザクションがマルチシグであり、tfFullyCanonicalSigフラグが明示的に有効にされていない。
     - システムでトランザクションのフィールドから`Flags`フィールドが省略されているが、署名時にtfFullyCanonicalSigを自動的に有効にしない非標準の実装が使用されている。
 
-    トランザクションがECDSAキーペアで署名されている場合、そのトランザクションは脆弱になります。マルチ署名済みの場合、トランザクションの署名に少なくとも1つのECDSAキーペアが使用される必要があります。
+    トランザクションがECDSAキーペアで署名されている場合、そのトランザクションは脆弱になります。マルチシグの場合、トランザクションの署名に少なくとも1つのECDSAキーペアが使用される必要があります。
 
     ほとんどの場合、脆弱なトランザクションには完全に正規である署名が使用されていますが、トランザクションが完全に正規ではない署名を使用していても、フラグはそのトランザクションが有効であると示します。また、限られた時間内に最終結果が判かるように、トランザクションで`LastLedgerSequence`が使用されていることもあります。
 

content/concepts/introduction/xrp-ledger-overview.ja.md

@@ -80,9 +80,9 @@ XRP LedgerのConsensusアルゴリズムの動作方法の詳細は、[XRP Ledge
 ## 安全で適応性のある暗号技術
 [安全で適応性のある暗号技術]: #安全で適応性のある暗号技術
 
-暗号技術は分散システムにおいて最も重要な部分の1つであり、小さな技術的問題が一瞬にして世界中の悪意あるハッカーによる盗難につながる危険性を秘めています。XRP Ledgerは、取引の署名および検証のための業界標準の技術と、何年もの間、数千億USドルにも相当する価値を保護することに成功してきたアルゴリズムを使用しています。また、XRP Ledgerにはマルチ署名機能が備わっているため、バックアップとして多要素認証や複数のユーザー間で分割キーを使用できます。さらに暗号技術の飛躍的な進歩によって古いアルゴリズムが時代遅れになり、新しいアルゴリズムが導入される場合でも、ユーザーはそのままキーを使い続けることができます。
+暗号技術は分散システムにおいて最も重要な部分の1つであり、小さな技術的問題が一瞬にして世界中の悪意あるハッカーによる盗難につながる危険性を秘めています。XRP Ledgerは、取引の署名および検証のための業界標準の技術と、何年もの間、数千億USドルにも相当する価値を保護することに成功してきたアルゴリズムを使用しています。また、XRP Ledgerにはマルチシグ機能が備わっているため、バックアップとして多要素認証や複数のユーザー間で分割キーを使用できます。さらに暗号技術の飛躍的な進歩によって古いアルゴリズムが時代遅れになり、新しいアルゴリズムが導入される場合でも、ユーザーはそのままキーを使い続けることができます。
 
-詳細は、[暗号鍵](cryptographic-keys.html)および[マルチ署名](multi-signing.html)を参照してください。
+詳細は、[暗号鍵](cryptographic-keys.html)および[マルチシグ](multi-signing.html)を参照してください。
 
 
 ## スマートコントラクト用の最新機能

content/concepts/payment-system-basics/accounts/accounts.ja.md

@@ -20,7 +20,7 @@ XRP Ledgerの「アカウント」は、XRPの所有者と[トランザクショ
 - [トランザクションの承認](transaction-basics.html#トランザクションの承認)方法。以下に例を示します。
   - アカウント固有のマスターキーのペア。（[無効](accountset.html)にできますが、変更はできません。）
   - [ローテーションで使用](setregularkey.html)できる「レギュラー」キーペア。
-  - [マルチ署名](multi-signing.html)の署名者のリスト。（アカウントのコアデータとは別に保存されます。）
+  - [マルチシグ](multi-signing.html)の署名者のリスト。（アカウントのコアデータとは別に保存されます。）
 
 アカウントのコアデータは、レジャーのデータツリーの[AccountRoot](accountroot.html)レジャーのオブジェクトタイプに保存されます。アカウントは、他の複数のタイプのデータの所有者（または部分的な所有者）になることもできます。
 
@@ -102,9 +102,9 @@ XRP Ledgerでは、トランザクション（取引）履歴をトランザク
 - `RippleState`オブジェクト（トラストライン）。アカウントに関連付けられています。
 - `DirectoryNode`オブジェクト（特にアカウントの所有オブジェクトを追跡する所有者ディレクトリ）。
 - `Offer`オブジェクト。分散型取引所でのアカウントの未処理の取引注文を表すオブジェクト。
-- `PayChannel` アカウントとの間の非同期のPayment Channelを表すオブジェクト。
-- `Escrow` 時間または暗号条件によってロックされ、アカウントとの間の保留中の支払いを表すオブジェクト。
-- `SignerList` [マルチ署名](multi-signing.html)によってアカウントのトランザクションを承認できるアドレスのリストを表すオブジェクト。
+- `PayChannel`アカウントとの間の非同期のPayment Channelを表すオブジェクト。
+- `Escrow`時間または暗号条件によってロックされ、アカウントとの間の保留中の支払いを表すオブジェクト。
+- `SignerList`[マルチシグ](multi-signing.html)によってアカウントのトランザクションを承認できるアドレスのリストを表すオブジェクト。
 
 これらの各オブジェクトの詳細は、[レジャーフォーマットのリファレンス](ledger-data-formats.html)を参照してください。
 

content/concepts/payment-system-basics/accounts/multi-signing.ja.md

@@ -1,16 +1,16 @@
 ---
 html: multi-signing.html
 parent: accounts.html
-blurb: マルチ署名を使用することで、トランザクション送信時のセキュリティが強化されます。
+blurb: マルチシグを使用することで、トランザクション送信時のセキュリティが強化されます。
 labels:
   - スマートコントラクト
   - セキュリティ
 ---
-# マルチ署名
+# マルチシグ
 
-マルチ署名は、複数のシークレットキーを組み合わせて使用してXRP Ledgerの[トランザクションを承認する](transaction-basics.html#トランザクションの承認)手法です。アドレスで有効な承認手法（マルチ署名、[マスターキーペア](cryptographic-keys.html#マスターキーペア)、[レギュラーキーペア](cryptographic-keys.html#レギュラーキーペア)など）を自由に組み合わせて使用できます。（唯一の要件は、 _少なくとも1つの_ 手法を有効にする必要があることです。）
+マルチシグは、複数のシークレットキーを組み合わせて使用してXRP Ledgerの[トランザクションを承認する](transaction-basics.html#トランザクションの承認)手法です。アドレスで有効な承認手法（マルチシグ、[マスターキーペア](cryptographic-keys.html#マスターキーペア)、[レギュラーキーペア](cryptographic-keys.html#レギュラーキーペア)など）を自由に組み合わせて使用できます。（唯一の要件は、 _少なくとも1つの_ 手法を有効にする必要があることです。）
 
-マルチ署名には次のメリットがあります。
+マルチシグには次のメリットがあります。
 
 * 複数のデバイスからのキーを要求できます。これにより、不正使用者があなたの代わりにトランザクションを送信するには複数のマシンを悪用しなければならなくなります。
 * 複数のユーザー間で1つのアドレスの管理を共有できます。この場合、各ユーザーが、そのアドレスからトランザクションを送信する際に必要な複数のキーのいずれか1つだけを所有します。
@@ -19,25 +19,68 @@ labels:
 
 ## 署名者リスト
 
-マルチ署名を使用するには、あなたの代理として署名できるアドレスのリストを作成する必要があります。
+マルチシグを使用するには、あなたの代理として署名できるアドレスのリストを作成する必要があります。
 
-[SignerListSetトランザクション][]は、あなたのアドレスからのトランザクションを承認できるアドレスを定義します。SignerListには最大8個のアドレスを指定できます。SignerListのquorum値とweight値を使用して、必要な署名の数と組み合わせを制御できます。
+[SignerListSetトランザクション][]は、_署名者リスト_（自分のアドレスからのトランザクションを承認できるアドレスのセット）を定義します。署名者リストには、1～32のアドレスを含めることができます。このリストには、自分のアドレスを含めることはできず、重複して登録することはできません。リストの _Signer Weight_ と _Quorum_ の設定を使用することで、どのような組み合わせでどれだけの署名が必要かを制御することができます。
 
-## マルチ署名済みトランザクションの送信
+_([ExpandedSignerList amendment][]により更新されました。)_
 
-マルチ署名済みトランザクションを正常に送信するには、以下のすべての条件を満たす必要があります。
+### Signer Weight
 
-* トランザクションを送信するアドレス（`Account`に指定されるアドレス）は、[レジャーに`SignerList`](signerlist.html)を所有する必要があります。
+リスト内の各署名者にウェイトを割り当てます。ウェイトは、リスト上の他の署名者と比較して、その署名者の相対的な権限を表します。値が高いほど、より多くの権限を持つことになります。個々のウェイト値は、2<sup>16</sup>-1を超えることはできません。
+
+### Quorum
+
+リストの定足数(quorum)の値は、トランザクションを承認するために必要な最小のウェイト合計です。クォーラムは0より大きく、署名者リストのウェイト値の合計以下でなければならない。つまり、与えられた署名者のウェイトでクォーラムを達成することが可能でなければなりません。
+
+### Wallet Locator
+
+また、リスト内の各署名者のエントリに最大256ビットの任意のデータを追加することができます。このデータはネットワークで必要とされたり使用されたりすることはありませんが、スマートコントラクトや他のアプリケーションが署名者に関する他のデータを特定したり確認したりするために使用することができます。
+
+_([ExpandedSignerList amendment][]によって追加されました。)_
+
+### Signer WeightとQuorumの使用例
+
+ウェイトと定足数により、アカウントを管理する責任ある参加者への相対的な信頼と権限に基づき、トランザクションごとに適切なレベルの監視を設定することができます。
+
+共有アカウントのユースケースの場合、定足数1のリストを作成し、すべての参加者に1のウェイトを与えることができます。
+
+非常に重要なアカウントの場合、定足数を3に設定し、重みを1とする3人の参加者を設定することができます。すべての参加者がトランザクションごとに同意して承認する必要があります。
+
+CEOのウェイトを3、副社長3人のウェイトを各2、取締役3人のウェイトを各1に割り当てたとする。このアカウントのトランザクションを承認するには、取締役3名全員（合計ウェイト3）、副社長1名と取締役1名（合計ウェイト3）、副社長2名（合計ウェイト4）、またはCEO（合計ウェイト3）の承認が必要となります。
+
+先の3つのユースケースでは、レギュラーキーを設定せずにマスターキーを無効にすることで、マルチシグが唯一の[トランザクションの承認](transaction-basics.html#authorizing-transactions)の方法となるようにします。
+
+"バックアッププラン"としてマルチシグリストを作成するシナリオがあるかもしれません。アカウント所有者は、通常、トランザクションにレギュラーキー(マルチシグではない)を使用します。もしアカウント所有者が秘密鍵を紛失した場合、通常の鍵に代わるトランザクションにマルチシグするよう友人に依頼することができます。
+
+## マルチシグトランザクションの送信
+
+マルチシグトランザクションを正常に送信するには、以下のすべての条件を満たす必要があります。
+
+* トランザクションを送信するアドレス（`Account`に指定されるアドレス）は、[レジャーに`SignerList`](signerlist.html)を所有する必要があります。この方法については、[マルチシグを設定する](set-up-multi-signing.html)を参照してください。
 * トランザクションに`SigningPubKey`フィールドを空の文字列として含める必要があります。
 * トランザクションに、署名の配列が指定されている[`Signers`フィールド](transaction-common-fields.html#signersフィールド)を含める必要があります。
-* `Signers`配列に含まれている署名は、SignerListで定義されている署名と一致している必要があります。
-* 指定された署名で、これらの署名者に関連付けられている`weight`の合計が、SignerListの`quorum`以上である必要があります。
+* `Signers`配列に含まれている署名は、`SignerList`で定義されている署名と一致している必要があります。
+* 指定された署名で、これらの署名者に関連付けられている`weight`の合計が、`SignerList`の`quorum`以上である必要があります。
 * [トランザクションコスト](transaction-cost.html)（`Fee`フィールドで指定）は、通常のトランザクションコストの（N+1）倍以上である必要があります。このNは、指定される署名の数です。
 * トランザクションのすべてのフィールドは、署名収集前に定義する必要があります。フィールドの[自動入力](transaction-common-fields.html#自動入力可能なフィールド)は実行できません。
-* `Signers` 配列がバイナリ形式で指定される場合、この配列は署名者アドレスの数値に基づいて、低い値から順にソートされている必要があります。（JSONとして提出される場合は、[submit_multisignedメソッド][] がこの処理を自動的に実行します。）
+* `Signers`配列がバイナリ形式で指定される場合、この配列は署名者アドレスの数値に基づいて、低い値から順にソートされている必要があります。（JSONとして提出される場合は、[submit_multisignedメソッド][]がこの処理を自動的に実行します。）
 
-詳細は、[マルチ署名の設定](set-up-multi-signing.html)を参照してください。
+詳細は、[マルチシグの設定](set-up-multi-signing.html)を参照してください。
 
+## 関連項目
+
+- **チュートリアル:**
+    - [マルチシグを設定する](set-up-multi-signing.html)
+    - [マルチシグトランザクションを送信する](send-a-multi-signed-transaction.html)
+- **コンセプト:**
+    - [暗号鍵](cryptographic-keys.html)
+    - [マルチシグトランザクションの特別なトランザクションコスト](transaction-cost.html#特別なトランザクションコスト)
+- **リファレンス:**
+    - [SignerListSetトランザクション][]
+    - [SignerListオブジェクト](signerlist.html)
+    - [sign_forメソッド][]
+    - [submit_multisignedメソッド][]
 
 {% include '_snippets/rippled-api-links.md' %}
 {% include '_snippets/tx-type-links.md' %}

content/concepts/payment-system-basics/accounts/tickets.ja.md

@@ -60,7 +60,7 @@ XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引
 
 
 - **Concepts:**
-    - [マルチ署名](multi-signing.html)
+    - [マルチシグ](multi-signing.html)
 - **Tutorials:**
     - [チケットを使用する](use-tickets.html)
 - **References:**

content/concepts/payment-system-basics/transaction-basics/transaction-basics.ja.md

@@ -40,7 +40,7 @@ _トランザクション（取引）_ は、XRP Ledgerを変更する唯一の
 
 * 送信元アドレスと数学的に関連付けられている、マスター秘密鍵による単一の署名。[AccountSetトランザクション][]を使用して、マスターキーペアを無効または有効にできます。
 * アドレスに関連付けられているレギュラー秘密鍵と一致する単一の署名。[SetRegularKeyトランザクション][]を使用して、レギュラーキーペアを追加、削除、または置き換えることができます。
-* アドレスが所有する署名者のリストと一致する[マルチ署名](multi-signing.html)。[SignerListSetトランザクション][]を使用して、署名者のリストを追加、削除、または置換することができます。
+* アドレスが所有する署名者のリストと一致する[マルチシグ](multi-signing.html)。[SignerListSetトランザクション][]を使用して、署名者のリストを追加、削除、または置換することができます。
 
 署名の種類に関係なく、あらゆるタイプのトランザクションを承認できます。ただし、次の例外があります。
 

content/concepts/payment-system-basics/transaction-basics/transaction-cost.ja.md

@@ -27,7 +27,7 @@ XRP LedgerをスパムやDoS攻撃から守るため、各トランザクショ
 |-----------------------|--------------------------|
 | [Referenceトランザクション](#referenceトランザクションコスト)（ほとんどのトランザクション） | 10 drop |
 | [Key Resetトランザクション](#key-resetトランザクション)| 0 |
-| [マルチ署名済みトランザクション](multi-signing.html)| 10 drop × （1 + 署名の数） |
+| [マルチシグトランザクション](multi-signing.html)| 10 drop × （1 + 署名の数） |
 | [フルフィルメントを伴うEscrowFinishトランザクション](escrowfinish.html)| 10 drop × （33 + （バイト単位のフルフィルメントサイズ ÷ 16）） |
 | [AccountDeleteトランザクション](accounts.html#アカウントの削除)| 5,000,000 drop |
 
@@ -61,7 +61,7 @@ XRP LedgerをスパムやDoS攻撃から守るため、各トランザクショ
 
 新しいレジャーバージョンごとに、サーバーは前のレジャーのトランザクション数に基づいてオープンレジャーに含めるトランザクション数のソフトリミットを選択します。オープンレジャーコストは、オープンレジャー内のトランザクション数がソフトリミットと等しくなるまでは、スケーリングされていない最低トランザクションコストと同じです。それを超えると、オープンレジャーコストはオープンレジャーに含まれるトランザクションごとに急激に増加します。次のレジャーでは、現行のレジャーにソフトリミットを超えるトランザクションが含まれていれば、サーバーはソフトリミットを高くし、コンセンサスプロセスに5秒より時間が掛かる場合はソフトリミットを低くします。
 
-オープンレジャーコストの水準は、絶対的なトランザクションコストではなく[標準的なトランザクションコストに比例](#手数料レベル)しています。標準よりも高い要件を持つトランザクションタイプ（[マルチ署名済みトランザクション](multi-signing.html)など）は、オープンレジャーコストを満たすために最低限のトランザクションコスト要件を持つトランザクションよりも多く支払う必要があります。
+オープンレジャーコストの水準は、絶対的なトランザクションコストではなく[標準的なトランザクションコストに比例](#手数料レベル)しています。標準よりも高い要件を持つトランザクションタイプ（[マルチシグトランザクション](multi-signing.html)など）は、オープンレジャーコストを満たすために最低限のトランザクションコスト要件を持つトランザクションよりも多く支払う必要があります。
 
 関連項目: [`rippled`リポジトリー内のFee Escalationの説明](https://github.com/ripple/rippled/blob/release/src/ripple/app/misc/FeeEscalation.md)。
 
@@ -73,7 +73,7 @@ XRP LedgerをスパムやDoS攻撃から守るため、各トランザクショ
 
 ## Referenceトランザクションコスト
 
-「Referenceトランザクション」とは、負荷スケーリング前の[トランザクションコスト](transaction-cost.html)という観点からは、最も安価な（無料ではない）トランザクションと言えます。ほとんどのトランザクションのコストはReferenceトランザクションと同じです。[マルチ署名済みトランザクション](multi-signing.html)など一部のトランザクションでは、このコストの数倍のコストが必要です。オープンレジャーコストが上昇する場合は、コスト水準はトランザクションの基本コストに比例します。
+「Referenceトランザクション」とは、負荷スケーリング前の[トランザクションコスト](transaction-cost.html)という観点からは、最も安価な（無料ではない）トランザクションと言えます。ほとんどのトランザクションのコストはReferenceトランザクションと同じです。[マルチシグトランザクション](multi-signing.html)など一部のトランザクションでは、このコストの数倍のコストが必要です。オープンレジャーコストが上昇する場合は、コスト水準はトランザクションの基本コストに比例します。
 
 ### 手数料レベル
 
@@ -82,7 +82,7 @@ XRP LedgerをスパムやDoS攻撃から守るため、各トランザクショ
 | トランザクション | drop単位の最少コスト | 手数料レベルでの最少コスト   | drop単位で倍のコスト  | 手数料レベルで倍のコスト    |
 |-------------|-----------------------|----------------------------|----------------------|---------------------------|
 | Referenceトランザクション（ほとんどのトランザクション） | 10 | 256 | 20 | 512 |
-| 4つの署名を持つ[マルチ署名済みトランザクション](multi-signing.html) | 50 | 256 | 100 | 512 |
+| 4つの署名を持つ[マルチシグトランザクション](multi-signing.html) | 50 | 256 | 100 | 512 |
 | [Key Resetトランザクション](transaction-cost.html#key-resetトランザクション) | 0 | （事実上無限） | なし | （事実上無限） |
 | 32バイトのプリイメージ付きの[EscrowFinishトランザクション](escrowfinish.html)。 | 350 | 256 | 700 | 512 |
 
@@ -126,7 +126,7 @@ XRP LedgerをスパムやDoS攻撃から守るため、各トランザクショ
 * 署名するトランザクションの`Fee`フィールドの正確な値は事前にわかりません。
   * `rippled`を使用している場合は、[signメソッド][]の`fee_mult_max`パラメーターと`fee_div_max`パラメーターを使用して、署名しようとしている負荷スケーリングに制限を設定することもできます。
 * オフラインのマシンから現在のトランザクションコストを調べることはできません。
-* [マルチ署名](multi-signing.html)の場合、トランザクションコストの自動指定は行えません。
+* [マルチシグ](multi-signing.html)の場合、トランザクションコストの自動指定は行えません。
 
 
 

content/concepts/payment-types/escrow.ja.md

@@ -84,7 +84,7 @@ Escrow Amendmentのステータスは、[featureメソッド][]を使用して
 
 Escrowが時間のみによってロックされており、Crypto-conditionがない場合、EscrowFinishのコストは、リファレンストランザクションの標準[トランザクションコスト](transaction-cost.html)のみです。
 
-必要となる追加のトランザクションコストは、フルフィルメントのサイズに比例します。現時点では、フルフィルメントのあるEscrowFinishでは最小トランザクションコストとして、**330 drop（[XRPのdrop数](basic-data-types.html#通貨額の指定)）と、フルフィルメントのサイズで16バイトあたり10 drop**が必要です。[マルチ署名済み](multi-signing.html)トランザクションの場合、マルチ署名のコストがフルフィルメントのコストに加算されます。
+必要となる追加のトランザクションコストは、フルフィルメントのサイズに比例します。現時点では、フルフィルメントのあるEscrowFinishでは最小トランザクションコストとして、**330 drop（[XRPのdrop数](basic-data-types.html#通貨額の指定)）と、フルフィルメントのサイズで16バイトあたり10 drop**が必要です。[マルチシグ](multi-signing.html)トランザクションの場合、マルチシグのコストがフルフィルメントのコストに加算されます。
 
 **注記:** 上記の式は、トランザクションのリファレンスコストがXRPの10 dropであることを前提としています。
 

content/concepts/tokens/freezes.ja.md

@@ -80,7 +80,7 @@ XRP Ledgerは金融機関に対し、その発行資金が表す債務を履行
 
 No Freeze設定は、アドレスに対して発行される通貨と、アドレスから発行される通貨のすべてに適用されます。一部の通貨のみを凍結できるようにしたい場合は、通貨ごとに異なるアドレスを使用してください。
 
-No Freeze設定は、アドレスのマスターキーのシークレットキーにより署名されたトランザクションでのみ有効にできます。[レギュラーキー](setregularkey.html)または[マルチ署名済みトランザクション](multi-signing.html)を使用してNo Freezeを有効にすることはできません。
+No Freeze設定は、アドレスのマスターキーのシークレットキーにより署名されたトランザクションでのみ有効にできます。[レギュラーキー](setregularkey.html)または[マルチシグトランザクション](multi-signing.html)を使用してNo Freezeを有効にすることはできません。
 
 
 <!--{# TODO: update "See Also" with new tutorials' technical details #}-->