今週のニュースレターでは、Bitcoin Coreの一部古いリリースに影響しているセキュリティ情報公開、taprootに関連する新しい開発、LN paymentのデータ形式に関連する潜在的なプライバシー漏洩、そして議論されているLN仕様に対する2つの変更提案について説明していきます。また、レギュラーセクションではBitcoinプロジェクトに関する注目すべきアップデートを共有します。

Action items

今週は特になし。

News

  • ● CVE-2017-18350 SOCKSプロキシの脆弱性： Bitcoin Coreバージョン0.11.0（2012年9月）から0.15.1（2017年11月）の脆弱性の全面開示がBitcoin-Devメーリングリストに 共有されました。この脆弱性はSOCKSプロキシを、信頼できないサーバーを利用したり信頼できないネットワークを介して接続するように設定したユーザーにのみ影響します。影響を受けるほとんどすべてのバージョンは、以前検知された脆弱性、例えばCVE-2016-10724（ Newsletter #1)参照）やCVE-2018-17144（ Newsletter #14参照）の影響も受けるため、ユーザーは既にBitcoin 0.16.3以降にアップグレードしているはずです。

  • ● Taprootのレビュー、ディスカッション、関連情報： Newsletter #69で言及されたtaprootのシステマティックレビューに、163名の方々が登録をしました。先週、このグループは bip-taprootの最初の部分と関連するコノンセプトのレビューを開始しました。これには、以前にtaprootの設計に貢献したBitcoinの専門家との質疑応答セッションへの参加が含まれます。

    質問の1つは、taprootがなぜv1 segwit scriptPubKeysで34バイト以外（未満もしくは以上）— これはPay-to-Taproot（P2TR）のscriptPubKeyに必要な量 — の使用を許容するのかについてでした。BIP141 v0 native segwit scriptPubKeysがP2WPKHに対してきっかり22バイト、P2WSHに対して34バイトの使用のみ許可しているため、異常に思えます。答えとしては、より少ない制限により、今後のソフトフォークがv1 scriptPubKeysの他での用途をより短く、もしくは長く定義できるようになるから、ということでした。それまでの間、taprootが採用された場合、これらのより短い/長いv1 scriptPubKeysは、今まで通り誰でも使用できます。

    これを機に、5月に報告され、最近詳細に説明されたbech32アドレスエンコーディングアルゴリズムの問​​題とこの柔軟性がどのように相互作用するかについて、専門家の間で議論が始まりました。 BIP173で指定されているBech32アドレスは、誤ってコピーされたアドレスで最大4つのエラーが検出され、5つ以上のコピーエラーがあった場合、約1/10億の確率で検出されないとされています。残念ながら、これらの試算は、コピーされたアドレスの長さが元のアドレスと同じであるという仮定の下で行われました。コピーされたアドレスが長いか短い場合、bech32はまれに1文字のエラーでさえ検出できないことがあります。

    既存のP2WPKHおよびP2WSH bech32アドレスの場合、v0 scriptPubKeysがきっかり22または34バイトであるという制限は、誤ったP2WPKHアドレスの場合は追加で12バイトを含める、P2WSHアドレスの場合は12バイトを省略する必要があるため、問題になることはほとんどありません。これは、ユーザーが約19文字（もしくはそれ以下）bech32文字を入力する必要があることを意味し、あり得ないほどの大きな間違いとなるためです。

    ただし、P2TRが34バイトのv1 scriptPubKeysに対してのみ定義されており、33バイトおよび35バイトのv1 scriptPubKeysを誰でも使用できる場合は、1文字の間違いをしただけで、送ろうとした金額をすべてを失う可能性があります。 BIP173とtaprootの著者Pieter Wuilleは、問題に対処するためのいくつかの選択肢をBitcoin-Devメーリングリストに投稿し、どのオプションが実装されることを望むかについてフィードバックを求めました。1つのオプションは、現在ある全てのbech32実装に、22または34バイトのscriptPubKeyにならないnative segwitアドレスを拒否するように制限をかけることです。そしてその後bech32が追加または削除された文字をより適切に検出できるよう、アップグレードバージョンを開発することを提案します。

    1週間のtaprootのレビュー中に、その他多くのクリティカルではない議論もされ、ディスカッションの詳細に興味がある人は誰でもディスカッションログを見ることが出来ます。 (1, 2)

    他のschnorr / taprootニュースとしては、Jonas Nickはセキュリティレベル下げることなくシリアル化された公開キーのサイズを33バイトから32バイトに減らしたbip-schnorrとbip-schnorrの最近の大きな変更に関する 有益なブログ投稿を公開しました。この最適化の以前の議論については、Newsletter#59および#68を参照してください。

  • ● LNオニオン形式でのプライバシー漏洩の可能性： BOLT4で説明されているように、LNはSphinxプロトコルを使用してLNノード間で支払い情報を通信します。Olaoluwa Osuntokunは今週Lightning-Devメーリングリストに、Sphinxの当初の説明にある最近公開された 欠陥は、宛先ノードが「パスの長さの下限を推定できる」と投稿しました 。この修正は簡単です。オニオンパケットの一部をゼロバイトで初期化する代わりに、ランダム値のバイトを利用します。 Osuntokunは、LNDが使用するオニオンライブラリでこれを実装するPRと、BOLTリポジトリのドキュメント PRを作成しました。他の実装でも同じ変更が採用されています（以下の C-Lightning commitコミットを参照）。

  • ● LNの前払い： 現在のLNプロトコルは、支払いの試みが失敗した場合、または受信者によって拒否された場合、すべてのお金を支出者に返すため、支払いの試みが成功した場合のみルーティングノードが収入を受け取ります。一部の新しいアプリケーションでは、この費用のかからない障害メカニズムを使用して、利用するバンドワイズを支払わずにLN経由でデータを送信しています。 LNの設計者はこれらが起こることを予想しており、以前からネットワークに前払い料金を追加する方法について考えていました。つまり、支払いの試みが成功したかどうかに関係なくルーティングノードに金額が支払われる仕組みです。

    今週、Rusty RussellはLightning-Devメーリングリストでスレッドを立ち上げ、前払い料金の提案について議論しました。Russellは、ノードがルートの長さを推測するために余分な前払い情報を使用するのを防ぐために、料金とhashcashのproof of workを組み合わせたメカニズムを提案しました。 Anthony Townsは、払い戻しメカニズムを使用した支払い金額の管理に焦点を当てた部分的代替案を提案しています。

    Joost Jagerは、少額の追加コストでもマイクロペイメントの採算が取れなくなる可能性があるため、前払いは最後の手段としてのみ必要であることを提案しました。彼はノードレピュテーションに基づくレート制限を使用してバンドワイズの浪費するネットワークアクティビティに対処することが可能であることを提案し、前払いの研究はまず流動性濫用（アタッカーが一定期間in-channelファンドを停止させるなど）の解決に焦点を当てる必要があることを提案しました。これによりルーティングノードのバンドワイズ乱用も防ぐことができます。

    最終的な結論はまだ得られておらず、この記事の執筆時点ではこのトピックに関する議論は継続中です。

  • ● LNオファー用に提案されたBOLT： Rusty Russellは、ユーザーがLNルーティングプロトコルを介してオファーを送信し、インボイスを受け取ることができる新しいBOLTのドラフトテキストを投稿しました。たとえば、アリスはボブが提供するサービスに加入し、毎月ボブに支払いのオファーを送信し、ボブはインボイスで返信し、アリスはインボイスに支払い、ボブはサービスを提供することが出来ます。

    提案に対する初期のフィードバックは Universal Business Language（UBL）など、機械で読み取りが出来る、確立された言語を使用することが提案されています。しかし、完全なUBL仕様を実装することは、LNソフトウェアの開発者にとって過度の負担になるという懸念も上がっています。

  • ● Optechウェブサイトの新しいトピックインデックス： Optechウェブサイトにトピックインデックスを追加し、読者が特定のトピックに言及したOptechウェブサイトの全ページを簡単に見つけられるようにすることを発表しました。インデックスは40トピックでまずリリースされており、来年には約100トピックに増やしたいと考えています。

