今週のニュースレターでは、BIP32マスターシードのバックアップが破損していないことを デジタル機器を使用せずに検証する最速の方法についての議論を掲載しています。 また、新しいリリースとリリース候補の発表や、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、 恒例のセクションも含まれています。

ニュース

  • ● より高速なシードバックアップのチェックサム: Peter Toddは、BIP32シードのリカバリーコードの作成、検証、使用を可能にする方式である Codex32のBIPドラフト（先週のニュースレター参照）に関する議論に返信しました。 既存の方式に対するCodex32の特別な利点は、ペンと紙、ドキュメントを使ってわずかな時間でバックアップの完全性を検証できることです。

    Codex32は、バックアップのエラーを検出する能力について、設計どおり強力な保証を提供します。 Peter Toddは、より簡単な方法として、リカバリーコードを生成し、 そのパーツを加算してチェックサムを生成する方法を提案しました。 チェックサムを既知の定数で割って余りが出ないようにすれば、 チェックサムアルゴリズムのパラメーター内でバックアップの完全性を検証することができます。 Peter Toddは、タイプミスに対しておよそ99.9%の保護を提供するアルゴリズムの使用を提案しました。 これは十分に強力で、利用者が使いやすく、覚えやすく追加のCodex32資料を必要としないと考えています。

    Russell O’Connorは、利用者がより低い保護率の受け入れを望むのであれば、 Codex32の完全なリカバリーコードは、完全な検証よりもはるかに速くチェックできると答えました。 一度に2文字ずつチェックすれば、リカバリーコードの1文字の間違いも確実に検出でき、 その他の置換ミスに対しても99.9%の保護が可能です。 このプロセスは、Peter Toddが説明したチェックサムの生成と多少似ていますが、 一般の利用者が覚えにくいルックアップテーブルを使用する必要があります。 検証者がコードをチェックする度に、異なるルックアップテーブルの使用を厭わなければ、 検証を重ねる毎にエラーを検出する確率が上がり、7回めの検証まででCodex32の完全な検証と同じ保証を得ることができます。 Codex32を使用するために必要なテーブルやワークシートを提供するために、 Codex32のドキュメントを更新する必要がありますが、 強化されたクイックチェックの特性を得るためにCodex32に変更を加える必要はありません。

リリースとリリース候補

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

  • ● HWI 2.2.1は、ソフトウェアウォレットとハードウェア署名デバイスのインターフェースとなる このアプリケーションのメンテナンスリリースです。

  • ● Core Lightning 23.02rc3は、この人気のLN実装の新しいメンテナンスバージョンのリリース候補です。

  • ● lnd v0.16.0-beta.rc1は、この人気のLN実装の新しいメジャーバージョンのリリース候補です。

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

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

  • ● Bitcoin Core #25943は、sendrawtransaction RPCにパラメーターを追加し、 アウトプット毎に焼却される資金の量を制限します。 トランザクションが、ヒューリスティックに使用不可能と判断されるスクリプト（ OP_RETURNや、無効なopcode、最大スクリプトサイズを超えるものなど）のアウトプットを含み、 その金額がmaxburnamountより大きい場合、そのトランザクションはmempoolに送信されません。 デフォルトでは、この金額はゼロに設定されており、ユーザーを意図しない資金の焼却から保護します。

  • ● Bitcoin Core #26595は、暗号化されたレガシーウォレットと 現在ディスクリプターウォレットにロードされていないウォレットの移行をサポートするために、 migratewallet RPCに、wallet_nameパラメーターとpassphraseパラメーターを追加しました。

  • ● Bitcoin Core #27068は、Bitcoin Coreがパスフレーズ入力を処理する方法を更新しました。 これまでは、ASCII ヌル文字（0x00）を含むパスフレーズを受け入れ、 最初のヌル文字までの文字列の一部がウォレットの暗号化処理で使用されていました。 このため、ユーザーが期待するよりも安全性の低いパスフレーズを持つウォレットになってしまう可能性があります。 このPRでは、ヌル文字を含むパスフレーズ全体を暗号化と復号に使用します。 もしユーザーがヌル文字を含むパスフレーズを入力し、既存のウォレットの復号に失敗した場合、 古い動作の下でパスフレーズを設定した可能性を示し、回避策が指示されます。

  • ● LDK #1988は、ピア接続と資金提供のないチャネルの制限を追加し、 サービス拒否攻撃によるリソース枯渇を防止します。新しい制限は次のとおりです:

    • ローカルノードと資金提供されたチャネルを持たないデータ共有ピアの最大数は250

    • ローカルノードと現在チャネルを開こうとしているピアの最大数は50

    • 1つのピアからまだ資金提供を受けていないチャネルは最大4つ

  • ● LDK #1977は、BOLT12ドラフトで定義されたOfferを シリアライズおよびパースするための構造をpublicにしました。 LDKはまだブラインド・パスをサポートしていないため、 現在Offerを直接送受信することはできませんが、このPRにより開発者が実験を開始することができます。