今週のニュースレターでは、提案された新しいopcodeについての議論と、 bech32mのサポートを追跡するために更新されたwikiページのリンクを掲載しています。 また、Bitcoin Core PR Review Clubミーティングのハイライトや、 Taprootの準備についての提案、人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更の説明など、 恒例のセクションも含まれています。

ニュース

  • ● OP_CHECKSIGFROMSTACKの設計の提案リクエスト: Jeremy Rubinは、OP_CHECKSIGFROMSTACK opcodeの仕様案を Bitcoin-Devメーリングリストに投稿し、 代替設計を好む開発者からのフィードバックを求めました。 いくつかの代替案が議論されましたが、スレッドはOP_CAT opcodeを同時に導入すべきかどうかという議論にも分岐しました。

    OP_CATとOP_CSFSは、任意のトランザクションのイントロスペクションを可能にします。 つまり、ビットコインを受け取ったスクリプトが、そのビットコインを後で使用するトランザクションのほぼすべてのパーツをチェックできるようになります。 これにより多くの高度な機能（SIGHASH_ANYPREVOUTや、 OP_CHECKTEMPLATEVERIFYなどの、 他の提案中のアップグレードバージョン1を含む）を有効にできますが、 OP_CATを使用すると再帰的なCovenantsを作成することが可能で、 そのCovenantsにコミットしたビットコインの使用可能性を永続的に制限することができます。 BitcoinでCovenantsを許可することをに反対する人もいますが、 再帰的なCovenantsの最悪なケースの問題は、現在のビットコインで既に存在しているという趣旨で いくつか議論がされており、 OP_CATまたは同様のopcodeを有効にすることについて心配する必要はありません。

    そのような議論がありながらも、Rubinは、 OP_CSFSはそれ自体で十分に役に立つと主張し、 OP_CATを追加する提案から独立したOP_CSFSの提案を維持したいと考えています。

  • ● bech32mサポートの追跡: Bitcoin Wikiのbech32採用ページが更新され、 どのソフトウェアやサービスがTaprootのbech32mアドレスへの支払いや受け取りをサポートしているかが追跡されています。

Bitcoin Core PR Review Club

この毎月のセクションでは、最近のBitcoin Core PR Review Clubミーティングを要約し、 重要な質問と回答のいくつかに焦点を当てます。 以下の質問をクリックしてミーティングでの回答の要約を確認してください。

Use script_util helpers for creating P2{PKH,SH,WPKH,WSH} scriptsは、 Sebastian FalbesonerによるPRで、機能テストで手動のスクリプト作成をscript_utilヘルパー関数の呼び出しに置き換え、 get_multisig()関数のエラーを修正しています。 Review Clubミーティングでは、PRで使用されている用語と各スクリプトアウトプットタイプが分類されました。

  • script_util.pyのkey_to_p2pkh_scriptおよびscript_to_p2sh_script、key_to_p2wpkh_script、 script_to_p2wsh_scriptは、何をする関数ですか？

    これらは、公開鍵やスクリプトからPay to Public Key Hashや、Pay to Script Hash、 Pay to Witness Public Key Hash、Pay to Witness Script Hash スクリプト用のCScriptオブジェクトを構築するヘルパー関数です。 ➚

  • scriptPubKeyおよびscriptSig、witnessの定義

    scriptPubKeyおよびscriptSigは、それぞれトランザクションのアウトプットとインプットのフィールドで、 使用条件を指定および満たすためのものです。witnessはSegregated Witnessで導入された同じ目的のための追加フィールドです。 使用条件はアウトプットのscriptPubKeyでコミットされ、 それを使用するインプットにはその条件を満たすデータをscriptSigやwitnessに添付する必要があります。 ➚

  • redeem scriptとwitness scriptの定義。それらの関係は？

    P2SHおよびP2WSHアウトプットタイプは、scriptPubKey内のスクリプトハッシュにコミットします。 アウトプットが使用される際、使用者はスクリプト自体とそれをパスするために必要な署名やその他のデータを一緒に提供する必要があります。 スクリプトがscriptSigに含まれる場合はredeemScriptと呼ばれ、witnessに含まれる場合はwitness scriptと呼ばれます。 そういう意味で、両者は似ています。P2SHアウトプットにおけるredeemScriptは、P2WSHアウトプットにおけるwitness scriptのようなものです。 ただし、P2SH-P2WSHアウトプットを使用するトランザクションには両方が含まれているため、両者は相互に排他的ではありません。 ➚

  • スクリプトにエンコードされた使用条件でコインを誰かに送信する場合、アウトプットのscriptPubKeyには何が含まれますか？ またコインが使用される際、インプットで何を提供する必要がありますか？

    scriptPubKeyにはスクリプトのハッシュとそれが一致することを検証するためのopcodeが含まれています: OP_HASH160 OP_PUSHBYTES_20 <20B script hash> OP_EQUAL。scriptSigには、スクリプト自体と初期スタックが含まれています。 ➚

  • なぜPay-To-ScriptではなくPay-To-Script-Hashを使用するのですか？

    BIP16に記載されている主な動機は、資金を使用する人に使用条件を提供する負担をかけながら、 任意の複雑なトランザクションに資金を供給する一般的な方法を作成することです。 参加者はまた、scriptPubKeyからスクリプトを除外することはスクリプトに関連する手数料がコインが使用されるまで支払われないことを意味し、 結果としてUTXOセットが小さくなることに言及しました。 ➚

  • 非segwitノードがP2SH-P2WSHインプットを検証する際、何をしているのですか？ 非segwitノードによって実行される手順に加えて、segwit対応ノードは何をするのでしょうか？

    非segwitノードはwitnessを確認することはありあません。 redeemScriptがscriptPubKeyでコミットされたハッシュと一致することを確認することで、 P2SHルールを適用するだけです。segwitノードはこのデータをwitness programと認識し、 witnessデータと適切なscriptCodeを使用してsegwitルールを適用します。 ➚

  • 元のget_multisig() 関数のP2SH-P2WSHスクリプトのどこが問題なのでしょうか？

    P2SH-P2WSHのredeem scriptで、そのハッシュの代わりにwitness scriptを使用しています。 ➚

