Like many beginners and myself, when using a WEB3 wallet for the first time, I eagerly opened the Bitcoin wallet and prepared to copy the address, only to find that the wallet I created actually had multiple different addresses. It felt like standing at a unfamiliar crossroads, utterly confused.
Why are there different addresses? Which of these addresses should be used?
Multiple Bitcoin addresses in OKX wallet
What are these addresses?
The Bitcoin community is a constantly evolving community, and new content is generated as technology advances. Different address formats can be seen as the result of new technological applications. Let’s explore the differences between different address formats.
Legacy Address (P2PKH)
This format was adopted when Bitcoin was first launched in 2009, hence the name “Legacy”. It is also called the Pay-to-Public-Key-Hash (P2PKH) address because Bitcoin addresses were created from public/private key pairs at that time.
Currently, Legacy addresses tend to occupy more space in transactions, resulting in higher transaction fees. Currently, this type of address is only used when using old wallets that are incompatible with new addresses.
One characteristic of Legacy addresses is that they all start with “1”. This is because when generating an address, a prefix is added to the public key based on different scenarios (e.g., testnet/mainnet), and the address, after being computed through hash calculation, will ultimately start with “1”.
Nested SegWit Address (P2SH-P2WPKH)
Compared to the traditional Legacy address, the P2SH address uses the hash of a redeem script instead of the hash of a public key. Simply put, P2PKH pays to the hash of a public key, while P2SH pays to the redeem script. The funds inside can only be spent if the recipient meets the conditions specified in the redeem script.
By changing the payment target from a public key to a script, the flexibility is greatly enhanced, allowing for the customization of the execution logic of the redeem script. A typical application includes implementing multi-signature transactions.
Based on P2SH, if the Segregated Witness (SegWit) technology is included, the address format becomes a Nested SegWit address. You can learn more about Segregated Witness addresses when introducing SegWit addresses. With the introduction of Segregated Witness technology, transaction volume can be reduced, thereby reducing transaction fees.
P2SH addresses start with “3”.
Segregated Witness Address (Native SegWit) Address
Before introducing this address type, it is necessary to introduce the key technology involved, Segregated Witness (SegWit). As the name suggests, Segregated Witness separates the witness data from the main structure for separate processing.
One notable advantage of this approach is the reduction in transaction information size, which in turn reduces transaction fees. Another benefit of the reduced size is the increase in the size limit of Bitcoin block transactions, from 1 MB to 4 MB.
The characteristic of Segregated Witness addresses is that they start with “bc1”.
Taproot Address
The advantage of Taproot addresses lies in privacy and efficiency in complex transaction scenarios. Compared to Native SegWit, Taproot addresses use the Schnorr algorithm instead of the Elliptic Curve Digital Signature Algorithm (ECDSA). The former is more efficient in batch transaction scenarios and improves the privacy of multi-signature wallets.
Taproot addresses generally start with “bc1q”.
Which address format should I choose?
Currently, mainstream wallets such as OKX and Unisat support the above four address formats. Therefore, to reduce transaction fees, it is more reasonable to use Native SegWit and Taproot formats.
Additionally, if you are interested in the intricacies of Bitcoin’s script, then these two address formats are the best choices for you. Most wallets have made additional modifications to the script of these two address formats, protecting your special UTXOs from being mistakenly transferred in transactions. Look for wallet addresses that start with “bc1”!
Of course, wallets with different address formats can still transact funds, so there is no need to worry.
If you want to check Bitcoin balances or block information, feel free to use ZAN’s node service. We provide a rich API for developers to use. API documentation details can be found at: https://docs.zan.top/reference/zan_getbalance-enhance
Going Deeper – Introduction to Key Technologies
After the above introduction, you may have a preliminary understanding of wallets, but if you are interested in some of the technical aspects inside the wallet, just like me, let’s take a look at the mysterious techniques inside.
Redeem Script
When introducing P2SH, we learned that it is a technology for redeem script transactions. But what exactly is a redeem script and what role does it play in the Bitcoin ecosystem?
Before introducing the redeem script, we need to explain the basic structure of a Bitcoin transaction.
Below is a typical P2PK transaction, where an address starting with 04ae wants to transfer 10 BTC to an address starting with 15kD. The account associated with the address starting with 04ae needs to prove to others on the chain that they have the right to use the account (by owning the private key), so they need to provide a signature (ScriptSig) in this transaction to prove their identity.
In addition to obtaining the signature, the validator also needs to find the output script corresponding to the UTXO of the previous transaction. These two scripts concatenated together form the redeem script. The redeem script is used to prove the validity of the transaction.
In this transaction, you can see that the signature and output script are both segments of computer instructions. “OP_PUSHBYTES” indicates pushing a segment of data onto the stack. First, in the ScriptSig, the address starting with 04ae signs the entire transaction with its private key, and the resulting signature is pushed onto the stack. Then, the public key is pushed onto the stack. Finally, in “OP_CHECKSIG”, the signature is decrypted with the public key to compare if the transaction is consistent. If they are consistent, it means the identity is valid.
In addition to the P2PK method, redeem scripts can also implement different identity verification methods such as P2PKH and P2SH.
Segregated Witness (SegWit)
From the above introduction, it can be seen that newer wallet formats currently adopt the Segregated Witness technology. So, what is a witness, and how is it segregated?
The witness here can be considered as the script signature (ScriptSig) information in the basic structure of Bitcoin transactions. Segregated Witness separates the witness from the basic structure and places it in a new data structure.
In the above image, you can see that the essential content of the transaction is reduced to only the information of the transaction source and the transaction output. The size of the transaction is reduced. Since the yellow part (the total size of the transaction) has a size limit, splitting the transaction’s signature for transmission allows a block to accommodate more transactions. Additionally, since the signature part is not included in the calculation of the transaction’s hash value, it effectively solves the problem of transaction malleability.
Below is a P2TR transaction, where you can see that there is an additional Witness part. Its purpose is to verify the validity of the transaction. After using the Witness instead of the ScriptSig, the way to verify the validity remains the same, which is to decrypt the signature in the Witness with the public key and verify if the transaction’s content is consistent. Only when a node needs to verify the legitimacy of a transaction will it request the Witness information. Now, you can connect to the Bitcoin network stably and quickly by using the free ZAN Node service (visit ZAN.TOP).
In summary, Segregated Witness separates the signature part of a transaction from the rest of the content and reduces the size of individual transactions, increasing the capacity of the entire block. Furthermore, since the signature part is not included in the calculation of the transaction’s hash value, it effectively solves the problem of transaction malleability.
This article was written by Yeezo (X account @GaoYeezo 75065) of the ZAN Team (X account @zan_team).
