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

Bitcoin Optech Newsletter #136

Feb 17, 2021

今週のニュースレターでは、トランザクション署名の生成と検証のための新しい定数時間アルゴリズムの開発についての説明、未承諾トランザクションの処理を止める提案についての言及、マルチシグウォレットをセットアップする方法について提案されたBIPの要約、 LN上でのエスクローに関する議論から得られた洞察の共有、双方向のアップフロント手数料に関する新たな議論へのリンクと、悪意あるハードウェアウォレットのリスクを軽減するための新しいプロトコルについての言及をお送りします。また、更新されたクライアントやサービスについてのニュースや、新しいソフトウェアリリースおよびリリース候補の通知、人気のBitcoinインフラストラクチャソフトウェアの注目すべき変更点の説明を含む通常のセクションを掲載しています。

ニュース

● より高速な署名演算: Russell O’ConnorとAndrew Poelstraは、 Bitcoin Coreの署名検証を15%高速化できるアルゴリズムの実装を発表するブログ記事を公開しました。これはまた、サイドチャネル攻撃によるデータ漏洩リスクを軽減する定数時間アルゴリズムを使用したままでも、署名生成にかかる時間を25%短縮できます。これは、デバイスのリソースが限定されているハードウェアウォレットの開発者にとって特に興味深いことかもしれません。

ブログ記事では、Daniel J. BernsteinとBo-Yin Yangによる新しいアルゴリズムの開発、 Peter Dettmanによるlibsecp256k1の実装（ニュースレター #111で言及）、アルゴリズムが定数時間で目標を達成するために必要な最大ステップ数を計算するためのPieter Wuilleによる斬新でCPU効率の高い方法、 Gregory MaxwellによるBernsteinとYangのアルゴリズムのより効率的なバリエーション、 O’ConnorとPoelstraによる、Wuilleの境界検査プログラムの正しさを保証するためのCoq Proof Assistantへの実装について説明しています。 libsecp256k1のDettmanのオリジナルの実装は、PR #831としてWuilleによる最近の開発で更新されました。
● 未承諾トランザクションの処理を止める提案: 通常、ノードは新しいトランザクションの通知をP2Pプロトコルのinvメッセージで受け取ることを期待しています。ノードがそのトランザクションに興味がある場合（以前に他のピアからそのトランザクションを受信したことがない場合など）、ノードはgetdataメッセージを使ってそのトランザクションを要求し、ブロードキャスターはtxメッセージでそのトランザクションを返信します。しかし、ほぼ10年間、一部の軽量クライアントや他のソフトウェアは、invやgetdataの手順をスキップし、未承諾でtxメッセージを送信するようになっています（例）。

今週、Antoine RiardがBitcoin-Devメーリングリストにそのような未承諾のtxメッセージの処理を止める提案を投稿しました。 Bitcoin CoreのPRで議論されているように、これによりノードはトランザクションを受信して処理するタイミングをより細かく制御できるようになり、検証にコストのかかるトランザクションを送信するピアの影響を制限する追加の方法が提供されます。 Riardは、この変更を早ければBitcoin Coreの次のメジャーバージョンであるバージョン22.0で行う提案をしています。

このアプローチの欠点は、現在未承諾のtxメッセージを送信しているすべてのクライアントは、 Bitcoin Coreの0.21.xもしくはそれ以前のバージョン（または同様の動作を他のBitcoin実装）がネットワークからいなくなる前にアップグレードしないとトランザクションを送信することができなくなることです。古いバージョンが完全にネットワークからいなくなるには通常数年かかるため、クライアントのアップグレードを完了するには十分な時間が必要です。影響を受けるクライアントの開発者は、提案を読んでコメントを検討することをお勧めします。
● マルチシグウォレットを安全にセットアップする: Hugo Nguyenは、ウォレット、特にハードウェアウォレットがマルチシグの署名者になるために必要な情報を安全に交換する方法を記述したBIPドラフトを Bitcoin-Devメーリングリストに投稿しました。交換する必要のある情報には、使用するScriptテンプレート（署名に2-of-3の鍵が必要なP2WSHなど）や、署名に使用する予定のキーパスにおける各署名者のBIP32拡張公開鍵（xpub）が含まれています。

