今週のニュースレターでは、Replace-by-Feeトランザクションのリレーポリシーの変更に関する議論に加えて、 Bitcoin Core PR Review Clubミーティングの概要や、新しいリリースとリリース候補の発表、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更点などの恒例のセクションを掲載しています。

ニュース

  • ● RBFポリシーに関する議論: Gloria Zhaoは、Bitcoin-Devメーリングリストで、 Replace-by-Fee (RBF)のポリシーに関する議論を開始しました。 彼女のメールは、現在のポリシーの背景を説明し、 長年にわたって発見されたいくつかの問題（Pinning攻撃など）を列挙し、 ポリシーがウォレットのユーザーインターフェースにどう影響するかを検証し、 そしていくつかの可能な改善策について説明しています。 次のブロックテンプレート（マイナーがProof of Workのために作成しコミットするブロック候補）における トランザクションを考慮した改善案に大きな注意が払われました。 置換が次のブロックテンプレートに与える影響を評価することで、 次のブロックのマイナーがより多くの手数料収入を得られるかどうかを、 ヒューリスティックを使用せずに確実に判断することができます。 Zhaoの要約と提案に対して、何人かの開発者が、追加の提案および代替案を含むコメントを返信しました。

    この要約が書かれている間も、議論は続いています。

Bitcoin Core PR Review Club

この毎月のセクションでは、最近のBitcoin Core PR Review Clubミーティングを要約し、 重要な質問と回答のいくつかに焦点を当てます。 以下の質問をクリックしてミーティングでの回答の要約を確認してください。

Add usage examplesは、Elichai TurkelによるPRで、 ECDSA署名およびSchnorr署名、ECDH鍵交換のサンプルを追加するものです。 これは、libsecp256k1のPRに対する最初のReview Clubミーティングでした。 参加者は、良い乱数ソースの重要性について議論し、サンプルを通じてlibsecp256k1についての一般的な質問をしました。

  • なぜサンプルではランダム性の取得方法を示しているのですか？

    このライブラリの多くの暗号方式の安全性は、秘密鍵、nonceおよびsaltが秘密/ランダムであることに依存しています。 もし攻撃者が、ランダム性のソースから返される値を推測したり、影響を与えることができると、 署名を偽造したり、秘密にしようとしている情報を知ったり、鍵を推測したりすることができるようになるかもしれません。 このように暗号方式を実装する際の課題は、ランダム性を取得することにあることが多く、サンプルはこの事実を強調しています。 ➚

  • ランダム性の取得方法について推奨される良いアイディアはありますか？

    libsecp256k1のメインのユーザーであるBitcoin Coreは、OSやP2Pネットワークで受信したメッセージおよび、 その他のエントロピーのソースを組み込んだ、ランダム性のための独自アルゴリズムを持っています。 独自のエントロピーを持つ必要がある他のユーザーの場合、ランダム性の優れたソースが非常に重要であり、 OSのドキュメントが常に明確であるとは限らないため、推奨内容がユーザーの役に立つかもしれません。 これらの推奨内容は、OSのサポートや脆弱性によって古くなる可能性があるため、 メンテナンスの負担はありますが、これらのAPIは頻繁に変更されることはないため負担も最小限になると予想されます。 ➚

  • PRで追加されたサンプルについて不足していることはありますか？

    参加者は、サンプルのコンパイルと実行、デバッガの使用、サンプルコードとBitcoin Coreの使用方法の比較、 非Bitcoinユーザーに対するUXの検討の経験について議論しました。ある参加者は、 Schnorr署名を生成した後に検証しないのは、Bitcoin CoreのコードとBIP340の推奨から逸脱していると指摘しました。 別の参加者は、メッセージのハッシュ化を忘れるとユーザーの誤用につながる可能性があるため、 secp256k1_ecdsa_signの前にsecp256k1_sha256の使用例を示すことを提案しました。 ➚

  • ユーザーが署名後に署名の検証を忘れたり、seckey_verifyの呼び出し、contextのランダム化などを忘れた場合、 どのようなことが起こり得るのでしょうか？

    最悪の場合、もし実装に欠陥があれば、署名後に署名の検証を忘れると、 誤って無効な署名を与えてしまうことになります。鍵をランダムに生成した後のseckey_verifyの呼び出しを忘れると、 （無視できる確率ですが）無効な鍵を持つ可能性があります。 contextのランダム化は、サイドチャネル攻撃からの保護を目的としています。 このランダム化は、最終結果には影響を与えませんが、 実行された操作に関する情報を取得するために悪用される可能性のある中間値をブラインドします。 ➚

リリースとリリース候補

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

  • ● LND 0.14.2-betaは、いくつかのバグ修正と小さな改善を含むメンテナンスバージョンのリリースです。

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

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

  • ● Bitcoin Core #23508は、ソフトフォークのデプロイステータスをgetblockchaininfoRPCから、 新しいgetdeploymentinfoRPCに移動しました。新しいRPCはさらに、 チェーンの先頭時点だけでなく、特定のブロック高でのデプロイステータスを照会することができます。

  • ● Bitcoin Core #21851は、arm64-apple-darwin (Apple M1)用のビルドのサポートを追加しました。 この変更は現在マージされており、コミュニティは次のリリースでM1バイナリが動作することを期待できます。

  • ● Bitcoin Core #16795は、getrawtransaction、gettxout、decoderawtransaction、decodescript RPCを更新し、 デコードされたscriptPubKeyに対して推測されるoutput script descriptorを返すようになりました。

  • ● LND #6226は、従来のSendPayment、SendPaymentSync、QueryRoutes RPCを使用して作成されるLNを介してルーティングされる支払いのデフォルト手数料として5%を設定します。 新しいSendPaymentV2 RPCを使用して送信される支払いはデフォルトで手数料ゼロが設定され、 基本的にユーザーが値を指定する必要があります。 追加でマージされたPR、LND #6234は、従来のRPCで行われた1,000 satoshi未満の支払いに対して、 デフォルトで100%の手数料が設定されます。

  • ● LND #6177は、HTLCインターセプターのユーザーが、HTLCが失敗した理由を指定できるようになりました。 これにより、失敗がLNDを使用するソフトウェアにどう影響するかテストするのにインターセプターがより便利になります。

  • ● LDK #1227は、経路探索ロジックを改善し、既知の過去の支払いの失敗/成功を考慮するようにしました。 これらの失敗/成功は、チャネルバランスの上限と下限を決定するために使用され、 経路探索ロジックが経路を評価する際に、より正確な成功確率を提供します。 これは、以前のニュースレター（#142、#163、 #172を含む）で紹介したRené Pickhardtや他の人が以前説明したアイディアの実装です。

  • ● HWI #549は、BIP370で定義されたPSBTバージョン2のサポートを追加しました。 既存のColdcardハードウェア署名デバイスのように、バージョン0のPSBTをネイティブにサポートするデバイスを使用する場合、 v2のPSBTはv0のPSBTに変換されます。

  • ● HWI #544は、Trezorハードウェア署名デイバイスを使用したTaproot支払いの受け取り、 送信をサポートするようになりました。