Legacy and SegWit are terms used to describe different types of addresses and spending conditions on the Bitcoin network. These names may seem strange and confusing to beginners, but the main formats are fairly easy to distinguish: Legacy addresses usually begin with “1”, P2SH addresses with “3”, and native SegWit addresses with “bc1q”.
Despite the technical complexity of the subject, Bitcoin address types are important for anyone entering the world of cryptocurrency. In previous articles, we have already discussed what Bitcoin is, the different types of Bitcoin wallets and how to buy BTC. This information may appear sufficient to become a fully fledged cryptocurrency user, but understanding the differences between address formats is also important for transferring funds safely.
These differences can understandably confuse users. Firstly, it may not be immediately clear why several formats exist. Secondly, users may worry about losing funds when transferring Bitcoin between different address types. Caution is justified: before sending, you should check the network, the address and whether the service supports the relevant format. However, standard addresses belong to the same Bitcoin network, and provided that the wallet supports them, transfers between the formats are completed in the usual way — the situation is not as alarming as it may initially seem.
In this article, we will examine the main features of Bitcoin addresses, explain the differences between Legacy, P2SH and SegWit, and show that choosing an appropriate format is not particularly difficult in practice.
Key Takeaways
- Legacy, P2SH and SegWit are different formats for representing the conditions under which BTC can be spent. They operate on the same Bitcoin network but differ in transaction structure, compatibility and the efficiency with which they use block space.
- Legacy P2PKH addresses begin with “1”. They are supported by almost all Bitcoin services, but spending coins received at these addresses generally requires a larger virtual size and, at the same sat/vB rate, a higher fee.
- Addresses beginning with “3” are P2SH addresses. They may contain different spending conditions, including multisignature arrangements and compatible SegWit P2SH-P2WPKH, so the “3” prefix alone does not mean that an address is necessarily multisignature or SegWit.
- Native version 0 SegWit addresses use the Bech32 format and usually begin with “bc1q”. They provide stronger error detection and use block space more efficiently. Taproot addresses begin with “bc1p” and are encoded using Bech32m.
- The network fee depends on the transaction’s virtual size and the selected sat/vB rate rather than the value of the amount being transferred. SegWit may reduce virtual size, but it does not guarantee fixed savings or faster confirmation.
What Is a Bitcoin Wallet Address?
A Bitcoin wallet address is a convenient representation of a spending condition to which BTC is sent. It can be loosely compared with payment details used to receive funds, although technically an address is not a bank account and does not store coins inside it. To make a transfer, the user enters the recipient’s address, while the recipient provides this address to the sender. The right to spend the received BTC is confirmed using the corresponding private keys and wallet scripts.
During Bitcoin’s early years, Legacy P2PKH was the most widely used format. However, P2SH was introduced to the network in 2012, and after SegWit was activated in 2017, new spending conditions and address formats became common. Not only did the visual representation of addresses change, but so did the way signature data was placed and accounted for in transactions.
Let us examine the main types of Bitcoin addresses and the important features of each one.
What Is a Legacy Bitcoin Address?
A Legacy P2PKH address — Pay-to-Public-Key-Hash — is the classic Bitcoin payment destination format included in early versions of the protocol and still supported by most crypto wallets, exchanges and services.
This type of address can be identified by the number “1” at the beginning. Funds are sent to a hash of the public key, and when spending them, the owner reveals the corresponding public key and provides a valid digital signature.
Legacy has remained a widely compatible format since the launch of the Bitcoin network. However, it is no longer always the most economical option for new wallets and regular transactions.
Despite the widespread use of Legacy addresses, they have several practical characteristics and disadvantages:
- Base58Check is case-sensitive, so changing an uppercase letter to lowercase, or vice versa, changes the address; the long string is also inconvenient to copy by hand;
- with the same number of inputs and outputs, a Legacy transaction usually has a larger virtual size than a comparable SegWit transaction, so its total fee will be higher at the same sat/vB rate;
- Legacy P2PKH uses secure ECDSA signatures on the secp256k1 curve but does not benefit from SegWit features such as the witness-data discount, signature separation and correction of the principal form of third-party TXID malleability;
- classic transactions may be subject to third-party transaction identifier malleability because signature data is included in the calculation of the TXID.
Technical details! For a P2PKH address, the public-key hash is encoded using Base58Check. This is not simply a conversion of the public key into Base58: a version byte and checksum are added to the hash, after which the result is represented using the Base58 alphabet. This format resembles Base64 only in the general concept of representing binary data as text, but it uses a different alphabet and includes built-in error checking.
The Base58 alphabet excludes visually similar characters: 0 — zero, O — an uppercase Latin “o”, I — an uppercase Latin “i”, and l — a lowercase Latin “L”. The “+” and “/” characters used in Base64 are also excluded from Base58. This reduces the likelihood of errors when reading, copying or writing an address by hand.
At first glance, these disadvantages may seem insignificant, but as demand for Bitcoin block space increased and new use cases developed, transaction efficiency became increasingly important.
A transaction fee is paid in satoshis and calculated according to the operation’s virtual size and the rate in sat/vB. An increase in BTC’s market price may raise the fiat equivalent of a fee that has already been set, but the fee mechanism itself depends primarily on demand for block space. When transferring BTC worth the equivalent of USD 10,000, a USD 5 fee may seem small, but for a micropayment the same fee would represent a substantial share of the transferred amount. More compact transaction types are therefore particularly useful during periods of high network congestion and when many inputs are used.
What Are SegWit and a SegWit Bitcoin Address?
Until the end of summer 2017, most BTC users worked primarily with Legacy and P2SH addresses. On 24 August 2017, the Segregated Witness soft fork was activated on the Bitcoin network at block height 481,824. The main SegWit specification was published as BIP141 and prepared by a group of developers including Eric Lombrozo, Johnson Lau and Pieter Wuille.
The upgrade introduced the witness structure for data required to verify signatures, as well as new SegWit outputs: P2WPKH — Pay-to-Witness-Public-Key-Hash — and P2WSH — Pay-to-Witness-Script-Hash. The Bech32 format was subsequently standardised as a convenient representation for native version 0 SegWit addresses.
Segregated Witness separates witness data, including signatures and unlocking scripts for SegWit inputs, from the main part of the transaction serialisation used to calculate the TXID. However, this data is not removed from the blockchain or stored outside it: it is transmitted, verified and committed to the block through a separate witness commitment.
Brief description of the technology: SegWit changed the transaction structure and the method used to calculate its weight. Data without witness information is counted with a factor of four, while each witness byte is counted with a factor of one. The maximum block weight is 4,000,000 units, so a block may contain more operations when a substantial share of their data is witness data. SegWit also corrected the principal form of third-party TXID malleability for SegWit inputs and created a foundation for more reliable second-layer protocols, including the Lightning Network. However, the upgrade did not eliminate the fee market: confirmation speed still depends on the sat/vB rate, current mempool congestion and miners’ decisions.
The upgrade did not change the public-key format itself. Instead, it affected the rules used to form transaction outputs and inputs, the structure of witness data and the address-encoding methods used for new payment destination types.
Native version 0 SegWit addresses use Bech32 and usually begin with “bc1q”. Bech32 is case-insensitive provided that the entire string uses the same case: the address may be written entirely in lowercase or entirely in uppercase. Uppercase and lowercase characters must not be mixed within the same address. For example, the lowercase version bc1qnnc… and the fully uppercase version BC1QNNC… may be valid representations, while the mixed-case version bc1Qnnc… must be rejected. In practice, wallets usually display addresses in lowercase.
The Bech32 format simplified automatic address validation and made addresses more convenient for QR codes and machine processing. The advantages of native SegWit addresses include:
- a checksum designed to identify common errors reliably when entering and copying addresses;
- more efficient use of block weight, allowing a block to include more comparable transactions;
- a smaller virtual size when spending P2WPKH compared with P2PKH, which usually means a lower total fee at the same sat/vB rate.
Historically, the main disadvantage of native SegWit was incomplete support for Bech32 addresses among older wallets and services. Support is now considerably broader, but before making a large transfer, users should still check whether the relevant platform accepts “bc1q” or “bc1p” addresses. During the transition period, a compatible form of SegWit nested within P2SH was used.
Legacy and SegWit address support is available in Trustee Wallet, as well as in popular solutions such as Trezor, Electrum and Ledger hardware wallets. Available formats and the location of settings may vary depending on the application or firmware version.
What Are Multisignature, P2SH and Compatible Addresses?
The P2SH format appeared on the Bitcoin network in 2012 not as a direct solution to high fees, but to simplify payments to complex spending conditions. The sender only needs to specify a fixed-length script hash, while the recipient reveals the script itself and the required data when spending the coins.
Developer Gavin Andresen proposed the BIP16 upgrade, which transferred responsibility for providing the spending conditions from the sender to the recipient. P2SH makes it possible to send BTC to the hash of a programmable Bitcoin Script, including multisignature conditions. Such conditions functionally resemble limited smart contracts but differ from Ethereum’s smart-contract model.
After P2SH was implemented on the main network, addresses beginning with the number “3” appeared. It is important to remember that the same prefix is used for different scripts: an address beginning with “3…” may represent a multisignature arrangement, compatible SegWit P2SH-P2WPKH or another P2SH condition.
The textual representation of P2SH has a structure similar to Legacy: both formats use Base58Check but have different version bytes and encode different hashes. Multisignature wallets often use an m-of-n arrangement, such as 2-of-3, in which any two valid signatures from three designated keys are required to spend the funds. It would be inaccurate to say that a single address simply “has two or three private keys” — the number of participants and the signatures required are defined by the script conditions.
Rather than exploring the Bitcoin Script system in excessive technical detail, let us consider how P2SH interacts with Legacy and SegWit.
Older wallets created before Bech32 became widespread might not recognise “bc1” addresses. For backward compatibility, SegWit could be nested within P2SH, producing the P2SH-P2WPKH or P2SH-P2WSH format, often called Compatible SegWit or Nested SegWit. An older wallet recognises an address beginning with “3…” as an ordinary P2SH address and can send BTC to it, while the owner spends the resulting output using witness data. This option is generally more efficient than Legacy, although native Bech32 SegWit normally requires even less data. However, not every address beginning with “3…” is Compatible SegWit — the exact condition can only be identified once the script is revealed during spending.
Moving from Legacy to SegWit in Trustee Wallet
After SegWit was introduced in Trustee Wallet, some users asked: “How can this happen? I sent part of my BTC, but the wallet showed the whole selected input as spent.” This display is related to the UTXO model and the creation of a change output rather than the loss of the remaining balance.
To answer this question, it is necessary to examine the Bitcoin transaction mechanism in slightly greater detail.
Bitcoin does not store a balance as a single adjustable number in an account. A wallet manages a set of unspent transaction outputs, or UTXOs. When sending funds, it selects one or more UTXOs, spends them completely as inputs and creates new outputs: one or more for the recipients and, where there is a remaining amount, a change output sent to an address controlled by the same wallet. The wallet does not have to use the entire available balance: the coin-selection algorithm chooses only the UTXOs needed to cover the payment amount and fee.
When SegWit support was available in Trustee Wallet, the following migration feature may have been used: when spending a UTXO received at a Legacy address, the change output was created at a SegWit address belonging to the same wallet. This allows the user’s funds to move gradually from P2PKH to a more efficient format without a separate transaction between their own addresses. The word “free” should be understood conditionally in this context: a separate migration operation is not required, but the ordinary network fee for the original transaction must still be paid. The exact change-address selection behaviour depends on the wallet version and settings.
Conclusion
Technology does not stand still, and the protocols and software within the cryptocurrency ecosystem continue to develop. New address formats are introduced to improve efficiency, expand script capabilities, strengthen error detection and support new Bitcoin use cases.
Above, we examined the main Bitcoin address types and explained the differences between Legacy P2PKH, P2SH, Compatible SegWit and native Bech32 SegWit. The Trustee Wallet team supports widely used address formats. Before transferring BTC, always check the network, the recipient’s complete address, support for the selected format and the calculated network fee.
Frequently Asked Questions About Legacy and SegWit Bitcoin Addresses
What is the difference between a Legacy address and a SegWit address?
Legacy P2PKH begins with “1” and uses the classic transaction structure. Native SegWit P2WPKH usually begins with “bc1q” and stores the signature in the witness section. Under comparable conditions, spending a SegWit output has a smaller virtual size, so the fee is usually lower at the same sat/vB rate.
Can BTC be sent from a Legacy address to a SegWit address?
Yes. The different standard formats operate on the same Bitcoin network. Transfers between Legacy, P2SH and SegWit are possible provided that the sending wallet recognises the recipient’s address format. Older services may not support “bc1”, so compatibility should be checked before sending, and a small test transfer should be considered first.
Why do some Bitcoin addresses begin with “1”, while others begin with “3” or “bc1”?
The prefix indicates the encoding format and type of spending condition. “1” usually represents Legacy P2PKH, “3” represents P2SH, including multisignature or Nested SegWit, “bc1q” represents native version 0 SegWit, and “bc1p” represents version 1 Taproot. An address beginning with “3” cannot automatically be treated as SegWit or multisignature without examining the revealed script.
Does SegWit always reduce fees by 50%?
No. The amount saved depends on the number and types of inputs and outputs, the script used and the transaction structure. SegWit applies a discount to witness data and often reduces the virtual size, but there is no fixed percentage saving. The total fee is calculated by multiplying the virtual size by the selected sat/vB rate.
Which Bitcoin address type is best to use?
For new ordinary transfers, native SegWit “bc1q” is generally a convenient and economical option provided that both the sender and recipient support it. Legacy may be appropriate when compatibility with an older service is required. P2SH may be needed for Nested SegWit or specialised scripts, while Taproot “bc1p” is intended for wallets and use cases supporting version 1 SegWit.