簡単に説明すると、（複数のハードウェアウォレットメーカーに対応して開発された）Nguyenの提案では、コーディネーターがScriptテンプレートを選択し、プライベートな暗号と認証クレデンシャルを生成することで、マルチシグフェデレーションプロセスを開始します。これらのパラメーターはメンバーのウォレットと共有され、メンバーウォレットは適切なキーパスを選択し、対応する秘密鍵で生成された署名と一緒にxpubを返します。 {identifying_parameters, key_path, xpub, signature}のセットは、各ウォレットによって暗号化され、コーディネーターに返されます。続いて、コーディネーターは、それらをoutput script descriptorに結合し、暗号化し各メンバーウォレットに返します。各メンバーウォレットは、自身のxpubが含まれていることを確認し、署名するScriptテンプレートとしてdescriptorを保存します。

この提案はメーリングリストでかなりの議論を受け、いくつかの変更が計画されています。提案が成熟し、実装に近づくにつれて重要な更新があるかどうか、議論を監視していきます。
● LN上のエスクロー: １年以上前にLightning-Devメーリングリストで議論が始まった LNでのノンカストディ型のオンチェーンエスクローの作成について、ここ１週間で新たな議論がみられました。議論の中で特に際立っていたのは、Booleanステートメントに対してド・モルガンの法則の１つの使って, エスクロー、また支払いを受け取る前に売り手が債権を発行する必要があるトレードオフを持つおそらく多くのLNベースのコントラクトの構築を大幅に簡素化するZmnSCPxjによる投稿でした。 ZmnSCPxjのアイディアでは、PTLCを使用する必要があり、これは現在 Taprootがアクティベートされるまで実現しそうにありません。
● 双方向のアップフロントLN手数料に関する新たな議論: Joost Jagerは、 Lightning-Devメーリングリストで、チャネルの限られた利用可能な資金（”流動性”）と同時支払いキャパシティ（”HTLC slots”）を使用して、送信者と受信者が消費する時間に応じて課金するLNサービス手数料の追加について議論を再開しました。 Jagerは以前の提案（ニュースレター #122参照）を基に、固定手数料を支払い処理時間に比例した手数料（”hold fees”）で拡張しています。この提案は適度な議論を受け、１つの懸念は送信者/受信者のプライバシーの低下でした。この根本的な課題は5年前から知られており、何度も議論されてきたので、今後も議論が続くことを期待しています。
● 流出防止: Andrew PoelstraとJonas Nickは、Shift Crypto BitBox02およびBlockstream Jade ハードウェアウォレットに実装されているセキュリティ技術についてのブログ記事を公開しました。その目標は、ハードウェアウォレットとそれを制御するコンピューターの両方が、署名を生成するために使用されるナンスが確実に推測不可能な値であることをそれぞれ保証できるようにすることです。これにより、悪意あるハードウェアウォレットのファームウェアが、ファームウェアの作成者に知られているナンスを生成するのを防ぎます。ナンスを知られてしまうと、ファームウェアの作成者は、チェーン上で見つけたデバイスのトランザクション署名の１つと組み合わせて、その秘密鍵を導出し、その鍵で管理されている他のビットコインを使用することができるようになります。この記事では、ほぼ1年前にこのテーマに関するメーリングリストのスレッドで言及された（ニュースレター #87および #88を参照）、使用された技術を説明しています。

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

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

● BlockstreamがLNsyncを発表: LNsyncを使用すると、しばらくオフラインだったLightningウォレットが、支払いの宛先まで最適なルーティングをするためのLNのトポロジーの更新をすばやくダウンロードできます。オープンソースのプラグインであるhistorianは、C-Lightningのユーザーにこの機能を提供します。
● Rustの軽量クライアントNakamotoのリリース: Alexis Sellierは、Compact Block Filterをベースにした “低リソース使用率、モジュール性、セキュリティに重点を置いたRustのBitcoin軽量クライアント実装” であるNakamotoをリリースしました。
● Blockstream SatelliteがLNデータとBitcoin Coreのソースをブロードキャスト: Blockstreamの衛星からのブロードキャストには、Bitcoinブロックチェーンデータに加えて、Bitcoin Coreのソースコード、衛星に最適化されたBitcoinフォーク（Bitcoin Satellite）のコードおよび LNゴシップデータが含まれています。
● Blockstream GreenがCSVを実装: Green Walletは、これまでウォレットのリカバリーの仕組みにnLockTimeを使用しており、ユーザーが資金を回収するために各取引の後にBlockstreamから事前署名されたトランザクションを含むバックアップメールを受信するようになっていました。 OP_CHECKSEQUENCEVERIFY (CSV) を使ったリカバリーの仕組みを実装することで、トランザクション固有のバックアップファイルや、ウォレットにメールアドレスを関連付けることなく、ウォレットをリカバリーできるようになりました。
● Muun 2.0リリース: モバイルのBitcoinおよびLightningウォレットMuunの2.0リリースは、マルチシグやウォレットのリカバリー機能を含む他、AndroidとiOSのモバイルアプリをオープンソース化しています。
● Joinmarket 0.8.1リリース: 0.8.1のリリースには、外部で作成されたPSBTのサポートやSignetのサポート、 BIP21 URIの大文字アドレスのサポートの修正（ニュースレター #127参照）が含まれています。 JoinMarketのターミナルベースのUI、JoininBoxも0.8.1をサポートするよう更新されました。
● VBTCでLNおよびSegwitバッチによる引き出しが可能に: ベトナムの取引所であるVBTCは、最近Lightningによる引き出しを可能にした後、 Segwitバッチ引き出しオプションを追加しました。インセンティブのあるSegwitバッチ引き出しは、mempoolが大量のトランザクションバックログを持つ可能性が低い時間を対象として、週に1回行われます。
● Bitcoin Dev Kit v0.3.0リリース: RustのウォレットライブラリBitcoin Dev Kitは、CLIの独自のリポジトリへの分割を含むv0.3.0のリリースを発表しました。最近のBDK v0.2.0のリリースでは、分枝限定法（BnB）によるコイン選択および、（最近追加されたsortedmultiを含む）descriptorテンプレートなどが追加されました。