Taprootの準備 #4: P2WPKHからシングルシグのP2TRへ

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

既にv0 segwit P2WPKHアウトプットの受け取りと使用をサポートしているウォレットにとって、 シングルシグ用のv1 segwit P2TRへのアップグレードは簡単です。 主な手順は次のとおりです:

  • ● 新しいBIP32鍵導出パスの使用: BIP32 階層的決定性 (HD)コードを変更する必要はなく、 ユーザーはシードを変更する必要もありません。2 ただし、P2TR公開鍵用の新しい導出パス（BIP86で定義されているような）を使用することを強く推奨します。 そうしないと、ECDSAとSchnorr署名 の両方で同じ鍵を使用した場合に発生する攻撃を受ける可能性があります。

  • ● ハッシュによる公開鍵の調整: シングルシグでは技術的には必須ではありませんが、 特にすべての鍵がランダムに選択されたBIP32シードから導出されている場合、 BIP341では鍵を使用不可能なscripthashツリーにコミットすることを推奨しています。 これは公開鍵とその鍵のハッシュの曲線の点を加算する楕円曲線の加算操作を使用するという簡単なものです。 この推奨事項に従うことのメリットは、後でスクリプトレスなマルチシグのサポートや、 tr() descriptorのサポートを追加する場合に、同じコードを使用できることです。

  • ● アドレスの作成と監視: bech32mを使ってアドレスを作成します。 支払いは、scriptPubKey OP_1 <tweaked_pubkey>に送られます。 P2WPKHなどのv0 segwitアドレスのスキャンに使用する方法を使って、 スクリプトに支払いをするトランザクションをスキャンできます。

  • ● 使用トランザクションの作成: Taprootのすべての非witnessフィールドは、 P2WPKHと同じため、トランザクションのシリアライゼーションの変更について心配する必要はありません。

  • ● 署名メッセージの作成: これは使用トランザクションのデータに対するコミットメントです。 データのほとんどは、P2WPKHトランザクションに署名するのと同じものですが、 フィールドの順番が変更され、いくつかの追加項目が署名されています。 これを実装するのは、さまざまなデータをハッシュしシリアライズするだけなので、 コードを書くのは簡単です。

  • ● 署名メッセージのハッシュに署名: Schnorr署名を作成するには、さまざまなな方法があります。 最善の方法は、「独自の暗号を使う」のではなく、信頼できる十分レビューされたライブラリの関数を使用することです。 ただ、何らかの理由によりそれができない場合は、 BIP340は、ECDSA署名を作成するためのプリミティブが利用可能であれば、 簡単に実装できるアルゴリズムを提供します。署名ができたら、 インプットのwitnessデータに入れ、使用トランザクションを送信します。

ブロック709,632でTaprootがアクティベートされる前でも、 testnetやパブリックなデフォルトsignet、 Bitcoin Coreのプライベートなregtestモードを使ってコードをテストできます。 オープンソースのウォレットにTaprootのサポートを追加する場合、 他の開発者があなたのコードから学べるように、 Bitcoin Wikiのtaproot usesページや bech32m adoptionページにその実装のPRへのリンクを追加することをお勧めします。

