今週のニュースレターでは、提案中のOP_VAULT opcodeのBIPドラフトのリンクや、 LNノードがチャネルにサービス品質フラグを設定できるようにすることについての議論、 LNの近隣ノードの評価基準に関するフィードバックのリクエスト、 電子機器なしで確実に実行できるシードのバックアップおよびリカバリー方式のBIPドラフトを掲載しています。 また、Bitcoin StackExchangeの人気のある質問とその回答の要約や、 新しいリリースおよびリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、 恒例のセクションも含まれています。

ニュース

  • ● OP_VAULTのBIPドラフト: James O’Beirneは、彼が以前提案したOP_VAULT opcodeのBIPドラフト（ニュースレター #234参照）のリンクを Bitcoin-Devメーリングリストに投稿しました。 彼はまた、Bitcoinのコンセンサスやネットワーク・プロトコルルールへの主な変更をテストするプロジェクトである Bitcoin Inquisitionにコードをマージしようとしていることも発表しました。

  • ● LNのサービス品質フラグ: Joost Jagerは、 ノードがチャネルが「高可用性」であること（オペレーターが失敗することなく支払いを転送できると信じている状態）を 通知できるようにする提案をLightning-Devメーリングリストに投稿しました。 支払いの転送に失敗した場合、支払人は今後の支払いでそのノードを長期間使用しないことを選択できます。 この期間は、支払人が高可用性を通知しなかったノードに使用するよりもはるかに長い期間になります。 （手数料の安さよりも）支払い速度を最大化する支払人は、自己識別された高可用性ノードで構成される支払い経路を優先的に選択します。

    Christian Deckerは、自己評価を含むレピュテーションシステムの問題点について優れた要約を返信しました。 彼の懸念の1つは、一般的な支払人は、大規模なペイメントチャネルネットワークにおいて、 同じノードに頻繁に遭遇するほど多くの支払いを送らないという点です。 リピート率が高くなければ、一時的にリピートを提供しないという脅しは効果的ではないかもしれません。

    Antoine Riardは、支払いを高速化する別のアプローチである回収付きの過払いを参加者にリマインドしました。 以前、ブーメラン・ペイメント（ニュースレター #86参照）や 払い戻し可能な過払い（ニュースレター #192参照）と呼ばれていたこの方法では、 支払人は支払額と余分な額を、いくつかのパーツに分割して、 さまざまな経路で送信します。インボイスへの支払い額に対して十分な数のパーツが到着したら、 受取人はそのパーツのみを請求し、後から届いた追加のパーツ（余分な金額分）は拒否します。 このため、迅速な支払いを望む支払人は、自分のチャネルにある程度の追加資金を保持している必要がありますが、 選択した経路のいくつかが失敗しても機能します。このため、 支払人が可用性の高いチャネルを簡単に見つけられる必要性が低くなります。 この方法の課題は、到着した過払い分を受取人が保持できないようにする仕組みを構築することです。

  • ● LNの良い近隣ノードのスコア化に関するフィードバックのリクエスト: Carla Kirk-CohenとClara Shikhelmanは、Lightning-Devメーリングリストに、 チャネルの相手が転送された支払いの適切なソースかどうかをノードが判断するための推奨パラメーターに関する フィードバックのリクエストを投稿しました。 彼らは、判断するためのいくつかの判断基準と各基準に対する推奨デフォルトパラメーターを提案しており、 その選択についてのフィードバックを求めています。

    ノードがピアの1つを良い近隣ノードと判断し、そのノードが転送された支払いを承認するタグをつけると、 ノードは非適格な支払いに与えるのよりも多くのリソースへのアクセスを与えることができます。 また、ノードは支払いを次のチャネルに転送する際に、その支払いを承認することもできます。 Shikhelmanの共著論文にあるように（ニュースレター #226参照）、 これはチャネルジャミング攻撃を緩和する提案の一部です。

  • ● Codex32 シードエンコード方式のBIP提案: Russell O’ConnorとAndrew Poelstra（名前のアナグラムを使用）は、 BIP32シードのバックアップとリカバリーを行う新しい方式のBIPを提案しました。 SLIP39と同様、オプションでシャミアの秘密分散法 (SSSS)を用いて複数のシェアを作成でき、 シードをリカバリーするために必要な設定数のシェアを一緒に使用することを求めます。 攻撃者は、閾値以下の数のシェアを取得してもシードについて何も知ることができません。 ワードリストを使用するBIP39、Electrum、Aezeed、SLIP39のリカバリーコードと異なり、 Codex32はbech32アドレスと同じアルファベットを使用します。 BIPドラフトのシェアの例:

    ms12namea320zyxwvutsrqpnmlkjhgfedcaxrpp870hkkqrm

    Codex32が既存のすべての方式と比較して優れているのは、 すべての操作をペンと紙、説明書と切り抜きだけで実行できることです。 Codex32には、エンコードされたシードの生成（ここではサイコロが使用可能）、 チェックサムによるシードの保護、チェックサム付きシェアの生成、 チェックサムの検証、シードのリカバリーが含まれます。 特に、シードやシェアのバックアップのチェックサムを手動で検証できるというアイディアは、強力なコンセプトだと思います。 現在、ユーザーが個々のシードバックアップを検証する唯一の方法は、 信頼できるコンピューティングデバイスにそれを入力し、期待通りの公開鍵が得られるかどうかを確認するというものですが、 デバイスが信頼できるかどうかを判断するのは、多くの場合簡単な手順ではありません。 さらに悪いことに、既存のSSSSシェア（SLIP39など）の完全性を検証するために、 ユーザーは検証したい各シェアを閾値分の他のシェアと一緒に、信頼できるコンピューティングデバイスに入力しなければなりません。 つまり、シェアの完全性を検証することは、 そもそものシェアの大きな利点である情報を複数の場所や人に分散して安全・安心に保つ能力を否定することになります。 Codex32では、紙とペン、印刷物を使って、各シェアの完全性を数分の時間で定期的に確認することができます。

    メーリングリストでは、主にCodex32と数年前から実運用されているSLIP39の違いについて議論されました。 Codex32に興味のある方は、ウェブサイトを調べたり、 作者の1人による動画をご覧ください。 BIPのドラフトでは、Codex32でエンコードされたシードを使用するためのサポートがウォレットに追加されることを著者らは期待しています。

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

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

