en | ja

Bitcoin Optech Newsletter #77

Dec 18, 2019

今週のニュースレターは、LND 0.8.2-betaのリリースの発表、最新のC-Lightningリリース候補のテスト支援要請、LNの基本的なマルチパス・ペイメントの広範なサポートについてのディスカッション、bech32エラー検出の信頼性に関するアップデートの提供、OP_CHECKTEMPLATEVERIFYオペコードの提案に関するアップデートのサマリー、LNチャネルにおけるエクリプス攻撃の影響に関するディスカッションのリンクなどをお送りします。また、主要なBitcoinインフラストラクチャ・プロジェクトに関する注目すべき変更、サービスとクライアント・ソフトウェアの変更、および主要なBitcoin StackExchangeのQ&Aもお届けします。

Action items

● LND 0.8.2-betaへのアップグレード: 本リリースには、複数のバグ修正とUXのマイナーな改善が含まれます。特に、Static channel backupsのリカバリに関するものです。
● C-Lightning 0.8.0 RCのテストのご協力: C-Lightningの次期バージョンリリース候補では、デフォルト・ネットワークをテストネットからメインネットへ変更し（Newsletter #75を参照）、後述する基本的なマルチパス・ペイメントのサポートを追加します。また、その他の追加機能、バグ修正も含まれます。
● bech32アクションプランの確認: 後述のとおり、Pieter Wuilleは、すべてのbech32アドレスを20または32バイトのウィットネス・プログラムに制限し、pで終わるアドレスに関連する転記エラーによる資金損失の防止を提案しています。このルールは、P2WPKHおよびP2WSHに使用されるv0 segwitアドレスに既に適用されているため、変更は、将来のアップグレード（提案されているtaprootなど）のために現在予約されているv1以降のアドレスに拡張するだけのものです。これには、bech32送信サポートを既に実装しているウォレットとサービスは、コードをアップデートする必要がありますが、変更は小さいものとなります。例えばPythonリファレンス実装の場合、次のようになります。
```
  --- a/ref/python/segwit_addr.py
  +++ b/ref/python/segwit_addr.py
  @@ -110,7 +110,7 @@ def decode(hrp, addr):
           return (None, None)
       if data[0] > 16:
           return (None, None)
  -    if data[0] == 0 and len(decoded) != 20 and len(decoded) != 32:
  +    if len(decoded) != 20 and len(decoded) != 32:
           return (None, None)
       return (data[0], decoded)
```
この提案された変更について質問や懸念がある場合は、以下のNewsセクションにリンクされているメーリングリストの投稿に返信してください。

News

● LN実装へのマルチパス・ペイメントのサポート追加: 数多くの議論と開発を経て、Optechがトラッキングしている3つのLN実装はすべて、マルチパス・ペイメントの基本サポートを追加しました（C-Lightning、Eclair、LND）。マルチパス・ペイメントは、異なるパスを介してルーティングされる複数のLNペイメントで構成され、これらのペイメントはすべて、受信者によって同時に請求されます。これにより、ユーザーは同一の全体のペイメントにおいて、複数のチャネルで資金を使用または受信できるようになるため、LNの使いやすさが大幅に向上します。このアップグレードにより、すべてのチャネルで利用可能な最大残高まで送信できるため（他のLN制限次第）、特定のチャネルでどのくらいの残高があるかを気にする必要がなくなります。
● bech32エラー検出の分析: Pieter Wuilleは、以前のニュースレター（#72、#74および#76）で説明されているbech32のマリアビリティの懸念をフォローアップするメールをBitcoin-Devメーリングリストに送信しました。bech32文字列の最後にあるpの直前に任意の数のqを追加または削除できます。 Wuilleの分析は、これがbech32に期待したエラー検出能力の唯一の例外であり、「bech32の1つの定数を変更するとこの問題が解決する」ことを示しています。