リリースとリリース候補

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

  • ● LND 0.13.1-beta.rc2は、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の注目すべき変更点。

  • ● C-Lightning #4625は、最新の仕様の変更に合わせて、 LN offersの実装を更新しました。 注目すべきは、offerに署名を含める必要がなくなったことです。 これによりofferのエンコード文字列が大幅に短くなり、QRコードの認識性が向上します。

  • ● Eclair #1746では、プライマリのSQLiteデータベースと並行して、 PostgreSQLデータベースにデータを複製する機能が追加されました。 この機能は、最終的にバックエンドの移行を希望するサーバーのテストを容易にするためのものです。 昨年、SuredbitsのエンジニアであるRoman Taranchenkoは、Optechのフィールドレポートで、 PostgreSQLバックエンドを使用してEclairをエンタープライズ用途にカスタマイズしたことを紹介していました。

  • ● LND #5447では、クラスターのノード間で複製され自動フェイルオーバーを可能にする代替データベースを使用して、 クラスタ内に複数のLNDノードをセットアップする方法を説明するドキュメントを追加しています。 興味のある方は、ニュースレター #128に掲載されているEclairのアプローチと比較してみてください。

  • ● Libsecp256k1 #844は、Schnorr 署名のAPIをいくつか更新しています。 最も注目すべきは、任意の長さのメッセージの署名と検証を可能にするコミットです。 現在Bitcoinで使用されている署名は、すべて32バイトのハッシュに署名していますが、 可変長データへの署名を可能にすることは、Bitcoin以外のアプリケーションで有用で、 またOP_CHECKSIGFROMSTACKなどの新しいopcodeを有効にして Bitcoin以外のシステムで作成された署名を検証できるようになります。 BitcoinのSchnorr署名の仕様BIP340が更新され、可変長データへの安全な署名について記述されることが期待されます。

  • ● BIPs #943は、SegWit v0ではなく、 まもなくアクティベートされるTaprootおよびTapscriptに基づいて構築されるようにBIP118を更新しています。 さらに、このリビジョンでは、 タイトルの名前がSIGHASH_NOINPUTからSIGHASH_ANYPREVOUTに変更され、 sighash flagは”ANYPREVOUT”と呼ばれるようになりました。 これは、prevoutが署名で使用される可能性がある一方で、インプットのいくつかの側面がまだコミットされているためです。

  • ● BTCPay Server #2655は、ブロックエクスプローラで ユーザーがトランザクションのリンクをクリックした際に、 HTTP refererフィールドを送信しないようWebブラウザに通知します。 これにより、ユーザーがどのBTCPay Serverから来たのかをブロックエクスプローラに伝えないようにします。 この情報は、サーバーがブロックエクスプローラで表示されているトランザクションを作成もしくは受信したことを示す強力な証拠です。 この変更があっても、強力なプライバシーを望むユーザーは、 サードパーティのブロックエクスプローラで自分のトランザクションを検索するのを避ける必要があります。

脚注

  1. BIP118のSIGHASH_ANYPREVOUTや BIP119のOP_CHECKTEMPLATEVERIFYのような提案の機能を実装するのに、 OP_CHECKSIGFROMSTACK (OP_CSFS)を使用すると、 scriptpathで使用する場合に最適化された提案よりも多くのブロックスペースが必要になります。 OP_CSFSを支持する議論は、 より効率的な実装を追加するためにコンセンサスの変更をする前に、 一般的な構成から始めて、人々が実際にその機能を使用することを証明することができるからです。 さらに、Taprootのkeypathでの使用により、 どのようなスクリプトでも、状況によってはブロックスペースの使用を最小限に抑えることができ、 最適化されていない状況でスペースを節約するために特定の構成の必要性が減る可能性があります。 ↩

  2. Electrumがsegwit v0にアップグレードされた際、 bech32アドレスで受け取りたい人は誰でも新しいシードを生成する必要がありました。 これは技術的には必要ありませんでしたが、 Electrumの作者は自分たちのカスタムシードの導出方法にいくつかの新しい機能を導入することができました。 その１つがシードのバージョン番号で、シードを使用するスクリプトを指定する機能です。 これにより古いスクリプトを安全に非推奨にできます（例えば、将来リリースされるElectrumのバージョンでは、 従来のP2PKHアドレスへの受信がサポートされなくなる可能性があります）。

    Electrumの開発者がバージョン付きのシードを展開していたのと同時期に、 Bitcoin Coreの開発者は、output script descriptorを使用して、 （他の問題の解決に加えて）スクリプトの非推奨を可能にするという同じ問題を解決し始めました。 次の表は、Electrumのバージョン付きのシードとBitcoin Coreのdescriptorを、 以前両方のウォレットで使用され、 現在も多くの他のウォレットで一般的に使用されているimplicit scripts方式と比較したものです。

    スクリプト管理 初期バックアップ 新しいスクリプトの導入 スキャン（帯域幅/CPUコスト） 非推奨スクリプト
    Implicit scripts (例：BIP44) シードワード 自動（ユーザー操作は不要） サポートされているすべてのスクリプトをスキャン、O(n) サポートされていないスクリプトを使用していることをユーザーに警告する方法はありません
    Explicit scripts（バージョン付きシード） シードワード（バージョンビットを含む） ユーザーは新しいシードのバックアップが必要。 資金は2つの別々のウォレットに分割されるか、ユーザーは旧ウォレットから新しいウォレットに資金を送信する必要があります 単一のスクリプトテンプレートのみをスキャン、O(1) サポートされていないスクリプトに関するユーザーへの警告
    Explicit scripts (descriptor) シードワードとdescriptor ユーザーは新しいdescriptorのバックアップが必要 実際に使用されたスクリプトテンプレートのみをスキャン、O(n); 新しいウォレットの場合はn=1 サポートされていないスクリプトに関するユーザーへの警告

    ↩