Author: Fu Shaoqing, SatoshiLab, ThreeDAO BTC Studio

1. Preparatory knowledge

1.1. Asymmetric encryption and public&private keys

1.2. Common hashing algorithms used in Bitcoin

1.3. Common encoding knowledge Base64, Base58, Bench32

1.4. The basic principle of digital currency address generation

2. Bitcoin address related protocols

2.1. Three core protocols (BIP-32, 39, 44) and related protocols

2.2. Address format protocol and evolution protocol

3. Bitcoin address types and locking script types

3.1. P2PK（Pay to Public Key）

3.2. P2PKH（Pay To Public Key Hash）

3.3. P2MS（Pay To Multisig）

3.4. P2SH（Pay To Script Hash）

3.5. P2SH-P2WPKH(P2WPKH wrapped in a P2SH)

3.6. P2SH-P2WSH(P2WSH wrapped in a P2SH)

3.7. P2WPHK（Pay To Witness Public Key Hash）

3.8. P2WSH(Pay To Witness Script Hash)

3.9. P2TR（Pay To Taproot）

4. Derived Path Addresses and Privacy Protection in Bitcoin Transactions

4.1. Bitcoin transaction history

4.2. Common known derivation path definitions

4.3. Privacy protection and multi-address usage

References

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 techniques, 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.

Asymmetric encryption, first proposed by Whitfield Diffie and Martin Hellman in 1976, is a cornerstone of modern cryptography. Its core feature is the use of a pair of mathematically related keys: a public key that is publicly available and a private key that is kept secret. The 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 with the corresponding public key. This perfectly solves the key distribution problem inherent in symmetric encryption, enabling secure communication without the need for shared secrets.

In the digital currency, the most commonly used asymmetric encryption algorithm is the Elliptic Curve Digital Signature Algorithm (ECDSA), particularly the secp256k1 curve used by Bitcoin and other currencies. This algorithm offers shorter keys and greater efficiency than the traditional RSA algorithm while maintaining the same security strength. Following Bitcoin's Taproot technology, the Schnorr digital signature algorithm has also begun to be used in the cryptocurrency sector, offering several advantages over ECDSA.

The principles and functions of public and private keys (this article focuses on the digital currency).

In digital currency, 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.

Their functions are as follows:

Private key: Used to generate transaction signatures, proving your authority to spend the corresponding funds. This key must be kept strictly confidential.

Public key: Used to verify the validity of transaction signatures, ensuring they were generated by the corresponding private key. It is also used to generate public payment addresses that can be securely shared with anyone.

In short, the private key is used for signing, and the public key is used for verification and address generation. Together, they ensure the security and reliability of asset ownership transfers.

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) or 03 (odd) and are 33 bytes long.

An example is as follows:

public key (uncompressed):

04b4632d08485ff1df2db55b9dafd23347d1c47a457072a1e87be26896549a87378ec38ff91d43e8c2092ebda601780485263da089465619e0358a5c1be7ac91f4

public key (compressed):

02b4632d08485ff1df2db55b9dafd23347d1c47a457072a1e87be26896549a8737

Diagram of a traditional uncompressed public key

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 Format) Private Key. Its encoding format is as follows:

The specific data samples are as follows:

In addition to public and private key knowledge, you also need to understand 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 verify 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 complex series of mathematical calculations, generates a fixed-length (256 bits, or 32 bytes) string that appears to be random gibberish. This string is typically represented by 64 hexadecimal digits (0-9, A-F).

For example, if you input "hello world," the SHA-256 calculation yields:

b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

RIPEMD-160 stands for RACE Raw Integrity Check Message Digest - 160 bits. 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, the input "hello world" would be calculated using RIPEMD-160 to produce:

d7d56920283f17ab4d7e10d4a5d6df50e594a9c3

2.Common hashing algorithms used in Bitcoin include:

HASH256 (Dual SHA-256 is the most commonly used)

