今週のニュースレターでは、Bitcoinのコンセンサスを変更せずにDLCの改善にBLS署名を使用する方法と、 新しいソフトウェアリリースとリリース候補の発表や、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更の概要など、 恒例のセクションを掲載しています。

ニュース

  • ● DLCにBitcoin互換のBLS署名を使用: Discreet Log Contracts (DLC)は、オラクルとして知られる信頼できる第三者が、 データの一部を証明できるようにします。オラクルを信頼する個人が、 オラクルにコントラクトの存在やその条件を明かすことなく、その証明をコントラクトに使用することができるのがDLCのメリットです。 DLCは、当初Schnorr署名の特徴を利用する提案でしたが、 その後より一般化した署名アダプターを利用する形で開発されてきました。

    今週、Lloyd FournierがBLS（Boneh-Lynn-Shacham）署名を使用してオラクルに証明させることについてのメリットを DLC-Devメーリングリストに投稿しました。 BitcoinはBLS署名をサポートしておらず、それを追加するためにはソフトフォークが必要ですが、 FournierはBLS署名から安全に情報を抽出し、Bitcoinに変更を加えることなくBitcoin互換の署名アダプターを使用できる方法を説明した 共著の論文をリンクしました。

    そしてFournierは、BLSベースの証明のいくつかの利点を説明しています。 その中で最も重要なのは、「ステートレス」なオラクルが実現可能になることです。 これは、（オラクルではない）コントラクトの参加者が、オラクルに証明してもらいたい情報について非公開での合意を可能にします。 たとえば、オラクルが実行可能な任意のプログラミング言語で書かれたプログラムを指定できます。 そして、そのコントラクトに従って、オラクルにその使用を伝えることなく預けた資金を割り当てることができます。 コントラクトを決済するタイミングが来たら、各参加者は自分でプログラムを実行し、 その結果に全員が合意したらオラクルを介さずにコントラクトを協力的に決済することができます。 合意が得られなかった場合は、各参加者がプログラムをオラクルに送信し（おそらくこれに対して少額の支払いが発生する）、 プログラムのソースコードを実行し、その実行結果に対するBLS署名を送り返してもらうことができます。 この証明は、DLCのオンチェーン決済を可能にする署名に変換することができます。 現在のDLCのコントラクトと同様に、オラクルはどのオンチェーントランザクションがそのBLS署名に基づくものなのか知ることはできません。 （5-of-10のような）閾値設定を含む、複数のオラクルも使用することができます。

    投稿は、コントラクトの作成時にコントラクトを認識する必要がある既存のDLCオラクルに対するステートレスオラクルの優位性を説得力のある形で提示しています。 この記事を書いている時点では、他のDLCコントリビューターからの返信はありませんでした。

リリースとリリース候補

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

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

今週の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 #23480は、鍵を調整することなく使用する場合（非推奨、BIP341参照）、 もしくは内部鍵とスクリプトが知られていない場合（これは安全でない可能性があります。詳細はPRのコメントおよびPRに追加されたドキュメントを参照）に、 Taprootのアウトプットで公開された鍵を参照するためのrawtr()ディスクリプターでアウトプット・スクリプト・ディスクリプターを更新しています。 既存のraw()ディスクリプターを使用することで、これらの鍵を参照することは可能ですが、 これはBitcoin CoreのUTXOのデータベースをスキャンするためのscantxoutset RPCようなツールで使用することを意図しており、 新しいrawtr()ディスクリプターにより、鍵のオリジン情報などTaprootのアウトプットに追加情報を関連付けるのが簡単になります。 鍵のオリジン情報は、バニティアドレスを作成するためのインクリメンタルな調整や、 プライバシーのための協調的な調整など、別の鍵生成方式が使用されていることを示す場合があります。

  • ● Bitcoin Core #22751は、未承認トランザクションの配列を受け取り、 そのトランザクションでどれだけのBTCがウォレットの残高に追加されるか、もしくは減らされるかを返すsimulaterawtransaction RPCを追加しました。

  • ● Eclair #2273は、2つのLNノードがより緊密に連携して新しいペイメントチャネルを開設する、 提案中の対話型のファンディング・プロトコルを実装しました。対話型のファンディングの実装により、 Eclairはチャネルに参加する両方のノードが新しいチャネルに資金を提供できるデュアル・ファンディングのサポートに近づきました。 ディアル・ファンディングの追加の準備も、今週Eclair #2247でマージされました。

  • ● Eclair #2361は、BOLTs #996で提案されているように（ニュースレター #211参照）、 チャネルの更新時にhtlc_maximum_msatフィールドを含めるよう要求するようになりました。

  • ● LND #6810は、ウォレットで自動生成するアウトプットスクリプトのほほすべてで、 支払いの受け取りにTaprootアウトプットを使用するようになりました。 さらに、LND #6633ではoption_any_segwitのサポートを実装し（ニュースレター #151参照）、 チャネルの協調クローズで資金をTaprootアウトプットで受け入れるようにしました。

  • ● LND #6816は、ゼロ承認チャネルの使用方法に関するドキュメントを追加しました。

  • ● BDK #640は、get_balance関数を更新し、現在の残高を4つのカテゴリに分けて返すようになりました。 承認済みのアウトプット用のavailable残高、 自身のウォレットからの未承認アウトプット（つまり、お釣り用のアウトプット）用のtrusted-pending残高、 外部ウォレットからの未承認アウトプット用のuntrusted-pending残高、 Bitcoinのコンセンサスルールに従って使用可能になるまでに最低100回の承認に達していないコインベース（マイニング）アウトプット用のimmature残高。