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

Bitcoin Optech Newsletter #141

Mar 24, 2021

今週のニュースレターでは、Bitcoinの既存のコンセンサスルールの下で署名を委譲する手法、 Bitcoinの量子暗号への耐性に対するTaprootの影響についての議論の要約、 Taprootのアクティベートを支援するための一連のウィークリーミーティングの公表について掲載しています。また、サービスやクライアントソフトウェアの注目すべき変更点や、新しいリリースとリリース候補、人気のあるBitcoinのインフラストラクチャソフトウェアの注目すべき変更点の解説などの通常のセクションも含まれています。

ニュース

● 既存のコンセンサスルール下での署名の委譲: アリスが、すぐにオンチェーン・トランザクションを作成したり、ボブに自身の秘密鍵を渡したりすることなく、ボブにアリスのUTXOの１つを使う能力を与えたいと考えているとします。これはデリゲーションと呼ばれ、何年も前から議論されており、最近ではGraftrootの提案の一部として議論されてきました。先週、Jeremy RubinがBitcoin-Devメーリングリストに、現在のBitcoinを使ってデリゲーションを実現する技術の説明を投稿しました。

アリスがUTXO_Aを持ち、ボブがUTXO_Bを持っているとします。アリスは、UTXO_AとUTXO_Bを両方使用する部分的に署名されたトランザクションを作成します。アリスは自分のUTXOにsighashフラグSIGHASH_NONEを使用して署名し、署名がトランザクションのどのアウトプットにもコミットしないようにします。これにより、トランザクションのもう一方のインプットの所有者であるボブは、アウトプットの選択を一方的に制御することができ、通常のSIGHASH_ALLフラグを持つ彼の署名を使用してアウトプットにコミットし、他の誰もトランザクションを変更できないようにします。この２つのインプットとSIGHASH_NONEトリックを使うことで、アリスは自分のUTXOに署名する能力をボブに委譲することができます。

この手法は主に理論的な関心事であると思われます。他にも、 GraftrootやOP_CHECKTEMPLATEVERIFY、 OP_CHECKSIGFROMSTACKなど、いくつかの点で優れた委譲技術が提案されていますが、このような実験を行いたい人には、この手法だけが現在mainnetで利用可能です。
● Taprootに対する量子コンピューターの攻撃についての議論: オリジナルのBitcoinソフトウェアでは、ビットコインを受け取るのに２つの方法が用意されていました:
- ● Pay-to-Public-Key (P2PK) は、ビットコインを公開鍵で受け取り、そのコインを署名で使用できるようにするという、オリジナルのBitcoinの論文に記載されている単純明快な方法を実装していました。 Bitcoinのソフトウェアは、公開鍵のマテリアルをソフトウェアですべて処理できる場合、デフォルトでこれを使用していました。
- ● Pay-to-Public-Key-Hash (P2PKH) は、使用される公開鍵をコミットしたハッシュダイジェストでビットコインを受け取るという、間接的なレイヤーを追加したものです。コインを使用するには、公開鍵を署名と一緒に公開する必要があり、ハッシュダイジェストにさかれる20バイトがオーバーヘッドコストになります。この方法は、コピー＆ペーストできるアドレスなど、支払い情報を人が扱う必要がある場合にデフォルトで使用されてきました。
Nakamotoは、なぜこの２つの方法を実装したのか説明していませんが、 Bitcoinアドレスを小さくして通信しやすくするために、ハッシュの間接参照を追加したのではないかと言われています。当初のBitcoinの公開鍵の実装は65バイトでしたが、アドレスのハッシュは20バイトしかありません。

それから10年、さまざまな開発が行われてきました。特定のマルチシグプロトコルをデフォルトでシンプルかつ安全なものにするためマルチパーティプロトコル用のスクリプトでは、32バイトのコミットメントを使用すべきだと判断されました。 Bitcoinの開発者は、公開鍵を33バイトに圧縮することができる以前から知られていた技術を知り、その後それを32バイトに最適化する方法を説明しました。最後に、Taprootの主なイノベーションは、 32バイトの公開鍵が32バイトのハッシュと同様のセキュリティでスクリプトにコミットできることを示しました。これはつまり、ハッシュと公開鍵のどちらを使っても通信に必要なアドレスデータの量は変わらないということを意味します。普遍的なアドレス形式が必要な場合、どちらを使っても32バイトです。しかし、公開鍵を直接使用することで、ハッシュの間接参照に起因する余分な帯域幅やストレージをなくすことができます。もし、すべての支払いが32バイトのハッシュではなく公開鍵になったとしたら、年間で約13GBのブロックチェーンスペースを節約できることになります。 TaprootのBIP341仕様では、P2PKHスタイルのハッシュの代わりにP2PKスタイルの公開鍵への支払いを受け付ける理由として、スペースの節約を挙げています。

