今週のニュースレターでは、LNのスプライシングのドラフト仕様、 トランザクションリレーのセキュリティに関するワークショップのお知らせ、 libsecp256k1-zkpへのECDSA署名アダプターサポート追加の発表、 BIPプロセスの変更提案のリンクを掲載しています。 また、Bitcoin Stack Exchangeで人気のあった質問と回答の要約、 ソフトウェアのリリースとリリース候補のお知らせ、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更点の説明など、 通常のセクションも含まれています。

ニュース

  • LNスプライシングのドラフト仕様: Rusty Russellは、Lightning Specificationリポジトリ(“BOLTs”)に スプライシングに対応するために必要なプロトコルの変更を提案する PRを公開しました。 また、PRのリンクをLightning-Devメーリングリストに投稿しました。 スプライシングを利用すると、チャネル参加者は、 チャネルの資金を使用するのにオンチェーン承認の遅延を待つことなく、 資金をオンチェーンのアウトプットから既存のペイメントチャネルに、 もしくは既存のペイメントチャネルから独立したオンチェーン・アウトプットに転送することができます。 これにより、ウォレットは残高管理の技術的な詳細をユーザーから隠すことができます。 例えば、アリスのウォレットは同じペイメントチャネルからボブに対して、 オフチェーンもしくはオンチェーンで自動的に支払いをすることができます。 オフチェーンではそのペイメントチャネルを介してLNを使用し、 オンチェーンではそのペイメントチャネルからスプライス・アウト(引き出し)を使用します。

    Russellは以前、2018年にスプライシングのドラフト仕様を提案していましたニュースレター #17参照)。今回の新しいドラフトでは、C-Lightningが実験的にサポートしている デュアル・ファンディングの一部に含まれている対話型のファンディングプロトコルを使用できるという利点があります。

  • クロスレイヤー・ワークショップのトピック募集: Antoine Riardは、LNなどのレイヤー2プロトコルに影響を与えるオンチェーントランザクションリレーの課題を議論するために、 IRCベースのワークショップを開催する予定であることをBitcoin-DevメーリングリストとLightning-Devメーリングリストに投稿しました。 その目的は、どの提案が注目に値するかについて参加者間で技術的なコンセンサスを得て、 開発者やレビュアーが短期的にそれらの提案に集中できるようにすることです。

    この投稿では、パッケージリレーや手数料スポンサー(ニュースレター #116参照)、 BIP125 opt-in Replace By Fee(RBF)からフルRBFへの移行、 フルノードなどのオンチェーンプロジェクトとLNノードなどのオフチェーンプロジェクト間のセキュリティ対応の調整の改善、 レイヤー2プロトコルに合理的に依存できるmempoolとリレーポリシーの定義などのアジェンダが提案されています。 またRiardは、5月7日を締め切りとして、参加予定者に追加のトピックの提案も求めています。 ワークショップの開催は6月中旬を予定しています。

  • libsecp256k1-zkpにECDSA署名アダプターのサポートを追加: 署名アダプターは、もともとAndrew PoelstraがBitcoinのために Schnorrベースのマルチシグを使って説明したものです。 これにより1つの署名で最大3つのことを同時にできるようになりました: (1) 作成者が特定の秘密鍵にアクセスしたことの証明、 (2) 他の参加者が事前に選択した暗号鍵を知っていることの証明、 (3) 事前に選択した暗号鍵を別の参加者に公開。 これにより、現在Bitcoin Scriptで行っていることの多くを署名だけで行うことができ、 アダプター署名を使用して”Scriptless Script”を作成することができると考えられます。

    ECDSAで同じことを実現するのは、それほど簡単ではありません。 しかし、Lloyd Fournierは、ゴール#1(秘密鍵の証明)をゴール#2とゴール#3(暗号鍵の証明と公開、別名アダプター) から分離すれば、比較的簡単になると提案しました。 この場合、1つの署名オブジェクトを単なる署名として使用し、 別の署名オブジェクトをアダプター用に使用する必要があるため、 OP_CHECKMULTISIGを使用することになり、前述したようなScriptlessにはなりません。 また、この分離した構造では、楕円曲線Diffie Hellman (ECDH)鍵交換とElGamal暗号に関わる鍵の一部を再利用することに関連して、 セキュリティ上の警告が必要です。それ以上に、 この技術は今日のBitcoinで署名アダプターを完全に使用可能にするもので、 それはさまざまなDLCプロジェクトで使用されています。

    2020年4月、Jonas NickはドラフトPRでこれらの簡略化されたECDSA署名アダプター (ニュースレター #92参照)のサポートを実装しました。 Jesse Posnerは、より高度な暗号プロトコルをサポートするlibsecp256k1のフォークであるlibsecp256k1-zkpに、 このPRを移植、拡張しました。更新されたPRは、 署名アダプターのセキュリティをよりよく理解しようとしている人にとって興味深い いくつかの会話を含む詳細なレビュープロセスの後、マージされました。

  • BIPプロセスの問題: BIPリポジトリでいくつかのドラマ(そしておそらく以前からの不満)があった後、 新しいBIP編集者の追加、botを使ったBIPのPRのマージ、 また中央化されたBIPリポジトリの完全放棄について、 メーリングリストでいくつかの議論が始まりました。

Bitcoin Stack Exchangeから選ばれたQ&A

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

リリースとリリース候補

人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。

  • Bitcoin Core 0.21.1rc1は、 提案されているTaprootソフトフォークのアクティベーションロジックを含むバージョンのBitcoin Coreのリリース候補です。 Taprootは、Schnorr署名を使用し、Tapscriptを使用可能にします。 これらはそれぞれ、BIP 341340および342で定義されています。 また、BIP350で定義されたbech32mアドレスへの支払いを行う機能も含まれていますが、 mainnet上でそのようなアドレスに送金されるビットコインは、 taprootなどのそのようなアドレスを使用するソフトフォークがアクティベートされるまで安全ではありません。 この他にもバグ修正や小さな改善が行われています。

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

今週のBitcoin CoreC-LightningEclairLNDRust-Lightninglibsecp256k1Hardware Wallet Interface (HWI)Rust BitcoinBTCPay ServerBitcoin Improvement Proposals(BIP)、および Lightning BOLTsの注目すべき変更点。

  • Bitcoin Core #21595では、bitcoin-cli実行ファイルに新しいaddrinfoコマンドが追加されました。 bitcoin-cli -addrinfoを実行すると、ノードが知っている潜在的なピアのネットワークアドレースのカウントが ネットワークタイプ毎に分けて返されます。サンプル出力:

      $ bitcoin-cli -addrinfo
      {
        "addresses_known": {
          "ipv4": 14406,
          "ipv6": 2511,
          "torv2": 5563,
          "torv3": 2842,
          "i2p": 8,
          "total": 25330
        }
      }
    
  • Rust-Lightning #844は、LNDC-Lightningおよび Eclairと互換性のあるスキームを使用した メッセージの署名、署名検証および公開鍵のリカバリーをサポートしました。

  • BTCPay Server #2356は、WebAuthN/FIDO2プロトコルを使用した多要素認証をサポートしました。 U2Fを使用したBTCPayの既存の多要素認証は引き続き動作します。

  • Libsecp256k1 #906は、可変時間アルゴリズムよりもサイドチャネル攻撃の耐性が高い定数時間アルゴリズムを使用する際に、 モジュラ逆数の計算に必要な反復回数を724から590に削減しました。アルゴリズムの正しさは、 Coq proof assistantを使用してチェックされ、最も厳密な検証には約66日の実行時間を要しました。 この改善につながったアルゴリズムの進歩については、ニュースレター #136をご覧ください。