/ home / newsletters /
Bitcoin Optech Newsletter #156
今週のニュースレターでは、Output script descriptor関連のBIPおよび、 LNプロトコルの拡張とアプリケーションのインターオペラビリティのための一連の標準ドキュメントの作成の提案、 あらかじめ信頼されているゼロ承認のチャネル開設をサポートする標準化の議論を掲載しています。 また、Taprootの準備方法や、リリースとリリース候補、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更点などの恒例のセクションも含まれています。
ニュース
-
● Output script descriptorのBIP: Andrew Chowは、 Output script descriptor を標準化するためのBIPの提案をBitcoin-Devメーリングリストに投稿しました。 コアとなるBIPは、descriptorで使用される一般的なセマンティクスと主な要素を提供します。 6つの追加のBIPは、
pkh()
、wpkh()
およびtr()
など、引数を使ってスクリプトテンプレートを埋める拡張関数を記載しています。 複数のBIPにより、開発者はどのdescriptorの機能を実装するか選択することができます。 例えば、新しいウォレットでは、レガシーなpkh()
descriptorを実装しないこともあります。descriptorはもともとBitcoin Core用に実装されたものですが、 ここ1年間で他のプロジェクトでも採用が増えています。 ウォレットが、Taprootによって可能になる柔軟性や、 Miniscriptなどのツールを介して柔軟なスクリプトへのアクセスを簡単にする機能を模索し始めると、 descriptorの使用が大幅に増加することが予想されます。
-
● BLIP: Ryan Gentryは、Lightning-Devメーリングリストに、 インターオペラビリティの標準から恩恵を受けるLNの拡張やアプリケーションを記載したドキュメントである Bitcoin Lightning Improvement Proposals (BLIP)のコレクションの提案を投稿しました。 René Pickhardtは、2018年に彼が行ったほぼ同じ提案をリンクしました。
議論の中で、このアイディアは幅広い支持を得ているようにみえましたが、 それらの標準を基本のBOLTドキュメントに組み込むための障壁、 つまり経験豊富な開発者が多くのコミュニティ提案をレビューする十分な時間がないという障壁を実際に解決できないという 懸念が示されました。 BLIPが十分なレビューを経ずにマージされると、バグが含まれていたり、 複数のステークホルダーから幅広い支持を得られなかったりする可能性が高くなり、 異なるプロジェクトが競合する標準を採用することで断片化が進むことになりかねません。 しかし、非メインラインのプロトコルは既に作成されており、 それらのプロトコルに関するドキュメントを公開できる有名なアーカイブを提供することは主に有益であると ほとんどの議論の参加者は考えているようです。
-
● ゼロ承認のチャネル開設: Rusty Russellは、 Lightning-Devメーリングリスト上で、turbo channelという名前でも知られている、 ゼロ承認チャネルの取り扱いを標準化するための議論を開始しました。 これらは、資金提供者が初期資金の一部またはすべてを受領者に提供する新しいシングルファンド・チャネルです。 これらの資金は、チャネルを開設するトランザクションが十分な数の承認を得るまで安全ではないため、 受領者が標準的なLNプロトコルを使用して資金の一部を資金提供者に戻すことにリスクはありません。
例えば、アリスはボブのカストディアルな取引所の口座に数BTC持っています。 アリスはボブに、アリスに1.0 BTC支払う新しいチャネルを開くよう依頼します。 ボブは自分自身が開設したばかりのチャネルを二重使用しないと信じているので、 チャネル開設トランザクションが1つめの承認を受ける前であっても、 アリスがボブのノードを通じて0.1 BTCを第三者のキャロルに送信できるようにすることができます。
一部のLNの実装は、既にこのアイディアを非標準的な方法でサポートしているものもあり、 議論に参加した全員が標準化を支持しているようでした。 具体的にどのような方法で使用するかは、執筆時にはまだ議論中でした。
Taprootの準備 #3: Taproot descriptor
ブロック高709,632のTaprootのアクティベーションに向けて、 開発者やサービスプロバイダーがどのような準備をすればよいかについての週刊シリーズです。
Output script descriptorは、 ウォレットがアドレスを作成し、そのアドレスに支払われるアウトプットを効率的にスキャンし、 後でそのアドレスから支払うために必要な情報を保存するための汎用的な方法を提供します。 さらに、descriptorは、適度にコンパクトで基本的なチェックサムを含んでいるため、 アドレスの情報をバックアップしたり、異なるウォレット間でコピーしたり、 複数の署名を提供するために協力するウォレット間で共有したりするのに便利です。
descriptorは、現在いくつかのプロジェクトでしか使われていませんが、 descriptorと関連するMiniscriptプロジェクトは、 異なるウォレットやツール間のインターオペラビリティを大幅に向上させる可能性があります。 これは、より多くのユーザーがTaprootの利点を活用して、 マルチシグによるセキュリティとバックアップの使用条件によるリカバリーを向上させるにつれて、 ますます重要になるでしょう。
その前に、Taprootで動作するようにdescriptorを更新する必要があります。 それが最近マージされたBitcoin Core #22051のプルリクエストの主題でした。 単一のdescriptorテンプレートで、P2TRのkeypathによる使用と、 scriptpathによる使用の両方を使用するために必要なすべての情報を提供できるように設計されています。 単純なシングルシグの場合は、以下の記述で十分です:
tr(<key>)
同じ構文をマルチシグや閾値署名にも使用することができます。
例えば、アリスとボブ、キャロルはMuSigを使って鍵を集約し、
tr(<combined_key>)
に支払います。
直感的には、tr(<key>)
で指定されたkey
はアドレスにエンコードされる鍵にはなりません。
tr()
descriptorは、BIP341の安全上の推奨事項に従い、
使用不可能なスクリプトツリーにコミットする内部鍵を使用しています。
これにより、簡易的な鍵集約方式のユーザーに対する攻撃がなくなります
(MuSigやMuSig2などのより高度な方式は影響を受けません)。
scriptpathによる使用については、バイナリツリーの内容を指定できる新しい構文が追加されました。
例えば、{ {B,C} , {D,E} }
は次のようなツリーを指定します:
Internal key
/ \
/ \
/ \ / \
B C D E
ツリーは、前述したdescriptorテンプレートのオプションの2つめのパラメーターとして指定できます。 例えば、アリスがkeypathを介して使用できるようにしたいが、 ボブ、キャロル、ダン、エドモンドが彼女の監査証跡を生成するscriptpathを介して使用できるようにしたい場合 (ただし、サードパーティのチェーン監視用のためのものではない)、アリスは次のdescriptorを使用できます:
tr( <a_key> , { {pk(<b_key>),pk(<c_key>)} , {pk(<d_key>),pk(<e_key>)} )
上記の機能は、Taproot用のdescriptorを使用するために必要なことですが、 PR #22051では、descriptorが期待されるポリシーを完全に記述するために追加できるものがまだいくつか欠けていると指摘しています:
-
keypathの無効化: ユーザーによっては、scriptpathによる使用を強制するために、 keypathの使用を防止したい場合があります。これは現在、
tr()
の最初のパラメーターに使用不可能な鍵を使用することで可能ですが、 ウォレットがこの設定をdescriptor自体に保存し、 プライバシーを保護した使用不可能なkeypathを計算させることができると良いでしょう。 -
Tapscriptのマルチシグ: レガシーおよびv0 segwitでは、
multi()
およびsortedmulti()
descriptorがOP_CHECKMULTISIG
opcodeをサポートしています。 Taprootではバッチ検証を可能にするため、スクリプトベースのマルチシグはTapscriptでは少し違った方法で処理されるため、tr()
descriptorでは現在必要なマルチシグopcodeをraw()
スクリプトで指定する必要があります。 Tapscript用にmulti()
およびsortedmulti()
の更新版があると良いでしょう。 -
MuSigベースのマルチシグ: この記事の前半で、 アリスとボブ、キャロルが
tr()
descriptorを使用するために手動で鍵を集約する説明をしました。tr(musig(<a_key>, <b_key>, <c_key>))
のように指定して、元の鍵情報をすべて保持し、 それを使って協力して署名する際に使用するPSBTフィールドに入力できるようにする関数があると理想的です。 -
タイムロック、ハッシュロック、ポイントロック: LNやDLC、 Coinswapおよびその他の多くのプロトコルで使用されるこれらの強力な構造は、 今のところ
raw()
関数でしか記述できません。これらのサポートをdescriptorに直接追加することは可能ですが、 代わりにdescriptorの兄弟プロジェクトであるMiniscriptを介してサポートが追加されることになるかもしれません。 Bitcoin CoreへのMiniscriptの統合はまだ進行中のプロジェクトですが、 PSBTやdescriptorのようなツールが既にそうであるように、 その革新性が他のウォレットにも広がることを期待しています。
ウォレットは、Taprootを使い始めるためにdescriptorを実装する必要はありませんが、 実装したウォレットは、後でより高度なTaprootの機能を使用するためのより良い基盤を得ることができます。
リリースとリリース候補
人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。
- ● LND 0.13.1-beta.rc1は、0.13.0-betaで導入された機能の マイナーな改善とバグ修正を含むメンテナンスリリースです。
注目すべきコードとドキュメントの変更
今週の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 #19651では、 ウォレットキーマネージャーが既存のdescriptorを更新できるようになりました。 これにより、ウォレットのユーザーは、ラベルの編集やdescriptorの範囲の拡張、 非アクティブなdescriptorの再有効化およびその他の更新を
importdescriptors
ウォレットRPCを使って行うことができます。 -
● C-Lightning #4610では、
--experimental-accept-extra-tlv-types
コマンドラインオプションが追加されました。 これにより、ユーザーはプラグインが処理するためにlightningd
が通過させるべき偶数番めのTLVタイプのリストを指定できるようになります。 これまでは、lightningd
はすべての未知の偶数タイプのTLVメッセージを無効とみなしていました。 この変更により、プラグインがlightningd
に知られていない独自のカスタムTLVタイプを定義して処理できるようになりました。 -
● Eclair #1854は、警告メッセージタイプが最近実装された C-Lightningのような相手から送られた警告メッセージのデコードとロギングのサポートを追加しました。
-
● BIPs #1137は、単一の鍵のP2TRアウトプットに対する鍵導出方式を提案するBIP86を追加しました。 このBIPについては、先週のニュースレターにまとめられています。
-
● BIPs #1134は、BIP155を更新し、 ソフトウェアプログラムがバージョン2のaddrメッセージを理解する場合に、 プログラムが必ずしも
addr
メッセージの受信を望んでいない場合も含めて、sendaddr2
P2Pの機能ネゴシエーションメッセージを送信する必要があることを示しています。