リリースとリリース候補

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

  • ● BDK 0.27.1は、「SQLiteのprint関数に大きな文字列を入力すると、 配列の境界のオーバーフローが発生する場合がある」という脆弱性を修正するセキュリティアップデートです。 BDKのオプションであるSQLiteのデータベース機能を使用しているソフトウェアのみ、アップデートが必要です。 詳細は、脆弱性レポートをご覧ください。

  • ● Core Lightning 23.02rc3は、この人気のあるLN実装の新しいメンテナンスバージョンのリリース候補です。

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

*今週のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals（BIP）、およびLightning BOLTsの注目すべき変更点。

  • ● Bitcoin Core #24149は、P2WSHベースの Miniscriptベースのアウトプット・ディスクリプターに対する署名をサポートします。 Bitcoin Coreは、必要なプリイメージと鍵がすべて利用可能で、タイムロックが満たされている場合、 任意のMiniscriptのインプットに署名できるようになります。 Bitcoin CoreのウォレットでMiniscriptを完全にサポートするには、 いくつかの機能がまだ不足しています。ウォレットは、 署名前に一部のディスクリプターのインプットのweightをまだ推定できず、 一部のエッジケースでPSBTに署名することがまだできません。 P2TRアウトプット用のMiniscriptサポートもまだ保留中です。

  • ● Bitcoin Core #25344は、RBF（Replace By Fee）による手数料の引き上げの作成のために、 bumpfee RPCとpsbtbumpfee RPCを更新しました。この更新により、 置換トランザクションのアウトプットを指定することができます。 置換トランザクションは、置換されるトランザクションとは異なるアウトプットのセットを含むことができます。 これは、新しいアウトプットを追加したり（例：反復的な支払いのバッチ処理）、 アウトプットを削除したり（例：未承認支払いのキャンセルの試行）するために使用できます。

  • ● Eclair #2596は、デュアル・ファンドチャネルを開設しようとするピアに対して、 チャネル開設トランザクションのRBFによる手数料引き上げ回数を制限し、 ノードがそれ以上のアップデート受け付けないようにします。 これは、ノードがチャネル開設トランザクションのすべてのバージョンに関するデータを保存する必要があるため、 無制限の手数料引き上げを許可すると問題が発生する可能性があることが動機になっています。 通常、手数料引き上げの回数は、 各置換トランザクションが追加のトランザクション手数料を支払う必要性があることによって、実際には制限されます。 しかし、デュアル・ファンディングプロトコルでは、ノードが完全に検証できない手数料引き上げも保存するよう想定しているため、 攻撃者は承認もされずトランザクション手数料もかからない無効な手数料引き上げトランザクションを無制限に作成することができます。

  • ● Eclair #2595は、スプライシングサポートに関するプロジェクトの作業の継続で、 今回はトランザクションの構築に使用される関数を更新しました。

  • ● Eclair #2479は、次のフローによるOfferの支払いをサポートします: ユーザーがOfferを受け取り、Eclairに支払いを指示、EclairはOfferを使って受信者からインボイスを取得し、 インボイスに期待されるパラメーターが含まれていることを確認し、インボイスへ支払う。

  • ● LND #5988は、支払い経路を見つけるための新しいオプションの確率推定器を追加しました。 これは以前の経路探索の研究（ニュースレター #192参照）に部分的に基づいており、 他のアプローチからの追加的なインプットも含まれています。

  • ● Rust Bitcoin #1636は、predict_weight()関数を追加しました。 この関数への入力は、トランザクションを構築するためのテンプレートで、 出力は予想されるトランザクションのweightです。これは特に、手数料管理に便利です。 どのインプットをトランザクションに追加すべきか判断するには、 手数料の金額を知る必要がありますが、手数料の金額を判断するには、トランザクションのサイズを知る必要があります。 この関数は、実際に候補となるトランザクションを構築することなく、妥当なサイズの推定値を提供することができます。