Wuilleは、弱点を説明するためにBIP173を修正し、既存のbech32アドレスの使用を20バイトまたは32バイトのwitness programに制限する変更を提案する予定です。またWuilleは、Bitcoin以外の使用、および20バイトまたは32バイトではないwitness programが必要な将来のために、別の定数を用いたbech32の修正バージョンを定義する予定です。
● bip-ctvに関する変更提案: Jeremy Rubinはソフトフォークによる更新を可能にする提案をしているオペコードOP_CHECKTEMPLATEVERIFY(CTV)に対するさらなる変更を提案しました。最も注目すべきは、この変更により、CTVで使用されるテンプレートをビットコインスクリプトを介して他のデータから導出できないという制限がなくなります。この更新により、Newsletter#75で説明されているScript言語への変更が簡単になります。いずれの更新も、CTVの動作を、前述のユースケースに重大な影響を与える方法で変更することは私たちが知る限りありません（ただし、根本的な変更を認識している方は、リストで議論することをお勧めします）。
● LNノードに対するエクリプス攻撃の議論: Antoine Riardは、Lightning-Devメーリングリストに、エクリプス攻撃によりブロックのリレーが遅らせることによるLNユーザーに対して可能な2つの攻撃について投稿しました。攻撃者がISPもしくはユーザーのルーターを制御している場合によくあることですが、フルノードまたは軽量クライアントによって行われたすべての接続が1人の攻撃者によって制御されることによりエクリプス攻撃が起こります。これにより、攻撃者はノードまたはクライアントが送受信するデータを完全に制御できます。１つ目の攻撃手法として、攻撃者は、取り消されたコミットメントトランザクションを、正直なユーザーに気づかないように送信することができます。本来、取り消されたコミットメントトランザクションを検知した場合の対応策として、送信された相手側は一定時間内に対応するペナルティトランザクションを送信する必要があります。この検知を妨げることにより攻撃者は正直なユーザーから資金を盗むことができます。もう１つの攻撃手法としては、HTLCの1つ以上が期限切れになりそうなため最新のコミットメントトランザクションをブロードキャストする必要があることを正直なユーザーに気づかなくさせることができます。これにより、攻撃者はHTLCの有効期限が切れた後に資金を盗むことができます。

Riardの投稿とMatt CoralloおよびZmnSCPxjからの返信の両方で、フルノードと軽量クライアントをエクリプス攻撃耐性のための今までの積み重ねてきた対策について説明します。エクリプス攻撃とその軽減策について詳しく知りたい読者は、先週のビットコインコアレビュークラブのミーティングノートとログを読むことを強くお勧めします。

Changes to services and client software

この月刊セクションでは、ビットコインのウォレットとサービスの興味深い更新を取り上げます。

● BitfinexはLNの入出金をサポートしています: 最近のブログ投稿で、Bitfinexの取引所はLightning Networkのサポートを発表しました。 Bitfinexのユーザーは、LNを使用して資金の入金と引き出しの両方ができるようになりました。
● BitMEX ResearchがLNペナルティトランザクショントラッカーを開始: BitMEX Researchが投稿した記事によると、オープンソースのForkMonitorツールがLightningペナルティトランザクションを一覧表示するようになりました。このツールは、フォークを検出するために、さまざまなビットコイン（BTC、BCH、BSVなど）のチェーン情報とバージョンも監視します。
● BitMEX bech32送信サポート: 最近のブログ投稿で、BitMEXは取引所からネイティブbech32アドレスへの送信のサポートを発表しました。この投稿では、BitMEX自身のウォレットをP2SHからP2SHでラップされたsegwitアドレスに移行する計画の概要も説明しています。
● Unchained CapitalがマルチシグコーディネーターであるCaravanをオープンソース化: ブログ投稿とデモビデオを使用して、Unchained Capitalは、Caravanというマルチシグコーディネーターをオープンソース化しました。 Caravanは、さまざまな外部キーストアを使用してマルチシグアドレスの作成および支払いをするためのステートレスWebアプリケーションです。

