Original Author: Fu Shaoqing, SatoshiLab, Everything Island BTC Studio

1. Preparation Knowledge

Before fully understanding various cryptocurrency wallet addresses, we need some foundational knowledge. This mainly includes knowledge of asymmetric encryption's public and private keys, hash algorithms, common encoding knowledge, and the basic principles of address generation. Bitcoin wallet addresses are designed according to the BIP protocol, and most non-Bitcoin wallet addresses are also designed based on BIP-related protocols. While sorting out the knowledge points related to Bitcoin addresses, we will also introduce related types of wallet addresses.

1.1. Asymmetric Encryption Knowledge and Public/Private Keys

Asymmetric encryption is the cornerstone of modern cryptography, first proposed by Whitfield Diffie and Martin Hellman in 1976. Its core feature is the use of a pair of mathematically related keys: a public key and a private key. The main characteristic is that the encryption and decryption processes are completed by different keys: information encrypted with the public key can only be decrypted by the corresponding private key; conversely, information signed with the private key can be verified for authenticity by the corresponding public key. This perfectly solves the key distribution problem in symmetric encryption, enabling secure communication without the need to share secrets in advance.

In the current cryptocurrency field, the most commonly used asymmetric encryption algorithm is the Elliptic Curve Digital Signature Algorithm (ECDSA), particularly the secp256k1 curve used by currencies like Bitcoin, as it offers shorter keys and higher efficiency than traditional RSA algorithms at the same security strength. After Bitcoin's Taproot technology, the Schnorr digital signature algorithm has also begun to be used in the cryptocurrency field, which has more advantages compared to ECDSA.

The algorithm principles and functions of public and private keys (this article mainly describes them in the context of digital currencies)

In digital currencies, the private key is a randomly generated large random number and is the only proof of asset control. The public key is derived from the private key through one-way elliptic curve multiplication (i.e., it is easy to derive the public key from the private key, but almost impossible to reverse-engineer the private key from the public key). Wallet addresses are usually the hash value of the public key.

Their functions are as follows:

Private Key: Used to generate transaction signatures to prove that you have the right to spend the corresponding funds. It must be kept absolutely confidential.

Public Key: Used to verify the validity of transaction signatures, ensuring that the signature was indeed generated by the corresponding private key. At the same time, it is used to generate a public receiving address that can be safely shared with anyone.

In short, the private key is used for signing, the public key is used for verification and generating addresses, and the combination of the two ensures the security and reliability of asset ownership transfer.

In Bitcoin, public keys are divided into uncompressed public keys and compressed public keys. Uncompressed public keys start with 04 and are 65 bytes long. Compressed public keys start with 02 (even) or 03 (odd) and are 33 bytes long.

Examples are as follows:

public key (uncompressed): 04 b 4632 d 08485 ff 1 df 2 db 55 b 9 dafd 23347 d 1 c 47 a 457072 a 1 e 87 be 26896549 a 87378 ec 38 ff 91 d 43 e 8 c 2092 ebda 601780485263 da 089465619 e 0358 a 5 c 1 be 7 ac 91 f 4

public key (compressed):

02 b 4632 d 08485 ff 1 df 2 db 55 b 9 dafd 23347 d 1 c 47 a 457072 a 1 e 87 be 26896549 a 8737

Traditional uncompressed public key diagram

Compressed public key diagram

In the public/private key knowledge related to digital currencies, there is also a common term WIF (Wallet Import) Private Key, whose encoding format is illustrated as follows: Format

Specific data examples are as follows:

1.2. Common Hash Algorithms in Bitcoin

In addition to public/private key knowledge, it is also necessary to understand hash algorithms, also known as hashing algorithms.

A one-way hash function has one input and one output, where the input is called a message, and the output is called a hash value. A one-way hash function can compute a hash value based on the content of the message, and the hash value can be used to check the integrity of the message. Hash functions can output a fixed-length value from input data of any length.

1. We introduce commonly used SHA-256 and RIPEMD-160.

SHA-256 stands for Secure Hash Algorithm 256-bit, which can accept input data of any size and, through a series of complex mathematical calculations, generate a fixed length (256 bits, or 32 bytes) string that looks like a random jumble of characters. This string is usually represented by 64 hexadecimal digits (0-9, A-F).

For example, inputting "hello world" will yield the following after SHA-256 calculation:

b 94 d 27 b 9934 d 3 e 08 a 52 e 52 d 7 da 7 dabfac 484 efe 37 a 5380 ee 9088 f 7 ace 2 efcde 9

RIPEMD-160 stands for RACE Integrity Primitives Evaluation Message Digest-160 bit. It is a generator specifically designed to produce shorter digital fingerprints. Like SHA-256, it is also a one-way hash function. It takes input and produces a fixed length (160 bits, or 20 bytes) output, usually represented by 40 hexadecimal digits.

For example, inputting "hello world" will yield the following after RIPEMD-160 calculation:

d 7 d 56920283 f 17 ab 4 d 7 e 10 d 4 a 5 d 6 df 50 e 594 a 9 c 3

2. Common hash algorithms in Bitcoin include

HASH 256 (double SHA-256, most commonly used)

HASH 160 (SHA-256 + RIPEMD-160)

SHA-256 (single SHA-256)

HMAC-SHA 512 (HMAC with SHA-512)

3. Use Cases

(1) Bitcoin mining uses HASH 256, which is double, meaning the hash value in the block header is HASH 256. SHA-256

(2) Transaction identifier - TXID uses HASH 256.

(3) The Merkle root in transactions uses HASH 256.

(4) Public key hash uses HASH 160, which is a single SHA 256 + single RIPEMD-160.

(5) Extended keys use HMAC (SHA-512).

(6) Signed transactions use HASH 256.

1.3. Common Encoding Knowledge Base 64, Base 58, Bench 32

In Bitcoin wallet addresses, it is necessary to understand several encoding types, namely Base 64, Base 58, and Bench 32.

1. Base 64 Encoding (not used in Bitcoin, but introduced as an early common encoding)

Design Goal: To securely and reliably transmit binary data in media that only support text (such as email, HTML, XML), ensuring that data is not modified during transmission (since certain characters have special meanings in protocols, such as newline characters).

Principle:

• Divide every 3 bytes (24 bits) of binary data into 4 groups, each group containing 6 bits.

• Each 6-bit value (0-63) corresponds to a printable character. Since 2^6 = 64, there are 64 characters.

• If the input data is not a multiple of 3, it will be padded with the '=' character.

Character Set:

(64 characters total) A-Z, a-z, 0-9, +, /

Main Features:

• High encoding efficiency: Each character carries 6 bits of information, making it the most efficient of the three encodings.

• Strong universality: Widely used in MIME emails, data URLs (such as data:image/png;base64,…), and for storing encryption keys and certificates.

• Includes non-alphanumeric characters: Uses + and /, which may need to be escaped in command lines or URLs.

• No error-checking function: Standard Base 64 encoding does not provide error detection.

