en | ja | es | cs | hi | zh | de | fr

Bitcoin Optech Newsletter #272

Oct 11, 2023

今週のニュースレターでは、提案されているOP_TXHASH opcodeの仕様のリンクに加えて、 Bitcoin Core PR Review Clubミーティングの概要、新しいリリースとリリース候補のリンクおよび、人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更など、恒例のセクションが掲載されています。

ニュース

● OP_TXHASHの仕様の提案: Steven Rooseは、新しいOP_TXHASH opcodeのBIPドラフトをBitcoin-Devメーリングリストに投稿しました。このopcodeの背後にあるアイディアは以前も議論されましたが（ニュースレター #185参照）、これはアイディアの最初の仕様です。このopcodeがどのように機能するかを正確に記述するだけでなく、このopcodeが呼び出されるたびにフルノードが最大数MBのデータをハッシュする必要がある可能性など、いくつかの潜在的な欠点を軽減することも検討されています。Rooseのドラフトには、 opcodeのサンプル実装が含まれています。

Bitcoin Core PR Review Club

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

util: Type-safe transaction identifiersは、 Niklas Gögge (dergoegge)によるPRで、 txid（トランザクション識別子またはsegwitのwitnessデータを含まないハッシュ）と wtxid（同じだがwitnessデータを含む）に別々の型を導入することで、両方ともuint256（SHA256ハッシュを含むことができる256ビットの整数）で表現されるのに比べて型の安全性を向上させるものです。このPRは、運用上何の影響もないはずです。このPRの目的は、もう一方のトランザクションIDが意図されていたのに、別のトランザクションIDが使用されるという将来のプログラミングのミスを防止することです。このようなエラーは、コンパイル時に検出されるようになります。

混乱を最小限に抑え、レビューを容易にするため、これらの新しい型は、初期はコードは1つの領域（トランザクションの「オーファン」）のみで使用されます。将来のPRで、コードベースの他の領域でも新しい型を使用する予定です。

トランザクション識別子が型安全であるとはどういうことですか？なぜそれが重要で役に立つのですか？デメリットはありますか？

トランザクション識別子には2つの意味（txidかwtxid）のいずれかがあるため、型安全とは、識別子が間違った意味で使用されることがないという特性です。つまり、wtxidが期待される場面でtxidを使用することはできず、その逆も同様で、これはコンパイラの標準型チェックによって強制されます。 ➚
uint256を 継承する 新しい型クラスTxidおよびWtxidではなく、 uint256を 含める （ラップする）べきですか？そのトレードオフは何ですか？

これらのクラスをそうすることも可能ですが、コードチャーン（Code Churn）がさらに多くなります（さらに多くの行のソースを触る必要があります）。 ➚
なぜ実行時ではなくコンパイル時に型を強制する方が良いのですか？

開発者は、実行時にバグを発見するために大規模なテスト・スイートを書くことに依存するよりも（そしてこれらのテストはまだいくつかのエラーを見落としているかもしれません）、コーディングしている時に素早くエラーを発見することができます。しかし、そもそも型安全性では誤った型のトランザクションIDの一貫した使用は防止されないので、テストは依然として有用です。 ➚
概念的に、トランザクションを参照する新しいコードを書いている時、いつtxidを使用して、いつwtxidを使用する必要がありますか？コード内で一方を他方の代わりに使用すると非常にまずい例があれば教えてください。

一般的には、トランザクション全体にコミットするため、wtxidの使用が望ましいです。重要な例外は、使用する各インプットからアウトプット（UTXO）へのprevoutによる参照で、これはtxidでトランザクションを指定する必要があります。一方を使用し、他方を使用しないことが重要な例をここに示します（詳細については、ニュースレター #104参照ください）。 ➚
uint256の代わりにtransaction_identifierを使用することで、どのような具体的な方法で既存のバグを発見したり、新しいバグの発生を防ぐことができますか？逆にこの変更によって新たなバグが発生する可能性はありますか？

このPRがなければ、uint256引数を取る関数（ブロックIDのハッシュなど）にtxidが渡される可能性があります。このPRがあれば、これはコンパイル時にエラーになります。 ➚
GenTxidクラスは既に存在します。これはどう型の正確性を強制しているのでしょうか？また、このPRのアプローチとの違いは何ですか？

