Watch-only Wallet

アリスは鍵をハードウェアウォレットに保管し、スマートフォンで入金を確認したいと考えています。そこで、バックアップの単語ではなく、ウォレットの公開設定をスマートフォンへ移します。アプリはその設定から対象のアドレスを認識し、ネットワーク上の支払いを調べます。署名機器が自宅で電源を切られていても、20 000 sat（ビットコインの最小単位） の入金と承認状況を確認できます。しかし、スマートフォンにその資金を使う権限が生まれたわけではありません。同じ仕組みで、店主は鍵を渡さずに経理担当者へ入出金を見せられます。大切なのは実際に何を取り込んだかです。鍵を復元するバックアップの単語、Seed Phrase を入力すれば、この分離は失われます。 [12]

観察用アプリには他人の公開アドレスも追加できます。画面の金額は、利用者がその資金を使える証拠でも、すべての借金を返せる証拠でもありません。アプリは見つかった UTXO、つまり過去の支払いで作られ、まだ使われていない出力を合計します。ただし見つかるのは、取り込んだ情報と利用できる履歴に対応する分だけです。アドレスの不足、検索の未完了、信頼できないサーバーなどによって、表示が不完全になることがあります。画面のゼロだけでビットコインを失ったと判断せず、まず監視範囲と情報源を確認してください。 [8] [9]

アリスが支払うとき、アプリは利用できる UTXO を選び、受取人、金額、手数料を設定します。入力の使い残しを自分のウォレットへ戻すこともあり、これをお釣り、または change と呼びます。こうした情報は BIP174 で定められた部分署名済みビットコイン取引の形式、PSBT で渡せます。別の機器は自前の UTXO データベースを持たなくても、署名に必要な情報を受け取れます。アリスはその機器の信頼できる画面で、実際の受取人、金額、手数料、お釣りを確認しなければなりません。侵害されたアプリが意図と違う支払いを準備しているかもしれないからです。署名が取引のどの部分を対象とするかを決める sighash にも注意が必要です。確認して署名した後で初めて、承認した案とウォレットのルールに合う最終取引をネットワークへ送ります。 [2] [10]

拡張公開鍵 xpub は、ウォレットのある枝でさらに公開鍵を導出できますが、単独では支払いに署名できません。それでも、ウォレットのルールとともに入手した人は、導出できるアドレス、過去と将来の支払い、残高を結び付けられます。一度の入金用アドレスを伝えるより、はるかに多くの情報を渡すことになります。外部サーバーも、アプリからの繰り返しの照会で似た全体像を得る可能性があります。ブロックチェーンを自分で検証する Full Node は、こうした開示を減らします。暗号化などで接続を保護しても、宛先サーバーから照会内容は隠せません。必要なアカウントだけを書き出し、コピーを限定し、アドレスに名前や支払い目的を結び付けるラベルも保護してください。 [1] [13] [14]

以下は設定と復元のための技術的な参考情報です。スクリプトは支出条件を定め、Output Descriptor はそのルールとアドレスの導出情報を記録します。HD Wallet は seed から鍵の木構造を作ります。seed は、それらの鍵を導出する出発点となる秘密データです。non-hardened 導出では xpub から新たな公開鍵を作れますが、hardened 導出には秘密鍵が必要です。Multisig は必要な署名の数をあらかじめ定めます。 アドレスのインポートで監視するのはそのスクリプトだけで、将来の受取・お釣りアドレスではありません。公開鍵から異なるスクリプト形式を扱えるのは、ソフトウェアが明示的に導出する場合だけです。アカウントの xpub は non-hardened の子孫を導出できますが、P2PKH、SegWit、Taproot、内部ブランチ、Multisig の署名しきい値は指定しません。補うのがディスクリプターです。署名機器の正しいアカウントから、ネットワークとスクリプト形式を確認して書き出してください。導出パス、つまり出発点の鍵からたどる手順を推測してはいけません。 [1] [4] [7]

HD ウォレットは通常、受取用の /0/* と change、つまりお釣り用の内部 /1/* を分けます。内部ブランチがないと、支出後に資金の一部が消えたように見えることがあります。range は導出するアドレスの範囲で、狭すぎると入金を見落とすことがあります。next_index は次に生成するアドレスを決めます。二つのプログラムで値が食い違うと、アドレスを再利用するおそれがあります。有効なディスクリプター、範囲、インデックスを合わせてください。受取アドレスは署名機器の画面で確認します。残高がもっともらしくても、マルウェアがアドレスを差し替える可能性があります。 [6] [9]

Bitcoin Core の importdescriptors は timestamp で再スキャンの開始点を指定します。now は過去の履歴を飛ばし、0 は Genesis Block からの探索を要求します。range の範囲と過去のブロックの入手可能性も重要です。active はそのディスクリプターで新しいアドレスを生成するかを定め、internal はお釣りなどウォレット内部の出力を示します。プルーニングしたノードは容量を節約するために古いブロックを削除しているので、必要な履歴がない場合があります。Rescan は既存の取引を見つけるだけです。最初に使った日付やブロック高を記録し、画面のゼロだけでなく、既知のアドレスや取引と復元結果を照合してください。 [9] [10]

BIP380 は出力スクリプトの集合を記述する言語です。例の wpkh([d34db33f/84h/0h/0h]xpub…/0/*)#checksum は、スクリプト形式、マスター鍵の指紋、由来のパス、アカウント公開鍵、ブランチ、可変インデックス、チェックサムを示します。そのままインポートできる有効なデータではありません。Taproot は BIP386 の tr() を使い、BIP389 は一つの記述で複数パスを扱います。チェックサムは転記ミスを検出しますが、作成者の身元は確認しません。xprv を含む記述には秘密鍵があり、観察用コーディネーターへ入れるべきではありません。 [4] [5] [6] [7]

BIP32 には重要な例外があります。親の xpub と、non-hardened の手順だけで導出した子孫の秘密鍵がそろうと、親の秘密鍵を計算できます。xpub だけでは足りず、この組み合わせが危険です。書き出したアカウントより上に hardened の段階があれば、攻撃がその境界を越えるのを防げます。観察用ウォレット、そのデータベース、付随する PSBT ファイルに xprv、seed、秘密鍵を入れてはいけません。 [1]

Multisig の観察には、署名しきい値、スクリプト形式、全共同署名者の xpub、鍵の由来と順序、両方のアドレスブランチが必要です。一つの xpub では不十分です。seed が無事でも、ディスクリプターを失うと復元は難しくなります。鍵順やスクリプトの包み方が違うと、別のアドレスになることがあるためです。全署名機器でルールと見本アドレスを確認し、チェックサム付きのディスクリプターか標準構成を保存してください。これは共同署名者間の関係も明かす情報です。 [4] [11]

秘密鍵とは分けて、両ブランチのディスクリプター、鍵の由来、ネットワーク、作成日やブロック高、範囲、インデックス、ラベル、Multisig のルールを保管します。BIP329 はラベルを運びますが、ディスクリプターや履歴の代わりにはなりません。別プロファイルやテストネットで公開構成をインポートし、履歴を再スキャンして、両ブランチの旧アドレスと期待する UTXO を照合してください。PSBT を作り、指定機器で署名し、配信前に結果を確認します。Watch-only は観察と準備を支援するもので、支出権限を与えるものではありません。 [3] [9] [12]