2. Base 58 Encoding

Design Goal: Optimized for human processing, avoiding visual ambiguity, and making it easier for users to manually input and verify. Mainly applied to Bitcoin's original address format.

Principle:

• Derived from Base 64 but removes easily confused characters.

• Treats the data as a large integer, then continuously divides by 58, mapping the remainder to the character set.

• Leading zero (0x00) bytes are encoded as the character '1'.

Character Set:

123456789 ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

(Removes 0 (zero), O (uppercase o), I (uppercase i), l (lowercase L), +, /, totaling 58 characters)

Main Features:

• User-friendly: The character set removes easily confused characters, greatly reducing transcription and input errors.

l Pure alphanumeric: The generated string is very "clean," containing no symbols, making it easy to copy and paste in any environment.

l Slightly lower efficiency: Each character carries about 5.857 bits of information, which is slightly less efficient than Base 64.

l Commonly combined with checksums: In Bitcoin, Base 58 Check is actually used, which adds a version prefix and a 4-byte checksum before encoding, effectively detecting input errors.

Applications: Bitcoin legacy addresses (P2PKH, starting with 1), Bitcoin private keys (WIF format), and addresses of other cryptocurrencies like Litecoin.

3. Bech 32 Encoding

Design goal: Designed for Bitcoin SegWit (Segregated Witness) addresses, it has stronger error detection and correction capabilities, is case insensitive, and supports efficient uppercase letter conversion.

The relevant BIP protocols are:

BIP-173 Base 32 address format for native v0-16 witness output

BIP-350 Bech 32m format for v1+ witness addresses

Bech 32m is the V1 version of Bech 32, with slight adjustments to the checksum algorithm.

Principle:

l Constructed based on BCH (Bose–Chaudhuri–Hocquenghem) codes, which are error-correcting codes capable of detecting and correcting multiple errors.

l Structure: HRP (Human-Readable Part, such as bc1) + Separator (1) + Data Part (Base 32 encoding) + Checksum.

l Uses an optimized 32-character subset.

Character set: (All letters are lowercase, but the encoding is case insensitive) qpzry9x8gf2tvdw0s3jn54khce6mua7l

Main features:

l Powerful error detection: Can detect the vast majority of error combinations and automatically correct a few errors. This is more advanced than Base 58 Check, which can only "detect" but not "correct."

l Case insensitive: Whether you input in uppercase or lowercase, the address is valid, providing a better user experience.

l Compact and efficient: The data part uses Base 32 (5 bits per character), making it more compact for SegWit data.

l Human-readable part (HRP): The address starts with bc1 (Bitcoin mainnet) or tb1 (Bitcoin testnet), clearly indicating the network type, reducing confusion.

l Higher cost: The computational complexity of encoding and decoding is higher than Base 58.

Applications: Bitcoin native SegWit addresses (P2WPKH, starting with bc1q…), Taproot addresses (P2TR, starting with bc1p…).

If readers need further detailed information, it is recommended to refer to the following website, which contains detailed Encode and Decode, checksum illustrations, and step explanations.

https://learnmeabitcoin.com/technical/keys/bech32/

Summary and How to Choose

General data transmission: Choose Base 64. It is a web standard, with ready-made libraries in almost all programming languages, and offers the highest efficiency.

User-facing identifiers (such as legacy systems): Choose Base 58 Check. The strings it generates are easy to read and manually input, effectively preventing visual errors.

Modern cryptocurrency addresses (especially Bitcoin): Strongly recommend using Bech 32 (i.e., addresses starting with bc1). It provides the highest security and user experience, and transfer fees may also be lower (due to the principles of SegWit technology, where the witness field is calculated at a quarter of the original area). It is the direction of future development.

1.4. Basic Principles of Cryptocurrency Address Generation

Cryptocurrency addresses are generated based on the cryptographic mechanism of public and private keys, creating a pair of keys, and then deriving the public key into a cryptocurrency address through some algorithms and standards. A set of private keys and a corresponding set of public keys are often generated through certain mechanisms.

The generation of the private key can be referenced in the following illustration.

Once the private key is derived, the corresponding public key can be obtained. Then, the wallet address is calculated based on the algorithm. We demonstrate the process of generating the most common Bitcoin address as follows:

The demonstration diagram shows the principle diagram of the most common address algorithm generation. There are also some different types of Bitcoin addresses, which will have some differences in the principle diagram and will be explained in detail in the following section.

2. Protocols Related to Bitcoin Addresses

With the algorithms and encodings related to generating Bitcoin addresses, specific protocol standards are also needed, mainly derived from BIP protocols and SLIP protocols. The abbreviations and meanings of these two words are as follows:

BIP: Bitcoin Improvement Proposal

SLIP: SatoshiLabs Improvement Proposals

2.1. Three Core Protocols (BIP-32, 39, 44) and Related Protocols

1. BIP-32 (Hierarchical Deterministic Wallets) - Hierarchical Deterministic Wallets

