今週のニュースレターは、Taprootのウォレットサポートに関連する２つのBIP提案の要約と、 Bitcoin Stack Exchangeから厳選された質問とその回答や、Taprootの準備方法、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更点などの恒例のセクションを掲載しています。

ニュース

  • ● Taproot用のPSBT拡張: Andrew Chowは、 Taprootのアウトプットを使用するもしくは作成する際に使用するPSBTの新しいフィールドを定義する BIPの提案をBitcoin-Devメーリングリストに投稿しました。 このフィールドは、元のバージョン0のPSBTと提案されているバージョン2のPSBT（ニュースレター #128参照）の両方を拡張します。 keypathおよびscriptpathの両方の使用がサポートされています。

    また、提案されているBIPでは、Taprootがv0 segwitインプットに対する手数料の過払い攻撃への対策をしているため （ニュースレター #101参照）、 PSBTのP2TRインプットが参照するトランザクションのコピーを省略できることを推奨しています。

  • ● P2TRのシングルシグ用の鍵導出パス: Andrew Chowは シングルシグ用のTaprootアドレスを作成するウォレットで使用するBIP32導出パスを提案する2つめのBIP提案も Bitcoin-Devメーリングリストに投稿しました。 Chowは、このBIPがP2SHでラップしたP2WPKHアドレス用のBIP49や、 ネイティブP2WPKHアドレス用のBIP84とよく似ていると指摘しています。

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

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

Taprootの準備 #2: Taprootはシングルシグでも価値があるか？

ブロック高709,632のTaprootのアクティベーションに向けて、 開発者やサービスプロバイダーがどのような準備をすればよいかについての週刊シリーズです。

OptechのTransaction size calculatorを使用すると、 さまざまななタイプのシングルシグ・トランザクションのサイズを比較できます。 予想どおり、P2WPKHのインプットとアウトプットを使用したトランザクションは、 P2PKHのインプットとアウトプットを使用したトランザクションよりもはるかに小さいですが、 意外なことに、P2TRのトランザクションは同等のP2WPKHのトランザクションよりもわずかに大きくなります。

  P2PKH (legacy) P2WPKH (segwit v0) P2TR (taproot/segwit v1)
Output 34 31 43
Input 148 68 57.5
2-in, 2-out tx 374 208.5 211.5

