今週のニュースレターは、mempoolポリシーに関する限定週刊シリーズの最終回に加えて、 クライアントやサービス、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など恒例のセクションを掲載しています。

ニュース

今週は、Bitcoin-DevメーリングリストやLightning-Devメーリングリストでは目立ったニュースはありませんでした。

承認を待つ #10: 参加してみよう

トランザクションリレーや、mempoolへの受け入れ、マイニングトランザクションの選択に関する限定週刊シリーズの最終回です。 Bitcoin Coreがコンセンサスで認められているよりも制限的なポリシーを持っている理由や、 ウォレットがそのポリシーを最も効果的に使用する方法などが含まれます。

このシリーズが読者の皆様に、承認を待っている間に何が起こっているのかについて、 より良く理解する助けになっていれば幸いです。私たちは、Bitcoinのイデオロギー的な価値のいくつかが、 その構造や設計目標にどのように反映されているかという議論から始めました。 ピアツーピアネットワークの分散構造は、典型的な中央集権的モデルよりも、 検閲への耐性とプライバシーを高めています。オープンなトランザクションリレーネットワークは、 承認前にブロック内のトランザクションを誰もが知るのを助け、ブロックリレーの効率を向上させ、 新しくマイナーとして参加しやすくし、ブロックスペースの公開オークションを作り出します。 理想的なネットワークは、ノードを実行する多くの独立した匿名のエンティティで構成されるため、 ノードソフトウェアはDoSから保護し、一般的に運用コストを最小限に抑えるよう設計されなければなりません。

手数料は、ブロックスペースの競争を解決するための「公正な」方法として、Bitcoinネットワークで重要な役割を果たしています。 トランザクションの置換やパッケージに対応した選択および排除アルゴリズムを備えるmempoolでは、 トランザクションを保存する有用性を測定するためにインセンティブ互換性が使用され、 ユーザーに対してRBFやCPFPを使用した手数料の引き上げを可能にします。 このようなmempoolポリシーや、経済的にトランザクションを構成するウォレット、 そして優れた手数料の推定が組み合わさることで、 ブロックスペースの効率的な市場が形成され、すべての人に利益をもたらします。

また、個々のノードは、リソースの枯渇から自らを守り、 個人的な好みを表明するために、トランザクションリレーポリシー を適用します。 ネットワーク全体のレベルでは、標準ルールとその他のポリシーが、 スケーリングやノードの実行しやすさ、コンセンサスルールを更新する能力にとって重要なリソースを保護します。 ネットワークの大多数がこれらのポリシーを適用しているため、 BitcoinのアプリケーションやL2プロトコルが構築されるインターフェースの重要な部分でもあります。 そしてまた、完璧ではありません。私たちは、広範な制限やL2決済トランザクションに対するPinning攻撃など 特定のユースケースに対処する、いくつかのポリシー関連の提案について説明しました。

また、ネットワークポリシーの継続的な進化には、プロトコル、アプリケーション、 ウォレットに携わる開発者間の協力が必要であることも協調しました。 Bitcoinエコシステムがソフトウェア、ユースケース、ユーザーに関して成長するにつれて、 分散型の意思決定プロセスはより必要とされるようになりますが、同時により困難にもなります。 Bitcoinの普及が拡大しても、このシステムはステークホルダーの懸念や努力から生まれています。 顧客からのフィードバックを集め、新しいプロトコル機能を構築したり 使用されなくなった機能を削除したりするためのエンジニアを雇用する責任を負う企業はありません。 ネットワークのラフコンセンサスに参加したいステークホルダーには、 さまざまな参加方法があります。情報を提供したり、質問や問題を提起したり、 ネットワークの設計に参加したり、あるいは改善の実装に貢献したりすることです。 この次、あなたのトランザクションの承認に時間がかかっている場合は、何をすればいいか分かりますね！

サービスとクライアントソフトウェアの変更