Notable code and documentation changes

今週のBitcoin Core, C-Lightning, Eclair, LND, libsecp256k1, Bitcoin Improvement Proposals (BIPs), および Lightning BOLTsの注目すべき変更点。

  • ● Bitcoin Core #16110は、Android Native Development Kit（NDK）のBitcoin Core（GUIを含む）のビルドのサポートを追加します。 Android NDK用の独自のBitcoin Coreバイナリを構築するAndroid Bitcoin Core (ABCore)のような独立したプロジェクトとは対照的に、Bitcoin Coreプロジェクトに直接サポートを追加すると、テストが簡単になるでしょう。また、将来のPRにおいて、Androidビルドを確定的に生成された実行可能ファイルを追加追加することもできます。これによりユーザーは、コードリポジトリにあるコードと同じレベルの十分にレビューされたものを実行している、というより大きな保証を受けることができます。

  • ● Bitcoin Core #16899は、現在のUTXOセットのコピーを、将来assumeutxoを活用するブートストラップノードで使用するために設計されたシリアル化形式で、ディスクに書き込むdumptxoutset RPCを追加します（ Newsletter #41参照）。さらに、プロジェクトのコントリビューターツールにスクリプトが追加されます。このスクリプトは指定されたブロックの高さにブロックチェーンが巻き戻し、その時点でUTXOセットがダンプしてから、ブロックの再処理が正常に再開します。これにはブロックごとに数秒かかる場合があるため、過去に数千ブロックの高さでこのスクリプトを実行すると、非常に長い時間がかかる場合があります。

  • ● Bitcoin Core #17258は、listsinceblock RPCを更新し、別のトランザクションが同じ入力の少なくとも1つを使用し、ブロックがRPCコールによって評価される前にブロックチェーンに既に含まれていたために確認できないトランザクションを、リストしないようにします。

  • ● C-Lightning #3246 は今週、LNメーリングリストで説明されている潜在的なデータ漏洩の修正を試みます。

  • ● LND #3442により、支払い側は、シンプルマルチパスペイメント（複数に分割され、異なるチャネルを介して独立してルーティングできる支払い）のパケットを手動で構築できます。これは、ユーザーがアクセスするためのものではなく、マルチパス支払いに関連する機能を追加するであろう、今後のリリースのためのものです。マルチパス支払いの詳細については、Newsletter #27をご参照ください。

  • ● BIPs #857はBIP157を編集して、一度に要求できるコンパクトブロックフィルターの最大数を100から1,000に増やします。これは昨年のPRが1,000から100に下げた数を、また戻すものです。

  • ● BIPs #849はBIP174を編集して、標準化されていない（独自の）アプリケーションで使用するために、部分的署名ビットコイントランザクション（Partially Signed Bitcoin Transactions または PSBT）で特定のデータタイプ識別子を割り当てます。さらに、PSBTには、下位互換性のないPSBTへの変更を識別するのに役立つバージョン番号が付与されるようになりました。明示的なバージョン番号を含まない古いPSBTには、暗示的なバージョン番号0をふります。両方の変更は、Bitcoin-Devメールリスト（Newsletter #58を参照）。

  • ● BIPs #856 は、現在の用語「Bitcoin address」（ビットコイン アドレス）を「Bitcoin invoice address」（ビットコインインボイスアドレス）または「invoice address」（インボイスアドレス）や「invoice」（インボイス）などの単純なバリエーションに変更することを提案する提案であるBIP179を追加します。これは、以前Bitcoin-Devメーリングリストで議論 されています。

  • ● BIPs #803は BIP325に、マイニングブロックの代わりに署名付きブロックに基づいてテストネットを作成するためのシグネットプロトコルの説明を追加します。シグネットはオペレーターがブロックの生成レートとブロックチェーンの再編成の頻度と規模を制御できるようにします（Newsletter #37を参照））。

  • ● BIPs #851は、エラープロトコルの一部として使用することを目的としたトランザクションアナウンスメント調整方法の説明を含むBIP330を追加します（Newsletter #66を参照）。この機能がノードソフトウェアに採用された場合、トランザクションアナウンスメントリレーのバンドワイズオーバーヘッド（現在ある典型的なノードの40％以上のバンドワイズ）を大幅に削減する最初のステップになります。