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

Bitcoin Optech Newsletter #210

Jul 27, 2022

今週のニュースレターでは、非レガシーアドレス用の署名付きメッセージを作成するために提案されているBIPと、サービス拒否攻撃の対策のために少量のビットコインを焼却することに関する議論を掲載しています。また、Bitcoin Stack Exchangeの人気のある質問と回答や、新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更などの恒例のセクションも含まれています。

ニュース

● マルチフォーマットのシングルシグのメッセージ署名: Bitcoin Coreや他の多くのウォレットは、署名に使用される鍵がP2PKHアドレスに対応したものである場合、任意のメッセージへの署名と検証を長い間サポートしています。 Bitcoin Coreは、シングルシグのP2SH-P2WPKHやネイティブのP2WPKHおよびP2TRアウトプットをカバーするアドレスを含む、他のアドレスタイプに対する任意のメッセージへの署名および検証をサポートしていません。以前提案されていたBIP322は、任意のScriptに対して機能する完全に汎用的なメッセージ署名を提供するものですが、まだBitcoin Coreにマージされておらず、私たちの知っている他の人気のウォレットにも追加されていません。

今週、Ali Sheriefは、P2WPKHで使用されているのと同じメッセージ署名アルゴリズムを他のアウトプットタイプにも使用することを提案しました。検証のために、プログラムは鍵の導出方法を（必要であれば）推測し、アドレスタイプを使用して署名を検証する必要があります。たとえば、20バイトのデータ要素を持つbech32アドレスが提供された場合、それはP2WPKHアウトプットであると仮定します。

開発者のPeter Grayは、ColdCardウォレットは既にこの方法で署名を作成していると指摘し、開発者のCraig Rawは、Sparrow WalletはBIP137の検証ルールとElectrumに実装されている少し異なるルールセットも加えた上で、それらの検証することができると述べました。

Sheriefは、動作を定義するBIPの作成を計画しています。
● Proof of micro-burn: 何人かの開発者は、リソースの消費の証明としてビットコインを少しずつ破壊する（焼却する）オンチェーントランザクションのユースケースと設計について議論しました。スレッドにあったRuben Somsenのユースケースを拡張することで、 100人のユーザーがそれぞれ$1のビットコインが焼却されたという証明をメールに添付できるようにするものは、もともとhashcashの利点として想定されていた類のアンチスパム保護を提供するものです。

マークルツリーを使用したいくつかのソリューションが議論されましたが、ある回答者は、参加者が中央の第三者を信頼（または部分的に信頼）することは、不必要な複雑さを回避するための合理的な方法であることを、この小額の金額が示唆していると述べました。

Bitcoin Stack Exchangeから選ばれたQ&A

Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。

● OP_CHECKSIGADDで無効な署名がスタックにプッシュされないのはどうしてですか？ Chris Stewartは、「無効な署名が見つかった場合、インタプリターは実行を継続するのではなく失敗する」のは何故かと質問しています。 Pieter Wuilleは、BIP340-342で定義されたこの動作は、将来Schnorr署名のバッチ検証をサポートするために設計されたと説明しています。 Andrew Chowは、この動作の追加の理由として、ある種のマリアビリティに関する懸念もこのアプローチによって軽減されると述べています。
● Bitcoin Coreにおけるパッケージとは何か、またそのユースケースについて教えてください。 Antoine Poinsotは、パッケージ（関連のあるトランザクションのグループ）と、パッケージリレーとの関係性、最近のパッケージリレーのBIP提案について説明しています。
● 完全なUTXOセットを支払いに使用するには、どれくらいのブロックスペースが必要ですか？ Murchは、既存のUTXOセットを全て統合するという架空のシナリオを検討しています。彼は、各アウトプットタイプ毎にブロックススペースを計算し、このプロセスには、約11,500ブロックが必要であるという結論を出しました。
● 経済合理性のないアウトプットをUTXOセットに残しておく必要はありますか？ Stickies-vは、OP_RETURNや、最大Scriptサイズを超えるScriptを含むおそらく使用不可能なUTXOは、 UTXOセットから削除されますが、経済合理性のないアウトプットを削除すると、 Pieter Wuilleが指摘しているように、そのアウトプットが使用された場合にハードフォークなどの問題を引き起こす可能性があると指摘しています。
● libsecp256k1に、Bitcoin Coreのコードベースに移動すべきコードはありますか？ libbitcoinkernelやプロセス分離などのBitcoin Coreのコードベースをモジュール化する他の取り組みと同様に、 Pieter Wuilleは、libsecp256k1プロジェクトの明確な責任範囲である秘密鍵と公開鍵の操作に関わるすべてに注目しています。
● DoS攻撃として古くなった低難易度ブロックのマイニング Andrew Chowは、assumevalidおよび、より最近ではnMinimumChainWorkが、難易度の低いチェーン攻撃をフィルタリングするのに役立つと説明しています。

リリースとリリース候補

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

● BTCPay Server 1.6.3は、この人気のあるセルフホスト型のペイメントプロセッサに、新機能、改良、バグ修正を追加しています。
● LDK 0.0.110は、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 #25351は、アドレスや鍵およびディスクリプターをウォレットにインポートした後、その後の再スキャンがブロックチェーンだけでなくmempool内のトランザクションがウォレットに関係しているかどうかも評価することを保証します。
● Core Lightning #5370は、commandoプラグインを再実装し、CLNに組み込みました。 commandoは、ノードがLNメッセージを使用して認可されたピアからコマンドを受信できるようにします。ピアは、簡易版のmacaroonsをベースにしたカスタムCLNプロトコルであるrunesを使用して認可されます。 commandoは、現在CLNに組み込まれていますが、ユーザーがrune認証トークンを作成した場合のみ操作可能です。詳しくは、CLNのcommandoとcommando-runeのマニュアルページをご覧ください。
● BOLTs #1001は、支払い転送ポリシーの変更を通知したノードが、古いポリシーで受け取った支払いを10分ほど受け入れ続けることを推奨しています。これは、送信者が最近のポリシーの更新について知らなかったという理由で、支払いが失敗するのを防ぐためのものです。このようなルールを採用した実装例については、ニュースレター #169をご覧ください。