今週のニュースレターは、Bitcoin CoreおよびLNDのリリース候補のテストの協力の推奨、以前提案されたnoinputおよびanyprevout sighashフラグに関する継続的な議論内容の、Bitcoinインフラストラクチャプロジェクトに対するいくつかの注目すべき変更について説明します。

Action items

  • ● Bitcoin Core 0.19.0rc1のテスト支援: Bitcoin Coreを活用している事業ユーザーは、 最新のリリース候補をテストして、自身の組織のニーズを満たすことを確認することが特に推奨されています。特にテスト実行可能な経験豊富なユーザーは、GUIをテストする時間を取り、本テストに参加していない経験の少ないユーザーに影響する可能性のある問題を探ることが推奨されています。

  • ● LND 0.8.0-beta-rc2のテスト支援: LNDの経験豊富なユーザーは、次のリリースの テスト支援することを推奨します。このテストには、LNDの ビルドの再現性 も含まれており（今回が初）、LND開発者が配布したバイナリと同一のものがビルドで生成されたかを確認することが含まれています。

News

  • ● NOINPUT / anyprevoutの議論が継続: LN上で eltoo を使用可能とするsighash flagが、Bitcoin-devとLightning-devのメーリングリスト上で再び 議論されました。 今まで議論を要約した後、クリスチャン・デッカーはいくつかの質問をしました： 本提案の背後にあるアイデアは有用か？（ここは同意を得られているように見受けられました） chaperon signaturesが必須となることはどう考えているか？（反対意見もいくつかあるように見受けられました） Transaction outputに強制的にタグがつけられることに対してどう考えているか？（反対意見が挙がり、特にその一部は強くそれを感じました。）

    Transaction outputのタグ付けに関する質問に応えて、C-Lightningの貢献者ZmnSCPxj は、タグをtaprootコミットメント内に配置する代替タグ付けメカニズムを提案しました。これにより、outputのタグ付けの元の目標である、noinput互換スクリプトへの支払いの防止を、プライバシーとファンジビリティの毀損させることなく実現できます。このアイデアに興味を示した人が何人かいましたが、ZmnSCPxjの提案を知りたいのか、もしくはTransaction outputのタグ付けにそもそも賛成なのかはよくわかりませんでした（上記のように、反対意見が多く見受けられました）。

    スレッド全体は現在20メッセージを超えており、これについてのOP_CATについてのスピンオフディスカッションが開始されました 。noinputに関連する課題が解決してソフトフォークの提案に含まれるためにも、このディスカッションが軌道に乗ることを願っています。

注目すべきコードとドキュメントの変更点

Bitcoin Core,LND, C-Lightning, Eclair,libsecp256k1, Bitcoin Improvement Proposals(BIPs), Lightning BOLTs.における注目すべき変更点

  • ● Bitcoin Core #13716 これは、ウォレットパスフレーズをシェル履歴に保存されるCLIパラメーターとしてではなく、標準入力バッファーから読み取ることができるようにするためのパラメーター-stdinrpcpass -stdinwalletpassphraseをbitcoin-cliに追加しました。また、読み取り中は標準入力のエコーが無効になるため、パスフレーズは画面を見ている人には見えません。

  • ● Bitcoin Core #16884 は、RPCインターフェイス（bitcoin-cli経由も含む）のユーザーのデフォルトアドレスタイプをP2SHでラップされたP2WPKHからネイティブsegwit（bech32）P2WPKHに切り替えます。この変更はマスター開発コードブランチにあり、2020年半ばのBitcoin Core 0.20.0までリリースされる予定はありません。ただし、来月に0.19.0の一部としてリリースされる予定のBitcoin Core #15711により、GUIユーザーのデフォルトのアドレスタイプもbech32 P2WPKHも使用されるように変更されます。

  • ● Bitcoin Core #16507 は、ノードがdynamic minimum feerateよりも高いfeerateのTransactionをメムプールに取り込むが、ピアにリレーしない問題を解消しました。本問題はdynamic minimum feerateが0.00001000 BTC単位で切り上げされた結果、Transactionのfeerateを超えた際に発生するものです。

  • ● LND #3545 は、ユーザーがLNDの再現可能なビルドを作成できるようにするコードとドキュメント を追加します。これにより、中程度の技術スキルを持つ人がLightning Labsがリリースしたものと同一のバイナリを構築できるようになり、ユーザーがLNDリポジトリからピアレビューされたコードを実行できるようになります。

  • ● LND #3365 は、このセクションで後述されるように 、 option_static_remotekey commitment outputsの使用のサポートを追加します。この新しいcommitment protocolは、何らかの原因によりデータを失ったときに特に役立ちます。その場合は、HDウォレットから直接派生したキーを支払うことで、チャンネルの相手がチャンネルを閉じるのを待つだけです。キーは追加のデータ（”tweaking”）なしで生成されたため、ウォレットは資金を見つけて使用するために追加のデータを必要としません。これは、LNDが以前使用していた data loss protection プロトコルの単純化された代替手段です。

  • ● C-Lightning #3078 は、LiquidサイドチェーンでLiquid-BTCを使用するチャネルの作成と使用のサポートを追加します。

  • ● C-Lightning #2803 はLN仕様の部分的な実装を含む新しいpythonパッケージ pyln を追加します。 ドキュメント,にはこう記載されています。「このパッケージは、純粋なPythonでLightningネットワークプロトコルの一部を実装しています。プロトコルのテストと一部のマイナーなツールのみを対象としています。実際の資金を扱うのに十分な安全性があるとはみなされていません（これは警告です！）」

  • ● C-Lightning #3062 はplugin コマンドでは、要求されたプラグインが20秒以内に正常な起動を報告しなかった場合、エラーを返します。

  • ● BOLTs #676 は、BOLT2を修正して、ノードがfunding transactionを検証するまでfunding_lockedメッセージを送信しないように指定します。これにより、先週のニュースレターで説明されている脆弱性につながる問題について、今後の実装者に警告します。

  • ● BOLTs #642 を使用すると、2つのピアがチャネルを開いてoption_static_remotekeyフラグについてネゴシエートできます 。両方のピアがこのフラグを設定した場合、一方的に（チャネルを強制的に閉じるために）使用できるコミットメントトランザクションは、最初のチャネルのオープン時にネゴシエートされた静的アドレスにピアの資金を支払う必要があります。たとえば、Aliceがaddressbc1ally、Bobがaddressbc1bobを保持しており、両方がoption_static_remotekeyである場合、Aliceがonchainで発行できるコミットメントトランザクションはbc1bobに、Bobがonchainで発行できるコミットメントトランザクションはbc1allyに支払われる必要があります。ノードのうち少なくとも1つがこのフラグを設定しない場合、リモートピアのpubkeyとcommitment identifierを組み合わせて作成されたアドレスを使用して、コミットメントトランザクションごとに異なる支払いアドレスを使用する古いプロトコルにフォールバックします。

    常に同じアドレスに支払うことで、そのアドレスはクライアントのHDウォレット内の通常の派生可能なアドレスになり、ユーザーはHDシード以外のすべての状態を失った場合でも資金を回収できます。これは、少なくともリモートピアと通信してチャネルを識別できる十分な状態を保存することに依存する data loss protection プロトコルよりも優れていると考えられて います。option_static_remotekeyを使用することにより、リモートピアは最終的に欠落しているピアが現れるのを待つことにうんざりし、一方的にチャネルを閉じて、HDウォレットが見つけるオンチェーン上のアドレスに返却することが想定できます。