この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。

  • ● ウォレット10101のベータテストでLNとDLCの資金をプール: 10101は、LDKとBDKで構築されたウォレットを発表しました。 このウォレットを使用すると、ユーザーはLN支払いの送受信、転送にも使用できるオフチェーンコントラクトの DLCを使用して、非カストディアルなデリバティブ取引ができます。 DLCは、価格の証明にアダプター署名を使用するオラクルに依存しています。

  • ● LDK Nodeの発表: LDKチームは、LDK Node v0.1.0を発表しました。 LDK Nodeは、LDKとBDKライブラリを使用したライトニングノードのRustライブラリで、 開発者がさまざまなユースケースに合わせて高度なカスタマイズを提供しながら、 セルフカストディ型のライトニングノードを素早くセットアップできるようにします。

  • ● Payjoin SDKの発表: Payjoin機能を統合したいウォレットやサービスで使用するためのBIP78を実装したRustライブラリである Payjoin Dev Kit (PDK)が発表されました。

  • ● VLS（Validating Lightning Signer）betaの発表: VLSを使用すると、ライトニングノードとその資金を管理する鍵を分離することができます。 VLSを使用するライトニングノードは、署名要求をローカルにある鍵ではなく、リモートの署名デバイスにルーティングします。 betaリリースでは、CLNとLDK、レイヤー1とレイヤー2の検証ルール、 バックアップ/リカバリー機能をサポートし、参照実装を提供しています。 ブログ記事の発表では、コミュティからのテストや機能リクエスト、フィードバックも呼びかけています。

  • ● BitGoがMuSig2をサポート: BitGoは、BIP327（MuSig2）のサポートを発表し、 サポートされている他のアドレスタイプと比較して、手数料の削減とプライバシー保護が強化されたことを言及しています。

  • ● PeachがRBFをサポート: ピアーツーピア取引用のPeach Bitcoinモバイルアプリケーションは、 RBF（Replace-By-Fee）による手数料の引き上げのサポートを発表しました。

  • ● Phoenixウォレットがスプライシングをサポート: ACINQは、Phoenixモバイルライトニングウォレットの次期バージョンのベータテストを発表しました。 このウォレットは、スプライシングとSwap-in-Potentiam技術（Podcast #259参照）と 同様の仕組みを使用してリバランスされる単一のダイナミックチャネルをサポートしています。

  • ● Mining Development Kitのフィードバックの募集: MDK（Mining Development Kit）に取り組んでいるチームは、 Bitcoinのマイニングシステム用のハードウェア、ソフトウェアおよびファームフェアの開発の進捗状況に関する最新情報を投稿しました。 この投稿では、ユースケースやスコープ、アプローチについてコミュニティからのフィードバックを募集しています。

  • ● Binanceがライトニングをサポート: Binanceは、ライトニングネットワークを使用した送金（引き出し）と受け取り（入金）のサポートを発表しました。

  • ● NunchukがCPFPをサポート: Nunchukは、トランザクションの送信者と受信者両方に対して CPFP（Child-Pays-For-Parent）による手数料の引き上げのサポートを発表しました。

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

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

  • ● Bitcoin Core #27411は、ノードがそのTorやI2Pアドレスを 他のネットワーク（プレーンなIPv4やIPv6など）上のピアに配信するのを防止します。 また、非匿名ネットワークからTorやI2P上のピアにアドレスを配信することもありません。 これは、誰かがノードの通常のネットワークアドレスを匿名ネットワーク上のアドレスの1つに関連付けるのを防ぐのに役立ちます。 現時点では、CJDNSはTorやI2Pとは異なる扱いになっていますが、将来的には変更される可能性があります。

  • ● Core Lightning #6347は、ワイルドカード*を使用して すべてのイベント通知を購読するプラグインの機能を追加しました。

  • ● Core Lightning #6035は、P2TRアウトプットスクリプトで入金を受け取るための bech32mアドレスをリクエストする機能を追加しました。 トランザクションのお釣りも、デフォルトでP2TRアウトプットに送信されるようになりました。

  • ● LND #7768は、BOLTs #1032と#1063 （ニュースレター #225参照）を実装し、 支払い（HTLC）の最終的な受信者が、要求した金額よりも多くの金額を、 要求したよりも長い有効期限で受け取ることができるようにしました。 これまでは、LNDベースの受信者は、要求した金額と有効期限の差分が正確に等しいというBOLT4の要件を遵守していましたが、 その正確さは、どちらかの値をわずかに変更することで、転送ノードが次のホップを調査し、 それが最終受信者であるかどうかを確認できることを意味していました。

  • ● Libsecp256k1 #1313は、GCCとClangのコンパイラの開発スナップショットを使用した自動テストを開始し、 特定のlibsecp256k1のコードが可変時間で実行される可能性のある変更を検出できるようにしました。 非定数時間のコードで秘密鍵やnonceを扱うと、サイドチャネル攻撃につながる可能性があります。 そのようなことが起こった可能性のあることについてはニュースレター #246を、 別の事例とこの種のテストが計画されているという発表はニュースレター #251をご覧ください。