Selected Q&A from Bitcoin StackExchange

Bitcoin StackExchangeはOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・答えについて共有しています。

● Lightningネットワークのパス長制限（20ホップ）の理論的根拠は？ Sergei TikhomirovがBOLT4の20ホップ制限とTorのオニオンルーティングとLNのスフィンクスの違いについて質問しています。 Rene Pickhardtは、プロトコルの違いと現在の20ホップの根拠を説明しています。20ホップの根拠については、TCP/ IPパッケージを小さく保つ必要があり、またLN自体が小規模なネットワークである（20ホップもあれば相手に到達できる規模である）という説明しています。
● トランザクションの構築で未コンファーム状態のRBF(Rplace-by-Fee)アウトプットを使用できるようにする方法はありますか？ G. Maxwellは、Bitcoin Coreは、RBFサポートを通知しないトランザクションのアウトプットを処理するのと同じ方法で、RBFを選択したことを通知するトランザクションのアウトプットを処理することを説明しています。 Bitcoin Coreによるアウトプットの処理方法で違いが発生するのは、出力を含むトランザクションがコンファームされたかどうか、およびトランザクションがユーザーのBitcoin Coreウォレットによって作成されたかどうかによるものです。
● BIP32派生パスに許可される最大の深さは？ Andrew Chowは、BIP32が深さのフィールドに1バイトを割り当てているため派生パスに最大256個の可能な要素があると説明しています。

Notable code and documentation changes

今週のBitcoin Core、C-Lightning、Eclair、LND、libsecp256k1、ビットコイン改善提案（BIP）、およびLightning BOLTの注目すべき変更点。

● Bitcoin Core #17678 は、S390Xおよび64ビットPOWER CPUアーキテクチャへのコンパイルのサポートを追加します。
● Bitcoin Core #12763 は、特定のユーザーが実行できるRPCを制限できるRPCホワイトリスト機能を追加します。デフォルトでは、認証されたユーザーはすべてのコマンドを実行できますが、新しい設定オプションrpcwhitelistとrpcwhitelistdefaultを使用して、どのユーザーがどのRPCにアクセスできるかを設定できます。
● C-Lightning #3309 は、上記のnewsセクションの説明としてマルチパス・ペイメントのサポートを追加します。
● LND #3697 は、デフォルトの最小HTLC値を0ミリサトシ（msat）に設定します。新しいチャネルの場合、以前のデフォルトの1,000 msatから減少します。チャンネルを開いた後、HTLCの最小値を変更することはできません。この変更により、本設定を使用するチャンネルでサブサトシの支払いを受け入れることができます。
● LND #3785 は、Newsletter#74で言及されている問題を解消します。これまではC-LightningとLNDとで同じメッセージに異なる形式を使用し、解析エラーおよびコネクション切断が発生していました。
● LND #3702 は、closechannelRPCをdelivery_addressパラメーターで拡張します。このパラメーターを使用して、指定したアドレスに資金を送信するチャネルの相互クローズを要求できます。先週のニュースレターで説明されているアップフロント・シャットダウン・スクリプト機能をユーザーが以前にアクティブにした場合、これは機能しません。
● LND #3415 は、LNDに基本的なマルチパス・ペイメント・サポートのために必要なコードを追加し、マルチパス・ペイメントによるインボイスの決済を可能にします。（上記のNewsセクションの説明を参照）
● BOLTs #643 は、Newsセクションに記載されている通り、基本的なマルチパス・ペイメントのサポート追加します。Lighting Specification 1.1 Meetingにて1年前に設定された主要なゴールの１つであるLNウォレットUXを大幅に改善に関して達成したことになります。

Holiday publication schedule

12月25日または1月1日には、ニュースレターの発行はありません。代わりに、12月28日土曜日に2回目のアニュアル・レビュー特別レポートを発行します。通常のニュースレターの発行は、1月8日水曜日に再開されます。

良い休日を！