Contents
When building with Hiro tools, you may need to work with Bitcoin addresses. Maybe you are looking to build an app with support for Ordinals. Maybe you are constructing a Chainhook predicate scoped towards a specific Bitcoin output script. Maybe you’re using the Clarity smart contract language to parse and verify Bitcoin transactions.
Whatever the use case may be, you may have noticed that some Bitcoin addresses look different from one another. That’s because Bitcoin addresses can be generated in different formats.This often leads to confusion amongst new developers. What do phrases like “Legacy”, “SegWit”, and “Pay-to-Script-Hash” mean anyway?
Don’t worry. In this post, we’ll explain what these different formats are and when you should use them.
What Is a Bitcoin Address?
A Bitcoin address is a unique string of characters that you publicly use to send and receive Bitcoin. When someone wants to send you Bitcoin, you share your unique Bitcoin address with them, in the same way you would share an email address if you wanted to get in touch.
Bitcoin addresses can be in several different formats, but at a high level, all public Bitcoin addresses stem from a corresponding public key hash. Bitcoin addresses also pertain to a particular script type.
These addresses will also contain an encoding scheme, a version prefix, and a checksum, but there are differences in how these various address formats are generated, which you’ll see in the visual graphics below.
What Are The Current Bitcoin Address Formats?
There are 4 Bitcoin address formats you will commonly see being used on the Bitcoin network today: Legacy (P2PKH), Nested SegWit (P2SH), Native SegWit (P2WPKH), and Taproot (P2TR).
Legacy Address Format
For Transaction Script Type: Pay-to-Public-Key-Hash (P2PKH)
Example address: <code-rich-text>12rYgz414HBXdhhK72BkR9VHZSU23dqqG7<code-rich-text>
Legacy addresses were commonly used during the early days of Bitcoin. They’re derived from taking a hash160 of the public key, and then base58 encoding that hash along with a version prefix and checksum, resulting in a 20-byte public key hash. Legacy addresses always lead with a <code-rich-text>1<code-rich-text>.
Legacy addresses were commonly used during the early days of Bitcoin.
Legacy addresses were the fix to a previously short-lived method of paying directly to the public key itself, referred to as Pay-to-Public-Key (P2PK). But with Legacy, your bitcoin are actually being sent to your public key hash, hence the script name Pay-to-Public-Key-Hash (P2PKH). In most cases, your wallet software is taking care of decoding your public address to reveal the public key hash for this process.
Legacy addresses, and their corresponding P2PKH scripts, are still supported today by many wallets and apps. And considering its longevity, there are still many early Bitcoin users that are spending and holding their bitcoin in these addresses.
Learn more about Legacy addresses.
Native SegWit Format
For Transaction Script Type: Pay-to-Witness-Public-Key-Hash (P2WPKH)
Example address: <code-rich-text>bc1qhrnucvul769yld6q09m8skwkp6zrecxhc00jcw<code-rich-text>
Native SegWit addresses are now the most common address type you’ll see in wallets today. If your app is focused on delivering Lightning network capabilities or on reducing transaction fees for your users, you’ll need to support Native SegWit addresses.
Native SegWit addresses stemmed from a major network upgrade on Bitcoin back in 2017. This upgrade brought a host of advantages to the network such as block size increases, transaction malleability fixes, and much more.
SegWit made transactions cheaper by moving a specific data field, namely the ScriptSig, into the Witness field, which is not required for transaction ID calculation. This is why SegWit transactions have the “Witness” in its Pay-to-Witness-Public-Key-Hash script type.
Native SegWit addresses are now the most common address type you'll see in wallets today.
Its benefits include using a new bech32 encoding, which is more “efficient” with block space than Legacy’s base58 encoding, and a new faster checksum generation. SegWit address formats also made QR coding faster and more compact, which helped increase the popularity of Bitcoin addresses being used via QR codes.
SegWit also added support for another script type Pay-to-Witness-Script-Hash (P2WSH), which allowed for unmalleable multisig transactions. These transactions are useful for allowing multiple parties to sign off on a transaction without the risk of transaction malleability. As a side note, P2WSH also enabled bidirectional payment channels, a core part of the Lightning network, a Bitcoin L2 payment network.
Lastly, while P2WSH transaction types also took on bech32 (starting with <code-rich-text>bc1q<code-rich-text>) formatted addresses, it's worth noting that they are longer than a normal Native SegWit address.
P2WPKH vs P2WSH address length comparison:
P2WPKH: <code-rich-text>Bc1qhrnucvul769yld6q09m8skwkp6zrecxhc00jcw<code-rich-text>
P2WSH: <code-rich-text>bc1qz0gzt40gkg7yt59wjr6q7sujaxp4nrhkajq4vqjmt6258eesuzfsgchgtm<code-rich-text>
Learn more about BIP173’s Native SegWit address format.
Nested SegWit Format
For Transaction Script Type: Pay-to-Script-Hash (P2SH), (P2SH-P2WPKH), and (P2SH - P2WSH)
Example address: <code-rich-text>3BY19nUKCAkrnzrgRezJoekGv4AFzsTs2z<code-rich-text>
Nested SegWit address formats enable the usage of arbitrary scripts, or a set of flexible conditions, that must be met in order to spend the funds. The flexibility of arbitrary scripts allows for the construction of complex transactions to secure your bitcoin in various ways. Instead of sending to a public key hash, bitcoins are instead sent to a hash of that script, hence Pay-To-Script-Hash (P2SH).
The flexibility of arbitrary scripts allows for the construction of complex transactions to secure your bitcoin in various ways.
The reason why it's referred to as Nested Segwit is because it also allows for backwards compatibility of SegWit transactions, helping to account for older wallets that did not support SegWit at the time of upgrade. This was useful in the early days when many wallets and exchanges did not fully support the SegWit upgrade when it happened. You’ll still see many older bitcoin users and exchanges use this address format to this day.
How did these address formats allow for backwards compatibility of SegWit? After the SegWit upgrade went live on the Bitcoin network, one of the ways that made SegWit backward compatible with older wallets was by “nesting” a Native Segwit (P2WPKH) script inside a P2SH script. Hence the name “Nested” SegWit (P2SH-P2WPKH), since the Native SegWit script is nested or used in place of a P2SH RedeemScript. A Nested Segwit address is a normal P2SH address (starting with <code-rich-text>3<code-rich-text>), but the RedeemScript is the ScriptPubKey of P2WPKH.
Although this address format is being listed after we introduced Native Segwit formats earlier, its usage actually came out before to allow for non-SegWit multi-signature transactions, which were not possible with Legacy addresses (starting with <code-rich-text>1<code-rich-text>). What can get confusing is that addresses starting with a <code-rich-text>3<code-rich-text>, could now be a SegWit compatible address or a multi-signature non-SegWit address. You won’t know until you see how outputs are being spent from that address. As a general rule of thumb today though, an address starting with a <code-rich-text>3<code-rich-text> is usually a Nested Segwit (P2SH-P2WPKH) address.
Read more on BIP13’s P2SH address format.
Taproot Format
For Transaction Script Type: Pay-to-Taproot (P2TR)
Example address: <code-rich-text>bc1p5d7rjq7g6r4jdyhzks9smlaqtedr4dekq08ge8ztwac72sfr9rusxg3297<code-rich-text>
If you’re building a wallet or an app with the intent of supporting Ordinals, BRC20 tokens, or Runes, then you need to support Taproot addresses. All of those assets are only stored in Taproot addresses.
Taproot addresses came from the Taproot upgrade, which was another soft-fork on the Bitcoin network. This upgrade brought many implementations of privacy and scaling enhanced features, such as Schnorr signatures and more efficient scripting capabilities, the latter of which led to the explosion of Ordinals.
Taproot addresses support Bitcoin Ordinals, BRC-20 tokens, and Runes.
Bitcoin devs created this new address format because Native SegWit’s bech32 encoding scheme has an unexpected weakness that would affect future implementations (existing uses in Native SegWit addresses are safe). This motivated the work to release an improved variant bech32m.
Read more on BIP350’s bech32m P2TR address format.
Why Are There Different Formats?
Although Bitcoin development might seem slow compared to other chains, the Bitcoin network has upgraded over time. Bitcoin address formats have evolved to make transactions cheaper and more flexible. As new use cases and transaction types are added to Bitcoin, new address formats are sometimes required to support those innovations and network improvements.
To illustrate how Bitcoin address formats have enabled cheaper transactions over time, let’s look at a typical transaction with one input/output and how its on-chain footprint has gotten smaller over time across these different formats:
- 192 vbytes with Legacy
- 134 vbytes with Nested Segwit
- 112 vbytes with Taproot
- 110 vbytes with Native Segwit
These differences might seem small, but when you add in more complexity to a transaction, and depending on the network congestion, that small difference can be quite expensive.
Do Different Bitcoin Wallets Use Different Address Formats?
Many Bitcoin ecosystem apps and wallets often use different address formats for a wide range of reasons, including internal team preference, supported functions, user demand, the time of creation, and more.
For example, in the world of Stacks, the two most popular wallets use different Bitcoin address formats. Leather uses Native SegWit (addresses starting with <code-rich-text>bc1q<code-rich-text>) whereas Xverse uses Nested SegWit (addresses starting with <code-rich-text>3<code-rich-text>). The reason for that is that Xverse wanted to support stacking back when the protocol didn’t support Native Segwit addresses (though that has now changed).
With the diversity in Bitcoin address formats, many apps and wallets have to make design decisions on how to account for these differences, and as a developer, Bitcoin address formats are yet another detail you need to pay attention to.
Support for these different address types is something we bake into all of our products at Hiro. For example, you can create event streams for all 4 of these address formats when using Chainhook.
Conclusion
Hopefully you now have a better understanding of the differences between Bitcoin address formats. And with that knowledge, you can choose which address formats your app needs to be aware of during development.If you’ve been intrigued by the progression of Bitcoin address formats, check out our free book on Bitcoin’s evolution to learn more about how the ecosystem has evolved over time.
