/ home / newsletters /
Bitcoin Optech Newsletter #307
今週のニュースレターでは、量子安全なBitcoinアドレスフォーマットのBIPドラフトの発表と、 Bitcoin Core PR Review Clubの要約、新しいリリースとリリース候補の発表、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更など、 恒例のセクションが含まれています。
ニュース
- ● 量子安全なアドレスフォーマットのBIPドラフト: 開発者のHunter Beastは、 バージョン3のsegwitアドレスを量子耐性のある署名アルゴリズムに割り当てるための BIPのラフなドラフトをDelving Bitcoinとメーリングリストの両方に投稿しました。 BIPドラフトには、問題と予想されるオンチェーンサイズと共にいくつかの可能性のあるアルゴリズムのリンクが掲載されています。 アルゴリズムの選択と実装の具体的な詳細は、Bitcoinに完全な量子耐性を追加するというビジョンを完全に実現するために必要な追加のBIPと同様に、 今後の議論に委ねられています。
Bitcoin Core PR Review Club
この毎月のセクションでは、最近のBitcoin Core PR Review Clubミーティングを要約し、 重要な質問と回答のいくつかに焦点を当てます。 以下の質問をクリックしてミーティングでの回答の要約を確認してください。
Don’t wipe indexes again when continuing a prior reindexは、TheCharlatanによるPRで、 進行中のインデクスの再作成が完了する前にユーザーがノードを再起動した際の起動時間を改善できます。
Bitcoin Coreは5つのインデックスを実装しています。UTXOセットとブロックインデックスは必須ですが、
トランザクションインデックスとコンパクトブロックフィルターインデックスおよび
coinstatsインデックスはオプションです。-reindexを指定して実行すると、すべてのインデックスが消去され、再構築されます。
このプロセスにはかなり時間がかかる可能性があるため、何らかの理由でノードが停止する前に完了する保証はありません。
ノードには最新のUTXOセットとブロックインデックスが必要であるため、 インデックスの再作成のステータスはディスク上に永続化されます。インデックスの再作成を開始した際に、 フラグがセットされ、終了した際にのみフラグは解除されます。 こうすることで、ノードの起動時に、ユーザーが起動オプションとしてフラグを指定しなかった場合でも、 インデックスの再作成の継続を検出することができます。
インデックスの再作成が未完了な状態で（-reindexなしで）再起動した場合、
必要なインデックスは保持され、再構築が継続されます。
Bitcoin Core #30132以前では、オプションのインデックスは再度消去されていました。
Bitcoin Core #30132は、必要のないオプションインデックスの消去を回避することで、
ノードの起動をより効率的にすることができます。
-
オプションのインデックスが新しいブロックを処理する2つの方法とは何ですか？
オプションのインデックスが初期化されると、その最も高いブロックが現在のチェーンの先頭と同じかどうかをチェックします。 同じでない場合は、まず
BaseIndex::StartBackgroundSync()を使用して、 欠落しているすべてのブロックをバックグランドで同期します。インデックスがチェーンの先頭に追いついたら、ValidationSignals::BlockConnectedを使用して検証インターフェースを通してそれ以降のすべてのブロックを処理します。 ➚ -
このPRは、新しいブロックを処理するオプションインデックスのロジックにどう影響しますか？
このPR以前は、chainstateを消去せずにオプションインデックスを消去すると、 これらのインデックスは同期されていないとみなされます。前の質問のとおり、 これは検証インターフェースに切り替える前に、最初のバックグランド同期を実行することを意味します。 このPRでは、オプションインデックスは、chainstateと同期されたままであるため、バックグラウンド同期は必要ありません。 注：バックグラウンド同期はインデックスの再作成が完了した後にのみ開始されますが、 検証イベントの処理は並行して行われます。 ➚
リリースとリリース候補
人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。
-
● Core Lightning 24.05は、この人気のLNノード実装の次期メジャーバージョンのリリースです。 このリリースには、プルーニングされたフルノードでより良く動作するための改良（ニュースレター #300参照）、 プラグインで動作するための
checkRPC（ニュースレター #302参照）、 安定性の改善（ニュースレター#303や#304に掲載されているものなど）、 オファーインボイスのより堅牢な配信（ニュースレター #304参照）、ignore_fee_limits設定オプションが使用されている場合の 手数料の過払い問題の修正（ニュースレター #306参照）などが含まれています。 -
● Bitcoin Core 27.1は、この主要なフルノード実装のメンテナンスリリースです。 複数のバグ修正が含まれています。
注目すべきコードとドキュメントの変更
最近の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およびBINANAsの注目すべき変更点。
-
● Bitcoin Core #29496は、
TX_MAX_STANDARD_VERSIONを3に引き上げ、 TRUC（Topologically Restricted Until Confirmation）トランザクションを標準にしました。 トランザクションのバージョンが3の場合、BIP431仕様で定義されているTRUCトランザクションとして扱われます。CURRENT_VERSIONは2のままで、これはウォレットがまだTRUCトランザクションを作成しないことを意味します。 -
● Bitcoin Core #28307は、P2SH-segwitとbech32の両方でSegwitのredeem scriptに 520バイトのP2SHの最大スクリプトサイズ制限を課していたバグを修正しました。 この修正により15個より多くの鍵を含むマルチシグアウトプットディスクリプターの作成が可能になり（
OP_CHECKMULTISIGのコンセンサスの上限である20個まで可能）、これらのスクリプトの署名や、 P2SHの制限を超える他のSegwit後のredeem scriptも作成できるようになります。 -
● Bitcoin Core #30047は、bech32エンコーディング方式の
charlimitのモデルを 定数90からEnumにリファクタリングしました。この変更により、bech32エンコーディング方式を使用するものの、 BIP173の設計と同じ文字数制限を持たない新しいアドレスタイプを簡単にサポートできます。 たとえば、118文字を必要とするサイレントペイメントアドレスの解析を有効にすることができます。 -
● Bitcoin Core #28979は、
sendallRPCコマンド（ニュースレター #194参照）のドキュメントを更新し、 承認済みのアウトプットに加えて未承認のお釣りも使用すると記載しています。 未承認のアウトプットが使用される場合、手数料の不足分が補填されます（ニュースレター #269参照）。 この項目は、公開後に修正されました。1 -
● Eclair #2854とLDK #3083は、BOLTs #1163を実装し、 Onionメッセージの配送に失敗した場合の
channel_updateの要件を削除しました。 この要件により、配送失敗のエラーステータスを生成した中継ノードがchannel_updateフィールドを介して HTLCの送信者を特定できる攻撃が容易になり、送信者のプライバシーが侵害されます。 -
● LND #8491は、
lncliRPCコマンドaddinvoiceとaddholdinvoiceにcltv_expiryフラグを追加し、 ユーザーがmin_final_cltv_expiry_delta（最終ホップのCLTV expiry delta）を設定できるようにしました。 この変更の動機はプルリクエストには記載されていませんが、LNDが最近BOLT2仕様に従うために デフォルトを9ブロックから18ブロックに引き上げたことに対応したものと思われます（ニュースレター #284参照）。 -
● LDK #3080は、
MessagerRouterのcreate_blinded_pathコマンドを2つのメソッドにリファクタリングしました。 1つはコンパクトなブラインドパスの作成用で、もう1つは通常のブラインドパスの作成用です。 これにより、呼び出し元の文脈に応じた選択が可能になります。コンパクトなブラインドパスは、 ファンディングトランザクション（またはチャネルエイリアス）を参照する通常8バイトのショートチャネルID（SCID）を使用します。 通常のブラインドパスは、33バイトの公開鍵でLNノードを参照します。コンパクトパスは、 チャネルが閉じられたりスプライスされたりすると古くなってしまう可能性があるため、 バイトスペースが重視される短期間のQRコードや支払いリンクに使用するのが最適です。 通常のパスは、長期的な使用に適しています。これは、 ノード識別子を使用することでノードとピアがチャネルを共有していない場合でもピアにメッセージを転送することができる Onionメッセージベースのオファーなどを含みます（Onionメッセージはチャネルを必要としないため）。ChannelManagerは、短期のオファーや返金にコンパクトなブラインドパスを使用し、 リプライパスには通常の（コンパクトでない）ブラインドパスを使用するようリファクタリングされました。 -
● BIPs #1551は、DNS Payment Instructionの仕様であるBIP353を追加しました。 これは、DNSのTXTレコード内にBIP21 URIをエンコードするプロトコルで、 人が読みやすくそのような解決を非公開でクエリできるようになります。 たとえば、
example@example.comはexample.user._bitcoin-payment.example.comのようなDNSで解決することができ、bitcoin:bc1qexampleaddress0123456のようなBIP21 URIを含むDNSSEC署名されたTXTレコードを返します。 以前の説明についてはニュースレター #290を、 関連するBLIPのマージについては先週のニュースレターをご覧ください。
脚注
-
Bitcoin Core #28979について最初に公開した説明では、
sendallが未承認のお釣りを使用する変更は、 動作の変更であると記載していました。（誤りはニュースレターの編集者によるもので） Gustavo Floresの元の正しい記述と、誤りを報告してくれたMark “Murch” Erhardtに感謝します。 ↩