Main function: To derive a massive number of key pairs (private keys and public keys) from a master seed. Previously, wallets were a collection of unrelated private keys, making backups extremely cumbersome. BIP-32 allows you to back up just one master seed (usually generated from BIP-39's mnemonic phrase) to recover all addresses and funds in the entire wallet tree structure. This greatly simplifies the backup and recovery process. BIP-32

The BIP-32 protocol defines specific public/private key derivation algorithms: Child Key Derivation (CKD) functions

Private parent key → private child key

Public parent key → public child key

Private parent key → public child key

Public parent key → private child key

The principle of BIP-32's hierarchical deterministic wallet is illustrated in the following diagram:

2. BIP-39 (Mnemonic code for generating deterministic keys) - Mnemonic Phrase

The main function of BIP-39: To convert the random master seed (a long string of 0s and 1s) from BIP-32 into a string of English words (usually 12 or 24 words) that are easy for humans to write, back up, and remember. The protocol also states that English sentences can be used (though there are few implementation cases). This is the mnemonic phrase you see when creating a wallet now. It greatly improves user experience and backup reliability.

https://github.com/Roasbeef/bips/blob/bip-tap/bip-0039/bip-0039-wordlists.md

BIP provides the following mnemonic wordlists in several languages: English, Japanese, Korean, Spanish, Chinese (Simplified), Chinese (Traditional), French, Italian, Czech, Portuguese

3. BIP-44 (Multi-Account Hierarchy for Deterministic Wallets) - Multi-Currency and Multi-Account Hierarchy

BIP 44 defines the logical hierarchy of deterministic wallets based on the algorithms described in BIP-32 and the purpose scheme described in BIP-43. It establishes a standardized structure for the key tree of BIP-32. It specifies a clear path format, such as: m/purpose'/cointype'/account'/change/addressindex. This standard allows the same HD wallet seed to manage multiple different cryptocurrencies (such as Bitcoin, Litecoin, Ethereum) and manage multiple accounts under each currency, distinguishing between receiving addresses and change addresses for each account. It ensures compatibility between different wallet providers. It allows for handling multiple tokens, multiple accounts, external and internal chains for each account, and millions of addresses for each chain.

Standard format: m/purpose'/cointype'/account'/change/addressindex

m: Master key

purpose': Fixed at 44', indicating compliance with BIP 44 standard (hardened derivation).

coin_type': Currency type, for example, Bitcoin is 0', Ethereum is 60' (hardened derivation).

change: Change chain. 0 is used for the external chain (Receiving address), and 1 is used for the internal chain (Change address).

address_index: Address index, generated sequentially starting from 0.

Example: The path for the first receiving address of the first Bitcoin account is: m/44'/0'/0'/0/0

The single quote ' indicates hardened derivation.

4. BIP-43 (Purpose Field for Deterministic Wallets)

Because the standalone BIP-32 protocol provides too much freedom to implementers, this protocol specifically describes the purpose field. This protocol encourages different schemes to apply for separate BIP numbers and use the same purpose field, preventing addresses from being generated from overlapping BIP 32 space.

In section 4.2, we will see the purpose fields defined by different BIPs.

Purpose codes 10001-19999 are reserved for SLIP protocols.

5. SLIP-0044 (Registered coin types for BIP-0044)

This protocol defines the types of cointype. The common cryptocurrency types in SLIP-0044 show the current mainstream cointype types, numbering in the thousands. Detailed information can be found at the link:

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

2.2. Address Format Protocols and Evolution Protocols

1. BIP-11 (M-of-N Standard Transactions)

This protocol provides a standard transaction type for M/N signatures, primarily to offer a more secure way to manage Bitcoin assets.

We can see examples of its instruction types in section 3.3.

The locking script: m {pubkey}…{pubkey} n OP_CHECKMULTISIG

The unlocking script: OP_0 …signatures…

However, this protocol only defines one standard transaction and does not define specific address types. Later, this multi-signature script was standardized as the P2SH address type.

2. BIP-13 (Address Format for pay-to-script-hash) - P2SH Address

The main function of BIP-13: To define the address standard starting with the number 3. This address does not directly correspond to a public key but corresponds to a hash value of a script. It is most commonly used for:

Multi-signature wallets (requiring multiple signatures to spend funds).

Compatibility with Segregated Witness.

Significance: Hashing complex script conditions into a short address simplifies the user experience and opens the door to complex smart contracts.

The specific definition of the address format:

base 58-encode: [one-byte version][20-byte hash][4-byte checksum]

3. BIP-16 (Pay to Script Hash)

This protocol defines the functionality of paying to a script hash. BIP-13 defines the address for paying to a script hash. The script defined by BIP-16 is as follows:

Locking script: OPHASH 160 [20-byte-hash-value] OPEQUAL

Unlocking script: …signatures… {serialized script}

Specific examples can be found in section 3.4.

4. BIP-49 (Derivation scheme for P2WPKH-nested-in-P2SH based accounts)

When using P2WPKH nested in P2SH (BIP 141) transactions, a universal derivation scheme is required. It allows users to seamlessly use different HD wallets with the same master seed and/or single account. Therefore, users need to create dedicated Segregated Witness accounts to ensure that only wallets compatible with this BIP can detect and properly handle the account.

To derive the public key from the root account, this BIP uses the same account structure defined in BIP 44, but uses a different purpose value to indicate different transaction serialization methods.

m / purpose' / cointype' / account' / change / addressindex

For the purpose path level, it uses "49". The usage of the remaining levels follows the definitions in BIP 44.

To derive the P2SH address from the public key calculated above, the encapsulation defined in BIP 141 is used:

witness: \u0026lt;signature\u0026gt; \u0026lt;pubkey\u0026gt;

scriptSig: \u0026lt;0\u0026lt;20-byte-key-hash\u0026gt;\u0026gt;

(0 x 160014{20-byte-key-hash})

scriptPubKey: HASH 160 \u0026lt;20-byte-script-hash\u0026gt; EQUAL

(0 xA 914{20-byte-script-hash}87)

5. BIP-84 (Derivation scheme for P2WPKH based accounts)

When using P2WPKH transactions, a universal derivation scheme must be in place. It allows users to seamlessly use different HD wallets with the same master seed and/or single account. Therefore, users need to create dedicated Segregated Witness accounts to ensure that only wallets compatible with this BIP can detect and properly handle the account.

To derive the public key from the root account, this BIP uses the same account structure defined in BIP 44 and BIP 49, but uses a different purpose value to indicate different transaction serialization methods.

m / purpose' / cointype' / account' / change / addressindex

For the purpose level, it uses 84'. The remaining levels are used according to the definitions in BIP 44 or BIP 49.

To derive the P2WPKH address from the public key calculated above, the encapsulation defined in BIP 141 is used:

witness: \u0026lt;signature\u0026gt; \u0026lt;pubkey\u0026gt;

scriptSig: (empty)

scriptPubKey: 0\u0026lt;20-byte-key-hash\u0026gt;

(0 x 0014{20-byte-key-hash})

6. BIP-86 (Key Derivation for Single Key P2TR Outputs)

This protocol provides single key P2TR (BIP 341) outputs as Taproot internal keys. To derive the public key from the root account, this BIP uses the same account structure defined in BIP 44, 49, and 84, but with a different purpose value for the script type.

m / purpose' / cointype' / account' / change / addressindex

For the purpose path level, it uses 86'. The usage of the remaining levels follows the definitions in BIP 44, 49, and 84.

7. BIP-173 (Base 32 address format for native v0-16 witness outputs) - Native Segregated Witness Address (Bech32)

The main function of BIP-173: To define a brand new address format specifically designed for native Segregated Witness transactions, which are typically addresses starting with bc1q.

Advantages:

Lower transaction fees: Native Segregated Witness transactions have a smaller data size, resulting in cheaper fees.

Stronger error resistance: Using Bech32 encoding effectively prevents input errors (such as confusing the letter 'O' with the number '0') and detects errors.

Supports larger-scale upgrades: Paving the way for future upgrades (such as Taproot).

8. BIP-350 (Addresses for P2WPKH and P2WSH in Bech32m) - Taproot Addresses (Bech32m)

The main function of BIP-350: To make a small but critical adjustment to the Bech32 format of BIP-173, creating Bech32m encoding to support the new Taproot payment method (P2TR). This is the address starting with bc1p.

Why a new format is needed: To distinguish it from the previous native Segregated Witness (v0 version), as Taproot uses a new witness version (v1). Bech32m ensures that the checksum and validation rules between different versions do not conflict.

9. BIP-141 (Segregated Witness) - Segregated Witness Itself

The main function of BIP-141: Although BIP-141 itself is a core protocol, it introduces compatibility addresses (Nested P2SH), which are Segregated Witness transactions wrapped in traditional P2SH scripts. These addresses start with 3 and look similar to multi-signature addresses.

Purpose: To provide users with a way to enjoy the fee benefits of Segregated Witness in advance while the software and services in the ecosystem have not yet been upgraded to support native Bech32 addresses. It has now gradually been replaced by native Bech32 addresses.

3. Bitcoin Address Types and Locking Script Types

3.1. Pay to Public Key (P2PK)

P2PK (Pay To Public Key) is a payment to a public key. This is the earliest address format, which pays to a public key without any address computation. It is now rarely used.

For comparative learning, we summarize its principles and sample data in the document:

(1) Principle Diagram

(2) Sample Data

To create a spendable script for P2PK, the sample data is as follows:

Locking script in output

OPPUSHBYTES65

049464205950188 c 29 d 377 eebca 6535 e 0 f 3699 ce 4069 ecd 77 ffebfbd 0 bcf 95 e 3 c 134 cb 7 d 2742 d 800 a 12 df 41413 a 09 ef 87 a 80516353 a 2 f 0 a 280547 bb 5512 dc 03 da 8

OP_CHECKSIG

Unlocking script in input

OPPUSHBYTES72

3045022100 c 219 a 522 e 65 ca 8500 ebe 05 a 70 d 5 a 49 d 840 ccc 15 f 2 afa 4 ee 9 df 783 f 06 b 2 a 322310220489 a 46 c 37 feb 33 f 52 c 586 da 25 c 70113 b 8 eea 41216440 eb 84771 cb 67 a 67 fdb 68 c 01

You can view a more detailed demonstration link here:

https://learnmeabitcoin.com/explorer/tx/1db6251a9afce7025a2061a19e63c700dffc3bec368bd1883decfac353357a9d#output-1

In some browsers, payments to public keys are still displayed as the hash value of the public key, which is a Bitcoin address starting with 1.

This address format is a long address starting with 1, for example:

13 QECtNiFPXijbMZmcgaTom 3 pCXwHvDYTUWGtRxZN 7 fY 24 u 4 fG 5 iiqXaQz 3 TvuQydLrkz 9 L 4 YhcYn 3 khC 44 yQwaZme 6 uoXQ

Formation Process

public key (uncompressed) =

04283338 ffd 784 c 198147 f 99 aed 2 cc 16709 c 90 b 1522 e 3 b 3637 b 312 a 6 f 9130 e 0 eda 7081 e 373 a 96 d 36 be 319710 cd 5 c 134 aaffba 81 ff 08650 d 7 de 8 af 332 fe 4 d 8 cde 20

prefix + public key + checksum =

0004283338 ffd 784 c 198147 f 99 aed 2 cc 16709 c 90 b 1522 e 3 b 3637 b 312 a 6 f 9130 e 0 eda 7081 e 373 a 96 d 36 be 319710 cd 5 c 134 aaffba 81 ff 08650 d 7 de 8 af 332 fe 4 d 8 cde 2067 da 00 eb

base 58 address =

13 QECtNiFPXijbMZmcgaTom 3 pCXwHvDYTUWGtRxZN 7 fY 24 u 4 fG 5 iiqXaQz 3 TvuQydLrkz 9 L 4 YhcYn 3 khC 44 yQwaZme 6 uoXQ

3.2. Pay to Public Key Hash (P2PKH)

P2PKH (Pay To Public Key Hash) is a commonly used transaction method.

(1) Principle Diagram

(2) Sample Data

Locking script in output

OP_DUP

OP_HASH 160

OPPUSHBYTES20

55 ae 51684 c 43435 da 751 ac 8 d 2173 b 2652 eb 64105

OP_EQUALVERIFY

OP_CHECKSIG

Unlocking script in input

OPPUSHBYTES72

3045022100 c 233 c 3 a 8 a 510 e 03 ad 18 b 0 a 24694 ef 00 c 78101 bfd 5 ac 075 b 8 c 1037952 ce 26 e 91 e 02205 aa 5 f 8 f 88 f 29 bb 4 ad 5808 ebc 12 abfd 26 bd 791256 f 367 b 04 c 6 d 955 f 01 f 28 a 772401

OPPUSHBYTES33

03 f 0609 c 81 a 45 f 8 cab 67 fc 2 d 050 c 21 b 1 acd 3 d 37 c 7 acfd 54041 be 6601 ab 4 cef 4 f 31

Execution script diagram

You can view a more detailed demonstration link here:

https://learnmeabitcoin.com/explorer/tx/40e331b67c0fe7750bb3b1943b378bf702dce86124dc12fa5980f975db7ec930#input-0

P2PKH Address Formation Diagram

This address format starts with 1, for example: 1 JBSCVF 6 VM 6 QjFZyTnbpLjoCJTQEqVbepG

Formation Process

public key (uncompressed) =

04283338 ffd 784 c 198147 f 99 aed 2 cc 16709 c 90 b 1522 e 3 b 3637 b 312 a 6 f 9130 e 0 eda 7081 e 373 a 96 d 36 be 319710 cd 5 c 134 aaffba 81 ff 08650 d 7 de 8 af 332 fe 4 d 8 cde 20

hash 160(public key) = bc 73550 c 1612 ee 81155 d 29254217 cbd 60084 a 6 d 1

prefix + hash 160(public key) + checksum =

00 bc 73550 c 1612 ee 81155 d 29254217 cbd 60084 a 6 d 1691 c 58 b 9

base 58 address = 1 JBSCVF 6 VM 6 QjFZyTnbpLjoCJTQEqVbepG

Theoretically, an uncompressed 130-character public key, when hashed to a 40-character hash value using Hash 160, could potentially produce hash collisions, meaning there could be duplicate addresses (though the probability is very low). Isn't that scary? Why use the hash of the public key as the address? Further reading can be found here:

https://bitcoin.stackexchange.com/questions/3600/why-are-bitcoin-addresses-hashes-of-public-keys

3.3. Pay to Multisig (P2MS)

P2MS (Pay To Multisig) refers to payments to a multisignature. Relevant principle explanations need to refer to BIP 11: M-of-N Standard Transactions.

(1) Principle Diagram

For the above diagram, using a 2/3 multisig is illustrated as follows:

(2) Sample Data

Locking script in output

OP_2

OPPUSHBYTES65

04 d 81 fd 577272 bbe 73308 c 93009 eec 5 dc 9 fc 319 fc 1 ee 2 e 7066 e 17220 a 5 d 47 a 18314578 be 2 faea 34 b 9 f 1 f 8 ca 078 f 8621 acd 4 bc 22897 b 03 daa 422 b 9 bf 56646 b 342 a 2

OPPUSHBYTES65

04 ec 3 afff 0 b 2 b 66 e 8152 e 9018 fe 3 be 3 fc 92 b 30 bf 886 b 3487 a 525997 d 00 fd 9 da 2 d 012 dce 5 d 5275854 adc 3106572 a 5 d 1 e 12 d 4211 b 228429 f 5 a 7 b 2 f 7 ba 92 eb 0475 bb 1

OPPUSHBYTES65

04 b 49 b 496684 b 02855 bc 32 f 5 daefa 2 e 2 e 406 db 4418 f 3 b 86 bca 5195600951 c 7 d 918 cdbe 5 e 6 d 3736 ec 2 abf 2 dd 7610995 c 3086976 b 2 c 0 c 7 b 4 e 459 d 10 b 34 a 316 d 5 a 5 e 7

OP_3

OP_CHECKMULTISIG

Unlocking script in input

OP_0

OPPUSHBYTES72

3045022100 af 204 ef 91 b 8 dba 5884 df 50 f 87219 ccef 22014 c 21 dd 05 aa 44470 d 4 ed 800 b 7 f 6 e 40220428 fe 058684 db 1 bb 2 bfb 6061 bff 67048592 c 574 effc 217 f 0 d 150 daedcf 36787601

OPPUSHBYTES72

3045022100 e 8547 aa 2 c 2 a 2761 a 5 a 28806 d 3 ae 0 d 1 bbf 0 aeff 782 f 9081 dfea 67 b 86 cacb 321340220771 a 166929469 c 34959 daf 726 a 2 ac 0 c 253 f 9 aff 391 e 58 a 3 c 7 cb 46 d 8 b 7 e 0 fdc 4801

Execution script diagram

You can view a more detailed demonstration link here:

https://learnmeabitcoin.com/technical/script/p2ms/

P2MS (Pay to Multisig) does not actually have an address format. The most common way is to wrap the P2MS payment script in a P2SH or P2WSH script, so its address references the other two similar addresses. Compared to directly using P2MS, it has the following advantages:

Since P2MS does not have an address format, if you want to directly lock your Bitcoin, you need to construct and send the raw locking script yourself. Worse, this may prevent you from creating this transaction because most wallets only allow you to use addresses (not raw scripts) when making transactions. This situation creates a high barrier for ordinary users, as only professionals using specific tools or development tools can construct inputs that can spend this UTXO.

P2MS is limited to a maximum of 3 public keys. Since it includes all public keys, the locking script of P2MS becomes very large (resulting in high transaction fees), hence the limit of 3 (to prevent UTXO from storing too much data). However, using P2SH, you can use up to 15 public keys for multisignature locking.

Therefore, if users wish, they can still use P2MS, but using P2SH to achieve the same functionality is more convenient.

3.4. Pay to Script Hash (P2SH)

P2SH (Pay To Script Hash) allows payments to a script hash. Paying to a script hash greatly enhances the capabilities of Bitcoin transactions.

(1) Principle Diagram

(2) Sample Data

Locking script in output

OP_HASH 160

OPPUSHBYTES20

748284390 f 9 e 263 a 4 b 766 a 75 d 0633 c 50426 eb 875

OP_EQUAL

Unlocking script in input

OP_0

OPPUSHBYTES71

3044022100 d 0 ed 946330182916 da 16 a 6149 cd 313 a 4 b 1 a 7 b 41591 ee 52 fb 3 e 79 d 64 e 36139 d 66021 f 6 ccf 173040 ef 24 cb 45 c 4 db 3 e 9 c 771 c 938 a 1 ba 2 cf 8 d 2404416 f 70886 e 360 af 401

OPPUSHBYTES71

5121022 afc 20 bf 379 bc 96 a 2 f 4 e 9 e 63 ffceb 8652 b 2 b 6 a 097 f 63 fbee 6 ecec 2 a 49 a 48010 e 2103 a 767 c 7221 e 9 f 15 f 870 f 1 ad 9311 f 5 ab 937 d 79 fcaeee 15 bb 2 c 722 bca 515581 b 4 c 052 ae

Execution script diagram

You can view a more detailed demonstration link here:

https://learnmeabitcoin.com/technical/script/p2sh/

Address Principle

Encode the hash 160 of a public key or script to a legacy address.

This address format starts with 3 (with testnet starting with 2), for example:

3 Nfmmt 78 SUwQTZtr 4 p 9 qty 5 Wgaykt 6 PhoS

Formation Process:

Hash 160 encoding of the user's public key or script yields the result:

hash 160(public key or Script) = d 5 ed 76 bbb 243 d 456240014178 ba 5 fbb 37 ada 36 bc

base 58 address = prefix (05) + hash 160(public key or Script) + checksum (32 e 485 ca) = 3 MCAKgGRPTMjYP 3 cD 1 vTeD 7 aQZJPVECAC 1

Several obvious advantages of P2SH are:

• Easier to use complex unlocking scripts (also provides a basis for using MAST trees in subsequent Taproot);
• Cheaper transaction fees (actually shifts the cost to the spender, as the person spending the output needs to use more unlocking bytes);
• P2SH provides stronger privacy;
• Because the bytes in the output are reduced, the entire UTXO set is smaller. Since the size of a single UTXO is smaller, more UTXOs can fit in memory.

Note: In P2SH, the maximum length of the redeem script is 520 bytes. This means that if the P2SH script is P2MS, it can have a maximum of 15 public keys (compressed public keys are 33 bytes, and 15 compressed public keys are 33*15=495 bytes, which is less than the maximum value of 520 bytes).

3.5. Pay to Wrapped Witness Public Key Hash (P2SH-P2WPKH)

P2SH-P2WPKH wraps the payment to the witness public key hash P2WPKH in a P2SH payment to the script hash.

(1) Principle Diagram

(2) Sample Data

Locking script in output

OP_HASH 160

OPPUSHBYTES20

6 d 3 ed 4 cf 55 dc 6752 a 12 d 3091 d 436 ef 8 f 0 f 982 ff 8

OP_EQUAL

Unlocking script in input

OPPUSHBYTES22

001402 c 8147 af 586 cace 7589672191 bb 1 c 790 e 9 e 9 a 72

Execution script diagram

(3) The diagram below illustrates how this payment forms an address:

You can view a more detailed demonstration link here:

https://learnmeabitcoin.com/technical/script/p2sh-p2wpkh/

This address format starts with 3, for example: 3 Beer 3 irc 1 vgs 76 ENA 4 coqsEQpGZeM 5 CTd

3.6. Pay to Wrapped Witness Script Hash (P2SH-P2WSH)

P2SH-P2WSH (P2WSH wrapped in a P2SH) wraps the payment to the witness script hash PS into the payment to script hash P2SH.

(1) Principle Diagram

(2) Sample Data

Locking script in output

OP_HASH 160

OPPUSHBYTES20

257014 cec 2 f 75 c 19367 b 2 a 6 a 0 e 08 b 9 f 304108 e 3 b

OP_EQUAL

Unlocking script in input

OPPUSHBYTES34

0020973 cfd 44 e 60501 c 38320 ab 1105 fb 3 ee 3916 d 2952702 e 3 c 8 cb 4 cbb 7056 aa 6 b 47 f

Execution script diagram

(3) The diagram below illustrates how this payment forms an address:

You can view a more detailed demonstration link here:

https://learnmeabitcoin.com/technical/script/p2sh-p2wsh/

This address format starts with 3, for example: 3 NUPJunPTWu 5 ivNHoi 375 bsTiN 7 P 2 MpZC 2

3.7. Pay to Witness Public Key Hash (P2WPKH)

P2WPKH (Pay To Witness Public Key Hash) is used for payments to witness public key hashes. This is used for payments to segregated witness addresses.

(1) Principle Diagram

(2) Sample Data

Locking script in output

OP_0

OPPUSHBYTES20

841 b 80 d 2 cc 75 f 5345 c 482 af 96294 d 04 fdd 66 b 2 b 7

Unlocking script in input (Witness area data)

3044022042 e 5 e 3 ed 2 a 41214 ae 864634 b 6 fde 33 ca 2 ff 312 f 3 d 89 d 6 aa 3 e 14 c 026 d 50 d 8 ed 3202206 c 38 dcd 0432 a 0724490356 fbf 599 cdae 40 e 334 c 3667 a 9253 f 8 f 4 cc 57 cf 3 c 448001

03 f 465315805 ed 271 eb 972 e 43 d 84 d 2 a 9 e 19494 d 10151 d 9 f 6 adb 32 b 8534 bfd 764 ab

Execution script diagram

You can view a more detailed demonstration link here:

https://learnmeabitcoin.com/technical/script/p2wpkh/

Address formation diagram

Using the prefix OP0 to distinguish the first version of segregated witness (the later Taproot addresses use OP1 for distinction), followed by 20 bytes of public key hash, and finally using Bech32 address encoding format.

This address format starts with bc1q, for example:

bc1 qar 0 srrr 7 xfkvy 5 l 643 lydnw 9 re 59 gtzzwf 5 mdq

Note: P2WPKH only accepts compressed public keys.

3.8. Pay to Witness Script Hash (P2WSH)

P2WSH (Pay To Witness Script Hash) is used for payments to witness script hashes.

(1) Principle Diagram

(2) Sample Data

Locking script in output

OP_0

OPPUSHBYTES32

65 f 91 a 53 cb 7120057 db 3 d 378 bd 0 f 7 d 944167 d 43 a 7 dcbff 15 d 6 afc 4823 f 1 d 3 ed 3

Unlocking script in input

00

30440220415899 bbee 08 e 42376 d 06 e 8 f 86 c 92 b 4987613 c 2816352 fe 09 cd 1479 fd 639 f 18 c 02200 db 57 f 508 f 69 e 266 d 76 c 23891708158 bda 18690 c 165 a 41 b 0 aa 88303 b 97609 f 7801

304402203973 de 2303 e 8787767090 dd 25 c 8 a 4 dc 97 ce 1 aa 7 eb 4 c 0962 f 13952 ed 4 e 856 ff 8 e 02203 f 1 bb 425 def 789 eea 8 be 46407 d 10 b 3 c 8730407176 aef 4 dc 2 c 29865 eb 5 e 5542 bf 01

522103848 e 308569 b 644372 a 5 eb 26665 f 1 a 8 c 34 ca 393 c 130 b 376 db 2 fae 75 c 43500013 c 2103 cec 1 ee 615 c 17 e 06 d 4 f 4 b 0 a 08617 dffb 8 e 568936 bdff 18 fb 057832 a 58 ad 4 d 1 b 752103 eed 7 ae 80 c 34 d 70 f 5 ba 93 f 93965 f 69 f 3 c 691 da 0 f 4607 f 242 f 4 fd 6 c 7 a 48789233 e 53 ae

Execution script diagram

You can view a more detailed demonstration link here:

https://learnmeabitcoin.com/technical/script/p2wsh/

Address formation diagram

Using the prefix OP0 to distinguish the first version of segregated witness (the later Taproot addresses use OP1 for distinction), followed by 32 bytes of script hash, and finally using Bech32 address encoding format.

This address format starts with bc1q, for example:

bc1 qmc 7 d 40 nxddfklulxq 55 f 2 jhupauaystdlxnj 69 asztedz 8 uz 6 e 3 q 9 lj 223

3.9. Pay to Taproot Address (P2TR)

P2TR (Pay To Taproot) is a payment to a Taproot address. There are two scenarios for this type of payment: one is Key Path Spend, and the other is Script Path Spend, detailed below.

(1) Principle Diagram

(2) Sample Data 1 - Key Path Spend

Locking script in output

OP_1

OPPUSHBYTES32

0 f 0 c 8 db 753 acbd 17343 a 39 c 2 f 3 f 4 e 35 e 4 be 6 da 749 f 9 e 35137 ab 220 e 7 b 238 a 667

Unlocking script in input

b 693 a 0797 b 24 bae 12 ed 0516 a 2 f 5 ba 765618 dca 89 b 75 e 498 ba 5 b 745 b 71644362298 a 45 ca 39230 d 10 a 02 ee 6290 a 91 cebf 9839600 f 7 e 35158 a 447 ea 182 ea 0 e 022 ae 01

Key Path Spend execution script diagram

(3) Sample Data 2 - Script Path Spend

Locking script in output

OP_1

OPPUSHBYTES32

0 f 0 c 8 db 753 acbd 17343 a 39 c 2 f 3 f 4 e 35 e 4 be 6 da 749 f 9 e 35137 ab 220 e 7 b 238 a 667

Unlocking script in input

01769105 cbcbdcaaee 5 e 58 cd 201 ba 3152477 fda 31410 df 8 b 91 b 4 aee 2 c 4864 c 7700615 efb 425 e 002 f 146 a 39 ca 0 a 4 f 2924566762 d 9213 bd 33 f 825 fad 83977 fba 7 f 01

206 d 4 ddc 0 e 47 d 2 e 8 f 82 cbe 2 fc 2 d 0 d 749 e 7 bd 3338112 cecdc 76 d 8 f 831 ae 6620 dbe 0 ac

c 0924 c 163 b 385 af 7093440184 af 6 fd 6244936 d 1288 cbb 41 cc 3812286 d 3 f 83 a 3329

Execution script diagram

You can view a more detailed explanation link here: https://learnmeabitcoin.com/technical/script/p2tr/

Using the prefix OP1 to distinguish the second version of segregated witness (the previous SegWit addresses use OP0 for distinction), followed by 20 bytes of public key hash, and finally using Bech32 address encoding format.

This address format starts with bc1p, for example:

bc1 ppsxtf 9 y 28 tx 36 e 6 nlra 79 m 270 vuagzknt 97 w 6 ga 4 ah 5 g 7 ggxpu 8 s 6 z 8 ftw

4. Derivation Path Addresses and Privacy Protection in Bitcoin Transactions

4.1. Historical Changes in Bitcoin Transactions

The changes in Bitcoin addresses are also closely related to several historical changes in Bitcoin transactions, mainly due to the two changes brought about by segregated witness.

1. Transactions Defined in the White Paper (Simple Transaction Model)

The earliest and most basic Bitcoin transactions allowed for multiple inputs and up to two outputs. One output is for change to oneself, and the other output is for transferring to an external party. (Note: The difference between total inputs and total outputs is the transaction fee.)

The early address types were P2PK, P2PKH, P2MS, and P2SH.

2. Transactions in the First Version of Segregated Witness (SegWit)

Segregated Witness (SegWit) is a protocol upgrade for the Bitcoin blockchain network, proposed by developer Pieter Wuille in December 2015 as a core update to the Bitcoin Core client. It achieves scalability by separating transaction data from signature data. This scheme maintains compatibility with the traditional Bitcoin network and avoids hard forks.

Its core mechanism expands the block capacity limit from 1 megabyte to 4 megabytes (with actual scalability in statistics of about 2-2.1 megabytes) by storing digital signatures in an additional witness block, freeing up space on the main chain. This technology addresses the transaction malleability issue, improves the way transaction identifiers are generated to prevent double-spending attacks, and lays the foundation for second-layer protocols like the Lightning Network. As the mainstream client standard adopted by most companies in the industry, this upgrade of Bitcoin Core requires 95% of the network's hash power to support, but the actual support rate has long maintained at 32%-33.8%. Opposition focuses on technical utility disputes and the potential weakening of Bitcoin's decentralization due to third-party involvement. The protocol was activated on the Bitcoin mainnet on August 24, 2017.

The address types in this version include P2WPKH, P2WSH, P2SH-P2WPKH, and P2SH-P2WSH.

3. Transactions in the Second Version of Segregated Witness (Taproot)

The Taproot technology was proposed in January 2020 and officially came into effect in November 2021 as a soft fork. This upgrade consists of BIP 340, BIP 341, and BIP 342. BIP 340 introduces Schnorr signatures, which can verify multiple transactions simultaneously, replacing the Elliptic Curve Digital Signature Algorithm (ECDSA), further expanding network capacity and speeding up batch transaction processing, making it possible to deploy complex smart contracts; BIP 341 implements Merkleized Abstract Syntax Trees (MAST) to optimize transaction data storage on the blockchain; BIP 342 (Tapscript) expands Bitcoin's native scripting capabilities using Bitcoin's script encoding language.

The address type in Taproot is P2TR.

4.2. Commonly Known Derivation Path Definitions

First, we will understand the common derivation paths for Bitcoin, and then look at the common derivation paths for other chains.

1. Common Bitcoin Derivation Paths

The standard format for derivation paths defined in BIP: m / purpose' / cointype' / account' / change / addressindex

The most common derivation paths for Bitcoin, with their main differences in the purpose field, correspond to different address types.

(1) BIP 44 - Legacy (Original) Address (1…)

Path: m/44'/0'/0'/0/0

Purpose: The earliest HD wallet standard used to generate P2PKH addresses starting with 1.

Features:

Best compatibility, supported by all wallets and exchanges.

Highest transaction fees due to larger transaction data size.

Use case: Mainly used to recover funds from very old wallets or to recharge old platforms that do not support new address types.

(2) BIP 49 - Nested SegWit (Wrapped Segregated Witness) Address (3…)

Path: m/49'/0'/0'/0/0

Purpose: Used to generate P2SH-P2WPKH addresses starting with 3.

Features:

Achieved by wrapping SegWit addresses in a P2SH script.

Lower fees than Legacy, but higher than Native SegWit.

Good compatibility, almost all wallets and exchanges support sending and receiving to addresses starting with 3.

Use case: A compatible solution during the early promotion of SegWit, still widely supported today.

(3) BIP 84 - Native SegWit (Native Segregated Witness) Address (bc1q…)

Path: m/84'/0'/0'/0/0

Purpose: Used to generate P2WPKH addresses starting with bc1q.

Features:

Lowest fees due to the smallest transaction data size, making it the most efficient format.

Best security, fully benefiting from the technical advantages of Segregated Witness.

Compatibility: Currently, the vast majority of modern wallets, nodes, and exchanges support it. However, some very old systems may not recognize it.

Use case: The current preferred and recommended standard for saving on fees and enjoying the latest technical features.

(4) BIP 86 - Taproot (P2TR) Address (bc1p…)

Path: m/86'/0'/0'/0/0

Purpose: Used to generate P2TR addresses starting with bc1p. This is the latest major upgrade for Bitcoin.

Features:

Better privacy, making simple payments and complex script transactions appear almost indistinguishable on-chain.

Higher efficiency, providing better scalability and lower fees for complex smart contracts (such as Lightning Network, DLCs).

More efficient signature algorithm (Schnorr Signatures) supporting key aggregation.

Use case: Represents the future direction of Bitcoin development, suitable for users and applications seeking to use the latest technology, lower fees, and better privacy.

(5) Derivation paths used in RGB technology

According to the RGB-0044 protocol, which complies with the BIP-44 protocol standard and the definition of coin in the SLIP-44 protocol, the purpose is set to 84. The official RGB derivation path is as follows: m_type/84’

Additionally, the author found in the official RGB website that according to the description in LNPBP-46: LN derivations, the derivation path m/9735' is used, with specific related content as follows:

Note: Which standard to use requires further research into related applications and RGB protocol documents.

(6) Other Important Paths

BIP 32 Root Path: m/0' (or sometimes m/0). Some old implementations or non-standard wallets may directly use this path, but it is highly discouraged as it does not comply with the multi-currency multi-account standard.

Multisignature Wallet Path: For multisig wallets, each collaborator typically uses their own standard path (e.g., m/48'/0'/0'/2') to derive public keys for multisig. This is usually managed by wallet software coordinating the multisig (such as Electrum, Specter), and ordinary users do not need to handle it manually.

Testnet Path: Simply change the coin_type in the above paths from 0' to 1'. For example, the testnet Native SegWit path is: m/84'/1'/0'/0/0.

2. Below are some mainstream cryptocurrencies and their common derivation paths.

(1) Ethereum and EVM-Compatible Chains (BSC, Polygon, Avalanche C-Chain, etc.)

Ethereum and its many derivative chains share the same coin_type because they use the same cryptography (secp 256k1 curve) and address format.

Path: m/44'/60'/0'/0/0

coin_type: 60'

Address format: 0x…

Description: This is the default path used by the vast majority of wallets like MetaMask and Trust Wallet. All EVM-based chains (e.g., BSC m/44'/60'/0'/0/0, Polygon m/44'/60'/0'/0/0) use the same path and the same set of private keys. Your addresses on different chains will look identical, but they are independent accounts on different chains. When switching networks, wallet software distinguishes different chains through RPC nodes.

(2) Binance Coin (BNB) Beacon Chain

BNB has its own chain and address system, different from EVM chains.

Path: m/44'/714'/0'/0/0

coin_type: 714'

Address format: bnb1… (Bech32) or tbnb1… (testnet)

Description: Used for BNB assets on the Binance Chain.

(3) Polkadot

Path: m/44'/354'/0'/0/0

coin_type: 354'

Address format: Based on SS58 format, usually starting with 1.

(4) Solana

Path: m/44'/501'/0'/0'

coin_type: 501'

Description: Note that Solana's path uses hardened derivation 0' at the end, rather than the regular 0. This is its standard practice.

(5) Cardano

Cardano's derivation path is relatively special and complex, based on its own BIP 44-ADA scheme.

Path: m/1852'/1815'/0'/0/0

purpose: 1852' (specifically designed for Cardano)

coin_type: 1815' (the year ADA was born)

Address format: addr1… (Bech32)

Description: This is the standard path used by Daedalus and Yoroi wallets.

(6) Ripple (XRP)

Path: m/44'/144'/0'/0/0

coin_type: 144'

Address format: r… (Base58)

(7) Litecoin

Litecoin is similar to Bitcoin and has multiple address types.

Legacy (L…): m/44'/2'/0'/0/0

SegWit (M…): m/49'/2'/0'/0/0

Native SegWit (ltc1q…): m/84'/2'/0'/0/0

coin_type: 2'

(8) Dogecoin

Path: m/44'/3'/0'/0/0

coin_type: 3'

Address format: D… (Base58)

(9) Tron

Path: m/44'/195'/0'/0/0

coin_type: 195'

Address format: T… (Base58)

3. Non-standard or Exceptional Cases

(1) Monero

Monero does not use BIP 32/BIP 44 standards. It has its own hierarchical deterministic wallet scheme, using different cryptography (Ed25519 curve) and key structure.

Its derivation path looks like: m/44'/128'/0' (but this is not a standard BIP 32 path)

Important Note: You cannot use mnemonic phrases designed for Bitcoin/Ethereum to directly recover funds in a Monero wallet, and vice versa. To recover a Monero wallet, you must use Monero's own mnemonic phrases and system.

(2) Hardware Wallet "Ethereum Classic" Path

Some hardware wallets (like Ledger) have set up independent paths for Ethereum Classic (ETC) to distinguish it from Ethereum (ETH), even though their address formats are the same.

Ethereum (ETH): m/44'/60'/0'/0/0

Ethereum Classic (ETC): m/44'/61'/0'/0/0

4.3. Privacy Protection and Multi-Address Usage

Bitcoin has a relatively unique phenomenon called "change address variation," or in other words, any blockchain with a UTXO model can have this characteristic. To understand "change address variation," three key concepts need to be understood:

1. UTXO Model (Unspent Transaction Output)

This is the core ledger model of Bitcoin, different from the traditional account balance model.

Basic principle: The Bitcoin network does not record your "balance," but rather a series of unspent "checks" (i.e., UTXOs). These checks have varying denominations, and once spent, they are destroyed and create new checks.

Transaction process: When you make a payment, you must take one or more "checks" (inputs) from your wallet, and their total value must be greater than or equal to the amount you want to pay. The transaction will create two new "checks":

One for the payee: with a value equal to the payment amount.

One for yourself (change): The amount equals (total input - payment amount - transaction fee).

Key conclusion: Change is essentially a new output (UTXO) paid to yourself. It has no structural difference from the output you pay to others in the transaction.

Note: The term "check" is used here instead of "cash" (which is often pre-printed in fixed denominations) because the amount on a check is random, and each check can have a different amount, which better fits the scenario description of UTXOs in Bitcoin. Often, the terms check and cash are used interchangeably to express the same meaning.

2. Privacy Protection Design

Using fixed addresses severely compromises privacy.

Address reuse issue: If all UTXOs (including change) return to the same address, blockchain analysis firms or individuals can easily:

• Associate all your transactions: Knowing all the fund flows behind this address.
• Estimate your wealth: Clearly seeing your total income.
• Destroy anonymity sets: Unable to mix others' transactions with yours.

Solution: Use a brand new address for the change of each transaction. This makes it difficult for external observers to determine which output in a transaction is the payment to the merchant and which output is the change returned to yourself. This greatly increases the difficulty of blockchain analysis and protects your financial privacy.

3. Technical Implementation of HD Wallets (Hierarchical Deterministic Wallets)

Manually managing new addresses and private keys for each change is impractical; HD wallets automate this process.

Chain structure: An HD wallet can generate nearly unlimited addresses and private keys from a single seed (mnemonic phrase).

Derivation paths: As discussed earlier, the standard path m/44'/0'/0'/1/* is specifically used for change (change = 1).

• m/44'/0'/0'/0/*: Used to generate receiving addresses (external chain).
• m/44'/0'/0'/1/*: Used to generate change addresses (internal chain).

Workflow:

When your wallet software constructs a transaction that requires change, it automatically takes from the internal "change address pool" (/1/*) as the change receiving address. The next unused address

Once this transaction is broadcast and confirmed, the new change UTXO is stored under this new address.

When you spend funds next time, your wallet will scan all UTXOs under both the receiving chain and the change chain, treating them as available "inputs." You do not need to manage this manually; the wallet handles everything automatically.

In summary: "Change address variation" is an inevitable result of the combination of the three. It is not optional but a standard behavior of Bitcoin wallets. UTXO model privacy protection requires HD wallet technology

Using a blockchain explorer: Find a real transaction (for example, one from your own wallet), and view its details on mempool.space or blockstream.info. Try to analyze its inputs and outputs, guessing which is the payment output and which is the change output (usually the change output points to a new address belonging to the sender).

Using a test wallet: Create a new wallet on the testnet, perform several send and receive operations, and then observe how the address list in your wallet changes, and how UTXOs are generated and consumed.

References

1. https://learnmeabitcoin.com/ - An excellent website for learning about Bitcoin addresses.

2. BIP 32: Hierarchical Deterministic Wallets, 2012-02-11, https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

3. BIP 39: Mnemonic code for generating deterministic keys, 2013-09-10, https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

4. BIP 44: Multi-Account Hierarchy for Deterministic Wallets, 2014-04-24, https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki

5. BIP 43: Purpose Field for Deterministic Wallets, 2014-04-24, https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki

6. SLIP-0044: Registered coin types for BIP-0044, 2014-07-09, https://github.com/satoshilabs/slips/blob/master/slip-0044.md

7. BIP 11: M-of-N Standard Transactions, 2011-10-18, https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki

8. BIP 13: Address Format for pay-to-script-hash, 2011-10-18, https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki

9. BIP 16: Pay to Script Hash, 2012-01-03, https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki

10. BIP 49: Derivation scheme for P2WPKH-nested-in-P2SH based accounts, 2016-05-19, https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki

11. BIP 84: Derivation scheme for P2WPKH based accounts, 2017-12-28, https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki

12. BIP 86: Key Derivation for Single Key P2TR Outputs, 2021-06-22, https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki

13. BIP 173: Base 32 address format for native v0-16 witness outputs, 2017-03-20, https://github.com/Roasbeef/bips/blob/bip-tap/bip-0173.mediawiki

14. BIP 350: Addresses for P2WPKH and P2WSH in Bech32m, 2020-12-16, https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki

15. BIP 141: Segregated Witness, 2020-12-16, https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。