Author: Anony, BTC Study

When users come into contact with Bitcoin, they often Encountered the concept of "address". When you try to receive Bitcoin payments, you need to provide your address. When checking whether the payment has been received in the block explorer, the specific address is often used as the search condition.

You may think: "The address is equivalent to a bank account in the Bitcoin world and can be used to receive Bitcoins." But this understanding may still make you confused when faced with some situations during the use of the wallet. For example: when you first use a Bitcoin software wallet, it may ask you to select an address "type", such as: "Bech32 (SegWit)", "P2PKH", "Nested-SegWit (P2SH)", etc. . Even when you want to switch to another software wallet, it will scare you: the new software wallet may give you a completely different set of Bitcoin addresses from the original software wallet; what should you do at this time?

This article is to give a slightly in-depth explanation of the concept of Bitcoin addresses and address types to help readers solve the problems they may encounter in the process of autonomously keeping Bitcoins. Some of the problems encountered include but are not limited to the selection of address type and the troubles that may occur during the software wallet migration process.

The last chapter will focus on describing the characteristics and economics of different addresses that readers may come into contact with; if you are not interested in the technical details at all, or just want to quickly To verify the information, you can skip to the last chapter; but if you want to plan a method of self-keeping, it is recommended that you read from the beginning.

To put it simply, a Bitcoin address is actually the result of special encoding (translation) of key data used in standardized Bitcoin scripts; special The encoding method makes it more suitable for delivery and provides the ability to remind errors; and the difference in its economy comes from the difference in the economy of its underlying Bitcoin script.

Standardized Bitcoin script

