bitcoinops · bitschmidty · Feb 20, 2020 · Feb 19, 2020
diff --git a/_plugins/auto-anchor.rb b/_plugins/auto-anchor.rb
@@ -21,7 +21,7 @@
         ## Remove double-quotes from titles before attempting to slugify
         title.gsub!('"', '')
         ## Use Liquid/Jekyll slugify filter to choose our id
-        id_prefix = '- {:#{{ "' + title + '" | slugify }}} '
+        id_prefix = '- {:#{{ "' + title + '" | slugify: "latin" }}} '
         string.sub!(/-/, id_prefix)
       end
     end

diff --git a/_posts/ja/newsletters/2019-11-13-newsletter-ja.md b/_posts/ja/newsletters/2019-11-13-newsletter-ja.md
@@ -38,7 +38,7 @@ lang: ja
     {:#x-only-pubkeys}
     他のschnorr / taprootニュースとしては、Jonas Nickはセキュリティレベル下げることなくシリアル化された公開キーのサイズを33バイトから32バイトに減らした[bip-schnorr][]と[bip-schnorr][]の最近の大きな変更に関する [有益なブログ投稿][x-only pubkeys]を公開しました。この最適化の以前の議論については、[Newsletter#59][news59 proposed 32B pubkeys]および[#68][news68 taproot update]を参照してください。
 
-- **LNオニオン形式でのプライバシー漏洩の可能性：** [BOLT4][]で説明されているように、LNは[Sphinx][]プロトコルを使用してLNノード間で支払い情報を通信します。Olaoluwa Osuntokunは今週Lightning-Devメーリングリストに、Sphinxの当初の説明にある[最近公開された][breaking onion routing] 欠陥は、宛先ノードが「パスの長さの下限を推定できる」と[投稿しました][osuntokun sphinx] 。この修正は簡単です。オニオンパケットの一部をゼロバイトで初期化する代わりに、ランダム値のバイトを利用します。 Osuntokunは、LNDが使用するオニオンライブラリでこれを実装する[PR][lnd-onion]と、BOLTリポジトリの[ドキュメント PR][bolts #697]を作成しました。他の実装でも同じ変更が採用されています（以下の [C-Lightning commit][news72 cl onion]コミットを参照）。
+- **LN<!--1-->オニオン形式でのプライバシー漏洩の可能性：** [BOLT4][]で説明されているように、LNは[Sphinx][]プロトコルを使用してLNノード間で支払い情報を通信します。Olaoluwa Osuntokunは今週Lightning-Devメーリングリストに、Sphinxの当初の説明にある[最近公開された][breaking onion routing] 欠陥は、宛先ノードが「パスの長さの下限を推定できる」と[投稿しました][osuntokun sphinx] 。この修正は簡単です。オニオンパケットの一部をゼロバイトで初期化する代わりに、ランダム値のバイトを利用します。 Osuntokunは、LNDが使用するオニオンライブラリでこれを実装する[PR][lnd-onion]と、BOLTリポジトリの[ドキュメント PR][bolts #697]を作成しました。他の実装でも同じ変更が採用されています（以下の [C-Lightning commit][news72 cl onion]コミットを参照）。
 
 - **LNの前払い：** 現在のLNプロトコルは、支払いの試みが失敗した場合、または受信者によって拒否された場合、すべてのお金を支出者に返すため、支払いの試みが成功した場合のみルーティングノードが収入を受け取ります。一部の新しいアプリケーションでは、この費用のかからない障害メカニズムを使用して、利用するバンドワイズを支払わずにLN経由でデータを送信しています。 LNの設計者はこれらが起こることを予想しており、以前からネットワークに前払い料金を追加する方法について考えていました。つまり、支払いの試みが成功したかどうかに関係なくルーティングノードに金額が支払われる仕組みです。
 

diff --git a/_posts/ja/newsletters/2019-12-18-newsletter-ja.md b/_posts/ja/newsletters/2019-12-18-newsletter-ja.md
@@ -18,7 +18,7 @@ lang: ja
 
 - **C-Lightning 0.8.0 RCのテストのご協力:** C-Lightningの次期バージョン[リリース候補][cl 0.8.0]では、デフォルト・ネットワークをテストネットからメインネットへ変更し（[Newsletter #75][news75 cl mainnet]を参照）、後述する基本的なマルチパス・ペイメントのサポートを追加します。また、その他の追加機能、バグ修正も含まれます。
 
-- **bech32アクションプランの確認:** 後述のとおり、Pieter Wuilleは、すべてのbech32アドレスを20または32バイトのウィットネス・プログラムに制限し、`p`で終わるアドレスに関連する転記エラーによる資金損失の防止を提案しています。 このルールは、P2WPKHおよびP2WSHに使用されるv0 segwitアドレスに既に適用されているため、変更は、将来のアップグレード（提案されている[taproot][topic taproot]など）のために現在予約されているv1以降のアドレスに拡張するだけのものです。 これには、bech32送信サポートを既に実装しているウォレットとサービスは、コードをアップデートする必要がありますが、変更は小さいものとなります。例えば[Pythonリファレンス実装][bech32 python]の場合、次のようになります。
+- **bech32<!--1-->アクションプランの確認:** 後述のとおり、Pieter Wuilleは、すべてのbech32アドレスを20または32バイトのウィットネス・プログラムに制限し、`p`で終わるアドレスに関連する転記エラーによる資金損失の防止を提案しています。 このルールは、P2WPKHおよびP2WSHに使用されるv0 segwitアドレスに既に適用されているため、変更は、将来のアップグレード（提案されている[taproot][topic taproot]など）のために現在予約されているv1以降のアドレスに拡張するだけのものです。 これには、bech32送信サポートを既に実装しているウォレットとサービスは、コードをアップデートする必要がありますが、変更は小さいものとなります。例えば[Pythonリファレンス実装][bech32 python]の場合、次のようになります。
 
     ```diff
     --- a/ref/python/segwit_addr.py
@@ -37,15 +37,15 @@ lang: ja
 
 ## News
 
-- **LN実装へのマルチパス・ペイメントのサポート追加:** 数多くの議論と開発を経て、Optechがトラッキングしている3つのLN実装はすべて、[マルチパス・ペイメント][topic multipath payments]の基本サポートを追加しました（C-Lightning、Eclair、LND）。 マルチパス・ペイメントは、異なるパスを介してルーティングされる複数のLNペイメントで構成され、これらのペイメントはすべて、受信者によって同時に請求されます。これにより、ユーザーは同一の全体のペイメントにおいて、複数のチャネルで資金を使用または受信できるようになるため、LNの使いやすさが大幅に向上します。 このアップグレードにより、すべてのチャネルで利用可能な最大残高まで送信できるため（他のLN制限次第）、特定のチャネルでどのくらいの残高があるかを気にする必要がなくなります。
+- **LN<!--1-->実装へのマルチパス・ペイメントのサポート追加:** 数多くの議論と開発を経て、Optechがトラッキングしている3つのLN実装はすべて、[マルチパス・ペイメント][topic multipath payments]の基本サポートを追加しました（C-Lightning、Eclair、LND）。 マルチパス・ペイメントは、異なるパスを介してルーティングされる複数のLNペイメントで構成され、これらのペイメントはすべて、受信者によって同時に請求されます。これにより、ユーザーは同一の全体のペイメントにおいて、複数のチャネルで資金を使用または受信できるようになるため、LNの使いやすさが大幅に向上します。 このアップグレードにより、すべてのチャネルで利用可能な最大残高まで送信できるため（他のLN制限次第）、特定のチャネルでどのくらいの残高があるかを気にする必要がなくなります。
 
-- **bech32エラー検出の分析:** Pieter Wuilleは、以前のニュースレター（[#72][news72 bech32]、[#74][news74 bech32]および[#76][news76 bech32]）で説明されているbech32のマリアビリティの懸念をフォローアップする[メール][wuille bech32 analysis]をBitcoin-Devメーリングリストに送信しました。bech32文字列の最後にある`p`の直前に任意の数の`q`を追加または削除できます。 Wuilleの[分析][wuille bech32 analysis]は、これがbech32に期待したエラー検出能力の唯一の例外であり、「bech32の1つの定数を変更するとこの問題が解決する」ことを示しています。
+- **bech32<!--2-->エラー検出の分析:** Pieter Wuilleは、以前のニュースレター（[#72][news72 bech32]、[#74][news74 bech32]および[#76][news76 bech32]）で説明されているbech32のマリアビリティの懸念をフォローアップする[メール][wuille bech32 analysis]をBitcoin-Devメーリングリストに送信しました。bech32文字列の最後にある`p`の直前に任意の数の`q`を追加または削除できます。 Wuilleの[分析][wuille bech32 analysis]は、これがbech32に期待したエラー検出能力の唯一の例外であり、「bech32の1つの定数を変更するとこの問題が解決する」ことを示しています。
 
    Wuilleは、弱点を説明するために[BIP173][]を修正し、既存のbech32アドレスの使用を20バイトまたは32バイトのwitness programに制限する変更を提案する予定です。またWuilleは、Bitcoin以外の使用、および20バイトまたは32バイトではないwitness programが必要な将来のために、別の定数を用いたbech32の修正バージョンを定義する予定です。
 
 - **bip-ctvに関する変更提案:** Jeremy Rubinはソフトフォークによる更新を可能にする提案をしているオペコード`OP_CHECKTEMPLATEVERIFY`(CTV)に対するさらなる変更を[提案][rubin ctv update]しました。最も注目すべきは、この変更により、CTVで使用されるテンプレートをビットコインスクリプトを介して他のデータから導出できないという制限がなくなります。 この更新により、[Newsletter#75][news75 ctv]で説明されているScript言語への変更が簡単になります。 いずれの更新も、CTVの動作を、前述のユースケースに重大な影響を与える方法で変更することは私たちが知る限りありません（ただし、根本的な変更を認識している方は、リストで議論することをお勧めします）。
 
-- **LNノードに対するエクリプス攻撃の議論:** Antoine Riardは、Lightning-Devメーリングリストに、エクリプス攻撃によりブロックのリレーが遅らせることによるLNユーザーに対して可能な2つの攻撃について[投稿][riard eclipse]しました。攻撃者がISPもしくはユーザーのルーターを制御している場合によくあることですが、フルノードまたは軽量クライアントによって行われたすべての接続が1人の攻撃者によって制御されることによりエクリプス攻撃が起こります。これにより、攻撃者はノードまたはクライアントが送受信するデータを完全に制御できます。１つ目の攻撃手法として、攻撃者は、取り消されたコミットメントトランザクションを、正直なユーザーに気づかないように送信することができます。本来、取り消されたコミットメントトランザクションを検知した場合の対応策として、送信された相手側は一定時間内に対応するペナルティトランザクションを送信する必要があります。この検知を妨げることにより攻撃者は正直なユーザーから資金を盗むことができます。 もう１つの攻撃手法としては、HTLCの1つ以上が期限切れになりそうなため最新のコミットメントトランザクションをブロードキャストする必要があることを正直なユーザーに気づかなくさせることができます。これにより、攻撃者はHTLCの有効期限が切れた後に資金を盗むことができます。
+- **LN<!--2-->ノードに対するエクリプス攻撃の議論:** Antoine Riardは、Lightning-Devメーリングリストに、エクリプス攻撃によりブロックのリレーが遅らせることによるLNユーザーに対して可能な2つの攻撃について[投稿][riard eclipse]しました。攻撃者がISPもしくはユーザーのルーターを制御している場合によくあることですが、フルノードまたは軽量クライアントによって行われたすべての接続が1人の攻撃者によって制御されることによりエクリプス攻撃が起こります。これにより、攻撃者はノードまたはクライアントが送受信するデータを完全に制御できます。１つ目の攻撃手法として、攻撃者は、取り消されたコミットメントトランザクションを、正直なユーザーに気づかないように送信することができます。本来、取り消されたコミットメントトランザクションを検知した場合の対応策として、送信された相手側は一定時間内に対応するペナルティトランザクションを送信する必要があります。この検知を妨げることにより攻撃者は正直なユーザーから資金を盗むことができます。 もう１つの攻撃手法としては、HTLCの1つ以上が期限切れになりそうなため最新のコミットメントトランザクションをブロードキャストする必要があることを正直なユーザーに気づかなくさせることができます。これにより、攻撃者はHTLCの有効期限が切れた後に資金を盗むことができます。
 
    Riardの投稿と[Matt Corallo][corallo eclipse]および[ZmnSCPxj][zmn eclipse]からの返信の両方で、フルノードと軽量クライアントをエクリプス攻撃耐性のための今までの積み重ねてきた対策について説明します。 エクリプス攻撃とその軽減策について詳しく知りたい読者は、先週のビットコインコアレビュークラブの[ミーティングノートとログ][review club notes]を読むことを強くお勧めします。