P2SH-P2WPKH: Backward-Compatible SegWit Addresses

P2SH-P2WPKH

nested SegWit, Often referred to as P2SH-P2WPKH (Pay-to-Script-Hash wrapped Pay to Witness Public Key Hash) is a transitional method of Bitcoin address and transaction. The purpose of its design was to bridge the gap between the efficiency advantages of SegWit transactions and older Bitcoin wallets that did not support native SegWit addresses. In essence, a P2WPKH script is wrapped inside a Pay To Script Hash script.

Purpose and Problem Solved

With the 2017 SegWit (Segregated Witness) update to Bitcoin, new, more effective address formats such as Bech32 which begin with bc1 were added. By transferring signature data to a distinct “witness” structure, these “native SegWit” addresses (P2WPKH and P2WSH) effectively reduce the transaction’s “weight” in a block, resulting in reduced transaction fees and improved efficiency.

All wallets and exchanges did not, however, instantly update their systems to enable transmitting to these new BC1 addresses. Users using native SegWit wallets were unable to receive bitcoins from older, non-SegWit wallets that only knew 1 (P2PKH) or 3 (P2SH) addresses due to this compatibility issue.

The development of P2SH-P2WPKH addressed this compatibility problem. By enclosing the P2WPKH script within a P2SH script, it was possible to use the more effective SegWit transaction structure when the funds were spent, while still allowing an address that resembled a typical P2SH address (beginning with a 3). Users were able to take advantage of reduced fees even if their sender’s wallet did not directly support native SegWit addresses with this “stepping-stone” for SegWit adoption.

How P2SH-P2WPKH Works (The Nesting Process)

P2SH and P2WPKH, the two fundamental transaction types, are combined in this process:

The Redemption Script (Inner Layer)

P2SH-P2WPKH is primarily a P2WPKH script that uses SegWit rules to define the spending conditions. Simple in nature, this script usually looks like OP_0 <20-byte hash of a compressed public key>.

The Locking Script (scriptPubKey – Outer Layer)

This P2WPKH redemption script is hashed by the recipient to generate the address (more precisely,RIPEMD160(SHA256(P2WPKH_script)). After that, a normal P2SH address that starts with a 3 is created using this 20-byte hash. A straightforward P2SH script serves as the blockchain’s locking script for the P2SH-P2WPKH output: OP_HASH160 <20-byte script hash> OP_EQUAL is equal. The majority of legacy wallets can still use it because of this common P2SH scriptPubKey.

Spending the Funds (Two-Stage Process)

The transaction proceeds in two steps when the owner wishes to spend the bitcoins:

Unlocking the P2SH Wrapper: The complete P2WPKH redeeming script is provided by the transaction’s scriptSig (the unlocking script) (e.g., OP_0 <20-byte public key hash>). The script’s hash is initially checked by the Bitcoin network to make sure it matches the script hash from the scriptPubKey of the original output. The transaction’s P2SH component is fulfilled if the hashes match. It is frequently referred to as “Nested P2WPKH” since the scriptSig contains another scriptPubKey.

Unlocking the SegWit Component: After the P2SH wrapper is “unlocked,” SegWit rules govern the network. A new section of the transaction known as the “witness” field contains the public key and the actual signature. The fact that this data is handled independently of the primary transaction data adds to SegWit’s effectiveness and reduced costs. In order to validate the signature against the public key and make sure the public key hashes match the right hash from the redemption script, the network employs this witness data.

Key Characteristics and Trade-offs

Address Format: Addresses from P2SH to P2WPKH always begin with 3. This format is identical to that of other P2SH addresses.

Compatibility: Because of their backward compatibility with the majority of legacy wallets, they can receive money from any wallet that has the ability to transmit to P2SH addresses.

Fee Efficiency/Costs:

• It is less expensive to spend from a P2SH-P2WPKH address than from a classic P2PKH address. The reason for this is that the public key information (the “witness”) and the signature are kept in a discounted portion of the transaction, where each byte only occupies 0.25 virtual bytes of space.
• They cost a little more to spend than native P2WPKH (bc1q) addresses, though, because the redemption script still occupies some space in the scriptSig, the main transaction body, which is not subject to the witness discount.
• The main savings on fees happen when you spend the bitcoins, not when you transmit them.

Complexity: The scriptSig and witness fields are both involved in the multi-step unlocking procedure of P2SH-P2WPKH, making it one of the more difficult scripts to comprehend.

Privacy: P2SH-P2WPKH addresses are identical to other P2SH address types (such as multisig) from a privacy perspective until the money is actually spent, at which time the embedded P2WPKH script becomes visible.

Public Keys: The only public keys used in P2SH-P2WPKH transactions are compressed ones.

Current Status and Historical Significance

P2SH-P2WPKH is still a common technique, but its usage has declined over time as native SegWit (bc1q) addresses are now directly supported by the majority of contemporary wallets and exchanges. It is now regarded as “more of a relic of the past” in daily life.

Although P2SH-P2WPKH is becoming less common, it was historically crucial to SegWit adoption. By offering a necessary transitional period, it made it possible for the network to progressively shift towards more efficient transaction types without requiring an abrupt, disruptive update for all infrastructure and users. It showed how adaptable Bitcoin’s programming language is and how the community can use soft forks to innovate and bring about important advancements. Before completely switching to native bc1q support, many major exchanges and services first used P2SH-P2WPKH to give their users SegWit benefits.

P2SH-P2WPKH was essentially a smart and significant compatibility layer that enabled users to start taking advantage of SegWit’s fee-saving features prior to the full Bitcoin network being updated to support native SegWit addresses.

Summary Table