ビットコインアドレスタイプの概要

By Anony, BTC Study

ビットコインに近づくとき、ユーザーはしばしば「アドレス」という概念に初めて遭遇する。ビットコインの支払いを受け取ろうとするとき、アドレスを提供する必要があります。ブロックブラウザで支払いが到着したかどうかを確認するとき、特定のアドレスはしばしば検索基準としても使用されます。

"アドレスはビットコインの世界では銀行口座に相当し、ビットコインを受け取るために使用できる "と思うかもしれません。しかし、ウォレットの使用中にいくつかの状況に直面したとき、この理解はまだあなたを混乱させるかもしれません。例えば、初めてビットコインソフトウェアウォレットを使用する際、アドレスの「タイプ」を選択するよう求められることがあります。P2PKH"、"Nested-SegWit (P2SH) "などのアドレスの "タイプ "を選択するよう求められることがあります。新しいソフトウェアウォレットは、元のソフトウェアウォレットとは全く異なるビットコインアドレスを提供するかもしれません。

この記事では、ビットコインアドレスとアドレスタイプの概念についてもう少し詳しく説明し、読者が自分自身でビットコインを保持する際に遭遇する可能性のある問題（アドレスタイプの選択や、あるソフトウェアウォレットから別のソフトウェアウォレットへの移行の手間など）を解決できるようにします。

最後のセクションは、読者が遭遇する可能性のあるさまざまなアドレスの特徴と経済性を説明することに焦点を当てています。技術的な詳細にまったく興味がない場合や、情報を素早くチェックしたい場合は、最後のセクションまで読み飛ばすことができます。

一言で言えば、ビットコインアドレスは、実際には、標準化されたビットコインのスクリプトで使用されるキーデータの特別なエンコード（音訳）の結果であり、特別なエンコード方法は、送信に適したものにし、エラーを警告する機能を提供します。経済性の違いは、基礎となるビットコインのスクリプトが経済性の違いを生むという事実から生まれる。

Standardised Bitcoin Script

ビットコインは、ピアツーピアネットワーク上で動作する電子通貨として知られています。ビットコインを開発する際、サトシ・ナカモトは "UTXO "として知られるようになった通貨の存在形態を考案しました。この形式は、ビットコインの資金を、口座に次から次へと保管されるお金ではなく、互いに分離された小切手に次ぐ小切手のようなものにしている。これらの "小切手 "には、2つの重要な情報が記録されている。お金の額面（satoshiで測定）とscriptPubkeyである。scriptPubkeyは、開けるために特定の鍵を必要とする錠前のようなものです。

サトシ・ナカモトは、巧妙な錠前をカスタマイズできれば、ビットコインをさまざまなシナリオでより柔軟に使えることに気づいた。したがって、スクリプトの公開鍵として使用されるプログラムを書くことができ、関連する資金が使用されたときに、そのようなプログラムに基づいて検証することができます。

この技術革新は現実的な困難をもたらします。トランザクションがピア・ツー・ピアのネットワークを通じて伝播するとき、トランザクションを受信したノードは最初にいくつかの検証作業を実行します。トランザクションがピアツーピアネットワークを伝搬する際、トランザクションを受け取ったノードは最初に何らかの検証作業を行う。もしこのプログラミング言語とプログラミングに固有の脆弱性があり、トランザクションの検証作業中にノードがクラッシュするようなことがあれば、この脆弱性を利用できるトランザクションはネットワーク全体を破壊するために使われる可能性がある。トランザクションの自由な伝播とネットワークのセキュリティのバランスをどのように取るのか？