このクラスは、ハッシュとそのハッシュがwtxidなのかtxidなのかを示すフラグを含むので、 2つの異なる型ではなく1つの型です。これにより型チェックが可能になりますが、明示的にプログラムする必要があり、さらに重要なことに、型チェックはコンパイル時ではなく実行時にのみ行われます。これは、どちらの種類の識別子であってもいい入力を受け取りたいというよくあるユースケースを満たします。そのため、このPRではGenTxidは削除されません。将来的には、std::variant<Txid, Wtxid>が良い選択肢になるかもしれません。 ➚
C++では整数は型でありクラスではないとすると、transaction_identifierはどのようにしてuint256をサブクラス化できるのでしょうか？

uint256は組み込み型ではなく、クラスだからです。（C++の最大の組み込み整数型は64ビットです。） ➚
uint256は、その他の点では、たとえばuint64_tと同じように動作しますか？

いいえ。（uint256の主な用途である）ハッシュでは意味をなさないため、算術演算はuint256では許可されていません。この名前は誤解を招きます。これは実際には単なる256ビットの塊です。別のarith_uint256では算術演算が可能です（たとえば、PoWの計算で使われます）。 ➚
なぜtransaction_identifierは完全に新しい型ではなく、uint256をサブクラスにしているのですか？

これにより、明示的および暗黙的な変換を使用して、新しいより厳密なTxid型またはWtxid型を使用するようにリファクタリングをする適切な時期が来るまで、 uint256形式のトランザクションIDを期待しているコードを変更しないままにすることができます。 ➚

リリースとリリース候補

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

● LDK 0.0.117は、LN対応アプリケーションを構築するためのこのライブラリのリリースです。このリリースには、直近のリリースに含まれていたアンカー・アウトプットに関するセキュリティバグ修正が含まれています。また、経路探索の改善や、ウォッチタワーのサポートの改善、新規チャネルのバッチファンディングを可能にするなど、いくつかの機能とバグ修正が含まれています。
● BDK 0.29.0は、ウォレットアプリケーションを構築するためのこのライブラリのリリースです。このリリースでは、依存関係を更新し、ウォレットがマイナーのコインベーストランザクションから複数のアウトプットを受け取った場合に影響がある（おそらく稀な）バグを修正しています。

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

今週の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 #27596は、 assumeutxoプロジェクトの最初のフェーズを終了します。これには、assumedvalidなスナップショットのチェーンステートの使用と、バックグラウンドでの完全な検証同期の両方に必要な残りの変更が含まれています。 UTXOスナップショットをRPC（loadtxoutset）を介してロードできるようにし、 assumeutxoパラメーターをchainparamsに追加します。

この機能セットはアクティベートされるまでmainnetで利用できませんが、このマージは複数年にわたる取り組みの集大成となります。2018年に提案され、 2019年に正式化されたこのプロジェクトは、ネットワークに初めて参加する新しいフルノードのユーザーエクスペリエンスを大幅に改善します。このマージに、Bitcoin Core #28590、#28562、 #28589が続きます。
● Bitcoin Core #28331、#28588、 #28577およびGUI #754は、 BIP324で定義されているバージョン2暗号化P2Pトランスポートのサポートを追加します。この機能は、現在デフォルトで無効になっていますが、-v2transportオプションを使用して有効にできます。

暗号化トランスポートは、（ISPなどの）受動的な監視者が、ノードがどのトランザクションをピアに中継するかを直接判断するのを防止することで、 Bitcoinユーザーのプライバシーを向上させるのに役立ちます。また、暗号化トランスポートを使用して、セッションIDを比較することで中間者の監視を阻止することもできます。将来的には、他の機能の追加により、軽量クライアントがP2P暗号化接続を介して信頼できるノードに安全に接続できるようになる可能性があります。
● Bitcoin Core #27609により、submitpackage RPCが非regtestネットワークで利用可能になりました。ユーザーは、このRPCを使用して、未承認の親を持つ単一のトランザクションのパッケージを送信することができます。この時、どの親も別の親のアウトプットを使用しません。子トランザクションは、ノードの動的なmempoolの最小手数料率を下回る親のCPFPに使用できます。ただし、パッケージリレーはまだサポートされていないため、これらのトランザクションがネットワーク上の他のノードに伝播するとは限りません。
● Bitcoin Core GUI #764は、GUIでレガシーウォレットを作成する機能が削除されました。レガシーウォレットを削除する機能は削除されます。Bitcoin Coreの将来のバージョンでは、新しく作成されるウォレットはすべてディスクリプターベースになります。
● Core Lightning #6676は、ノードのウォレットにオンチェーンで資金を受け取るためのアウトプットをPSBTに追加する新しいaddpsbtoutput RPCを追加しました。