HASH160 (SHA-256 + RIPEMD-160)

SHA-256 (Single SHA-256)

HMAC-SHA512 (HMAC with SHA-512)

3.Usage scenarios:

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

(2) The transaction identifier - TXID uses HASH256.

(3) The merkle root in the transaction uses HASH256.

(4) The public key hash uses HASH160, which is a single SHA256 + a single RIPE-160.

(5) The extended key uses HMAC (SHA-512).

(6) HASH256 is used in signed transactions.

There are several encodings you need to know about in Bitcoin wallet addresses, including Base64, Base58, and Bench32.

1. Base64 (not used in Bitcoin, but introduced together as an early common encoding)

Design goal: To 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:

• Each 3-byte (24-bit) binary data is divided into 4 groups of 6 bits each.

• 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 is padded with = characters.

  Character Set:

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

  Key Features:

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

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

• Contains non-alphanumeric characters: Uses + and /; these characters may need to be escaped in command lines or URLs.

• No validation: Standard Base64 encoding does not provide error detection.

2. Base58

Design goal: Optimize for manual processing, avoid visual ambiguity, and facilitate manual input and proofreading. Primarily used in Bitcoin's legacy address format.

Principle：

• Derived from Base64, but with easily confused characters removed.

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

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

Character set:

123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

(Removes 0 (zero), O (uppercase o), I (uppercase i), l (lowercase L), +, and /, for a total of 58 characters)

Key Features:

• User-Friendly: The character set eliminates easily confused characters, significantly reducing transcription and input errors.

• Alphanumeric: The generated strings are very "clean," without any symbols, making them easy to copy and paste in any environment.

• Slightly Less Efficient: Each character carries approximately 5.857 bits of information, slightly less efficient than Base64.

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

3. Bech32

Design Goal: Designed for Bitcoin SegWit (Segregated Witness) addresses, with enhanced error detection and correction capabilities, case-insensitivity, and efficient uppercase conversion.

Related BIPs:

BIP-173 Base32 address format for native v0-16 witness output

BIP-350 Bech32m format for v1+ witness addresses

Bech32m is the v1 version of Bech32, with minor adjustments to the checksum algorithm.

Principle:

• Based on the BCH (Bose–Chaudhuri–Hocquenghem) code, an error-correcting code that can detect and correct multiple errors.

• Structure: HRP (human readable part, such as bc1) + separator (1) + data part (Base32 encoding) + checksum.

• Uses an optimized 32-character subset.

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

Key features:

• Powerful Error Detection: It detects the vast majority of incorrect combinations and automatically corrects the few that do. This is superior to Base58Check, which can only detect but not correct errors.

• Case Insensitivity: Addresses are valid regardless of whether they are entered in uppercase or lowercase, providing a better user experience.

• Compact and Efficient: The data portion uses Base32 (5 bits per character), which is more compact for SegWit data.

• Human Readable Portion (HRP): The "bc1" (Bitcoin mainnet) or "tb1" (Bitcoin testnet) at the beginning of the address clearly identifies the network type, making it less confusing.

• Higher Cost: Encoding and decoding are computationally more complex than Base58.

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

If readers need to know more about the relevant content, we recommend you to refer to the following website, which contains detailed Encode, Decode, Checksum diagrams and step-by-step explanations.

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

Summary and Choice

For general data transmission: Choose Base64. It's a web standard, has libraries available for nearly every programming language, and offers the highest efficiency.

For user-facing identifiers (such as those for legacy systems): Choose Base58Check. It generates strings that are easy to read and input manually, effectively preventing visual errors.

For modern cryptocurrency addresses (especially Bitcoin): Bech32 (addresses starting with bc1) is highly recommended. It offers the highest security and user experience, and potentially lower transaction fees (due to the SegWit technology, which calculates the witness field as one-fourth the original size). It represents the future of cryptocurrency addressing.

