Original author: Fu Shaoqing, SatoshiLab, Wanwudao BTC Studio
1. Prepare knowledge
Before fully understanding various digital currency wallet addresses, we need some basic knowledge. This primarily includes knowledge of public and private keys in asymmetric encryption, hashing algorithms, common encoding concepts, and the fundamental principles of address generation. Bitcoin wallet addresses are designed based on the BIP protocol, and most non-Bitcoin wallet addresses are also designed based on BIP-related protocols. While reviewing the relevant knowledge points about Bitcoin addresses, we will also provide an introduction to other types of wallet addresses.
1.1. Asymmetric encryption knowledge and public and private keys
Asymmetric encryption is a 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 that is published and a private key that is kept secret. A key feature is that encryption and decryption are performed using different keys: information encrypted with a public key can only be decrypted with the corresponding private key; conversely, information signed with a private key can be verified as authentic using the corresponding public key. This perfectly solves the key distribution problem in symmetric encryption, enabling secure communication without the need for pre-shared secrets.
In the current digital currency sector, the most commonly used asymmetric encryption algorithm is the Elliptic Curve Digital Signature Algorithm (ECDSA), particularly the secp 256k1 curve used in currencies like Bitcoin. This algorithm uses shorter keys and is more efficient than the traditional RSA algorithm, while maintaining the same level of security. Following Bitcoin's Taproot technology, the Schnorr digital signature algorithm has also begun to be used in the cryptocurrency sector. Compared to ECDSA, Schnorr offers several advantages.
The algorithm principles and functions of public and private keys (this article mainly describes the field of digital currency)
In digital currencies, the private key is a randomly generated, large number that serves as the sole proof of control over an asset. The public key is derived from the private key through one-way elliptic curve multiplication (i.e., it's easy to derive the public key from the private key, but nearly impossible to reverse the process). The wallet address is typically a hash of the public key.
Its functions are as follows:
Private key: Used to generate transaction signatures to prove your authority to spend the corresponding funds. Must be kept strictly confidential.
Public key: Used to verify the validity of transaction signatures, ensuring that the signatures were indeed generated by the corresponding private key. It is also used to generate public payment addresses that can be safely shared with anyone.
In short, the private key is used for signing, and the public key is used for verification and address generation. The combination of the two ensures the security and reliability of asset ownership transfer.
In Bitcoin, public keys are divided into uncompressed and compressed. Uncompressed public keys begin with 04 and are 65 bytes long. Compressed public keys begin with 02 (even numbers) or 03 (odd numbers) and are 33 bytes long.
An example is 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
Diagram of a traditional uncompressed public key
Schematic diagram of compressed public key
In the public and private key knowledge related to digital currency, there is also a common term WIF (Wallet Import) Private Key, and its encoding format is as follows:
The specific data samples are as follows:
1.2. Commonly used hashing algorithms in Bitcoin
In addition to public and private key knowledge, you also need to understand hash algorithms or hash algorithms.
A one-way hash function has one input, called a message, and one output, called a hash value. A one-way hash function calculates a hash value based on the message's contents, which can be used to check the message's integrity. Hash functions can convert information of any length into a fixed-length output value.
1. We introduce the commonly used SHA-256 and RIPEMD-160.
SHA-256 stands for Secure Hash Algorithm 256-bit. It accepts input data of any size and, through a series of complex mathematical calculations, generates a fixed-length (256-bit, or 32-byte) string that appears to be random gibberish. This string is typically represented by 64 hexadecimal digits (0-9, A-F).
For example, if you enter hello world, after SHA-256 calculation, you will get:
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 Raw Integrity Check Message Digest-160. It is a generator specifically designed to produce shorter digital fingerprints. Similar to SHA-256, it is a one-way hash function. It takes an input and produces a fixed-length output (160 bits, or 20 bytes), typically represented by 40 hexadecimal digits.
For example, if you input hello world, after RIPEMD-160 calculation, you will get:
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 hashing algorithms used in Bitcoin are
HASH 256 (double SHA-256 is most commonly used)
HASH 160 (SHA-256 + RIPEMD-160)
SHA-256 (Single SHA-256)
HMAC-SHA 512 (HMAC with SHA-512)
3. Usage Scenarios
(1) Bitcoin mining uses HASH 256, which is double, that is, the hash value in the block header is HASH 256. SHA-256
(2) Transaction ID - TXID uses HASH 256.
(3) The merkle root in the transaction uses HASH 256
(4) The public key hash uses HASH 160, which is a single SHA 256 + a single RIPE-160.
(5) The extended key uses HMAC (SHA-512)
(6) HASH 256 is used in signature transactions.
1.3. Common encoding knowledge Base 64, Base 58, Bench 32
There are several encodings that you need to know about in Bitcoin wallet addresses, namely Base 64, Base 58, and Bench 32.
1. Base 64 encoding (not used in Bitcoin, but as an early common encoding, it is introduced together)
Design goal: Safely and reliably transmit binary data in text-only media (such as email, HTML, XML), ensuring that the data is not modified during transmission (because some characters have special meanings in the protocol, such as newline characters).
principle:
l Divide each 3 bytes (24 bits) of binary data into 4 groups, each with 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 = characters.
Character Set:
(64 characters total)AZ, az, 0-9, +, /
Key Features:
l High coding efficiency: Each character carries 6 bits of information, which is the most efficient of the three coding methods.
l High versatility: Widely used in MIME emails, data URLs (such as data:image/png;base 64,... in web pages), and for storing encryption keys and certificates.
l Contain non-alphanumeric characters: Use + and /. These characters may need to be escaped in the command line or URL.
l No checksum function: Standard Base 64 encoding itself does not provide error detection function.
2. Base 58 encoding
Design goal: Optimize for manual processing, avoid visual ambiguity, and facilitate manual input and proofreading. Primarily used in Bitcoin's original address format.
principle:
l is derived from Base 64, but with confusing characters removed.
Treat the data as a large integer, then divide it by 58 continuously and map the remainder to a character set.
A leading zero (0 x 00) byte is encoded as the character '1'.
Character Set:
123456789 ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz
(Removed 0 (zero), O (uppercase o), I (uppercase i), l (lowercase L), +, /, a total of 58 characters)
Key Features:
l Humanization: The character set removes easily confused characters, greatly reducing transcription and input errors.
Pure alphanumeric: The generated string is very "clean" and does not contain any symbols, making it easy to copy and paste in any environment.
l Slightly less efficient: Each character carries approximately 5.857 bits of information, which is slightly less efficient than Base 64.
l Often combined with a checksum: The Base 58 Check is actually used in Bitcoin, which adds a version prefix and a 4-byte checksum before encoding, which can effectively detect input errors.
Applications: Bitcoin legacy addresses (P 2 PKH, starting with 1), Bitcoin private keys (WIF format), addresses of other cryptocurrencies such as Litecoin.
3. Bech 32 encoding
Design goal: Designed for Bitcoin SegWit (Segregated Witness) addresses, with stronger error detection and correction capabilities, and is case-insensitive and supports efficient uppercase letter conversion.
The relevant BIP protocols are:
BIP-173 Base 32 address format for native v 0-16 witness output
BIP-350 Bech 32 m format for v 1+ witness addresses
Bech 32 m is the V 1 version of Bech 32, with minor adjustments to the checksum algorithm.
principle:
l It is constructed based on BCH (Bose–Chaudhuri–Hocquenghem) code, which is an error-correcting code that can detect and correct multiple errors.
l The structure is: HRP (human readable part, such as bc 1) + separator (1) + data part (Base 32 encoding) + checksum.
l Use an optimized 32-character subset.
Character set: (all letters are lowercase, but the encoding is case-insensitive) qpzry 9 x 8 gf 2 tvdw 0 s 3 jn 54 khce 6 mua 7 l
Key Features:
Powerful error detection: It can detect the vast majority of error combinations and automatically correct the few that do. This is more advanced than Base 58 Checksum, which can only detect but not correct errors.
l Case insensitivity: The address is valid whether you enter it in uppercase or lowercase, which provides a better user experience.
l Compact and efficient: The data part uses Base 32 (5 bits per character), which is more compact for SegWit data.
Human Readable Portion (HRP): The bc 1 (Bitcoin mainnet) or tb 1 (Bitcoin testnet) at the beginning of the address clearly identifies the network type and is not easy to confuse.
Higher cost: The computational complexity of encoding and decoding is higher than Base 58.
Applications: Bitcoin native SegWit address (P 2 WPKH, starting with bc 1 q...), Taproot address (P 2 TR, starting with bc 1 p...).
If readers need to know more about the relevant content, it is recommended to refer to the following website, which contains detailed Encode and Decode, Checksum diagrams and step-by-step explanations.
https://learnmeabitcoin.com/technical/keys/bech 32/
Summary and How to Choose
For general data transmission, choose Base 64. It is a network standard, has ready-made libraries for almost all programming languages, and is the most efficient.
For user-facing identifiers (such as legacy systems): Select Base 58 Check. This generates strings that are easy to read and enter manually, and prevents visual errors.
For modern cryptocurrency addresses (especially Bitcoin), Bech 32 (i.e., addresses starting with bc 1) is strongly recommended. It provides the highest security and user experience, and may also lower transaction fees (due to the principles of SegWit technology, where the witness field is calculated as one-quarter of the original area). It is the future development direction.
1.4. Basic Principles of Digital Currency Address Generation
The address of a digital currency is created by generating a pair of public and private keys based on the cryptographic mechanism of public and private keys. Then, through certain algorithms and standards, the public key is derived into the digital currency address. Certain mechanisms are also often used to generate a set of private keys and a corresponding set of public keys.
The generation of the private key can refer to the following diagram.
After deriving the private key, we can obtain the public key corresponding to the private key. Then, we calculate the wallet address according to the algorithm. We will use the most common Bitcoin address generation process as an example below:
The demonstration diagram shows the most common address algorithm generation principle diagram. There are some different Bitcoin address types later. There will be some differences in the principle diagrams. Each address type will be explained in detail in the third section below.
2. Bitcoin address related protocols
With the algorithms and encodings related to generating Bitcoin addresses, some specific protocol standards are needed, which mainly come from the BIP protocol and the SLIP protocol. 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)
The main function of BIP-32 is to derive a large number of key pairs (private and public keys) from a single master seed. Before this, wallets were a collection of unrelated private keys, making backups extremely difficult. BIP-32 allows you to restore all addresses and funds in the entire wallet tree structure by backing up only one master seed (usually generated from a BIP-39 mnemonic). This greatly simplifies the backup and recovery process.
The BIP-32 protocol defines specific public and 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 shown in the figure below:
2. BIP-39 (Mnemonic code for generating deterministic keys)
The main purpose of BIP-39 is to convert the random number master seed in BIP-32 (a long string of 0s and 1s) into a string of English words (usually 12 or 24 words) that is easy for humans to write, back up, and remember. The protocol also states that English sentences can be used (although this is rarely implemented). This is the mnemonic phrase you see when creating a wallet. It greatly improves the user experience and the reliability of backups.
https://github.com/Roasbeef/bips/blob/bip-tap/bip-0039/bip-0039-wordlists.md
BIP officially provides mnemonic word libraries in the following 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 a logical hierarchy for deterministic wallets based on the algorithm described in BIP-32 and the purpose scheme described in BIP-43. It defines a standardized structure for the BIP-32 key tree. It specifies a clear path format, such as: m/purpose'/coin_type'/account'/change/address_index. This standard allows the same HD wallet seed to be used to manage multiple cryptocurrencies (such as Bitcoin, Litecoin, and Ethereum), with multiple accounts within each currency, each with distinct receiving and change addresses. It ensures compatibility across different wallet providers, allowing for the handling of multiple tokens, multiple accounts, external and internal chains within each account, and millions of addresses per chain.
Standard format: m/purpose'/coin_type'/account'/change/address_index
m: master key (master)
purpose': Fixed to 44', indicating compliance with the BIP 44 standard (enhanced derivation).
'coin_type': currency type, for example, Bitcoin is 0', Ethereum is 60' (enhanced derivative).
account': Account index, allowing users to create multiple accounts in one wallet (enhanced derivation).
change: Change chain. 0 is used for the External Chain (receiving address), 1 is used for the Internal Chain (change address).
address_index: address index, generated sequentially starting from 0.
Example: The path of the first receiving address of the first Bitcoin account is: m/44'/0'/0'/0/0
Single prime ' indicates a strengthened derivation
4. BIP-43 (Purpose Field for Deterministic Wallets) purpose field
Because the separate 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 so that addresses are not generated from overlapping BIP 32 spaces.
In Section 4.2 we will see the purpose field defined by different BIPs.
Usage codes 10001-19999 are reserved for the SLIP protocol.
5. SLIP-0044（Registered coin types for BIP-0044）
This protocol defines the coin_type type. Thousands of the current mainstream coin_type types can be seen in the common digital currency types of SLIP-0044. You can view the details in the link:
https://github.com/satoshilabs/slips/blob/master/slip-0044.md
2.2. Address Format Protocol and Evolution Protocol
1. BIP-11 (M-of-N Standard Transactions) M/N Standard Transactions
The protocol provides a standard transaction type with M/N signatures, primarily to provide a more secure way to use and manage Bitcoin assets.
We can see examples of its instruction types in Section 3.3.
The locking script is: m {pubkey}...{pubkey} n OP_CHECKMULTISIG
Unlocking script: OP_0 ...signatures...
However, the protocol only defines a standard transaction and does not define a specific address type. Later, this multi-signature script was standardized as a P2SH address type.
2. BIP-13 (Address Format for pay-to-script-hash) - P 2 SH address
The main purpose of BIP-13 is to define a standard for addresses starting with the number 3. This address does not directly correspond to a public key, but rather to the hash value of a script. It is most commonly used for:
Multi-signature wallets (require multiple signatures to spend funds).
Compatibility with SegWit.
Significance: Hashing complex script conditions into a short address simplifies the user experience and opens the door to complex smart contracts.
Specific definition of 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 payment to script hash function, while BIP-13 defines the payment to the address of the script hash. You can see the script defined by BIP-16 as follows:
Locking script: OP_HASH 160 [20-byte-hash-value] OP_EQUAL
Unlocking script: ...signatures... {serialized script}
You can see a specific example in Section 3.4.
4. BIP-49 (Derivation scheme for P2WPKH-nested-in-P2SH based accounts)
When using P2WPKH with nested P2SH (BIP 141) transactions, a universal derivation scheme is required. This allows users to seamlessly use different HD wallets with the same master seed and/or single account. Therefore, users need to create dedicated SegWit accounts to ensure that only wallets compatible with this BIP can detect the account and process it appropriately.
To derive the public key from the root account, this BIP uses the same account structure as defined in BIP 44, but only uses a different purpose value to indicate a different transaction serialization method.
m/purpose'/coin_type'/account'/change/address_index
For the purpose path level, it uses "49". The remaining levels are used as defined in BIP 44.
To derive the P2SH address from the public key calculated above, use the encapsulation defined in BIP 141:
witness: <signature> <pubkey>
scriptSig: <0<20-byte-key-hash>>
(0 x 160014{20-byte-key-hash})
scriptPubKey: HASH 160 <20-byte-script-hash> EQUAL
(0xA 914{20-byte-script-hash}87)
5. BIP-84 (Derivation scheme for P2 WPKH based accounts)
When using P2 WPKH transactions, a universal derivation scheme is necessary. This allows users to seamlessly use different HD wallets with the same master seed and/or individual accounts. Therefore, users will need to create dedicated SegWit accounts to ensure that only wallets compatible with this BIP can detect the accounts and process them appropriately.
To derive the public key from the root account, this BIP uses the same account structure as defined in BIP 44 and BIP 49, but only uses different destination values to indicate a different transaction serialization method.
m/purpose'/coin_type'/account'/change/address_index
For the purpose level, it uses 84'. The remaining levels are used as defined in BIP 44 or BIP 49.
To derive the P² WPKH address from the public key calculated above, use the encapsulation defined in BIP 141:
witness: <signature> <pubkey>
scriptSig: (empty)
scriptPubKey: 0<20-byte-key-hash>
(0x0014{20-byte-key-hash})
6. BIP-86 (Key Derivation for Single Key P 2 TR Outputs)
This protocol provides a single key P2TR (BIP 341) output as the Taproot internal key. To derive the public key from the root account, this BIP uses the same account structure as defined in BIPs 44, 49, and 84, but with a different script type destination value.
m/purpose'/coin_type'/account'/change/address_index
For the purpose path level, it uses 86'. The remaining levels are used as defined in BIPs 44, 49, and 84.
7. BIP-173 (Base 32 address format for native v 0-16 witness outputs)
The main function of BIP-173: defines a new address format designed for native Segregated Witness (Native SegWit) transactions, which is usually an address starting with bc 1 q.
Advantages:
Lower transaction fees: Native SegWit transactions have smaller data volumes, resulting in cheaper transaction fees.
Stronger error prevention: Using Bech 32 encoding can effectively prevent input errors (such as confusing uppercase and lowercase 'O' and the number '0') and detection errors.
Support for larger upgrades: Paves the way for future upgrades like Taproot.
8. BIP-350 (Addresses for P 2 WPKH and P 2 WSH in Bech 32 m) - Taproot Addresses (Bech 32 m)
The main effect of BIP-350: A small but crucial adjustment to the Bech 32 format of BIP-173 was made, creating Bech 32 m encoding to support the new Taproot payment method (P 2 TR). This is the address that starts with bc 1 p.
Why the new format is needed: To distinguish it from the previous native SegWit (v 0), as Taproot uses a new witness version (v 1). Bech 32m ensures that the checksum validation rules between different versions do not conflict.
9. BIP-141 (Segregated Witness) - Segregated Witness itself
The main purpose of BIP-141: While BIP-141 itself is a core protocol, it introduces compatibility addresses (Nested P2SH), which are SegWit transactions wrapped in traditional P2SH scripts. These addresses begin with 3 and look the same as multi-signature addresses.
Purpose: Provides a way for users to benefit from SegWit fee discounts in advance, while ecosystem software and services have not yet been upgraded to support native Bech 32 addresses. These addresses are now being gradually replaced by native Bech 32 addresses.
3. Bitcoin address types and locking script types
3.1. Pay to public key hash P 2 PK
P2PK (Pay To Public Key) is the earliest address format, which pays to a public key without performing address operations. It is rarely used nowadays.
For comparative learning, we summarize its principles and sample data in the document:
(1) Schematic diagram
(2) Sample data
To create a script that P 2 PK can spend, the sample data is as follows:
Lock script in output
OP_PUSHBYTES_65
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
Unlock script in input
OP_PUSHBYTES_72
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 the following link for a more detailed demonstration:
In some browsers, payments to a public key will still be displayed as payments to 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) Schematic diagram
(2) Sample data
Locking script in output
OP_DUP
OP_HASH 160
OP_PUSHBYTES_20
55 ae 51684 c 43435 da 751 ac 8 d 2173 b 2652 eb 64105
OP_EQUALVERIFY
OP_CHECKSIG
Unlocking script in input
OP_PUSHBYTES_72
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
OP_PUSHBYTES_33
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
Diagram of executing script
You can view the following link for a more detailed demonstration:
Schematic diagram of P2PKH address formation
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(publickey)+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, if an uncompressed 130-character public key is compressed into a 40-character hash value using Hash 160, there's a chance of a hash collision, meaning there's a small chance of duplicate addresses. Isn't that a concern? Further reading on why the public key hash is used as the address:
https://bitcoin.stackexchange.com/questions/3600/why-are-bitcoin-addresses-hashes-of-public-keys
3.3. Payment to Multi-Signature P2MS
P 2 MS (Pay To Multisig) is a payment method that allows payment to multiple signatures. For an explanation of the relevant principles, please refer to BIP 11: M-of-N Standard Transactions.
(1) Schematic diagram
For the diagram above, using 2/3 multi-signatures is as follows:
(2) Sample data
Locking script in output
OP_2
OP_PUSHBYTES_65
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
OP_PUSHBYTES_65
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
OP_PUSHBYTES_65
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
OP_PUSHBYTES_72
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
OP_PUSHBYTES_72
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
Diagram of executing script
You can view the following link for a more detailed demonstration:
https://learnmeabitcoin.com/technical/script/p 2 ms/
P2MS (payment to multi-signature) doesn't actually have an address format. The most common method is to wrap the P2MS payment script in a P2SH or P2WSH script, so its address references the other two similar addresses. Compared to using P2MS directly, it has the following advantages:
Because P2MS lacks an address format, if you wish to directly lock your bitcoins, you must construct and send the original locking script yourself. Worse still, this may not create a transaction for you, as most wallets only allow transactions using addresses (not raw scripts). This situation means that constructing an input capable of spending such a UTXO is a challenge for only professionals using specialized tools or development kits, making it difficult for the average person to create such an input.
P2MS is limited to a maximum of three public keys. Including all public keys would make the locking script for P2MS very large (resulting in high fees), hence the limit of three (to prevent excessive centralization of UTXO data). However, with P2SH, you can use up to 15 public keys for multi-signature locking.
Therefore, users can still use P2MS if they wish, but it is more convenient to use P2SH to achieve the same function.
3.4. Pay to script hash P 2 SH
P2SH (Pay To Script Hash) pays to the script hash. After the ability to pay to the script hash, the transaction performance of Bitcoin has been greatly enhanced.
(1) Schematic diagram
(2) Sample data
Locking script in output
OP_HASH 160
OP_PUSHBYTES_20
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
OP_PUSHBYTES_71
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
OP_PUSHBYTES_71
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
Diagram of executing script
You can view the following link for a more detailed demonstration:
https://learnmeabitcoin.com/technical/script/p 2 sh/
Address principle
Encode the hash 160 of a public key or script to a legacy address.
This address format starts with 3 (the test network starts with 2), for example:
3 Nfmmt 78 SUwQTZtr 4 p 9 qty 5 Wgaykt 6 PhoS
Formation process:
Hash 160 encode the user's public key or script to get 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:
l Easier to use complex unlocking scripts (also provides a basis for using MAST trees in subsequent Taproot);
Cheaper transaction fees (this effectively shifts the cost to the spender, who needs to use more unlocked bytes to spend the output);
lP 2 SH provides stronger privacy;
Because the bytes in the output are reduced, the entire UTXO set is smaller. Because the size of a single UTXO is smaller, more UTXOs can be stored in memory.
Note: In P2SH, the maximum length of the redemption script is 520 bytes. This means that if the P2SH script is P2MS, then it can contain at most 15 public keys (the compressed public key is 33 bytes, and 15 compressed public keys are 33*15=495 bytes, which is the maximum value less than 520 bytes).
3.5. Witness public key hash P 2 SH-P 2 WPKH for payment to the package
2 SHP 2 WPKH wrapped in a P 2 SH, wrapping the payment to the witness public key hash P into the payment to the script hash P 2 SH method. PP 2 WPKH()2 WPKH
(1) Schematic diagram
(2) Sample data
Locking script in output
OP_HASH 160
OP_PUSHBYTES_20
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
OP_PUSHBYTES_22
001402 c 8147 af 586 cace 7589672191 bb 1 c 790 e 9 e 9 a 72
Diagram of executing script
(3) The schematic diagram of this payment address is as follows:
You can view the following link for a more detailed demonstration:
https://learnmeabitcoin.com/technical/script/p 2 sh-p 2 wpkh/
This address format starts with 3, for example: 3 Beer 3 irc 1 vgs 76 ENA 4 coqsEQpGZeM 5 CTd
3.6. Payment to the package witness script hash P 2 SH - P 2 WSH
P 2 SH-P 2 WSH (P 2 WSH wrapped in a P 2 SH) wraps the payment to the witness script hash PS into the payment to the script hash P 2 SH method.
(1) Schematic diagram
(2) Sample data
Locking script in output
OP_HASH 160
OP_PUSHBYTES_20
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
OP_PUSHBYTES_34
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
Diagram of executing script
(3) The schematic diagram of this payment address is as follows:
You can view the following link for a more detailed demonstration:
https://learnmeabitcoin.com/technical/script/p 2 sh-p 2 wsh/
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 P2 WPKH
P 2 WPHK (Pay To Witness Public Key Hash) is used for payments to a Segregated Witness address.
(1) Schematic diagram
(2) Sample data
Locking script in output
OP_0
OP_PUSHBYTES_20
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 zone 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
Diagram of executing script
You can view the following link for a more detailed demonstration:
https://learnmeabitcoin.com/technical/script/p 2 wpkh/
Address formation diagram
The prefix OP_0 is used to distinguish the first version of Segregated Witness (subsequent Taproot addresses use OP_1 to distinguish them), followed by a 20-byte public key hash, and finally the Bech 32 address encoding format.
This address format starts with bc 1 q, for example:
bc 1 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 P 2 WSH
P 2 WSH (Pay To Witness Script Hash), payment to witness script hash.
(1) Schematic diagram
(2) Sample data
Locking script in output
OP_0
OP_PUSHBYTES_32
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
Diagram of executing script
You can view the following link for a more detailed demonstration:
https://learnmeabitcoin.com/technical/script/p 2 wsh/
Address formation diagram
The prefix OP_0 is used to distinguish the first version of Segregated Witness (subsequent Taproot addresses use OP_1 to distinguish them), followed by a 32-byte script hash, and finally the Bech 32 address encoding format.
This address format starts with bc 1 q, for example:
bc 1 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 P 2 TR
P2TR (Pay To Taproot) pays to the Taproot address. This type of payment has two types: Key Path Spend and Script Path Spend. See the following description for details.
(1) Schematic diagram
(2) Sample Data 1 - Key Path Spend
Locking script in output
OP_1
OP_PUSHBYTES_32
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
Diagram of Key Path Spend execution script
(3) Sample Data 2-3 Script Path Spend
Locking script in output
OP_1
OP_PUSHBYTES_32
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
Diagram of executing script
You can check out the following link for a more detailed explanation: https://learnmeabitcoin.com/technical/script/p 2 tr/
The prefix OP_1 is used to distinguish the second version of Segregated Witness (previous SegWit addresses use OP_0 to distinguish them), followed by a 20-byte public key hash, and finally the Bech 32 address encoding format.
This address format starts with bc 1 p, for example:
bc 1 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. Derived Path Addresses and Privacy Protection in Bitcoin Transactions
4.1. Bitcoin transaction history
The change in Bitcoin addresses is also closely related to several Bitcoin transaction history changes, mainly due to the changes caused by Bitcoin's two SegWit implementations.
1. Transactions defined in the white paper (simple transaction model)
Early, basic Bitcoin transactions allowed for multiple inputs and up to two outputs. One output was for the recipient's change, while the other was for an external transfer. (Note: The difference between the total inputs and total outputs is the transaction fee.)
Early addresses included P 2 PK, P 2 PKH, P 2 MS, and P 2 SH.
2. Transactions in Segregated Witness Version 1 (SegWit)
Segregated Witness (SegWit) is a protocol upgrade for the Bitcoin blockchain network. Proposed by developer Pieter Wiulle in December 2015 as a core update to the Bitcoin Core client, it achieves capacity expansion by separating transaction data from signature data. This solution maintains compatibility with the traditional Bitcoin network and avoids a hard fork.
Its core mechanism increases the block size limit from 1 megabyte to 4 megabytes (the actual increase is estimated to be 2-2.1 megabytes according to statistics). This technology frees up space on the main chain by storing digital signatures in additional witness blocks. This technology addresses transaction malleability issues, improves transaction identifier generation to prevent double-spending attacks, and lays the foundation for second-layer protocols such as the Lightning Network. As the mainstream client standard adopted by most companies in the industry, Bitcoin Core requires 95% of the network's hash rate to support this upgrade, but actual support has consistently remained between 32% and 33.8%. Opposition has focused on controversial technical utility and the potential for third-party interference to weaken Bitcoin's decentralization. The protocol was activated on the Bitcoin mainnet on August 24, 2017.
The addresses in are P 2 WPKH, P 2 WSH, P 2 SH-P 2 WPKH, P 2 SH-P 2 WPSH and several other address types.
3. Transactions in Segregated Witness v2 (Taproot)
Taproot technology was proposed in January 2020 and officially took effect as a soft fork in November 2021. This upgrade is a combination of BIP 340, BIP 341, and BIP 342. BIP 340 introduced Schnorr signatures, which can simultaneously verify multiple transactions, replacing the Elliptic Curve Digital Signature Algorithm (ECDSA). This further expanded network capacity and accelerated the processing of batch transactions, facilitating the deployment of complex smart contracts. BIP 341 implemented Merkle-based Abstract Syntax Trees (MAST) to optimize transaction data storage on the blockchain. BIP 342 (Tapscript) uses Bitcoin's scripting language to expand upon the limitations of Bitcoin's native scripting capabilities.
The address in Taproot is a P 2 TR address type.
4.2. Common known derivation path definitions
Let’s first understand the common derivation paths of Bitcoin, and then look at the common derivation paths of other chains.
1. Common Bitcoin derivation paths
The derivation path standard format defined in the BIP is: m/purpose'/coin_type'/account'/change/address_index
The most common derivation paths of Bitcoin are mainly distinguished by the purpose field, which corresponds to different address types.
(1) BIP 44 - Legacy (Original) Addresses (1...)
Path: m/44'/0'/0'/0/0
Purpose: The earliest HD wallet standard, used to generate P2PKH addresses starting with 1.
Features:
The best compatibility, supported by all wallets and exchanges.
The transaction fee is the highest because the transaction data volume is large.
Usage scenarios: Currently mainly used to recover funds from very old wallets or to top up funds to old platforms that do not support new address types.
(2) BIP 49 - Nested SegWit Addresses (3...)
Path: m/49'/0'/0'/0/0
Purpose: Used to generate P 2 SH-P 2 WPKH addresses starting with 3.
Features:
This is achieved by wrapping the SegWit address in a P2SH script.
The transaction fee is lower than Legacy, but higher than Native SegWit.
The compatibility is very good, and almost all wallets and exchanges support receiving and sending to addresses starting with 3.
Use Case: In the early days of SegWit promotion, it served as a compatible solution for the transition to Native SegWit. It is still widely supported.
(3) BIP 84 - Native SegWit Address (bc 1 q...)
Path: m/84'/0'/0'/0/0
Purpose: Used to generate P 2 WPKH addresses starting with bc 1 q.
Features:
The transaction fee is the lowest because the transaction data volume is the smallest and the format is the most efficient.
Optimal security, fully benefiting from the technical advantages of SegWit.
Compatibility: Currently, most modern wallets, nodes, and exchanges support it. However, some very old systems may not be able to recognize it.
Usage scenario: The current preferred and recommended standard for saving fees and enjoying the latest technical features.
(4) BIP 86 - Taproot (P 2 TR) Address (bc 1 p...)
Path: m/86'/0'/0'/0/0
Purpose: Used to generate P 2 TR addresses starting with bc 1 p. This is the latest major upgrade of Bitcoin.
Features:
Improved 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).
The signature algorithm (Schnorr Signatures) is more efficient and supports key aggregation.
Usage scenarios: Represents the future development direction of Bitcoin and is suitable for users and applications who want to use the latest technology, pursue lower fees and better privacy.
(5) Derivation paths used in RGB technology
If the coin is defined according to the BIP-44 protocol standard and the SLIP-44 protocol according to the RGB-0044 protocol, the purpose is 84. The official derivation path of RGB is as follows: m_type/84'
In addition, the author also consulted the RGB official website and used the derivation path of m/9735'/ according to the description in LNPBP-46: LN derivations. The specific relevant content is as follows:
Note: Which specific standard to use requires further research on related applications and RGB protocol documents.
(6) Other important paths
BIP 32 root path: m/0' (or sometimes m/0). Some older implementations or non-standard wallets may use this path directly, but it is strongly discouraged because it does not meet the multi-currency and multi-account standards.
Multi-signature wallet path: For multi-signature wallets, each collaborator typically uses their own standard path (e.g., m/48'/0'/0'/2') to derive the public key for multi-signature. This is typically managed by the wallet software that coordinates multi-signatures (e.g., Electrum, Specter), and ordinary users do not need to manually handle it.
Testnet path: Simply change the coin_type in the above path from 0' to 1'. For example, the testnet Native SegWit path is: m/84'/1'/0'/0/0.
2. The following lists some mainstream currencies 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...
Note: This is the default path used by most wallets, including MetaMask and Trust Wallet. All EVM-based chains (such as BSC m/44'/60'/0'/0/0 and Polygon m/44'/60'/0'/0/0) use the same path and the same set of private keys. Your address will appear identical on different chains, but they are separate accounts on different chains. When switching networks, wallet software uses RPC nodes to distinguish between different chains.
(2) Binance Coin (BNB) Beacon Chain
BNB has its own independent chain and address system, which is different from the EVM chain.
Path: m/44'/714'/0'/0/0
coin_type: 714'
Address format: bnb 1... (Bech 32) or tbnb 1... (testnet)
Description: Used for BNB assets on Binance Chain.
(3) Polkadot
Path: m/44'/354'/0'/0/0
coin_type: 354'
Address format: Based on SS 58 format, usually starts with 1.
(4) Solana
Route: m/44'/501'/0'/0'
coin_type: 501'
Note: Notice that Solana’s paths use a hardened derivative 0 at the end, rather than a regular 0. This is standard practice.
(5) Cardano
Cardano's derivation path is rather special and complex, and it is based on its own BIP 44-ADA solution.
Path: m/1852'/1815'/0'/0/0
purpose: 1852' (designed specifically for Cardano)
coin_type: 1815' (the year ADA was born)
Address format: addr 1... (Bech 32)
Note: 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... (Base 58)
(7) Litecoin
Litecoin, like Bitcoin, also has multiple address types.
Legacy (L...): m/44'/2'/0'/0/0
SegWit (M...): m/49'/2'/0'/0/0
Native SegWit (ltc 1 q...): m/84'/2'/0'/0/0
coin_type: 2'
(8) Dogecoin
Path: m/44'/3'/0'/0/0
coin_type: 3'
Address format: D... (Base 58)
(9) Tron
Path: m/44'/195'/0'/0/0
coin_type: 195'
Address format: T... (Base 58)
3. Non-standard or exceptional circumstances
(1) Monero
Monero does not use the BIP 32/BIP 44 standards. It has its own hierarchical deterministic wallet scheme that uses different cryptography (Ed 25519 curve) and key structure.
Its derived path looks like: m/44'/128'/0' (but this is not a standard BIP 32 path)
Important: You cannot use a recovery phrase designed for Bitcoin/Ethereum to recover funds directly from a Monero wallet, and vice versa. Restoring a Monero wallet must use Monero's own recovery phrase and system.
(2) The Ethereum Classic Path for Hardware Wallets
Some hardware wallets, such as Ledger, have separate 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 unique phenomenon called "change address changes," or rather, any blockchain model based on the UTXO model exhibits this characteristic. Understanding "change address changes" requires understanding three key points:
1. UTXO Model (Unspent Transaction Output)
This is the core ledger model of Bitcoin, which is different from the traditional account balance model.
Basic principle: The Bitcoin network does not record your "balance", but rather a series of unspent "checks" (UTXOs). These checks have different denominations and are destroyed once they are spent, and new checks are created.
Transaction process: When you make a payment, you must take out one or more "checks" (inputs) from your wallet, the total value of which must be greater than or equal to the amount you want to pay. The transaction creates two new "checks":
One for the payee: the denomination is equal to the payment amount.
One for yourself (change): the denomination is equal to (total amount entered - payment amount - transaction fee).
Key takeaway: Change is essentially a new output (UTXO) paid to you. It has no difference in transaction structure from the output you pay to others.
Note: The term "check" is used here rather than "cash" (which is often printed with a fixed amount) because the amount on a check is random and can vary from check to check, which is more consistent with the UTXO scenario in Bitcoin. Often, the terms "check" and "cash" are used interchangeably to convey the same meaning.
2. Privacy Protection by Design
Using a fixed address can severely compromise privacy.
Address reuse problem: If all UTXOs (including change) go back to the same address, blockchain analysis agencies or personnel can easily:
Connect all your transactions: Know all the money flows behind this address.
Estimate your wealth: Clearly see your total income.
Destroys the anonymity set: it is impossible to mix other people’s transactions with yours.
Solution: Use a brand new address for change in each transaction. This makes it difficult for outside observers to determine which output in a transaction is paid to the merchant and which output is the change returned to you. This greatly increases the difficulty of blockchain analysis and protects your financial privacy.
3. Technical Implementation of HD Wallet (Hierarchical Deterministic Wallet)
Manually managing new addresses and private keys for each change is not feasible, and HD wallets automate this process.
Chain structure: HD wallets can generate nearly unlimited addresses and private keys from a seed (mnemonic).
Derived Paths: As we 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 the receiving address (external link).
m/44'/0'/0'/1/*: Used to generate the change address (internal chain).
Workflow:
When your wallet software constructs a transaction, if change is required, it will automatically take it from the internal "change address pool" (/1/*) as the change receiving address. The next address that has never been used
After the transaction is broadcast and confirmed, the new change UTXO is saved under this new address.
The next time you spend funds, your wallet will scan all the UTXOs on both the receiving and change chains and use them as available "inputs." You don't need to manage them manually; the wallet will handle everything automatically.
In short, the change address is the inevitable result of the combination of [ , ] and [ ]. It is not optional, but standard behavior of Bitcoin wallets. UTXO model privacy protection requirements HD wallet technology
Use a blockchain explorer: Find a real transaction (e.g. one from your own wallet) and view its details on mempool.space or blockstream.info. Try to analyze its inputs and outputs, and guess which is the payment output and which is the change output (usually the change output will point to a new address belonging to the sender).
Use a test wallet: Create a new wallet on the testnet, perform a few send and receive operations, and then observe how the address list in your wallet changes and how UTXO is generated and consumed.
References
1. https://learnmeabitcoin.com/ is a great website for learning about Bitcoin.
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 P 2 WPKH-nested-in-P 2 SH based accounts, 2016-05-19 https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki
11. BIP 84:Derivation scheme for P 2 WPKH based accounts, 2017-12-28, https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki
12. BIP 86: Key Derivation for Single Key P 2 TR Outputs, 2021-06-22, https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki
13. BIP 173: Base 32 address format for native v 0-16 witness outputs, 2017-03-20, https://github.com/Roasbeef/bips/blob/bip-tap/bip-0173.mediawiki
14. BIP 350: Addresses for P 2 WPKH and P 2 WSH in Bech 32 m, 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
- 核心观点：详解比特币地址生成原理与协议演进。
- 关键要素：
- 非对称加密与哈希算法是基础。
- BIP协议规范地址生成与派生。
- 地址类型从P2PKH演进至P2TR。
- 市场影响：提升钱包安全与交易效率。
- 时效性标注：长期影响。
IOS
Android