As we all know, Bitcoin is an electronic currency that runs in a peer-to-peer network. While developing Bitcoin, Satoshi Nakamoto designed a form of existence for the currency that came to be known as “UTXO.” This format makes Bitcoin funds less like money sitting in one account after another, and more like one independent check after another. These “checks” record two key pieces of information: the denomination of the funds (in Satoshi (sat)" as the unit); the script public key (scriptPubkey) is used to define under what circumstances the money can be spent. The script public key is like a lock that requires a specific key to open.

Satoshi Nakamoto realized that if we could customize clever locks, Bitcoin could be used more flexibly in different scenarios, so he also designed a method called "Bitcoin Script." ” programming language, and based on UTXO Transaction verification mode; thus, we can write a program that serves as the script's public key, and when the relevant funds are spent, it can be verified according to such a program.

This innovation brings a practical difficulty: when a transaction is propagated in a peer-to-peer network, the node receiving the transaction will first run some verification work. If this programming language and programming have inherent vulnerabilities, the node can If it crashes during the verification process, a transaction that can exploit this vulnerability can be used to destroy the entire network. How to strike a balance between the free propagation of transactions and the security of the network?

< p style="text-align: left;">In addition to intentionally restricting Bitcoin Script For flexibility, Satoshi Nakamoto also came up with a way: define some scripts that are known to be concise enough and will not trigger failures as "standardized Bitcoin scripts" [1]; when spending funds using such scripts , the transaction is treated as "Standard Bitcoin transactions" can be propagated in the network without hindrance. On the contrary, if such standardized scripts are not used, even if the transaction is valid, it can only be submitted directly to the miners, who will package it into blocks and mine them. , and then spread to the entire network. This limits transactions that may cause security issues from spreading in the network and causing node crashes.

The earliest standardized Bitcoin. There are two types of scripts: "P2PKH" and "P2PK"; as the name suggests, they place a public key (or a hash of a public key) within a script's public key and require transactions that spend funds to provide a signature with that public key (the underlying private key).

A P2PKH script public key is like this:

OP_DUP OP_HASH160 55ae51684c43435da751ac8d2173b2652eb64105 OP_EQUALVERIFY OP_CHECKSIG

(from the famous Bitcoin science website: learn me a bitcoin)

The concept of address

Standardized scripts allow the Bitcoin system to have basic functions (individuals can keep Bitcoins by holding private keys, Initiate electronic money payments to others). However, it is still data designed for computers - the subject that has to understand these strings is the computer. The computer is not sensitive to the length of the string and will not make errors while copying the data. And people are the opposite in many ways.

The problem is that people, as users of this system, do have to deal with this data: when a person receives Bitcoin payment, what TA requires is The other party sends a Bitcoin fund to a Bitcoin script controlled by the TA (or that the TA can successfully unlock); in addition, when the TA wants to keep its own funds for a long time, the TA may need to back up its own Bitcoin script.

What should we do at this time? A long string like the above is obviously not suitable for transmission (too long), nor for backup (easy to copy wrongly).

We have mentioned earlier that scripts that are practical for most people are standardized. This standardization means that two scripts only have one difference in one place. There are differences in key data: For the two P2PKH scripts, the only difference is that the recorded public key hash values ​​are different. Therefore, when receiving payment, we only need to provide this hash value, and the type of script (it is a P2PKH script), and that is enough. The payer (the software) will use this information to recover the complete Bitcoin script and send the Bitcoin to the correct place in the transaction.

Moreover, (Satoshi Nakamoto, who is familiar with engineering, realized), we can not pass the hexadecimal form of this hash value (55ae51684c43435da751ac8d2173b2652eb64105 , 40 characters). With the help of specially designed encoding methods, we can convert it into a shorter, more easily legible form.

This is the "address": encoded data that carries key information that allows us to correctly recover the Bitcoin script.

Encoding method Base58

"Base58"[2] is an encoding method invented by Satoshi Nakamoto, which was transformed from a famous encoding method "Base64" . Base64 character setIncludes: all numbers, uppercase and lowercase letters, and two symbols ("+" and "/"); a total of 64 characters. Satoshi Nakamoto deleted the number 0, the uppercase letters I and O, the lowercase l and symbols from it, and it became Base58.

This deletion is deliberate. Satoshi Nakamoto’s self-report is:

Why use base58 instead of base64?

0OIl is not used because these characters look similar and can be used to create accounts that look almost identical.

It is not easy for people to accept characters other than letters and numbers in their account numbers.

If you don't use punctuation, you will usually not be interrupted by line breaks in email.

Double-click to select the entire string, because there are only letters and numbers.

– Satoshi Nakamoto, Bitcoin v0.1 (base58.h)

The address needs to be restored to a Bitcoin script. Therefore, as long as one character is wrong, the funds may be sent to a completely different Bitcoin script (which may be a script that cannot be unlocked at all!), resulting in the loss of funds. losses; even more, if such confusing characters are allowed, malware can silently replace your address with one that looks similar but is actually controlled by the attacker, causing you to lose funds when receiving payments.

Therefore, Satoshi Nakamoto’s considerations are completely reasonable.

Before executing Base58 encoding, we also need to add a type code as a prefix to the key data (such as the hash value in the P2PKH script above), and start with The first 4 bytes of the results of two consecutive SHA256 operations of the key data of the prefix are used as the suffix.

The prefix can quickly describe the type and purpose of the data; precisely because of the added prefix, the same type of data will always appear in the Base58 encoded results. Same beginning. That's why we just have to look atThe beginning of a Bitcoin address tells you what type of address it is.

The suffix can serve as a checksum: if you enter an address with a transcription error into the software, the software will remind you that you may have made an error (although Unable to point out where the mistake was made).

That is, before starting encoding, we need to construct a string like this:

 Type code + key data + SHA256 (SHA256 (type code + key data)) [0:4] (the "+" here means string concatenation)

With the above P2PKH Taking the script as an example, we first need to add the prefix 00 to the key data (55ae51684c43435da751ac8d2173b2652eb64105); then run two consecutive SHA256 calculations on this data and take the first 4 bytes ( Hexadecimal 8 characters, 96ab3cb1), as a suffix, we get 0055ae51684c43435da751ac8d2173b2652eb6410596ab3cb1. Finally, running Base58 encoding, we get: 18p3G8gQ3oKy4U9EqnWs7UZswdqAMhE3r8.

This string not only contains the key information used in Bitcoin scripts (public key hash value), but also explains how to use it ( The prefix 1 indicates that it should be restored to a P2PKH script), it also has the function of detecting transcription errors, and it is still only 34 characters, shorter than the original hash value.

Bech32

"Bech32" is an encoding method defined by BIP 0173[3]. The two authors of this BIP are Pieter Wuille and Greg Maxwell. However, this encoding also has its own origin: "Bech" refers to "BCH" [4], which is a cyclic error correction coding algorithm invented by three mathematicians in 1959 and 1960 respectively (the name BCH comes from (the last names of these three mathematicians). And "32" means that the character set of this encoding method only has 32 characters: lowercase EnglishAlphabet letters and numbers, except the number "1", the letters "b", "i" and "o".

The consideration of this BIP is to take advantage of the "SegWit" upgrade to provide two new standardized scripts "P2WPKH" and "P2WSH" The address uses the new encoding method.

At the beginning of BIP 0173, the authors pointed out the unsatisfactory aspects of Base58:

Base58 uses both uppercase and lowercase English letters, which makes its data unable to use the smaller "numeric alphabet" mode when drawing it into a QR code, and can only use the larger "byte data" mode.

Using both upper and lower case letters also makes it difficult to copy, type on a mobile keyboard, and read aloud.

The checksum requires two consecutive SHA256 operations, which is slow and has no function to locate errors.

Most encoding methods that can locate errors only apply when the character set size is a prime power, and 58 is not a prime power.

Base58 decoding is more complex and the operation is slower.

So, this new method of Bech32 only uses lowercase letters and numbers; when necessary (such as when drawing QR codes), these letters can all Change to uppercase for a more compact representation. At the same time, Bech32 also has the ability to locate errors: it can not only find that you have copied errors, but also point out which words you have copied wrong (this ability to find errors is far better than Base58).

In fact, the BCH algorithm also has an "error correction" function: it can not only point out which digits you copied wrong, but also point out what it should be. character. However, the authors of BIP 0173 discovered its inherent dangers: on the one hand, strengthening the error correction function will weaken the function of locating errors; on the other hand, if the user trusts the error correction ability of the software too much, the software may mislead the user. The entered incorrect data is corrected into "valid but useless" data - although as a piece of BCH encoded data, it is valid; however, the Bitcoin script recovered by it may not be controllable by the payee.It is controlled and cannot even be controlled by anyone. This is extremely dangerous. Therefore, BIP 0173 cautiously reminds: "In addition to reminding the user which characters may have been copied incorrectly, the software should not implement error correction capabilities (give correction suggestions)."

In addition, Bech32 follows the pattern in Base58 encoding:

Bech32 data will have a "data with meaning (hrp)" at the beginning ”, similar to Base58 The prefix in can indicate what kind of data this is.

hrp can use far more than 32 characters; therefore, Bech32 also uses the number "1" as a separator to separate hrp and the actual character to be decoded data.

In addition to Bitcoin, there are many other projects that also use Bech32; the data of different projects use hrp to distinguish each other. Here is a very interesting (but only interesting) list of registered hrps [5].

Bech32 also designed a checksum that occupies the last 6 characters of the encoded data.

Assuming we use exactly the same public key hash value as in the above case, its P2WPKH script will look like this: 0 55ae51684c43435da751ac8d2173b2652eb64105 (Yes, it is simpler and more abstract than the original P2PKH); and its Bech32 The encoded address is: bc1q2kh9z6zvgdp4mf634jxjzuajv5htvsg9ulykp8 and is 42 characters long.

Bech32m

"Bech32m" is an encoding method defined by BIP 0350[6]. It was proposed because developers discovered a vulnerability in Bech32 encoding:

When the last character is "p", insert before the character Or deleting any number of "q" will not cause a checksum error, then the checksum mechanism will be completely useless.

If no longerBy adding standardized Bitcoin scripts, this problem can be easily solved: P2WPKH addresses and P2WSH addresses have a certain length, just add length verification. However, considering that in the future we will add new standardized scripts whose address lengths may change, it is necessary to fix this issue.

Bech32m fixes this problem by changing a parameter in the Bech32 checksum generator.

Currently, Bech32m is only used to encode the addresses of the "P2TR" scripts added with the "Taproot" upgrade. It may be used in the address encoding of other standardized scripts in the future.

Economy

After we understand that the address is a special representation of a standardized Bitcoin script, the type of address actually comes from the type of the standardized Bitcoin script , the problem of why different types of addresses have different economics—may have different handling fees when spent—is easily solved. This is because different Bitcoin scripts have different economics.

In order to maintain the decentralization and security of the network, the block size of Bitcoin is limited, and there are scripts that can make the transaction volume smaller. Economic advantages.

In this regard, the biggest change was undoubtedly the “SegWit” soft fork activated in 2017. While SegWit brings two new standardized scripts "P2WPKH" and "P2WSH", it also designs a new transaction verification mode for these two scripts:

In legacy Bitcoin scripts, data (such as digital signatures) used for the verification process defined by the script's public key will be placed in the transaction (scriptSignature field); this This brings about the so-called "transaction melting" Problem [7] prevents us from using Bitcoin scripts to program multi-party applications, and even makes the wallet unable to track transactions at all.

The transaction verification mode of Segregated Witness will put this part of the data outside the transaction (witness field); moreover, isolation Witness introduces a new unit for measuring volume ("virtual byte (vByte)"). Data placed in the witness field will be discounted when measuring volume (thisIt is an intentional design to make Segregated Witness transactions more economical than traditional transactions).

The final result is that the SegWit type scripts P2WPKH and P2WSH have significantly better economics than the traditional scripts P2PKH and P2SH: on the one hand, isolation The script public key of the witness script is more concise; on the other hand, the signature of the traditional script is placed in the transaction, and the signature of the segregated witness script is placed outside the transaction. Even if the data volume is the same, the vByte of the latter is smaller.

Here is a table that illustrates how much space different types of scripts take up when used as input and output of transactions.

- Picture from: Optech Limited Weekly · Waiting for confirmation-

Then, there is also a trade volume calculator here that can tell you how much trade volume different amounts of a certain type of script will cause.

Note: When considering economics, you cannot just compare the size of the script when used as input, because generally speaking, Bitcoin transactions will have "change output" ” (The amount of money you contribute to a trade is often greater than the payout, thus transferring some money back to yourself). The change output will usually use the same type of script as the payment address of this wallet.

Address Types

This chapter will introduce the characteristics and economics of different types of addresses that users may be exposed to.

P2PKH

Use Base58 encoding. Begins with the number "1" and is generally 34 characters long.

For single-signature wallets.

Poor economy.

Example (same as above): 18p3G8gQ3oKy4U9EqnWs7UZswdqAMhE3r8

P2SH

Use Base58 encoding method. Begins with the number "3" and is generally 34 characters long.

The actual P2SH addresses that users are most exposed toThe above is the address of a script called "Nested SegWit (P2SH)". The name means "P2SH script that encapsulates the Segregated Witness script."

Being able to implement this kind of encapsulation is the capability of P2SH itself, but the fundamental purpose of defining this kind of encapsulation is to deal with the compatibility issue of wallet software. Since the Segregated Witness address uses a new encoding method, wallet software that does not implement the new method will recognize the Segregated Witness address as an incorrect input and cannot recover a valid Bitcoin script from it. The Nested SegWit P2SH script provides an appropriate compromise: the payer's wallet (regardless of whether it is upgraded or not) will understand such an address as a normal P2SH address, then restore a P2SH script and correctly construct the transaction; the receiver's When you subsequently spend funds, you can reap some of the benefits brought by Segwit (with wallet software that supports Segwit).

When it is a single-signature wallet, the economy is better than P2PKH.

Can be used in multi-signature wallets (with or without Segregated Witness feature).

Example: 38Y2PBD1mihxtoVncaSz3oC2vRrjNF8sA2 (This P2SH script wraps the same P2PKH script as above, although there is no advantage)

P2WPKH

Native SegWit script. Uses Bech32 encoding, starts with numbers and letters "bc1q", and is 42 characters long.

For single-signature wallets.

The economy is significantly better than P2PKH and better than Nested SegWit P2SH.

Example (same as above): bc1q2kh9z6zvgdp4mf634jxjzuajv5htvsg9ulykp8

P2WSH

Native SegWit script. Uses Bech32 encoding, starts with numbers and letters "bc1q", and is 62 characters long.

Usually used in multi-signature wallets.

When used as a multi-signature wallet, the economy is significantly better than P2SH.

Example: bc1q56cuwyqlmq64aq0y3c8swd8a9gefe4wf7faxe2uyatyahfrly5aq0e6mfc (this P2WSH The script wraps the same P2PKH script as above, although this is of no benefit)

P2TR

The native SegWit script (Taproot is "SegWit v1"). Use Bech32m encoding, starting with "bc1p", and the length is 62 characters.

Can be used for both single-signature wallets and multi-signature wallets.

p>

When used as a single-signature wallet, the economy is slightly better than P2WPKH, but there is almost no difference (here it is assumed that one input and one change output are used as the inherent overhead of the transaction; use The more inputs, the greater the advantage of P2TR)

When used as a multi-signature wallet, with the help of some Schnorr signature aggregation algorithms, the economy can be better than that of P2WSH. Even better. But at the time of writing this article (November 2024), wallet software rarely implements such aggregation algorithms. This is due to the complexity of interaction of these algorithms.

P2TR The big difference from previous Bitcoin standard scripts is that they differentiate between users of single-signature wallets, which use public key hash scripts, and users of advanced scripting capabilities ("smart contracts"), which include multi-signature Advanced devices such as devices and lightning channels) will use the redemption script hash value script; P2TR unifies the two for the first time, making it impossible for us to directly infer its use from the external form of the script/address. Therefore, in the long run. Look, P2TR will have better privacy.

So far, not all wallets support P2TR addresses (but almost all wallets support P2WPKH and P2WSH). In addition, users' choice and migration capabilities are relatively limited. P2TR's support for multi-signature devices is even less

Example (randomly selected): bc1pxy5r3slcqc2nhc0r5698gmsqwruenj9c8pzmsy5cedp3649wyktstc6z3c

Conclusion

An address represents a specific Bitcoin script; such a Bitcoin script is standardized and can be completely restored with the information in the address. Special encoding methods are used to make the address more compact and It has the function of checking for transcription errors, and the economy of different address types comes from the economy of the standardized Bitcoin script behind it.

Appendix A. Descriptor

In "The concept of address" section, we have mentioned that there are two scenarios where users may need a compact and reliable script record: the payment (delivery) scenario and the long-term custody scenario

In the "Encoding Methods" section, we can see that the design of these encoding methods is mainly based on the transfer process rather than the long-term storage scenario. So, how should the address be saved in the storage scenario?

< p style="text-align: left;">Fortunately, we now have a proper way to represent a group of addresses (rather than just one), which is the "output (address) descriptor (output descriptor)".

Since the birth of Bitcoin and the emergence of the concept of addresses, the technology and security practices of self-custody have improved a lot. The concept of "Hierarchical Deterministic (HD) Wallet" is to use a piece of secret material to deduce many private keys according to a deterministic random algorithm, and then derive many addresses, so that on the one hand, it can meet the security habit of "not reusing addresses", and on the other hand, it can satisfy the security habit of "not reusing addresses". It can reduce the burden of backing up private keys as much as possible.

The descriptor is also based on this concept. It does this by combining the type of address and the method that generates this set of addresses. The steps are expressed in clear text, plus a checksum. For example:

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

From the above text, we can see that it represents a set of P2WPKH address, and the public key used in this set of addresses is derived from a fingerprint for 8b47f816 is derived from the 84h/0h/0hBIP32 derivation path; and, using 0 and 1< /code> derivation path to distinguish the payment address and change address. Finally, c38kz2nr is the checksum, which can be used to verify whether there are any transcription errors.

Such a string is very suitable for long-term storage and is also very suitable for wallet migration, because it has completely described the process of generating this set of addresses.

Footnotes

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

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

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

4.https:/ /en.wikipedia.org/wiki/BCH_code↩

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

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

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