Digital currency addresses are generated by generating a public-private key pair based on public-private key cryptography. The public key is then deduced from the digital currency address using certain algorithms and standards. Certain mechanisms are also often used to generate a set of private keys and a corresponding set of public keys.

The following diagram illustrates how private keys are generated.

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. There will be some differences in the principle diagrams. Each address type will be explained in detail in the third section below.

With the algorithms and encodings for generating Bitcoin addresses, specific protocol standards are needed. These primarily come from the BIP and SLIP protocols. The abbreviations and meanings of these two terms are as follows:

BIP: Bitcoin Improvement Proposal

SLIP: Satoshi Labs Improvement Proposals

1. BIP-32 (Hierarchical Deterministic Wallets)

BIP-32's primary function is to derive a large number of key pairs (private and public keys) from a single master seed. Previously, wallets consisted of a collection of unrelated private keys, making backups extremely cumbersome. BIP-32 allows you to restore all addresses and funds in the entire wallet tree structure by simply backing up a single master seed (usually generated from a BIP-39 mnemonic phrase). This greatly simplifies the backup and restore process.

The BIP-32 protocol defines the 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) - Mnemonic phrases

BIP-39's main function is to convert the random number master seed (a long string of 0s and 1s) in BIP-32 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 provides official mnemonic wordlists in the following languages: English, Japanese, Korean, Spanish, Chinese (Simplified), Chinese (Traditional), French, Italian, Czech, and Portuguese.

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

BIP44 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 prescribes a clear path format, such as: m/purpose'/coin_type'/account'/change/address_index. This standard allows a single 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

purpose: Fixed to 44, indicating compliance with the BIP44 standard (enhanced derivation).

coin_type: Coin type, e.g., 0 for Bitcoin and 60 for Ethereum (enhanced derivation).

account: Account index, allowing users to create multiple accounts within a single wallet (enhanced derivation).

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

address_index: Address index, generated sequentially starting at 0.

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

A single apostrophe ' indicates enhanced derivation.

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

Because the BIP-32 protocol alone provides implementers with too much freedom, this protocol specifically describes the purpose field. This protocol encourages different implementations to apply for separate BIP numbers and use the same purpose field, thus avoiding overlapping addresses generated from the BIP32 space.

In Section 4.2, we will see the purpose field defined by different BIPs.

Purpose 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. Among the common cryptocurrency types in SLIP-0044, you can see thousands of currently popular coin_type types. For more information, see the link:

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

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

This protocol provides a standard transaction type with M/N signatures, primarily to provide a more secure way to use and manage Bitcoin assets.

An example of its instruction type can be found in Section 3.3.

The locking script is: m {pubkey}...{pubkey} n OP_CHECKMULTISIG

The unlocking script is: OP_0 ...signatures...

However, the protocol only defines a standard transaction type and does not define a specific address type. Later, these multi-signature scripts were standardized as P2SH addresses.

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

BIP-13's main purpose: It defines a standard for addresses starting with the number 3. These addresses correspond not directly to a public key, but to the hash of a script. They are most commonly used for:

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

SegWit compatibility.

Significance: It hashes complex script conditions into a short address, simplifying the user experience and opening the door to complex smart contracts.

Specific address format definition:

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

3. BIP-16 (Pay to Script Hash)

This protocol defines the Pay to Script Hash feature. BIP-13 defines Pay to Script Hash Address. The script defined by BIP-16 is as follows:

Locking Script: OP_HASH160 [20-byte-hash-value] OP_EQUAL

Unlocking Script: ...signatures... {serialized script}

See Section 3.4 for a specific example.

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. This allows users to seamlessly use different HD wallets with the same master seed and/or single account. Therefore, users are required to create dedicated segregated witness 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 different purpose values 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, the encapsulation defined in BIP 141 is used:

witness:       scriptSig:    <0 <20-byte-key-hash>> (0x160014{20-byte-key-hash}) scriptPubKey: HASH160 <20-byte-script-hash> EQUAL (0xA914{20-byte-script-hash}87) 5. BIP-84 (Derivation scheme for P2WPKH-based accounts) Derivation scheme for P2WPKH accounts When using P2WPKH transactions, a universal derivation scheme is necessary. It 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 and BIP 49, but only uses different purpose values to indicate different transaction serialization methods. 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 P2WPKH address from the public key calculated above, the encapsulation defined in BIP 141 is used: witness:       scriptSig:    (empty) scriptPubKey: 0 <20-byte-key-hash> (0x0014{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 public keys from the root account, this BIP uses the same account structure as defined in BIPs 44, 49, and 84, but with a different purpose value for the script type. 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 (Base32 address format for native v0-16 witness outputs) - Native Segregated Witness Addresses (Bech32) BIP-173's primary purpose: It defines a new address format specifically designed for native Segregated Witness (SegWit) transactions, typically beginning with bc1q. Advantages: Lower transaction fees: Native SegWit transactions are smaller, resulting in lower fees. More robust: Using Bech32 encoding effectively prevents typos (such as confusing uppercase and lowercase 'O' with the number '0') and detection errors. Supports larger upgrades: It paves the way for future upgrades such as Taproot. 8. BIP-350 (Addresses for P2WPKH and P2WSH in Bech32m) - Taproot Addresses (Bech32m) BIP-350's main purpose: It makes a minor but crucial adjustment to the Bech32 format in BIP-173, creating Bech32m encoding to support the new Taproot payment method (P2TR). This is the address that begins with bc1p. Why the new format is needed: To distinguish it from the previous native Segregated Witness (v0), 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 purpose of BIP-141: While 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 begin with 3 and look like multi-signature addresses. The purpose: To provide users with a way to benefit from Segregated Witness fee discounts before ecosystem software and services are upgraded to support native Bech32 addresses. This is now being gradually replaced by native Bech32 addresses.

Author: Fu Shaoqing, SatoshiLab, ThreeDAO BTC Studio

1. Preparatory knowledge

1.1. Asymmetric encryption and public&private keys

1.2. Common hashing algorithms used in Bitcoin

1.3. Common encoding knowledge Base64, Base58, Bench32

1.4. The basic principle of digital currency address generation

2. Bitcoin address related protocols

2.1. Three core protocols (BIP-32, 39, 44) and related protocols

2.2. Address format protocol and evolution protocol

3. Bitcoin address types and locking script types

3.1. P2PK（Pay to Public Key）

3.2. P2PKH（Pay To Public Key Hash）

3.3. P2MS（Pay To Multisig）

3.4. P2SH（Pay To Script Hash）

3.5. P2SH-P2WPKH(P2WPKH wrapped in a P2SH)

3.6. P2SH-P2WSH(P2WSH wrapped in a P2SH)

3.7. P2WPHK（Pay To Witness Public Key Hash）

3.8. P2WSH(Pay To Witness Script Hash)

3.9. P2TR（Pay To Taproot）

4. Derived Path Addresses and Privacy Protection in Bitcoin Transactions

4.1. Bitcoin transaction history

4.2. Common known derivation path definitions

4.3. Privacy protection and multi-address usage

References

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 techniques, 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.

Asymmetric encryption, first proposed by Whitfield Diffie and Martin Hellman in 1976, is a cornerstone of modern cryptography. Its core feature is the use of a pair of mathematically related keys: a public key that is publicly available and a private key that is kept secret. The 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 with the corresponding public key. This perfectly solves the key distribution problem inherent in symmetric encryption, enabling secure communication without the need for shared secrets.

In the digital currency, the most commonly used asymmetric encryption algorithm is the Elliptic Curve Digital Signature Algorithm (ECDSA), particularly the secp256k1 curve used by Bitcoin and other currencies. This algorithm offers shorter keys and greater efficiency than the traditional RSA algorithm while maintaining the same security strength. Following Bitcoin's Taproot technology, the Schnorr digital signature algorithm has also begun to be used in the cryptocurrency sector, offering several advantages over ECDSA.

The principles and functions of public and private keys (this article focuses on the digital currency).

In digital currency, 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.

Their functions are as follows:

Private key: Used to generate transaction signatures, proving your authority to spend the corresponding funds. This key must be kept strictly confidential.

Public key: Used to verify the validity of transaction signatures, ensuring they were generated by the corresponding private key. It is also used to generate public payment addresses that can be securely shared with anyone.

In short, the private key is used for signing, and the public key is used for verification and address generation. Together, they ensure the security and reliability of asset ownership transfers.

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) or 03 (odd) and are 33 bytes long.

An example is as follows:

public key (uncompressed):

04b4632d08485ff1df2db55b9dafd23347d1c47a457072a1e87be26896549a87378ec38ff91d43e8c2092ebda601780485263da089465619e0358a5c1be7ac91f4

public key (compressed):

02b4632d08485ff1df2db55b9dafd23347d1c47a457072a1e87be26896549a8737

Diagram of a traditional uncompressed public key

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 Format) Private Key. Its encoding format is as follows:

The specific data samples are as follows:

In addition to public and private key knowledge, you also need to understand 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 verify 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 complex series of mathematical calculations, generates a fixed-length (256 bits, or 32 bytes) string that appears to be random gibberish. This string is typically represented by 64 hexadecimal digits (0-9, A-F).

For example, if you input "hello world," the SHA-256 calculation yields:

b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

RIPEMD-160 stands for RACE Raw Integrity Check Message Digest - 160 bits. 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, the input "hello world" would be calculated using RIPEMD-160 to produce:

d7d56920283f17ab4d7e10d4a5d6df50e594a9c3

2.Common hashing algorithms used in Bitcoin include:

HASH256 (Dual SHA-256 is the most commonly used)

HASH160 (SHA-256 + RIPEMD-160)

SHA-256 (Single SHA-256)

HMAC-SHA512 (HMAC with SHA-512)

3.Usage scenarios:

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

(2) The transaction identifier - TXID uses HASH256.

(3) The merkle root in the transaction uses HASH256.

(4) The public key hash uses HASH160, which is a single SHA256 + a single RIPE-160.

(5) The extended key uses HMAC (SHA-512).

(6) HASH256 is used in signed transactions.

There are several encodings you need to know about in Bitcoin wallet addresses, including Base64, Base58, and Bench32.

1. Base64 (not used in Bitcoin, but introduced together as an early common encoding)

Design goal: To 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:

• Each 3-byte (24-bit) binary data is divided into 4 groups of 6 bits each.

• 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 is padded with = characters.

  Character Set:

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

  Key Features:

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

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

• Contains non-alphanumeric characters: Uses + and /; these characters may need to be escaped in command lines or URLs.

• No validation: Standard Base64 encoding does not provide error detection.

2. Base58

Design goal: Optimize for manual processing, avoid visual ambiguity, and facilitate manual input and proofreading. Primarily used in Bitcoin's legacy address format.

Principle：

• Derived from Base64, but with easily confused characters removed.

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

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

Character set:

123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

(Removes 0 (zero), O (uppercase o), I (uppercase i), l (lowercase L), +, and /, for a total of 58 characters)

Key Features:

• User-Friendly: The character set eliminates easily confused characters, significantly reducing transcription and input errors.

• Alphanumeric: The generated strings are very "clean," without any symbols, making them easy to copy and paste in any environment.

• Slightly Less Efficient: Each character carries approximately 5.857 bits of information, slightly less efficient than Base64.

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

3. Bech32

Design Goal: Designed for Bitcoin SegWit (Segregated Witness) addresses, with enhanced error detection and correction capabilities, case-insensitivity, and efficient uppercase conversion.

