/ home / newsletters /
Bitcoin Optech Newsletter #268
今週のニュースレターは、Taproot Assetsに関する仕様のドラフトのリンクと、 PTLCを使用可能にするのに役立つLNのいくつかの代替メッセージプロトコルの概要を掲載しています。 また、Bitcoin Core PR Review Clubミーティングの要約や、 新しいソフトウェアリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、 恒例のセクションも含まれています。
ニュース
-
● Taproot Assetsの仕様: Olaoluwa Osuntokunは、Taproot Assets の Client-Side Validationプロトコルについて、 Bitcoin-DevメーリングリストとLightning-Devメーリングリストに個別に投稿しました。 Bitcoin-Devメーリングリストには、7つのBIPのドラフトを発表しました。 当時 Taro という名称だったプロトコルの最初の発表時（ニュースレター #195参照）より１つ増えています。 Lightning-Devメーリングリストには、 LNを使用してTaproot Assetsを送受信するためのBLIPのドラフトを発表しました。 このプロトコルは、LND 0.17.0-betaでリリース予定の実験的な「Simple taproot channels」の機能がベースになっています。
その名前とは裏腹に、Taproot AssetsはBitcoinプロトコルの一部ではなく、 コンセンサスプロトコルを一切変更しないことに注意してください。 このプロトコルは、既存の機能を使用して、クライアントプロトコルにオプトインしたユーザーに新しい機能を提供します。
この記事の執筆時点では、いずれの仕様もメーリングリストでは議論されていませんでした。
-
● PTLCのためのLNメッセージの変更: P2TRとMuSig2を使用したチャネルを実験的にサポートする 最初のLN実装がまもなくリリースされる予定であるため、Greg Sandersは、 HTLCの代わりにPTLCを使用した支払いの送信をサポートするためのLNメッセージの変更について、 以前議論されたいくつかの異なる変更の要約をLightning-Devメーリングリストに投稿しました。 ほとんどのアプローチでは、メッセージの変更は大規模また侵襲的なものでもないようですが、 ほとんどの実装では、おそらく従来のHTLCの転送を処理するためのメッセージのセットを使用し続ける一方で、 PTLCの転送をサポートするためにアップグレードされたメッセージを提供し、 HTLCが段階的に廃止されるまで、２つの異なるパスを同時に維持し続ける必要があります。 メッセージが標準化される前に、一部の実装で実験的なPTLCのサポートが追加された場合、 実装は、３つ以上の異なるプロトコルを同時にサポートする必要が生じ、すべての実装にとって不利になります。
この記事の執筆時点では、Sanderの要約に対するコメントはありませんでした。
Bitcoin Core PR Review Club
この毎月のセクションでは、最近のBitcoin Core PR Review Clubミーティングを要約し、 重要な質問と回答のいくつかに焦点を当てます。 以下の質問をクリックしてミーティングでの回答の要約を確認してください。
Transport abstractionは、最近マージされたPieter Wuille (sipa)によるPRで、 トランスポート の抽象化（インターフェースクラス）を導入するものです。 このクラスの具体的な具象クラスは、（ピア毎の）接続の（既にシリアライズされた）送受信メッセージをワイヤーフォーマットに変換します。 これは、より深いレベルのシリアライズとデシリアライズを実装すると考えることができます。 これらのクラスは、実際の送受信を行いません。
PRでは、TransportクラスからV1Transport（現在あるもの）とV2Transport（ネットワーク上で暗号化されるもの）という
２つの具象クラスを派生しています。このPRは、BIP324
バージョン2 P2P暗号化トランスポートプロトコル プロジェクトの一部です。
-
netとnet_processingの違いは何ですか？
netは、ネットワーキングスタックの最下層にあり、ピア間の低レベルの通信を処理します。 一方、net_processingは、netレイヤーの最上位にあり、netレイヤーのメッセージの処理と検証を行います。 ➚
-
より具体的に、net_processingと関連付けられるクラスや関数の例、またこれに対するnetの例は？
net_processing:
PeerManager、ProcessMessage。 net:CNode、ReceiveMsgBytes、CConnMan。 ➚ -
BIP324にはnetレイヤーの変更やnet_processingの変更、またはその両方の変更が必要ですか？ それは、ポリシーやコンセンサスに影響しますか？
変更はnetレイヤーのみであり、コンセンサスには影響しません。 ➚
-
このPRが（偶発的な）コンセンサスの変更となる可能性がある実装バグの例にはどのようなものがありますか？
最大メッセージサイズを4MB未満に制限するバグは、他のノードが有効とみなすブロックをノードが拒否する可能性があります。 ブロックのデシリアライズに関するバグは、ノードがコンセンサス上有効なブロックを拒否する可能性があります。 ➚
-
CNetMsgMakerとTransportは、どちらもメッセージをシリアライズします。これらが行うことの違いは何ですか？CNetMsgMakerは、データ構造をバイトにシリアライズします。Transportはこれらのバイトを受信し、 ヘッダーを追加（シリアライズ）し、実際に送信します。 ➚ -
CTransactionRef（トランザクション）のようなアプリケーションオブジェクトをバイト/ネットワークパケットに変換するプロセスでは、 何が起こりますか？その過程でどのようなデータ構造になるのでしょうか？msgMaker.Make()がSerializeTransaction()を呼び出してCTransactionRefメッセージをシリアライズし、PushMessage()がシリアライズされたメッセージをvSendMsgキューに入れ、SocketSendData()がヘッダーとチェックサムを追加し（このPRの変更後）、 送信する次のパケットをトランスポートに要求し、最後にm_sock->Send()を呼び出します。 ➚ -
PushMessage()から戻った後、このメッセージに対応するバイトを既に送信されましたか（はい/いいえ/おそらく）？それは何故ですか？すべての可能性があります。はいの場合: 私たち（net_processing）は、メッセージを送信するために何もする必要はありません。 いいえの場合: 関数から戻った時点で、受信者が受信している可能性は非常に低いです。 おそらくの場合: すべてのキューが空の場合は、カーネルソケットレイヤーまで到達しているでしょうが、 キューが空でなければ、OSに到達する前にキューが空になるのを待つことになります。 ➚
-
どのスレッドが
CNode::vSendMsgにアクセスしますか？メッセージが同期的に（楽観的に）送信っされている場合は
ThreadMessageHandlerが、 キューに入れられ後で取得されて送信される場合はThreadSocketHandlerです。 ➚
リリースとリリース候補
人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。
- ● LND v0.17.0-beta.rc2は、この人気のLNノード実装の次期メジャーバージョンのリリース候補です。 このリリースで予定されている主な実験的な新機能は、テストの恩恵を受ける可能性が高そうな、 「Simple taproot channel」のサポートです。
注目すべきコードとドキュメントの変更
今週の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 #26567では、署名のdry-runを行う代わりに、 ディスクリプターから署名されたインプットのweightを推定するようウォレットを更新しました。 このアプローチは、dry-runアプローチでは不十分であった、より複雑なMiniscriptディスクリプターでも成功します。