しかし、P2PKHのハッシュの間接参照には１つの利点があります: それは、支払いを承認するのに必要になるまで公開鍵を一般の目から隠すことができることです。つまり、公開鍵のセキュリティを侵害する能力を持つ敵対者は、トランザクションがブロードキャストされるまで、その能力を使い始めることができず、トランザクションが一定の深さまで承認されると、その鍵で管理されている資金を盗む能力を失ってしまう可能性があります。これにより攻撃に使える時間が制限され、ゆっくりとした攻撃ではうまくいかない可能性があることを意味します。これについては、P2PKスタイルで直接公開鍵を使用するTaprootの選択の文脈で前から長く議論されてきましたが（1、2およびニュースレター #70と#86参照）、今週、Bitcoin-Devメーリングリストで、Bitcoinスタイルの公開鍵を攻撃できるほどの強力な量子コンピューターが “早ければ10年後”に登場するのではないかという懸念からTaprootに反対するメールが公開されたことで、再び議論の対象になりました。

メーリングリストでの議論では、誰もTaprootに反対だとは言いませんでしたが、議論の前提を吟味し、代替案を議論し、その代替案が意味するトレードオフを評価しました。それらの会話の抜粋を以下に要約します:
- ● ハッシュは現在QC耐性としてうまく機能しない: 2019年の調査によると、強力なQCを持ちBitcoinのブロックチェーンのコピー以外何も持たない攻撃者は、全ビットコインの1/3を盗むことができるようです。そのほとんどは、ユーザーがアドレスを再利用した結果であり、これは推奨されていない行為ですが、すぐにはなくならないと考えられています。
  
  さらに、議論の参加者からは、個々の公開鍵やBIP32拡張公開鍵（xpub）を第三者と共有している人も、その公開鍵が漏洩した場合、強力なQCのリスクにさらされるという指摘がありました。これには、ハードウェアウォレットやLNのペイメントチャネルに保管されているほとんどのビットコインが含まれる可能性があります。つまり、P2PKHスタイルのハッシュされた公開鍵をほぼ一般的に使用しているにもかかわらず、公開データやサードパーティのデータにアクセスできる強力なQCによって、ほぼすべてのビットコインが盗まれる可能性があるということです。つまり、TaprootでP2PKスタイルのハッシュしていない公開鍵を使用するという選択は、 Bitcoinの現在のセキュリティモデルを大きく変えるものではないということです。
- ● オンチェーンコストをかけずにポストQCのリカバリーを向上させるTaproot: ビットコイナーは、強力なQCが登場した、もしくは登場することを知った場合、 Taprootの（単一の署名のみを必要とするタイプの）key-pathの使用を拒否することができます。しかし、Taprootアドレスの作成時にそのアドレスに受信したビットコインをscript-pathで使用することもできるよう準備することもできます。この場合、Taprootアドレスはユーザーが使用したいTapscriptのハッシュにコミットします。このハッシュコミットメントは、 QCに対して安全な新しい暗号アルゴリズムに移行するためのスキームの一部として使用することができます。また、QCが脅威となる前にそのようなアルゴリズムがBitcoin用に標準化されていれば、ビットコインの所有者はすぐに新しいスキームに移行することができます。この方法が有効なのは、個々のユーザーがバックアップ用のTapscriptの使用パスを作成し、そのバックアップパスに含まれる公開鍵（BIP32のxpubを含む）を共有していない場合、そして強力なQCがBitcoinに大きなダメージを与える前に判明した場合に限られます。
- ● 攻撃は現実的なのか？ ある回答者は、10年後までに高速なQCの実現は”予測される進捗率の中では非常に楽観的な部類に入る”と考えています。別の回答者は、1台の低速なQCを並行して機能できるQCファームに変換し、僅かな時間で結果を達成することは “かなり単純なエンジニアリングの課題”であり、P2PKHスタイルのハッシュの間接参照からの保護は無意味であると述べています。 3人め回答者は、高速なQCで成果を挙げている人だけが使用可能なBitcoinアドレスを構築し、ユーザーが自主的にそのアドレスにビットコインを寄付することで、インセンティブ付きの早期警告システムを構築することを提案しました。
- ● Taprootアクティベート後にハッシュスタイルのアドレスを追加することもできる: かなりの数のユーザーが、強力なQCの出現を本当に驚異に感じているのであれば、その後のソフトフォークでハッシュを使用するP2PKHスタイルのTaprootアドレスを追加することができます。しかし、これには複数の回答者が反対する結果となりました:
  - 混乱が生じる
  - より多くのブロックスペースを使用する
  - ● 直接でもリング署名のメンバーシップ証明やProvisionsなどのプロトコルを使用した場合でも、 Taprootの匿名セットのサイズが小さくなる
- ● 帯域幅/ストレージコストとCPUコストの比較: キーリカバリーと呼ばれる手法では、署名とその署名をしたトランザクションデータから公開鍵を導出することで、ハッシュの間接参照による余分な32バイトのストレージオーバーヘッドをなくすることができます。これも、反対されました。キーリカバリーには大量のCPUが必要で、ノードの動作が遅くなる上、履歴ブロックの検証を最大3倍高速化できるSchnorrのバッチ検証も使えなくなります。また、匿名のメンバーシップ証明やそれに関連する手法の開発が困難になり、CPUに負担がかかります。また、特許の問題もあるかもしれません。
この記事を書いている時点では、メーリングリストでの議論は終了しているようですが、 Taprootに対するコミュニティの支持は明らかに失われていません。研究者や企業が量子コンピューティングの技術を向上させていくなかで、 Bitcoinの安全性を保つための方法が今後も議論されることを期待しています。
● Taprootアクティベーションミーティングを毎週開催: Taprootのアクティベーションに関する詳細を議論するための10回のミーティングが、毎週火曜の19:00 UTCにIRCの##taproot-activationチャンネルで予定され、最初のミーティングが昨日（3月23日）行われました。

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

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