Related BIPs:

BIP-173 Base32 address format for native v0-16 witness output

BIP-350 Bech32m format for v1+ witness addresses

Bech32m is the v1 version of Bech32, with minor adjustments to the checksum algorithm.

Principle:

• Based on the BCH (Bose–Chaudhuri–Hocquenghem) code, an error-correcting code that can detect and correct multiple errors.

• Structure: HRP (human readable part, such as bc1) + separator (1) + data part (Base32 encoding) + checksum.

• Uses an optimized 32-character subset.

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

Key features:

• Powerful Error Detection: It detects the vast majority of incorrect combinations and automatically corrects the few that do. This is superior to Base58Check, which can only detect but not correct errors.

• Case Insensitivity: Addresses are valid regardless of whether they are entered in uppercase or lowercase, providing a better user experience.

• Compact and Efficient: The data portion uses Base32 (5 bits per character), which is more compact for SegWit data.

• Human Readable Portion (HRP): The "bc1" (Bitcoin mainnet) or "tb1" (Bitcoin testnet) at the beginning of the address clearly identifies the network type, making it less confusing.

• Higher Cost: Encoding and decoding are computationally more complex than Base58.

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

If readers need to know more about the relevant content, we recommend you to refer to the following website, which contains detailed Encode, Decode, Checksum diagrams and step-by-step explanations.

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

Summary and Choice

For general data transmission: Choose Base64. It's a web standard, has libraries available for nearly every programming language, and offers the highest efficiency.

For user-facing identifiers (such as those for legacy systems): Choose Base58Check. It generates strings that are easy to read and input manually, effectively preventing visual errors.

For modern cryptocurrency addresses (especially Bitcoin): Bech32 (addresses starting with bc1) is highly recommended. It offers the highest security and user experience, and potentially lower transaction fees (due to the SegWit technology, which calculates the witness field as one-fourth the original size). It represents the future of cryptocurrency addressing.

Digital currency addresses are generated by generating a public-private key pair based on public-private key cryptography. The public key is then deduced from the digital currency address using certain algorithms and standards. Certain mechanisms are also often used to generate a set of private keys and a corresponding set of public keys.

The following diagram illustrates how private keys are generated.

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. There will be some differences in the principle diagrams. Each address type will be explained in detail in the third section below.

With the algorithms and encodings for generating Bitcoin addresses, specific protocol standards are needed. These primarily come from the BIP and SLIP protocols. The abbreviations and meanings of these two terms are as follows:

BIP: Bitcoin Improvement Proposal

SLIP: Satoshi Labs Improvement Proposals

1. BIP-32 (Hierarchical Deterministic Wallets)

BIP-32's primary function is to derive a large number of key pairs (private and public keys) from a single master seed. Previously, wallets consisted of a collection of unrelated private keys, making backups extremely cumbersome. BIP-32 allows you to restore all addresses and funds in the entire wallet tree structure by simply backing up a single master seed (usually generated from a BIP-39 mnemonic phrase). This greatly simplifies the backup and restore process.

The BIP-32 protocol defines the 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) - Mnemonic phrases

BIP-39's main function is to convert the random number master seed (a long string of 0s and 1s) in BIP-32 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 provides official mnemonic wordlists in the following languages: English, Japanese, Korean, Spanish, Chinese (Simplified), Chinese (Traditional), French, Italian, Czech, and Portuguese.

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

BIP44 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 prescribes a clear path format, such as: m/purpose'/coin_type'/account'/change/address_index. This standard allows a single 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

purpose: Fixed to 44, indicating compliance with the BIP44 standard (enhanced derivation).

coin_type: Coin type, e.g., 0 for Bitcoin and 60 for Ethereum (enhanced derivation).

account: Account index, allowing users to create multiple accounts within a single wallet (enhanced derivation).

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

address_index: Address index, generated sequentially starting at 0.

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

