Whether you want to spend Bitcoin or just receive it, Bitcoin addresses are ubiquitous. For ordinary users, they are often the first and therefore most important point of contact with the Bitcoin network. This makes it all the more relevant to recognize and, of course, understand the differences between the various formats. In this article, we therefore take a closer look at the four common standards for simple Bitcoin wallets and compare the differences.
However, some terminology should be clarified first. A Bitcoin address is not a unique "address on the blockchain", as the name initially suggests, but rather a set of instructions. It explains to the wallet software used how the recipient would like to receive their Bitcoin. So when we talk about different address formats, we don't just mean the building instructions themselves, which can differ in their structure and appearance, but above all what is to be built from them: the Bitcoin script. Similar to a small computer program, this defines the conditions for being allowed to spend a certain amount of Bitcoin.
A different address format therefore also means a completely different wallet standard, which may or may not offer additional functions. Different address formats also lead to different storage space requirements in the transactions themselves, which is ultimately decisive for the transaction fees. In this article, we will therefore not only look at the addresses themselves, but also at what lies behind them.
Reading tip: The Bitcoin script language explained simply
The dinosaur among the Bitcoin standards, which for this reason is also known simply as "Legacy", was the first to introduce the concept of addresses. Bitcoin used to be sent directly to a public key, which was obvious, but unfortunately also impractical and expensive. After all, a single public key is quite long. The idea of making transactions to a shorter hash value of a public key instead was born, and with it the Pay-to-Public-Key-Hash (P2PKH ) script standard. A basic principle that is still actively used today.
However, a legacy address not only contains this hash value, i.e. the actual "account number" of the recipient, but also has several other properties that are primarily intended to improve the user experience and reduce susceptibility to errors in everyday life. This starts with the letters and numbers used to encode a legacy address: Ambiguous characters such as the letter O and the number 0, for example, are not used at all. In addition, a so-called checksum is placed at the end of the address. This is directly linked to the actual content in a clever mathematical way so that it would be invalid in the event of a typing error. So if you enter an "incorrect" address into a Bitcoin wallet, it still has the option of recognizing the error and warning the user.
A legacy address can be recognized by the version number 1, which is always placed at the beginning:
1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
At first glance, the wrapped Segwit or nested Segwit standard is probably the strangest, especially from today's perspective. At the time, however, with the Segwit update in 2017, it was crucial in order to benefit from the lower transaction fees made possible by Segwit as easily as possible and without major changes. Although the name "Segwit" is in the name, it is actually just another legacy standard called Pay-to-Script-Hash (P2SH). This was and is still used today for more complex custody methods such as multisig wallets, as transactions can be made not to a hash of a public key as described above, but to the hash of an entire Bitcoin script. This simply offers significantly more options.
P2SH addresses have a different version number, namely they start with a 3, but otherwise work in the same way as the P2PKH addresses described above. It is therefore crucial at this point: Just because an address starts with a 3 does not automatically mean that it is based on the wrapped Segwit standard.
37sfXRaSVnTXHP751Na7ZrfyzST1FHakCv
But what exactly constitutes a wrapped Segwit address? At first glance, at least from the outside, nothing at all. The trick lies buried in the script standard used, which is hidden behind the script hash of the address. Without anticipating the next section too much, a new wallet standard was created with the Segwit update. This offered a number of advantages, but not all existing wallet software was able to support the new standard from one day to the next. Even if your own wallet was already fully "Segwit-enabled", you could not always assume that this would also apply to other transaction partners. To avoid falling into a compatibility nightmare, it was therefore necessary to find a way for older wallets to be able to carry out transactions on newer Segwit wallets without having to completely forego the advantages of Segwit.
The new standard, pay-to-witness public key hash (P2WPKH), which is discussed in more detail in the following section on native Segwit, was therefore simply wrapped in a conventional P2SH script. A hybrid of old and new was created, which enabled a compromise between broad support and the advantages of Segwit.
Explaining the Segwit update and all its benefits in one paragraph would go beyond the scope of this article, but we can at least take a closer look at the most relevant aspect for end users: lower transaction fees. As a reminder, the amount of the fee charged for a transaction depends on the size, i.e. the storage space used, and not the amount of Bitcoin. A transaction that follows the native Segwit standard can save around 30% of these fees on average.
Reading tip: The Segwit update explained simply
But how is this possible? Is the structure of a P2WPKH script more efficient and takes up less space? No, not at all. The lower fees, also known as the Witness Discount, are purely artificial due to a design decision. With Segwit, we attach a trailer, so to speak, to the original Bitcoin block, which can be a maximum of 1 MB in size, and simply outsource data such as digital signatures. The more transactions use this additional storage space, the more space remains in the original block. The free fee market values such transactions accordingly, as more transactions fit into a block and these are financially more attractive for Bitcoin miners.
However, it is not just the background that is new; the format of the Bitcoin addresses themselves has also changed with native Segwit. The bech32 coding is not only more performant, but also enables even better error detection. Native Segwit addresses can be recognized by the first four characters bc1q.
bc1qnj2502g4eeu9h2pp669xxl6vkseepmgrfjgx6q
Note: Virtual bytes (vB) are used to indicate the size in order to illustrate the benefit of using Segwit and make it more comparable with previous transaction sizes. These directly include the fourfold reduction of data in the "Segwit trailer". This size unit is therefore relevant for the calculation of transaction fees, but not for the actual storage space used on a hard disk.
With the Taproot update in November 2021, the Bitcoin network received an elegant new signature algorithm and many technical innovations that open up some exciting possibilities, which we discuss in more detail in our article on the Taproot update. For ordinary users of a standard Bitcoin wallet, many of the advantages made possible by Taproot are not particularly relevant at first glance.
However, switching to Taproot addresses and the new Pay-to-Taproot (P2TR) standard can still be worthwhile. To name a few advantages:
But let's be honest: the vast majority of users are particularly interested in one thing: Saving fees. And the current Native-Segwit standard already does this very well. In many cases, native Segwit is even cheaper today. But there is one thing to bear in mind: While Taproot outputs have actually become larger, some savings have been made on inputs. Transactions with relatively more inputs than outputs are therefore cheaper with Taproot and therefore particularly interesting for users of a Bitcoin savings plan.
If the adoption of the Taproot standard increases significantly in the future, the advantage of the smaller outputs of native Segwit will gradually disappear. After all, the outputs of a transaction cannot be chosen by the sender, but are dependent on the wallet used by the recipient. If the recipient wants to receive their Bitcoin on a Taproot address, they have to pay for the slightly larger output themselves. However, support from wallets and service providers such as crypto exchanges still needs to increase significantly before this happens.
As far as the format of the addresses themselves is concerned, there has only been a small cosmetic improvement that fixed a bug in the bech32 process. Taproot addresses are therefore encoded using the adapted bech32m method and also have a different version number, which can be recognized by the fourth character p instead of q , i.e. bc1p.
bc1psvs8lx0kz3dl5nfnfkdjl3dy4vw3p34y97ytqt34hcapjeryn0gqg6njml
Let's take a closer look at the specific sizes of the inputs and outputs with the various wallet standards.
For slightly more meaningful figures, we also simulate two typical transactions, with one input and two outputs - and vice versa.
| Legacy (P2PKH) |
Wrapped-Segwit (P2SH-P2WPKH) |
Native-Segwit (P2WPKH) |
Taproot (P2TR) |
|
|---|---|---|---|---|
| Starts with... | 1... | 3... | bc1q... | bc1p... |
| Coding | Base58Check | Base58Check | bech32 | bech32m |
| Overhead | 10 | 10 | 10,5 | 10,5 |
| Inputs | 148 | 91 | 68 | 57,5 |
| Outputs | 34 | 32 | 31 | 43 |
| 1-in-2-out | 226 | 165 | 140, | 154 |
| 2-in-1-out | 340 | 224 | 177,5 | 168,5 |
| Compatibility | High | Very high | High | Relatively low |
The four common script and address standards for single-sig wallets in size comparison | Data in virtual bytes (vB)