リリースとリリース候補

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

● LND 0.12.1-beta.rc1は、LNDのメンテナンスリリースのリリース候補です。誤ってチャネルが閉鎖される可能性のあるエッジケースや、一部の支払いが不必要に失敗する可能性のあるバグを修正した他、いくつかのマイナーな改善とバグ修正が行われています。

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

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

● Bitcoin Core #20944は、getmempoolinfo RPCおよびmempool/info RESTエンドポイントで返されるオブジェクトに新しいtotal_feeフィールドを追加しました。 total_feeは、現在mempoolにあるすべてのトランザクションのトランザクション手数料の合計を示します。
● LND #4909では、デーモンを再起動することなく、LNDのミッションコントロールサブシステムの設定を取得し、一時的に変更できる新しいgetmccfgおよびsetmccfgRPCが追加されました。ミッションコントロールは、過去の支払いに関する情報を使って、次の支払いの試行のためのより良い経路を選択します。
● Rust-Lightning #787により、エラーメッセージによるチャネル閉鎖は、メッセージを送信した相手がチャネルのカウンター・パーティである場合にのみ発生するようになりました。これまでは、悪意のあるピアがチャネルIDを知っていれば任意のチャネルを強制的に閉じることが可能でした。
● BTCPay Server #2164では、ウォレットのセットアップウィザードが再設計され、 BTCPayの内部ウォレットをセットアップし、オプションでユーザー自身のリモートソフトウェアもしくはハードウェアウォレットと統合することができるようになりました。これはBTCPayのインターフェースの再設計の始まりです。
● HWI #443では、BitBox02ハードウェアウォレットを使用したマルチシグインプットへの署名のサポートが追加されました。
● Bitcoin Core #19145は、gettxoutsetinfoRPCのhash_typeオプションを拡張し、現在のブロック高で設定されたUTXOセットのMuHash3072ダイジェストを生成する新しいmuhashパラメーターを受け入れます。これは、UTXOセットのSHA256ダイジェストを生成するデフォルトの代わりの方法です。この方法で実行すると、MuHashはSHA256関数と同じ量のデータを処理する必要があるため、低速のシングルボードコンピューターで数分かかる可能性のある gettxoutsetinfoRPCのパフォーマンスに大きな変化はないと予想されます。しかし、以前計算されたMuHashオブジェクトは、比較的安価に要素を追加、削除できるため、将来のPRでは、各ブロックのUTXOセットのMuHashサマリーを迅速に計算し、それらのサマリーを単純なデータベースに保存し、要求に応じてほぼ即座にダイジェスト形式で返すことができるようになると期待されています。これは、選択された過去のブロック高でUTXOセットのハッシュを比較する機能に依存しているAssumeUTXOプロジェクトにも役立ちます。
● C-Lightning #4364では、チャネルパートナーへの問題の通知方法を変更し、既存のエラーメッセージを真のerrorsと単なるwarningsに分離しています。現在のBOLT1の仕様では、どんなエラーが発生した際にもチャネルを閉鎖するよう要求していますが（ただし普遍的に実装されているようには見えません）、提案された仕様の更新により、より柔軟な対応を可能にする警告メッセージが導入されています。興味のある方は、 “関係あるが、直接関係していないソフト警告エラー”と説明している、 Carla Kirk-CohenによるLightning-Devメーリングリストへの今週の投稿を読んでみてはいかがでしょうか。