P2PK

Pay-to-Public-Key (P2PK) is the original method of receiving bitcoin, and it does not involve an address. Instead, as the name suggests, bitcoin is paid directly to an exposed public key. The first ever bitcoin transaction from one person to another used P2PK, when Satoshi Nakamoto sent coins to Hal Finney in Block 170.

P2PK is no longer used because it is a more expensive, less private, and less secure way of receiving bitcoin than subsequent methods.

Quick facts

P2PKH

Pay-to-Public-Key-Hash (P2PKH) was available for use at bitcoin’s beginning, and it showed up on the blockchain for the first time less than two weeks after the genesis block. P2PKH makes several improvements upon P2PK, such as utilizing an address. As discussed in our earlier article, addresses contain a checksum that helps prevent typos and lost bitcoin.

P2PKH addresses are typically 34 or 33 characters in length (but could theoretically be as short as 26 characters), and they are encoded in Base58 format. They begin with a prefix of 1 and are currently responsible for receiving and securing 43% of the mined bitcoin supply, more than any other address type.

Creating a P2PKH address involves putting a single public key through hash functions SHA-256 and RIPEMD-160. This shortens the amount of data, which in turn helps save block space and transaction fees for the user. It also introduces further resistance to reverse-engineering the private key beyond the already believed-to-be-unbreakable secp256k1 elliptic curve.

Quick facts

P2MS

Pay-to-Multisig (P2MS) is a trivial transaction type that was only briefly relevant and has never been responsible for holding more than 100 bitcoin at one time across all network participants. Nevertheless, P2MS is a part of bitcoin’s history.

P2MS was introduced as a standard script in early 2012, as specified by BIP 11. However, this transaction type suffered from the same problems as P2PK since it included exposed public keys and did not use any address format. It also limited the number of public keys in a multisig quorum to three. Within months P2MS would be replaced by an alternative method for receiving bitcoin into a multisig arrangement called P2SH, which we will cover next.

Quick facts

P2SH

Pay-to-Script-Hash (P2SH) was introduced to bitcoin as a soft fork in accordance with BIP 16 on April 1, 2012. Like most forks, the story behind it is fascinating. P2SH shares a lot in common with P2PKH. The main difference is that the address is created by hashing a redeem script instead of hashing a single public key.

A redeem script can be thought of as coded instructions specifying how bitcoin received to the P2SH address can be spent in the future. There could be a wide range of possibilities, including multiple different public keys. The receiver, not the sender, determines the script details, and the spending instructions are not exposed publicly until bitcoin is spent out of the address.

While advanced users can construct complex scripts, the most common uses for P2SH have been to create Nested SegWit addresses (covered below) and multisig wallets. For example, a script can include three public keys and specify that signatures from any two of the corresponding private keys can spend the bitcoin. This would create a 2-of-3 multisig address.

P2SH addresses are exactly 34 characters in length, and they begin with a prefix of 3, as specified by BIP 13. Before the soft fork on April 1st, a handful of transactions experimented with this alternative prefix, the first of which is found in Block 170,052.

Quick facts

P2WPKH

Pay-to-Witness-Public-Key-Hash (P2WPKH) is the first of two address types introduced to bitcoin upon the SegWit soft fork in August 2017. The story behind this extremely important and particularly contentious soft fork is documented in a book called The Blocksize War, written by Jonathan Bier.

P2WPKH is the SegWit variant of P2PKH, which at a basic level, means that choosing this address type rather than older P2PKH addresses will help you save money on transaction fees when moving your bitcoin around.

SegWit addresses look quite different from the older address types because, per BIP 173, they use Bech32 encoding instead of Base58. Most notably, there are no capital letters in Bech32. P2WPKH addresses can be identified by a prefix of bc1q and a character length of exactly 42.

Quick facts

P2WSH

Pay-to-Witness-Script-Hash (P2WSH) is the SegWit variant of P2SH. The main advantage to using P2WSH over P2SH is that it can help lower transaction fees, and the primary reason to use a script hash instead of a public key hash is to accommodate multisig arrangements.

Like P2WPKH, a P2WSH address begins with a prefix of bc1q. However, it has a longer character length of exactly 62. Unlike the address types covered thus far, P2WSH addresses are created using the SHA-256 hashing function alone, without including RIPEMD-160, resulting in the increased character length. This was implemented cautiously, adding extra protection from a fairly nuanced and extremely unlikely multisig attack vector.

Quick facts

Nested SegWit (P2SH-P2WPKH and P2SH-P2WSH)

Nested SegWit (also known as Wrapped SegWit) is technically not a different address type than we’ve covered above. Still, it is a unique way to use previously discussed address types in a manner that was temporarily useful for the bitcoin community.

When the SegWit soft-fork occurred, not all bitcoin nodes, software, and services immediately upgraded to support the new Native SegWit address types, P2WPKH and P2WSH. Only the entities that did upgrade could send to these new addresses. This meant that folks who wanted the ability to receive bitcoin from anybody (including those who hadn’t upgraded) couldn’t use a Native SegWit wallet yet. However, since SegWit offered cheaper transaction fees, most people were keen to begin using it.

The crafty solution to this dilemma was to utilize the P2SH transaction type. The entities that had not yet implemented SegWit could still send bitcoin to P2SH addresses—which, as discussed above, are built with a redeem script specifying the instructions on how the bitcoin can be spent later on. As it turns out, these instructions could incorporate the new SegWit spending model, providing users with a bridge to reduced fees. Therefore, the P2SH addresses using this trick became known as Nested SegWit, and they played a significant role in the SegWit adoption process.

On the surface, Nested SegWit addresses are indistinguishable from other P2SH addresses, so the supply of bitcoin held in this arrangement is unknowable. Additionally, since all modern bitcoin tools can now send directly to Native SegWit addresses, there is no longer any good reason to use Nested SegWit.

Quick facts

P2TR

Pay-to-Taproot (P2TR) is the newest address type, made available by the Taproot soft-fork in November 2021. P2TR adoption remains quite low at the time of writing, and many bitcoin softwares and services are still working on integration.

While P2WPKH and P2WSH are known as SegWit V0, P2TR is considered SegWit V1. Notably, P2TR utilizes a digital signature algorithm called Schnorr, which differs from the ECDSA format used in earlier bitcoin transaction types. Schnorr signatures have several advantages, including additional transaction fee reductions and increased privacy.

Regarding privacy, the key and signature aggregations made possible by Schnorr allow multisig addresses to be indistinguishable from singlesig, and the spending conditions for a P2TR address are never revealed publicly. The creator of the address can even include multiple customized redeem scripts to choose from in order to spend the bitcoin later.

P2TR addresses are 62 characters long, and they use Bech32m encoding, a slightly modified version of Bech32, as described in BIP 350. P2TR addresses can be identified by their unique bc1p prefix.

Quick facts

Reference chart

Now that we have covered all standardized methods to receive bitcoin on-chain, some of the quick facts and address features can be combined into a convenient chart for reference.

• Data in these columns are subject to change.

Disclaimer：

1. This article is reprinted from [unchained]. All copyrights belong to the original author [Tom Honzik]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.