PSBT は、作成途中のビットコイン取引を、確認や署名を行うウォレットや機器の間で受け渡すための標準形式です。正式名称は Partially Signed Bitcoin Transaction、つまり部分的に署名された取引ですが、署名がまだ一つもないファイルも含まれます。運ぶのは取引案、補足情報、署名であり、秘密鍵ではありません。必要な情報がそろうと、ネットワークに送る通常の取引を取り出せます。デジタル署名は、秘密鍵を使って作る、検証可能な承認の証明です。秘密鍵は署名するための秘密のデータであり、署名しても鍵そのものは公開されません。
アンナはパベルに 60 000 sat、ビットコインの最小単位で6万単位を送りたいと考えています。ウォレットは、以前受け取ってまだ使っていない 100 000 sat の出力を一つ選びます。出力には、金額と、その資金を使うための条件が記録されています。この例では、パベルに 60 000 sat、アンナへのお釣りに 39 000 sat を割り当て、残りの 1 000 sat を手数料にします。この段階では、まだ支払いの指示案にすぎません。アプリはそれを PSBT にまとめ、機器に応じてケーブル、QRコード、メモリーカードなどでハードウェアウォレットに渡します。アンナは機器の画面で支払い内容を確認し、署名を承認します。戻ってくるのは署名であって、秘密鍵ではありません。支払いを準備する機器と、署名する権限を持つ機器を分けられるのです。 [1] [4]
拡張子が .psbt だからといって、安全な支払いとは限りません。作成したパソコンが侵害されているかもしれませんし、単に設定を間違えている場合もあります。アンナは、パベルから確実に受け取ったアドレスと送付先を照合し、金額、手数料の合計、お釣りが自分のウォレットに戻ることを確認します。ハードウェアウォレットでは、信頼できる機器の画面とメーカーの手順に従います。署名用ソフトウェアも、補足情報と、署名が何を確定させるのかを検証します。sighash という技術用語は、取引のどの部分を署名によって変更から守るかを表します。初心者が意味を理解せず、普段と異なるモードを承認すべきではありません。アドレスが違う、手数料を確認できないといった場合は、確認を飛ばさず取引案を見直します。 [1]
3本の鍵のうち2本の署名が必要な Multisig ウォレットなら、アンナが最初の署名を加え、パベルが自分の機器で2つ目を加えられます。復元用の単語を交換したり、同時にオンラインになったりする必要はありません。コーディネーター、つまり手順をまとめるアプリが、同じ支払いに関する情報を集めて署名を結合します。それでも、支払いが自分の意図どおりかは各署名者が確認します。コーディネーターが代わりに判断するわけではありません。BIP 174 では、案を作る役割を creator、情報を追加する役割を updater、署名する役割を signer、対応する版を結合する役割を combiner と呼びます。finalizer は入力の使用条件を満たす最終データを組み立て、extractor はネットワーク用の通常の取引を取り出します。一つのプログラムが複数の役割を担うのは普通です。これは仕事の名前であり、6人の参加者が必要という意味ではありません。 [1] [4]
PSBT から、どの資金を使う予定か、誰に支払うか、お釣りはいくらか、アドレス同士がどう結び付いているかが分かることがあります。さらに、別の公開鍵を導出し、ウォレットのアドレス規則と組み合わせてアドレスを生成するための公開情報である xpub や、ウォレット構造内の鍵の位置を示す導出パスが含まれる場合もあります。内容を読みたいだけでも、無関係なウェブサービスに送らないでください。署名済みの PSBT は、必要な情報がそろえば、別の人が承認済みの特定の取引を完成させて配信する手段にもなります。自分のコピーを削除しても署名は取り消せません。また、このファイルは Seed Phrase（鍵の復元に使うバックアップの単語列）や Multisig の完全な設定バックアップの代わりにはなりません。特定の支払いを進めるためのもので、ウォレット全体を復元するためのものではないからです。 [1] [4]
署名を加えただけでは、ネットワークはまだ支払いを知りません。最終的な取引を組み立てた後、誰かが配信する必要があります。ノードとは、ビットコインの取引やブロックを検証するソフトウェアを動かすコンピューターです。ノードはネットワークのルールと自らの取引受け入れ方針に照らして検証し、マイナーがその取引をブロックに入れる可能性があります。署名不足、すでに使用済みの入力、手数料不足はそれぞれ別の問題で、「完了」ボタンだけでは解決しません。実際に使う前に、アプリ、機器、ウォレットの種類の具体的な組み合わせを試しておきましょう。Bitcoin Core 29 の analyzepsbt は不足するデータや署名を示せます。finalizepsbt は完成した取引を生成できますが、送信はその後の手順です。完成に成功しても、ブロックでの承認を得たことにはなりません。 [4] [5] [6]
BIP 174 は、PSBT をキーと値の組で情報を記録するバイナリ形式として定義しています。ここでいうキーはフィールドの識別子であり、ビットコインの秘密鍵という意味ではありません。全体用のマップは取引全体を、入力用マップは使用する過去の出力を、出力用マップは新たに作る出力を記述します。取引案に加え、使用条件を表すスクリプト、鍵の由来、部分的な署名などを格納できます。データは .psbt ファイルに保存したり、バイナリを文字列に変換する Base64 で表現したりできます。Base64 は暗号化ではありません。PSBT はビットコインのルール上の新しい取引種別でもありません。ネットワークが受け取るのは完成した取引であり、作業用ファイル全体ではありません。 [1]
ネットワークから離れた機器でも、何への署名を求められているか把握する必要があります。UTXO は過去に作られ、まだ使われていない出力で、新しい入力がそれを参照します。Non-Witness UTXO は元の取引全体を運べるのに対し、Witness UTXO は対象の出力と、その金額および条件を運びます。必要な証拠は、入力の種類と署名用ソフトウェアのルールによって変わります。検証対象には、元の取引の識別子と対応する出力、スクリプト間の関係、許容される sighash などがあります。金額がないことを手数料ゼロと見なしたり、証拠不足を検証成功と扱ったりしてはいけません。推測で埋めず、信頼できる手順で必要なデータを補います。 [1]
PSBT のバージョンは形式の構造を示します。署名数や、ビットコイン取引そのもののバージョンではありません。PSBT v0 は未署名の取引を全体用フィールドに格納し、PSBT のバージョンが省略されている場合も v0 を意味します。BIP 370 の PSBT v2 はそのフィールドを除外し、取引の構築に必要な情報を個々のフィールドに分けます。これにより、許された変更範囲と既存の署名による制約に従って、入力や出力を追加できます。署名済みの支払いを自由に書き換えられるという意味ではありません。受け渡しの両側がそのバージョンを理解する必要があるので、「PSBT 対応」という説明だけでは互換性は判断できません。 [2]
BIP 371 は、署名、スクリプト、鍵の由来など、Taproot に必要な情報を追加します。これらのフィールドは PSBT v0 と PSBT v2 の両方で使えます。そのため、前者で Taproot を扱えるウォレットでも、後者には対応していない場合があります。逆に、v2 に対応していても、すべての Taproot の使い方を処理できるとは限りません。鍵の経路で署名する方法と、スクリプトの分岐を使う方法は、Taproot 出力の条件を満たす異なる手段です。利用者にとって大事なのは、自分の具体的な構成で、署名したい支払いを扱えるかどうかです。機能一覧の略語ではなく、文書と実際に試した手順で確かめます。 [3]
理解を深めるには、この項目とあわせて次もお読みください Multisig, Hardware Wallet, Cold Storage, Output Descriptor. 次の項目からも参照されています Multisig, Cold Storage, Hardware Wallet, Watch-only Wallet.