A single apostrophe ' indicates enhanced derivation.

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

Because the BIP-32 protocol alone provides implementers with too much freedom, this protocol specifically describes the purpose field. This protocol encourages different implementations to apply for separate BIP numbers and use the same purpose field, thus avoiding overlapping addresses generated from the BIP32 space.

In Section 4.2, we will see the purpose field defined by different BIPs.

Purpose 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. Among the common cryptocurrency types in SLIP-0044, you can see thousands of currently popular coin_type types. For more information, see the link:

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

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

This protocol provides a standard transaction type with M/N signatures, primarily to provide a more secure way to use and manage Bitcoin assets.

An example of its instruction type can be found in Section 3.3.

The locking script is: m {pubkey}...{pubkey} n OP_CHECKMULTISIG

The unlocking script is: OP_0 ...signatures...

However, the protocol only defines a standard transaction type and does not define a specific address type. Later, these multi-signature scripts were standardized as P2SH addresses.

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

BIP-13's main purpose: It defines a standard for addresses starting with the number 3. These addresses correspond not directly to a public key, but to the hash of a script. They are most commonly used for:

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

SegWit compatibility.

Significance: It hashes complex script conditions into a short address, simplifying the user experience and opening the door to complex smart contracts.

Specific address format definition:

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

3. BIP-16 (Pay to Script Hash)

This protocol defines the Pay to Script Hash feature. BIP-13 defines Pay to Script Hash Address. The script defined by BIP-16 is as follows:

Locking Script: OP_HASH160 [20-byte-hash-value] OP_EQUAL

Unlocking Script: ...signatures... {serialized script}

See Section 3.4 for a specific example.

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. This allows users to seamlessly use different HD wallets with the same master seed and/or single account. Therefore, users are required to create dedicated segregated witness 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 different purpose values 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, the encapsulation defined in BIP 141 is used:

witness:       scriptSig:    <0 <20-byte-key-hash>> (0x160014{20-byte-key-hash}) scriptPubKey: HASH160 <20-byte-script-hash> EQUAL (0xA914{20-byte-script-hash}87) 5. BIP-84 (Derivation scheme for P2WPKH-based accounts) Derivation scheme for P2WPKH accounts When using P2WPKH transactions, a universal derivation scheme is necessary. It 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 and BIP 49, but only uses different purpose values to indicate different transaction serialization methods. 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 P2WPKH address from the public key calculated above, the encapsulation defined in BIP 141 is used: witness:       scriptSig:    (empty) scriptPubKey: 0 <20-byte-key-hash> (0x0014{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 public keys from the root account, this BIP uses the same account structure as defined in BIPs 44, 49, and 84, but with a different purpose value for the script type. 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 (Base32 address format for native v0-16 witness outputs) - Native Segregated Witness Addresses (Bech32) BIP-173's primary purpose: It defines a new address format specifically designed for native Segregated Witness (SegWit) transactions, typically beginning with bc1q. Advantages: Lower transaction fees: Native SegWit transactions are smaller, resulting in lower fees. More robust: Using Bech32 encoding effectively prevents typos (such as confusing uppercase and lowercase 'O' with the number '0') and detection errors. Supports larger upgrades: It paves the way for future upgrades such as Taproot. 8. BIP-350 (Addresses for P2WPKH and P2WSH in Bech32m) - Taproot Addresses (Bech32m) BIP-350's main purpose: It makes a minor but crucial adjustment to the Bech32 format in BIP-173, creating Bech32m encoding to support the new Taproot payment method (P2TR). This is the address that begins with bc1p. Why the new format is needed: To distinguish it from the previous native Segregated Witness (v0), 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 purpose of BIP-141: While 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 begin with 3 and look like multi-signature addresses. The purpose: To provide users with a way to benefit from Segregated Witness fee discounts before ecosystem software and services are upgraded to support native Bech32 addresses. This is now being gradually replaced by native Bech32 addresses.