ビットコインスクリプトの柔軟性を意図的に制限することに加え、サトシ・ナカモトはそのための方法を考え出しました。それは、失敗を引き起こさない程度に簡潔であることが知られているスクリプトを「標準化されたビットコインスクリプト」として定義することです；^[1]; このようなスクリプトを使用して資金を使う場合、取引は失敗する。このようなスクリプトを使用して資金を支出する場合、取引は「標準的なビットコイン取引」として扱われ、ネットワークを通じて支障なく伝播することができます。逆に、このような標準化されたスクリプトを使用しないと、取引が有効であっても、それを直接マイナーに提出することしかできず、マイナーはそれをブロックにパックし、ネットワーク全体に伝播する前に採掘する。これにより、セキュリティ上の問題がネットワークに伝播し、ノードのクラッシュを引き起こす可能性のあるトランザクションの数が制限される。

実装された初期の標準化されたビットコインスクリプトには、「P2PKH」と「P2PK」の2つがありました。公開鍵（または公開鍵のハッシュ）を置き、その公開鍵（の背後にある秘密鍵）に対する署名を提供するためにお金を使うトランザクションを要求するスクリプトです。

P2PKHスクリプトの公開鍵は次のようになります:

OP_DUP OP_HASH16055ae51684c43435da751ac8d2173b2652eb64105 OP_EQUALVERIFY OP_CHECKSIG

(From the famous Bitcoin science website: learn mea bitcoin)

The concept of an address

標準化されたスクリプトは、ビットコインシステムに基本的な機能を与えます（個人は、ビットコインを保持するための秘密鍵を保持し、ビットコインを保持するための秘密鍵を保持することで、他の誰かにメッセージを送信し、ビットコインを保持するための秘密鍵を保持することで、他の誰かにメッセージを送信することができます）。ビットコインを保持するために秘密鍵を保持し、ビットコインを保持するために秘密鍵を保持して誰かにメッセージを送信し、他の人に電子マネーの支払いを開始することができます）。しかし、ビットコインは依然としてコンピュータ用に設計されたデータであり、文字列の意味を理解するのはコンピュータである。コンピュータは文字列の長さに敏感ではないし、データのコピーでミスをすることもない。そして人間は、多くの点で正反対なのだ。

問題は、このシステムのユーザーである人間が、このデータを扱わなければならないということだ。人がビットコインの支払いを受けるとき、TAが求めているのは、TAが管理している（あるいはTAがうまくロックを解除できる）ビットコインのスクリプトの一部に、相手がビットコインの資金を送金することだけである。さらに、TAが資金を長期間保持したい場合、TAはビットコインスクリプトをバックアップしたいと思うかもしれません。

それではどうすればいいのでしょうか？上記のような長い文字列は、明らかに送信にもバックアップにも適していません（長すぎます）。

先に述べたように、ほとんどの人にとって便利なスクリプトは標準化されており、この標準化は、2つのスクリプトがそのキーデータの1つだけ異なることを意味します：2つのP2PKHスクリプトの場合、それらの唯一の違いは、それらが異なる公開鍵ハッシュを記録することです。したがって、支払いを受け取る際には、このハッシュとスクリプトの種類（P2PKHスクリプトであること）を提供するだけで十分である。支払者（ソフトウェア）は、この情報に基づいて完全なビットコインスクリプトを復元し、トランザクションの正しい場所にビットコインを送ります。

また、（エンジニアリングに精通したサトシ・ナカモトが気づいたように）このハッシュの16進数形式（55ae51684c43435da751ac8d2173b2652eb64105、40ビット文字）を省くこともできました。特別に設計されたエンコード方法の助けを借りて、より短く、より簡単に、正しく認識できる形に変換することができます。

これが「アドレス」です。エンコードされたデータで、ビットコインスクリプトを正しく復元するための重要な情報を含んでいます。

エンコード方法

Base58

"Base58"  これは、サトシ・ナカモトによって発明された符号化方式で、「Base64」と呼ばれるよく知られた符号化方式を応用したものである。Base64の文字セットは、すべての数字、大文字と小文字、2つの記号（「+」と「/」）で構成される。"と"/"）で構成され、合計64文字である。サトシ・ナカモトは数字の0、大文字のIとO、小文字のl、記号を削除してBase58とした。