そのため、シングルシグのウォレットがブロック709,632 に備えてTaprootの送信を実装するのは逆効果のように思えるかもしれません。 しかし、よく見てみると、ウォレットのユーザーにとってもネットワーク全体にとっても、 シングルシグにP2TRを使用するのは多くのメリットがあります。

  • 使用料が安い: シングルシグのP2TR UTXOを使用する際のインプットレベルのコストは、 P2WPKH UTXOを使用する際のコストよりも約15%低くなります。 上の表のような単純な分析では、使用者が支払いを要求されているアドレスを選択できないという詳細が隠されています。 つまり、あなたがP2WPKHのままで他のユーザーがP2TRにアップグレードした場合、 あなたの2-in-2-outトランザクションの実際の典型的なサイズは、232.5 vbyteになりますが、 すべてP2TRのトランザクションは211.5 vbyteのままです。

  • プライバシー: アーリーアダプターが新しいスクリプトフォーマットに変更すると一部のプライバシーが失われますが、 Taprootに切り替えたユーザーはすぐにプライバシーが強化されます。 あなたのトランザクションは、新しいLNチャネルや、より効率的なDLC、 安全なマルチシグ、さまざまな賢いウォレットバックアップリカバリー方式、 その他の100の先駆的な開発に取り組んでいる人たちと見分けがつかなくなります。

    P2TRをシングルシグに使用することで、既存のユーザーのプライバシーに影響を与えることなく、 ウォレットをマルチシグやTapscript、LNサポート、またはその他の機能に後でアップグレードすることも可能です。 UTXOがソフトウェアの旧バージョンと新バージョンのどちらで受信されたかは問題になりません。 どちらのUTXOもオンチェーンでは同じように見えます。

  • ハードウェア署名デバイスの利便性の向上: 手数料の過払い攻撃が再発見されてから、 いくつかのハードウェア署名デバイスは、トランザクションで使用される各UTXOに、 そのUTXOを生成したトランザクション全体の重要な部分のコピーを含むメタデータが提供されない限り、 トランザクションへの署名を拒否します。 これにより、ハードウェア署名者が実行しなければならない最悪のケースの処理が大幅に増え、 特に限られたサイズのQRコードを主な通信媒体として使用するハードウェア署名者にとっては問題になります。 Taprootは、手数料の過払い攻撃の原因となる脆弱性を排除し、ハードウェア署名者のパフォーマンスを大幅に向上させます。

  • より予測可能な手数料率: P2PKHおよびP2WPKH UTXOのECDSA署名は、サイズが異なる場合があります（ニュースレター #3参照）。 ウォレットは署名を作成する前にトランザクションの手数料率を選択する必要があるため、 ほとんどのウォレットは、最悪のケースの署名サイズを想定し、 それより小さな署名が生成された場合に手数料率が若干オーバーするのを許容します。 P2TRでは、署名の正確なサイズが事前に分かるため、ウォレットは正確な手数料率を確実に選択することができます。

  • フルノードの支援: Bitcoinシステムの全体的なセキュリティは、かなりの割合のBitcoinユーザーが自身のノードで 承認済みの各トランザクションを検証することに依存しています。 これにはあなたのウォレットが作成するトランザクションの検証も含まれます。 TaprootのSchnorr署名は、効率的なバッチ検証が可能で、 前のブロックをキャッチアップする過程で署名を検証する際にノードが費やす必要のあるCPUサイクル数を約1/2に削減します。 このリストの他のすべてのポイントを拒否したとしても、 フルノードを実行する人々の利益のためにTaprootを使用する準備をご検討ください。

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

今週の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 #22154では、ブロック709,632でTaprootがアクティベートされた後に、 例えばgetnewaddress "" bech32mを呼び出すことで、 ユーザーがP2TRスクリプト用のbech32mアドレスを生成できるようにするコードが追加されています。 Taprootのアクティベート後、トランザクションにbech32mアドレスが含まれている場合、 Descriptor WalletもP2TRのお釣り用アウトプットを使用します。 この機能は、Taproot descriptorを持つウォレットにのみ適用されます（ニュースレター #152参照）。

  • ● Bitcoin Core #22166では、アウトプットからTaprootのtr()descriptorを推論する機能が追加され、 基本的なTaproot descriptorのサポートが完了しました。 descriptorの推論は、listunspentのようなRPCコールへの応答で より正確な情報を提供するために使用されます。

  • ● Bitcoin Core #20966は、保存されているbanlistファイルの名前とフォーマットを （シリアライズされたP2Pプロトコルのaddrメッセージをベースにした）banlist.datからbanlist.jsonに変更しました。 ファイルフォーマットの変更により、Tor v3のピアや他のネットワークのピアでオリジナルの addrメッセージに含められる最大値である128 bit幅を超えるアドレスの禁止エントリを保存できるようになりました。

  • ● Bitcoin Core #21056は、bitcoin-cliに新しい-rpcwaittimeoutパラメーターを追加しました。 既存の-rpcwaitパラメーターは、bitcoindサーバーが起動するまでコマンド（RPCコール）の送信を遅らせます。 新しいパラメーターは、指定された秒数後に待機を止め、エラーを返します。

  • ● C-Lightning #4606では、 LNDでの同様の変更（ニュースレター #93参照）と次のセクションで説明する仕様変更を受けて、 約0.043 BTC以上のインボイスの作成が可能になりました。

  • ● BOLTs #877では、実装のバグによる大きな損失を避けるために導入されたプロトコルレベルでの支払い毎の金額制限を撤廃しました。 これは、2020年にoption_support_large_channelが広く実装されたことを受けたもので、 これが有効になるとチャネル毎の金額制限がなくなります。 この2つの制限の詳細についてはLarge channelsのトピックをご覧ください。