アウトプットディスクリプタ

ディスクリプタが存在するのは、拡張鍵だけでは曖昧だからです。同じxpubからレガシー、ネストされたSegWit、ネイティブSegWit、Taprootのアドレスを生成でき、それを確定するのはラッパー関数だけです。Bitcoin Coreはバージョン23.0（2022年4月リリース）以降、ディスクリプタウォレットをデフォルトで作成しており、ディスクリプタのないマルチシグのバックアップは多くの場合復元できません。

仕組み

ディスクリプタは、鍵式に適用する関数の後にシャープ記号と8文字のチェックサムを続けたものです。関数がスクリプトを指定します。レガシーはpkh、ネストされたSegWitはsh(wpkh(...))、ネイティブSegWitはwpkh、Taprootはtr、2-of-3の金庫はwsh(sortedmulti(2,...))です。

残りの情報は鍵式が担います。角括弧には起点、つまりマスター指紋とその鍵に至るパスが入り、[1a2b3c4d/84h/0h/0h]のように書きます。続いて拡張鍵、そして/0/*のような接尾辞が来ます。ここでアスタリスクは、各アドレスインデックスを順に表すワイルドカードです。ワイルドカードを持つディスクリプタは範囲付きと呼ばれ、そこからアドレス0から999までを要求するのは、1,000回のインポートではなく1回のRPC呼び出しで済みます。

受取用とおつり用は1つではなく2つのディスクリプタであり、そのためウォレットは/0/*と/1/*で終わる組としてインポートします。BIP-389はマルチパス記法でこれを整理し、組を/<0;1>/*として1つの文字列で書くようにしました。

チェックサムは小さく、しかし重要な役割を担います。BIP-380はディスクリプタのテキストに対する8文字のコードを定義しており、長い文字列に実際に起こる種類の破損、すなわち文字の入れ替わり、貼り付け時の切り詰め、メールクライアントが挿入する改行を検出するように設計されています。Bitcoin Coreはチェックサムが一致しないディスクリプタを拒否し、getdescriptorinfoは自分で入力した文字列に対して正しいチェックサムを計算します。

使われる場面

ディスクリプタは、単一のシードより複雑なものすべてにとってのバックアップ形式です。Sparrow、Nunchuk、Specterは作成するすべてのウォレットについて1つをエクスポートし、Coldcardはマルチシグの設定時にディスクリプタをmicroSDに書き込むため、元のコーディネーターソフトウェアなしで構成を再構築できます。

Bitcoin Coreはそれらが標準となった場所です。2018年10月リリースのバージョン0.17.0がスキャンとアドレス生成のためにそれらを導入し、importdescriptorsとlistdescriptorsがそれらをウォレットのネイティブ言語とし、今ではディスクリプタウォレットがソフトウェアの作成する唯一の種類です。ディスクリプタと再スキャンからCoreウォレットを復元することは対応している手段であり、ソフトウェアを一から再インストールしても耐えられます。

単純な単一署名ウォレットであれば、シードフレーズと標準パスで足りるため、通常は一度も目にすることなく済みます。マルチシグでは、ディスクリプタがバックアップの欠けた半分です。スクリプト種別、鍵の順序、各共同署名者の起点の記録がない3つのシードフレーズでは、コインが置かれているアドレスを再構築できなくなることがあります。

アウトプットディスクリプタvs拡張鍵

拡張鍵は材料であり、ディスクリプタはレシピです。xpubはソフトウェアにどの鍵が存在するかを伝え、ディスクリプタはそれらから何を構築し、どこから数え始めるかを伝えます。そのため、同じxpubを2つの異なるアプリにインポートすると2つの異なるアドレス一覧が生じ得ますが、同じディスクリプタのインポートではそうはなりません。どちらも同じプライバシーを開示します。どちらかを持つ者はあなたのブランチを列挙でき、ディスクリプタは中の鍵と同じ注意を払う価値があります。