この削減は意図的なものだった。

なぜbase64ではなくbase58を使うのか？

• 0OIlが使われないのは、これらの文字が似ていて、ほとんど同じように見えるアカウントを作成するのに使えるからです。アカウントに使用することができるからです。

• 人々はアカウントに文字と数字以外の文字をなかなか受け入れません。

• 句読点がなければ、電子メールでは改行されないのが普通です。

• 文字と数字しかないので、ダブルクリックすると文字列全体が選択されます。blockquote>

  アドレスはビットコインスクリプトとして回収されることを意図しているため、資金がまったく別のビットコインスクリプト（おそらく完全にロック解除可能なもの！）に送られるのに、たった1文字のエラーが必要なだけです。または、そのような紛らわしい文字が許可されている場合、マルウェアはあなたのアドレスを、見た目は似ているが実際には攻撃者が管理しているものに無言で置き換えることができ、支払いを受け取る際に資金を失うことになります。

  したがって、サトシ・ナカモトの考慮は完全に正当化されます。

  Base58エンコーディングが実行される前に、鍵データ（上記のP2PKHスクリプトのハッシュなど）にもタイプコードをプレフィックスとして付け、プレフィックスを付けた鍵データに対する最初の2回の連続したSHA256演算の最初の4バイトをサフィックスとして付けます。

  • 接頭辞はデータの種類と目的を素早く示します。接頭辞があるため、Base58でエンコードされた結果では、同じ種類のデータは常に同じように始まります。このため、ビットコインアドレスの先頭を見ただけで、そのアドレスがどのようなものかがわかるのです。

  • 一方、サフィックスはチェックサムとして機能します。転記ミスのあるアドレスをソフトウェアに入力すると、ソフトウェアはエラーの可能性を警告します（転記ミスを指摘することはできませんが）。

  つまり、エンコードを開始する前に、文字列を構築します:

  タイプ コード + キー データ + SHA256(Key Data + Key Data)Key Data + SHA256(SHA256(Type Code + Key Data))[0:4] (ここで "+"は文字列のスプライシングを意味する)
  

  上記のP2PKHスクリプトを例にとると、まずキーにキーデータを与える必要がある。例えば、まず鍵データ(55ae51684c43435da751ac8d2173b2652eb64105)に接頭辞 00を追加し、最初の4バイト(16進数で最初の8文字)を取り出して2回連続してSHA256計算を実行する。次に、このデータに対して2回連続して SHA256計算を実行し、最初の4バイト（16進数で8文字、96ab3cb1）を取り出し、それらを接尾辞として使って 0055ae51684c43435da751ac8d2173b2652eb6410596ab3cb1を得る。最後に、18p3G8gQ3oKy4U9EqnWs7UZswdqAMhE3r8を得るためにBase58エンコーディングを実行します。

  この文字列は、ビットコインスクリプトで使用されるキー情報（公開キーハッシュ）を含み、どのように使用されるべきかを記述し（P2PKHスクリプトとして回収されるべきことを示すために 1 が先頭に付く）、転記エラーを検出する機能を備えていますが、それでもまだ34文字しかありません。それでも34文字しかないので、元のハッシュよりもさらに短いです。

  Bech32

  「Bech32」は、BIP 0173 [3]  BIP 0173 [4]を指し、1959年と1960年に3人の数学者によって発明された巡回誤り訂正符号化アルゴリズムである（BCHという名前は3人の数学者の名字に由来する）。(BCHという名前はこの3人の数学者の名字に由来する）。32」は、符号化方式の文字セットに含まれる文字が、数字「1」、文字「b」、「i」、「b」を除いた小文字のアルファベットと数字、合計32文字しかないことを意味する、i "と "o "である。

  BIPは、"Segregated Witness (SegWit) "のアップグレードを機に、"P2WPKH "と "P2WSH "の2つの新しい標準化スクリプトを提供することを考えています。"P2WSH" のアドレスです。

  BIP0173の冒頭で、著者はBase58の望ましくない側面を指摘しています:

  • 。Base58は大文字と小文字の両方のアルファベットを使用するため、小さい「Numeric Alphabet」モードではQRコードとしてプロットできず、大きい「Byte Data」モードでのみプロットできます。

  • また、大文字と小文字を使用しているため、書き写したり、携帯電話のキーボードで入力したり、読み上げたりするのが容易ではありません。

  • チェックサムには2回連続のSHA256演算が必要で、時間がかかり、エラーを特定する機能もありません。

  • エラーを特定できるエンコーディング方法のほとんどは、文字セットのサイズが素数の累乗である場合にのみ機能し、58は素数の累乗ではありません。

  • Base58のデコードはより複雑で遅くなります。

  そのため、この新しいアプローチであるBech32は、小文字の文字と数字のみを使用します。必要なとき（たとえば、QRコードを描くとき）には、これらをすべて大文字に切り替えて、よりコンパクトに表示することができます。同時に、Bech32は間違いを見つける能力も持っています：書き写し間違いを見つけることができるだけでなく、どの部分が間違って書き写されたかを指摘することもできます（これはBase58よりはるかに優れています）。

  実際、BCHアルゴリズムは「誤り訂正」でもあります：どのビットを間違ってコピーしたかを指摘するだけでなく、それがどの文字であるべきかについても指摘します。しかし、BIP 0173の作者たちは、その本質的な危険性を発見した。一方では、エラー訂正機能を強化することは、エラーを発見する能力を弱めることになる。他方では、ユーザーがソフトウェアのエラー訂正機能を信頼しすぎると、ソフトウェアは、ユーザーが入力した不正確なデータを「有効だが役に立たない」データに訂正してしまう危険性がある。-- BCHエンコードされたデータとしては有効だが、そこから復元されるビットコインスクリプトは、受取人、あるいは他の誰の管理下にもない可能性がある。これは極めて危険である。したがって、BIP 0173は、"ソフトウェアは、どのビットが誤って転写された可能性があるかをユーザーに警告する以外に、エラー訂正機能を実装すべきではない（訂正の提案を与える）"と警告しています。

  それ以外の点では、Bech32はBase58のエンコーディングに見られるパターンに従っています:

  • Bech32では、次のようになります。データは "data with meaning (hrp) "という段落で始まります。これはBase58の接頭辞と似ており、どのようなデータであるかを示すことができます。

  • hrpは32文字よりはるかに多くの文字を使うことができます。は、hrpとデコードされる実際のデータの間のセパレータとして使われます。

  • Bech32はビットコイン以外にも多くのプロジェクトで使用されています。登録されているhrpのリストです。これは興味深い（しかし興味深いだけですが） [5].

  • Bech32はまた、エンコードされたデータの最後の6文字を占めるチェックサムで設計されています。

  上記のケースとまったく同じ公開鍵ハッシュを使用すると仮定すると、そのP2WPKHスクリプトは次のようになります:0 55ae51684c43435da751ac8d2173b2652eb64105 (そう、オリジナルのP2PKHよりもシンプルで抽象的です); そしてそのBech32エンコードされたアドレスは:bc1q2kh9z6zvgdp4mf634jxzuajv5htvsg9ulykp8となり、42文字になります。

  Bech32m

  「Bech32m」は、BIP 0350 [6] エンコード方法を定義しています。

  最後の文字が "p "の場合、その文字の前にいくつ "q "を挿入または削除しても、チェックサムは得られません。"の前に "q "を挿入したり削除したりしても、チェックサムにはなりません。

  標準化されたビットコインスクリプトがこれ以上追加されなければ、これは簡単に解決できます。P2WPKHアドレスとP2WSHアドレスの両方が定義された長さを持っており、長さのチェックサムを追加することは問題ないでしょう。P2WPKH アドレスと P2WSH アドレスには定義された長さがあり、長さのチェックサムを追加することは問題ありません。しかし、今後新しい標準化スクリプトが追加され、そのアドレスの長さが変更される可能性があることを考えると、この問題を修正する必要があります。

  Bech32mは、Bech32チェックサムジェネレータのパラメータを変更することにより、これを修正します。

  現在、Bech32m は「Taproot」アップグレードで追加された「P2TR」スクリプトのアドレスのエンコードにのみ使用されています。将来的には、他の標準化されたスクリプトのアドレスのエンコードに使われるかもしれません。

  経済学

  アドレスが標準化されたビットコインスクリプトの特別な表現であり、アドレスの種類が実際に標準化されたビットコインスクリプトの種類に由来することを理解した後、異なる種類のアドレスが異なる経済学を持つことができるのはなぜでしょうか。異なるタイプのアドレスがなぜ異なる経済性を持つのか-そして、使用される時点で異なる手数料コストを持つ可能性があるのか-という疑問は解決される。これは、異なるビットコインスクリプトが異なる経済性を持つからです。

  ビットコインのブロックサイズは、ネットワークの分散化とセキュリティを維持するために制限されており、トランザクションを小さくするスクリプトは経済的に有利です。

  この点で、最大の変化は2017年に有効化されたSegregated Witness（SegWit）ソフトフォークによってもたらされた。Segregated Witnessは、「P2WPKH」と「P2WSH」という2つの新しい標準化されたスクリプトを導入し、同時に両者に対して全く新しいトランザクション検証モデルを設計しました：

  従来の（レガシー）ビットコインスクリプトでは、スクリプトの公開鍵によって定義された検証手順を通過するために使用されるデータ（デジタル署名など）は、トランザクション（scriptSignature フィールド）に配置されます。「[7]と呼ばれる問題が発生し、ビットコインスクリプトを使用したマルチパーティ参加型アプリケーションのプログラミングができなくなります。

  また、Segregated Witnessのトランザクション検証モデルは、このデータをトランザクションの外（witness フィールド）に置きます。バイト (vByte)"）が導入され、ウィットネスフィールドに置かれたデータはボリュームの測定で割り引かれます（これは、分離されたウィットネスを持つトランザクションを従来のトランザクションよりも経済的にするための意図的な設計です）。

  最終的な結果は、孤立証人タイプのスクリプトP2WPKHとP2WSHは、従来のスクリプトP2PKHとP2SHよりも大幅に経済的であるということです：一方では、孤立証人スクリプトのスクリプト公開鍵はより簡潔であり、他方では、従来のスクリプトの署名はトランザクション内に配置されますが、孤立証人スクリプトの署名はトランザクション外に配置されます。一方、従来のスクリプトの署名はトランザクション内に配置されるが、分離された証人のスクリプトの署名はトランザクション外に配置され、データサイズが同じであっても、後者のvByteは小さくなる。

  異なるタイプのスクリプトがトランザクションの入力と出力としてどれだけの容量を占めるかを示す表があります。

  

  - Image from:Optech limited weekly - awinging confirmationOptech limited weekly - awinging confirmation -

  それから、ここには取引量計算機もあり、ある種のスクリプトの異なる量がどれだけの量を引き起こすかを知ることができます。

  注意：経済を考える場合、スクリプトを入力として使用した場合の量だけを比較することはできません。があるためである。）おつり出力は通常、このウォレットのペイアウトアドレスと同じタイプのスクリプトを使用します。

  Types of Addresses

  このセクションでは、ユーザーが遭遇する可能性のある様々なタイプのアドレスの特徴と経済性について説明します。

  P2PKH

  • Base58エンコーディング方式を使う。数字 "1 "で始まり、通常34文字です。

  • シングル署名のウォレットに使用されます。

  • 経済的ではありません。

  • 例（上記と同じ）:18p3G8gQ3oKy4U9EqnWs7UZswdqAMhE3r8

  P2SH

• Base58エンコーディング方式を使用。数字 "3 "で始まり、通常34文字です。

• ユーザーが最もよく目にするP2SHアドレスは、実際には「Nested SegWit (P2SH)」として知られるスクリプトのアドレスです。これは「Segregated Witnessスクリプトをカプセル化したP2SHスクリプト」という意味です。

• このカプセル化を達成する能力はP2SH自身の偉業ですが、このカプセル化の根本的な定義は、ウォレットソフトウェアの互換性に対処することでした。は、ウォレットソフトウェアの互換性の問題に対処するためのものです。Segregated Witnessアドレスは全く新しいエンコード方式を使用しているため、新しい方式を実装していないウォレットソフトウェアはSegregated Witnessアドレスをミスエントリーとして認識し、そこから有効なビットコインスクリプトを復元することができません。 Nested SegWit P2SHスクリプトは適切な妥協策を提供します。支払者のウォレットは（アップグレードの有無に関わらず）そのようなアドレスを通常のP2SHアドレスとして解釈し、そして次のようになります。受信者のその後の資金の使用は、（それをサポートするウォレットソフトウェアのおかげで）分離された証人の利点の一部を取得します。

• 同じ単一署名ウォレットでP2PKHよりも経済的です。

• マルチシグネチャウォレット（Segregated Witness機能の有無にかかわらず）で使用できます。

• 例:38Y2PBD1mihxtoVncaSz3oC2vRrjNF8sA2 (このP2SHスクリプトは、上記のスクリプトと同じP2PKHスクリプトをカプセル化していますが、何の役にも立ちません)

• 例:

• マルチシグネチャウォレット(分離された証人の有無にかかわらず)で使用できます。

P2WPKH

• ネイティブ検疫証人スクリプト。Bech32エンコードを使用し、数字と文字 "bc1q "で始まり、長さは42文字です。

• シングル署名ウォレットの場合。

• P2PKHよりも著しく経済的で、Nested SegWit P2SHよりも優れています。

• 例（上記と同じ）：次のようになります。bc1q2kh9z6zvgdp4mf634jxjzuajv5htvsg9ulykp8

P2WSH

• ネイティブの検疫立会スクリプト。Bech32エンコーディング方式を使用し、数字と文字 "bc1q "で始まり、長さは62文字です。

• マルチシグネチャウォレットでよく使われます。

• マルチシグネチャウォレットとして使用される場合、経済性はP2SHよりもかなり優れています。

• 例： (このP2WSHスクリプトは上記と同じP2PKHスクリプトをカプセル化したものですが、これはほとんど有益ではありません)

P2TR

• ネイティブのSegregated Witnessスクリプト（Taprootは "Segregated Witness v1"）です。Bech32mエンコーディング方式を使用し、"bc1p "で始まり、長さは62文字です。

• シングル署名とマルチ署名の両方のウォレットに使用できます。

• シングル署名のウォレットとして使用される場合、経済性はP2WPKHよりわずかに優れていますが、ほとんど差はありません（これは、トランザクション固有のオーバーヘッドとして入力とゼロ化された出力があることを前提としています。）

• マルチシグネチャウォレットとして使用する場合、いくつかのシュナー署名集約アルゴリズムの助けを借りれば、経済性はP2WSHよりもさらに良くなります。しかし、この記事を書いている時点（2024年11月）では、ウォレットソフトウェアは相互作用が複雑なため、そのような集約アルゴリズムをほとんど実装していません。

• P2TRと以前の標準ビットコインスクリプトの大きな違いは、オリジナルのスクリプトはすべて、公開鍵ハッシュを使用するシングル署名ウォレットのユーザーを区別していたことです。前者は公開鍵ハッシュスクリプトを使用し、後者（マルチシグネチャデバイスやライトニングチャネルのような高度なデバイスを含む）は償還スクリプトハッシュスクリプトを使用します。P2TRは初めてこの2つを統一し、外見上の形からスクリプト/アドレスの使用について直接推測することを不可能にしました。その結果、P2TRは長期的にはより優れたプライバシーを持つことになる。

• 今のところ、すべてのウォレットがP2TRアドレスをサポートしているわけではありません（しかし、ほぼすべてのウォレットがP2WPKHとP2WSHをサポートしています）。ユーザーはより限られた選択肢と移行機能を持つことになります。加えて、P2TRベースのマルチシグネチャデバイスのサポートはさらに少なくなっています。

• 例 (ランダムに選択):bc1pxy5r3slcqc2nhc0r5698gmsqwruenj9c8pzmsy5cedp3649wyktstc6z3c

結論

アドレスは特定のビットコインスクリプトを表します。このようなビットコインスクリプトは標準化されており、アドレスの情報によってその全体を復元することができます。特殊なエンコード方法を使用することで、アドレスはよりコンパクトになり、転記ミスをチェックする機能があります。そして、異なるアドレスタイプの経済性は、その背後にある標準化されたビットコインスクリプトの経済性から生まれます。

Appendix A. Descriptors

「アドレスの概念」のセクションで、2つのシナリオがあることを述べました。

「住所の概念」では、ユーザーがコンパクトで信頼できるスクリプト記録を必要とする2つのシナリオがあることを述べました。

また、「エンコード方法」の項では、これらのエンコード方法の設計は、長期保管シナリオではなく、主に配送プロセスに基づいていることがわかります。では、保管シナリオにおいて、住所はどのように保存されるべきなのでしょうか？

幸いなことに、今日、（単一ではなく）一組のアドレスを表現する適切な方法があり、それは「出力（アドレス）記述子」です。

ビットコインが誕生し、アドレスの概念が出現して以来、技術も自律的な保管のセキュリティ慣行も大きく改善されました。いわゆる「階層的決定論的（Hierarchical Deterministic）（HD）ウォレット」と呼ばれるもので、そのアイデアは、決定論的ランダム化アルゴリズムに従って、多くの秘密鍵、ひいては多くのアドレスを導き出すために秘密資料の一部を使用することである。秘密鍵のバックアップの負担を最小限にすることができます。

ディスクリプタもこのコンセプトに基づいており、アドレスの種類と、そのアドレスの集合を生成する手順を平文で表し、さらにチェックサムを加えることで実現しています。例えば、

wpkh([8b47f816/84h/0h/0h]xpub6C8vwWQ[...])NgW2SnfL/<0;1>/*)#c38kz2nr

上の段落から、これはP2WPKHアドレスのセットを示し、このアドレスのセットで使用される公開鍵は、&...のフィンガープリントから導出されることがわかります。nbsp;8b47f816  マスター公開鍵は、 84h/0h/0h  BIP32 派生パスに従って  0  と  1  のフィンガープリントから導出される。code>1 の派生パスは、収集アドレスと変更アドレスを区別する。最後に、 c38kz2nr は転記ミスをチェックするためのチェックサムである。

このような文字列は、長期保存やウォレットの移行に最適です。

Footnotes

1. https://en.bitcoin.it/wiki/Script#Script_examples 

2. https://learnmeabitcoin.com/technical/keys/base58/ 

3. https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki

4．="text-align: left;">4. https://en.wikipedia.org/wiki/BCH_code 

5. https://github.com/satoshilabs/slips/blob/master/slip-0173.md 

6. https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki 

7.&。nbsp;https://www.btcstudy.org/2022/10/07/segregated-witness-benefits/#%E4%BF%AE%E5%A4%8D%E7%86%94%E8%9E%8D%E6%80%A7%E9%97%AE%E9%A2%98