● OKCoinがLightningの入出金を開始: ブログ記事では、OKCoinのLightning入出金サポートの概要を紹介しています。また、それに伴い、入出金の最低限度額を0.001から0.000001 BTCに引き下げました。現時点では、LNを使って取引する場合、0.05 BTCがOKCoinの上限です。
● BitMEXがbech32のサポートを発表: BitMEXは、ブログ記事の中で、bech32による入金サポートの立ち上げ計画を詳しく説明しました。 BitMEXは以前、bech32の引き出し（送金）サポートを展開していました。
● Specter v1.2.0リリース: Specter v1.2.0 には、 Bitcoin CoreのDescriptor Walletとコインコントロール機能のサポートが含まれています。
● BreezがオーディオにLightning支払いをストリーム: Breezウォレットにはオーディオプレーヤーが統合されており、 keysendと組み合わせることで、ユーザーはポッドキャストを聞きながら作者への支払いをストリーミングしたり、一度きりのチップを送信したりできます。
● キーマネージャーDux Reserveの発表: Thibaud Maréchalは、MacOS、WindowsおよびLinuxに対応し、 LedgerやColdcard、TrezorといったハードウェアウォレットをサポートするオープンソースのデスクトップキーマネージャーDux Reserveのベータ版を発表しました。
● Coldcardがlibsecp256k1を使用するようになりました: Coldcardのバージョン 4.0.0では、その他の機能として、暗号処理にBitcoin Coreのlibsecp256k1ライブラリを使用するようになりました。

リリースとリリース候補

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

● C-Lightning 0.10.0-rc1は、このLNノードソフトウェアの次のメジャーバージョンのリリース候補です。

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

今週の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 #20861では、BIP350 (v1以上のwitnessアドレス用のBech32mフォーマット) のサポートが実装されています。 Bech32mはバージョン1〜16のネイティブSegwitアウトプットのアドレスフォーマットとしてBech32(BIP173)に取って代わります。バージョン0のネイティブSegwitアウトプット(P2WPKHおよびP2WSH)は、引き続きBech32を使用します。このPRによりBitcoin Coreのユーザーは、ネットワーク上でTaprootアウトプット(BIP341)が定義されると、 Pay to Taproot (P2TR)アドレスに支払いを送信できるようになります。この変更はmainnetのシステムに影響を与えることはありませんが、以前提案されたように、 Bech32でエンコードされたアドレスを使ってTaprootが既に有効になっているsignetのようなテスト環境でアドレスの非互換性の問題を引き起こす可能性があります。 Bech32mのサポートはBitcoin Core 0.19、0.20、0.21にもバックポートされます。
● Bitcoin Core #21141は、ロードされたウォレットに影響を与えるトランザクションが発生するたびにユーザー指定のコマンドを呼び出す-walletnotifyの設定を更新しました。コマンドに渡すことができる引数に、トランザクションが含まれるブロックのハッシュを表す%bと、ブロックの高さを表す%hという2つのプレースホルダーが追加されました。どちらも未承認のトランザクションには定義された値を設定します。
● C-Lightning #4428では、fundchannel_completeRPCによるtxidの受け入れを非推奨にし、代わりにPSBTの受け渡しを要求します。 PSBTにファンディング・アウトプットが含まれているかどうかをチェックすることができ、誤ったデータを渡したユーザーが資金を回収できなくなるという問題を解消します。
● C-Lightning #4421では、先週のニュースレターで紹介したファンディング・トランザクションのリカバリー手順を実装しています。（RBFを使用するなど）誤って資金提供トランザクションが変更されたチャネルに資金提供したものの、まだそのチャネルを使用していないユーザーは、トランザクション・アウトプットをlightning-closeコマンドに提供し、 shutdown_wrong_funding機能をサポートするピアとリカバリーを交渉できるようになりました。
● LND #5068では、LNDが処理するネットワークのゴシップ情報の量を制限するための新しい設定オプションが多数追加されました。これはリソースが限定されているシステムで役立ちます。
● Libsecp256k1 #831は、署名検証を15%高速化するアルゴリズムを実装しました。また、サイドチャネル攻撃への耐性を最大化する定数時間アルゴリズムを使用しながら、署名生成にかかる時間を25%削減することができます。さらにLibsecp256k1が他のライブラリに依存していた部分を削除しました。この最適化についての詳細はニュースレター #136を参照してください。
● BIPs #1059は、以前メーリングリストで議論されたとおり（ニュースレター #128参照）、 PSBTバージョン2を定義するBIP370を追加しました。