ビットコインアドレス

Alice が Bob に支払うとします。Bob はウォレットで「受け取る」を開き、表示されたアドレスを確認して、文字列か QR コードで送ります。Alice は自分のウォレットに読み込み、送信前に受取人と金額を確認します。一文字ずつ意味を理解する必要はありません。アプリが処理するからです。ウォレットはアドレスから、後でそのお金を使うための条件を作ります。通常は、適切な秘密鍵による署名が必要になります。トランザクションでは、その条件を scriptPubKey というスクリプトとして記録します。記録されるのは金額とスクリプトで、普段見ているアドレス文字列そのものではありません。アドレスは支払い情報を伝える便利な表現であり、コインの入った箱ではないのです。 [1] [3]

長いアドレスは手入力せず、コピーするか QR コードを読み取りましょう。ただし、それで確認が終わるわけではありません。悪意あるソフトがクリップボード内のアドレスを差し替えることがあります。信頼できる経路で受取人から得た情報と、アドレス全体を照合してください。Hardware Wallet を使う場合は、その機器自身の画面でも確認します。先頭と末尾だけでは不十分です。不正なアドレスでも、その部分を似せられるからです。アドレスには入力ミスを見つけるチェックサムが含まれますが、正しい形式のアドレスが目的の相手のものかは判定できません。ウォレットが形式とネットワークに対応していることも必要です。少額のテスト送金は役立つことがありますが、次の送金時の照合に代わるものではありません。誤った宛先でも有効なアドレスへの支払いが承認されると、プロトコルに簡単な取り消し機能はありません。 [2] [7] [8] [18]

Bob が次に「受け取る」を開くと、別のアドレスが表示されることがあります。お金が消えたわけではありません。新しいアドレスはプライバシーを守る助けになります。公開された一つのアドレスを知る人は、そのアドレスへの支払いをブロックチェーンで追えますが、それだけでウォレットの全収入が分かるべきではありません。同じアドレスを使い続けると、その結び付けが簡単になります。ただし、新しいアドレスでも匿名性は保証されず、後のトランザクションから別の関連が分かる場合があります。支払いのために共有できる情報でも、むやみに公開するのは考えものです。また、一つのアドレスが一人を表すとは限りません。複数人の共同管理や、顧客に代わるサービスの管理もあります。 [1] [14]

ウォレットは鍵を管理し、使える支払いを探し、その合計を残高として表示します。残高は多くのアドレスから成り立っていてもかまいません。一般的な HD Wallet は共通の出発点から一連の鍵を生成するため、新しいアドレスは新しいウォレットを作ることではありません。支払い時には、使い切らなかった分を自分用の Change Address、つまりお釣り用アドレスに戻すこともあります。ただし、アドレスだけでは復元できません。バックアップには、必要な鍵とその使用条件を復元できる情報が必要です。多くのウォレットは Seed Phrase という復元用の単語列を使いますが、複雑な構成では追加情報が必要な場合があります。支払う相手がその単語や秘密鍵を必要とすることはありません。 [10] [14]

QR コードは情報を表す方法にすぎません。アドレスだけの場合も、bitcoin: で始まり、金額、受取人のラベル、メッセージを加えた支払い要求の場合もあります。この仕組みは BIP21 が記述し、BIP321 が拡張しています。承認前にはウォレットが実際に何を読み込んだか確認しましょう。Lightning Network の一回の支払い用の invoice や、新しい invoice を繰り返し取得できる offer は別の支払い手順を使い、Lightning Address はそのような支払い要求を取得しやすくします。一つの要求で複数の支払い方法を選べることもあります。同様に、メッセージへの電子署名だけで本人確認が済むわけではありません。BIP322 はスクリプトの条件を満たせることを示せますが、それだけで法的な身元や任意の請求書への同意を証明するものではありません。 [15] [16] [17]

Base58Check はバージョンバイトと payload と呼ぶデータを結合します。SHA256(SHA256(version || payload)) の先頭 4 バイトを付け加え、Base58 の文字集合で符号化します。mainnet では 0x00 が P2PKH、0x05 が P2SH を表すため、通常は 1 または 3 で始まります。テスト用ネットワークは別のバージョンを使います。文字集合からは紛らわしい 0、O、I、l が除かれています。この 32 ビットのチェックサムは多くの入力ミスを検出しますが、受取人の本人確認はできません。 [2] [3]

ネイティブ SegWit の表記は、mainnet の接頭辞 bc または testnet の tb、区切り文字 1、witness バージョン、5 ビット単位のデータを含み、末尾に 6 文字のチェックサムが付きます。BIP173 が Bech32 を導入しましたが、特定の挿入・削除に関する弱点が見つかったため、BIP350 はバージョン 0 に Bech32 を残し、バージョン 1–16 には Bech32m を指定しました。英字はすべて小文字でもすべて大文字でも構いませんが、混在はできません。符号化の上限は 90 文字です。有効な表記でも、別のネットワークや未対応のバージョンを指す場合があります。 [7] [8]

P2PKH と P2WPKH は公開鍵の 20 バイトの HASH160 を参照します。P2SH は redeemScript の HASH160、P2WSH は witnessScript の SHA256 を使います。つまり SegWit v0 は 20 バイトの P2WPKH と 32 バイトの P2WSH を認識します。BIP341 の P2TR は異なり、バージョン 1 のプログラムに、調整を加えた 32 バイトの x-only 出力鍵 Q が入ります。単なる受信用公開鍵のハッシュではありません。Q の生成には追加スクリプトの木のルートも組み込めます。これにより、鍵とその使用条件が暗号学的に結びつきます。そのため、アドレスだけからすべての使用方法は分かりません。 [6] [9]

初期のビットコイン出力は、公開鍵へ直接支払うものがよく使われました。P2PKH は公開鍵の開示を使用時まで遅らせました。BIP13 と BIP16 による P2SH は、複雑なスクリプトのハッシュを渡せるようにしました。BIP141 はバージョン付き witness プログラム、BIP173 は Bech32、BIP341 と BIP350 は Bech32m を使う Taproot 形式を加えました。見た目の違いは検証条件の違いでもあります。接頭辞を手で置き換えてアドレスを「変換」しないでください。別の出力や使用不能な出力を作ってしまう可能性があります。一部の非標準スクリプトや初期の pay-to-pubkey 出力には、通常の標準的なアドレスがありません。 [4] [5] [6] [7] [8] [9] [3]

BIP32 に従う HD Wallet は共通のルートから多数の鍵を導出します。パスは出力の種類を区別し、BIP44 は P2PKH に目的番号 44'、BIP84 は P2WPKH に 84'、BIP86 は単一鍵の P2TR に 86' を使います。その後に通貨の種類（coin type）、アカウント、受け取りまたはお釣りの分岐、アドレスのインデックスが続きます。Seed Phrase だけでは、すべてのパス、アカウント、Multisig の規則まで決まらない場合があります。Output Descriptor は鍵の由来やスクリプトの構成も保存します。復元の目的は実際の資金を見つけることであり、見覚えのあるアドレスを一つ再表示するだけではありません。 [10] [11] [12] [13] [14]

P2PKH と P2WPKH では、当初は通常、鍵のハッシュだけが見え、使用時に公開鍵が明らかになります。P2SH と P2WSH は使用した redeemScript または witnessScript を開示します。Taproot では調整後の公開鍵がすでに出力に含まれています。key path での使用は通常 Schnorr Signature を加え、script path での使用は選んだスクリプト、control block、Merkle パスを開示します。使わない分岐は隠したままにできます。したがって、どのアドレスも公開鍵を隠すという説明は正しくありません。 [6] [9]