TL;DR: Bitcoin supports multiple transaction types, each defining different spending conditions through the Bitcoin scripting system. Legacy types (P2PKH, P2SH) use more block space and cost more in fees. SegWit types (P2WPKH, P2WSH) move signature data to a separate witness section, reducing fees by 30-40%. Taproot (P2TR) uses Schnorr signatures for the lowest fees on complex transactions and improved privacy, making cooperative multisig spends indistinguishable from singlesig on-chain. For most users, native SegWit (P2WPKH) or Taproot (P2TR) is the best choice.
A Bitcoin transaction type defines the conditions under which bitcoin can be spent. Each type specifies a different script that locks bitcoin to an address and determines what proof the spender must provide to unlock it. The type determines the address format, the transaction size, the fee cost, and the privacy properties of the transaction. Bitcoin's scripting system has evolved from simple pay-to-public-key-hash (P2PKH) scripts in 2009 to Taproot (P2TR) scripts activated in 2021, with each generation improving efficiency, flexibility, or both.Why Bitcoin Has Different Transaction Types
Bitcoin has many ways to send and receive funds because its scripting system is programmable, and each script defines the conditions under which bitcoin can be spent. Each transaction contains a small script that acts as a lock: it specifies what proof the next spender must produce. That proof might be a single digital signature, multiple signatures from different keys, a time delay, or a combination of conditions.
Different transaction types are different locking and unlocking patterns built on top of this scripting system. Each type represents a design choice about security, efficiency, and capability. The earliest transactions used simple scripts. Over time, the Bitcoin protocol introduced new script types that use less block space, support more complex spending conditions, and offer better privacy.
The transaction type also determines the address format. When you see a Bitcoin address starting with 1, 3, bc1q, or bc1p, you are looking at different transaction types. Each prefix corresponds to a different script structure, a different witness format, and a different fee profile. Understanding these types explains why the same amount of bitcoin costs different fees to send depending on the address format involved.
Legacy Transaction Types
The original Bitcoin transaction types date back to the earliest versions of the protocol. They work reliably and are universally supported, but they use more block space than newer formats. Every byte of extra data in a transaction means higher fees.
P2PK (Pay-to-Public-Key)
P2PK is the oldest transaction type in Bitcoin. It pays directly to a raw public key. Satoshi Nakamoto's coinbase transactions from the earliest blocks used P2PK scripts. The locking script simply contains the recipient's full public key, and spending requires a valid signature from the corresponding private key.
P2PK has two significant drawbacks. First, the full public key (33 bytes compressed, 65 bytes uncompressed) sits directly in the transaction output, exposed on the blockchain. Second, P2PK offers no address format. There is no address checksum, which means no protection against transcription errors. For these reasons, P2PK was effectively replaced by P2PKH almost immediately and is not used in modern transactions. Its primary relevance today is historical: Satoshi's earliest bitcoin sits in P2PK outputs, and those coins remain spendable only by whoever holds the corresponding private keys.
P2PKH (Pay-to-Public-Key-Hash)
P2PKH was the original standard for Bitcoin transactions and the first type most people encountered. Addresses start with 1 (for example, 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa). Instead of embedding the full public key in the output, P2PKH stores only a hash of the public key (a 20-byte RIPEMD-160 hash of the SHA-256 hash of the public key). The locking script follows a specific opcode sequence: OP_DUP OP_HASH160 <20-byte pubkey hash> OP_EQUALVERIFY OP_CHECKSIG.
This hashing provides two benefits. First, it creates a shorter, standardized address format with a built-in checksum, catching typos before a transaction is broadcast. Second, it adds a layer of quantum resistance: the public key is not revealed on-chain until the bitcoin is spent, so an attacker cannot target the key before the owner moves their funds.
To spend a P2PKH output, the spender must provide both the original public key and a valid signature. The network hashes the provided public key, verifies it matches the stored hash, and then validates the signature against that key.
P2PKH still works and all Bitcoin nodes accept it, but it is less efficient than newer types. The signature and public key data sit in the transaction input section, which counts at full weight for block space calculations. A typical P2PKH input is roughly 148 bytes.
P2SH (Pay-to-Script-Hash)
P2SH, introduced in 2012 through BIP 16, was a major advance in flexibility. Instead of paying to the hash of a public key, P2SH pays to the hash of an arbitrary script. This means the sender does not need to know or care about the spending conditions. The sender just pays to a script hash. The spending conditions are only revealed when the recipient spends the funds.
P2SH addresses start with 3. The most common use case is multisig: a 2-of-3 multisig setup, for example, requires two out of three designated private keys to sign a transaction. The full multisig script, including all three public keys and the signing threshold, is hashed into a single 20-byte value that becomes the address. When spending, the full script (called the "redeem script") is revealed along with the required signatures.
P2SH also enabled time-locked scripts, hash-locked scripts (used in cross-chain atomic swaps and Lightning payment channels), and other complex spending conditions. Before P2SH, the sender had to include the entire spending script in the output, making complex transactions expensive and impractical. P2SH moved that cost to the spender, who reveals the script only when spending.
The trade-off: P2SH is still a legacy format. Its script data is not covered by the SegWit discount, so complex P2SH transactions (especially multisig with many keys) can be expensive. SegWit and Taproot offer more efficient alternatives for the same functionality.
SegWit Transaction Types
Segregated Witness (SegWit), activated in August 2017, restructured how Bitcoin transactions store signature data. The key change: witness data (signatures and public keys used for validation) is separated from the transaction data and placed in a new "witness" section that receives a 75% discount on block weight calculations. This means SegWit transactions use less effective block space and cost less in fees, even though they carry the same information.
SegWit also fixed transaction malleability, a long-standing issue where third parties could modify transaction IDs without invalidating the transaction. This fix was a prerequisite for the Lightning Network and other layer-2 protocols that depend on stable transaction IDs.
P2WPKH (Pay-to-Witness-Public-Key-Hash)
P2WPKH, defined in BIP 141 and BIP 143, is the SegWit equivalent of P2PKH. It uses the same underlying cryptography (a single public key hash, a single signature), but moves the signature and public key into the witness section instead of the scriptSig. This structural change reduces the effective transaction size by roughly 30-40% compared to P2PKH. The Blockstream app uses P2WPKH (native SegWit) as its default address type for Bitcoin transactions, giving users lower fees on every payment without requiring any configuration.
P2WPKH addresses use bech32 encoding (BIP 173) and start with bc1q. A typical P2WPKH address looks like bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4. The bech32 format is case-insensitive (all lowercase), uses a BCH error-correction code that can detect up to four character errors, and encodes more compactly in QR codes than the Base58 encoding used by legacy addresses.
A typical P2WPKH input is about 68 virtual bytes, roughly 272 weight units (compared to 148 vbytes for P2PKH, or 592 weight units). For a standard single-input, two-output transaction, this translates to meaningful fee savings on every payment.
P2WPKH is the most common transaction type on the Bitcoin network today. It is the default for most modern wallets, and nearly all exchanges and services accept bech32 addresses. If you are sending standard payments and want the best balance of broad compatibility and low fees, P2WPKH is the practical default.
P2WSH (Pay-to-Witness-Script-Hash)
P2WSH is the SegWit equivalent of P2SH. It supports the same complex spending conditions (multisig, time locks, hash locks) but benefits from the SegWit witness discount. The script and all signatures move to the witness section, significantly reducing the effective cost of complex transactions.
P2WSH addresses also start with bc1q, but they are longer than P2WPKH addresses because they encode a 32-byte SHA-256 hash (compared to P2WPKH's 20-byte hash). A P2WSH address is 62 characters long; a P2WPKH address is 42 characters long. The longer hash provides a stronger security margin against hash collisions, which matters more for complex scripts that control larger amounts of bitcoin.
The savings on multisig transactions are substantial. A 2-of-3 multisig P2WSH input costs roughly 60% less in fees than the equivalent P2SH multisig, because all three public keys and both signatures sit in the discounted witness section. For institutions and custody operations that execute hundreds or thousands of multisig transactions per month, this adds up to significant operational savings.
Taproot Transaction Type
Taproot, activated in November 2021, is the most recent major upgrade to Bitcoin's transaction types. It introduces Schnorr signatures (replacing ECDSA for Taproot outputs), Merklized Abstract Syntax Trees (MAST), and a new key path/script path architecture that fundamentally changes how complex transactions appear on-chain.
P2TR (Pay-to-Taproot)
P2TR, defined in BIP 341 (Taproot) and BIP 340 (Schnorr signatures), uses bech32m encoding (BIP 350, an updated version of bech32 with improved error detection). Addresses start with bc1p. A Taproot output commits to a single public key, but that key can represent two distinct spending paths:
- Key spend path: The output is spent with a single Schnorr signature against the committed public key. On-chain, this looks identical to a simple singlesig payment, regardless of what spending conditions may be hidden behind it. This is the common case and the cheapest to spend.
- Script spend path: The committed public key is actually a "tweaked" key that incorporates a Merkle root of multiple possible spending scripts. Any one of those scripts can be used to spend the output, and only the script actually used is revealed on-chain. The other scripts remain hidden. This is MAST in practice.
Schnorr Signatures and Key Aggregation
Schnorr signatures have a mathematical property that ECDSA lacks: they support linear key aggregation. Multiple public keys can be combined into a single aggregate key, and multiple signatures can be combined into a single aggregate signature. The result is that a 3-of-3 multisig transaction, when all parties cooperate, produces a single signature and a single key on-chain. That transaction is indistinguishable from a standard singlesig payment.
Key aggregation has direct privacy implications. Before Taproot, anyone looking at the blockchain could identify multisig transactions by their distinctive script structure (multiple public keys and signatures in the witness data). With Taproot key aggregation, cooperative multisig spends look like ordinary payments. An observer cannot determine whether an output was controlled by one person or five.
MAST: Hiding Unused Spending Conditions
MAST allows a Taproot output to commit to a tree of possible spending scripts without revealing any of them until one is used. Consider a complex custody arrangement with four possible spending paths: a 3-of-5 multisig for normal operations, a time-locked recovery path, an emergency key, and an inheritance condition. In a P2SH or P2WSH transaction, all four scripts would be revealed when any one of them is used. With MAST, only the script actually exercised is revealed. The other three remain hidden.
Hiding the unused branches improves both privacy (less information leaked about your custody setup) and efficiency (you only pay for the data of the script you use, not every possible script).
Taproot Fee Profile
For simple singlesig payments, Taproot's fee savings over P2WPKH are modest. The key path is slightly smaller than a P2WPKH spend because Schnorr signatures are 64 bytes (compared to 71-72 bytes for DER-encoded ECDSA signatures). The real savings appear in complex transactions. A cooperative multisig spend via the key path costs the same as a singlesig spend. A script path spend that would have required revealing a full multisig script in P2WSH only reveals the single branch used, with the rest hidden in the Merkle tree.
On Blockstream Explorer, you can see the transaction type for any transaction. The address format tells you the type: addresses starting with bc1q are SegWit, and addresses starting with bc1p are Taproot. Examining Taproot key path spends and script path spends side by side illustrates how the two spending modes differ in size and cost.
Special Transaction Types
Beyond the standard pay-to-address types, Bitcoin supports several special-purpose transaction patterns that serve specific functions in the protocol.
Multisig Transactions
Multisig (m-of-n) transactions require a specified number of signatures from a set of possible signers before bitcoin can be spent. A 2-of-3 multisig requires any two of three designated keys to sign. A 3-of-5 requires any three of five. The "m" is the threshold, and the "n" is the total number of keys.
Multisig is a spending condition rather than a transaction type in itself, and it can be wrapped in different transaction types:
| Multisig Format | Address Prefix | Fee Efficiency | Privacy | Notes |
|---|---|---|---|---|
| Bare multisig | None | Lowest (no discount, full script in output) | Low (full script exposed) | Limited to at most 3 public keys (m-of-n with n up to 3) by standardness rules. Rarely used. |
| P2SH multisig | 3 |
Low (no witness discount) | Low (all keys and signatures revealed at spend) | Former standard for multisig wallets. |
| P2WSH multisig | bc1q |
Medium (~60% cheaper than P2SH) | Low (full script visible in witness) | Current standard with broad tooling support. |
| P2TR multisig (MuSig2/FROST) | bc1p |
Highest (single key + single signature on-chain) | High (indistinguishable from singlesig) | MuSig2 for n-of-n, FROST for m-of-n. Requires interactive signing. |
For enterprise custody operations that require multisig governance, the choice of wrapping format has direct cost implications. A treasury operation processing 500 multisig transactions per month saves meaningful amounts on fees by choosing P2WSH over P2SH, and saves even more with Taproot key aggregation once the tooling supports it.
OP_RETURN Transactions
OP_RETURN is a script opcode that marks a transaction output as provably unspendable and allows arbitrary data to be embedded in the transaction. For years the default relay policy capped this at 80 bytes, but Bitcoin Core 30 (2025) raised the default datacarrier limit to roughly the transaction-size ceiling and allowed multiple OP_RETURN outputs per transaction; the 80-byte figure is a legacy default, not a consensus rule. Because the output is provably unspendable, nodes never add it to the UTXO set at all, avoiding the bloat that would result from storing unspendable outputs indefinitely.
Common uses for OP_RETURN include:
- Timestamping: Embedding a hash of a document or dataset to prove it existed at the time the transaction was confirmed. The hash becomes an immutable timestamp anchored to Bitcoin's proof-of-work security.
- Proof of existence: Similar to timestamping, but often used for legal or compliance purposes. A notarized hash of a contract, for example, proves the contract's contents have not changed since the timestamp.
- Anchor transactions: Layer-2 protocols and sidechains sometimes use OP_RETURN to anchor state commitments to the Bitcoin blockchain.
- Protocol markers: Some protocols use OP_RETURN to encode metadata about the transaction's purpose, such as asset issuance instructions or cross-chain communication.
OP_RETURN outputs normally carry zero bitcoin value; any bitcoin assigned to one would be unspendable and permanently destroyed. The fee cost is the data weight of the OP_RETURN output itself (the opcode plus the embedded data) added to the transaction's total weight.
Transaction Type Comparison
The following table summarizes the key properties of each transaction type. Typical input sizes assume a standard single-signature spend (except where noted for multisig).
| Type | Address Prefix | Typical Input Size | Relative Fee | Privacy | Primary Use Case |
|---|---|---|---|---|---|
| P2PK | None (no address format) | ~114 bytes | High | Low (public key exposed in output) | Historical only. Not used in modern transactions. |
| P2PKH | 1 |
~148 bytes | Highest | Standard (public key revealed at spend) | Legacy payments. Still universally supported. |
| P2SH | 3 |
Varies by script | High | Script structure visible at spend | Multisig, time locks, complex scripts (legacy). |
| P2WPKH | bc1q |
~68 vbytes | Low | Standard (public key revealed at spend) | Standard payments. Best balance of compatibility and fees. |
| P2WSH | bc1q (longer) |
Varies by script | Medium | Script structure visible at spend | Multisig, complex scripts with SegWit discount. |
| P2TR (key path) | bc1p |
~57.5 vbytes | Lowest | High (multisig looks like singlesig) | Standard payments, cooperative multisig, privacy. |
| P2TR (script path) | bc1p |
Varies by script | Low-Medium | Only used branch revealed | Complex spending conditions, fallback scripts. |
| OP_RETURN | N/A (unspendable) | N/A | Minimal (data weight only) | Data is publicly visible | Timestamping, anchoring, data embedding. |
Which Transaction Type Should You Use?
The right choice depends on what you are doing.
For Standard Payments
Use P2WPKH (native SegWit) or P2TR (Taproot). Both offer low fees and broad wallet support. P2WPKH has the widest compatibility across exchanges and services. P2TR offers slightly lower fees on key path spends and better privacy properties. If your wallet supports Taproot, use it. If you encounter a service that does not yet accept bc1p addresses, fall back to P2WPKH.
The Jade Plus hardware wallet supports all modern transaction types, including Taproot, and can sign transactions for any address format. When choosing between SegWit and Taproot for everyday use, both work with Jade Plus. The choice comes down to whether the recipient's wallet and the services you interact with support bech32m addresses.
For Multisig
Use P2WSH for multisig that needs maximum compatibility with existing tooling. Use P2TR with key aggregation (MuSig2 or FROST) when privacy is a priority and all cosigners can participate in the interactive signing protocol. Taproot multisig hides the number of signers and the threshold from blockchain observers. P2WSH multisig is more straightforward to implement and audit but reveals the full multisig script when spending.
For Advanced Scripts
Use P2TR with script path for complex spending conditions. MAST keeps unused script branches hidden, reducing both fees and information leakage. If the common spending case is cooperative (all parties agree), the key path handles it cheaply. The script path exists as a fallback for cases where cooperation fails (time-locked recovery, emergency keys).
Legacy Types: Avoid for New Transactions
There is no reason to create new P2PKH or P2SH transactions when SegWit and Taproot alternatives exist. Legacy types cost more in fees for the same functionality. The only scenario where you interact with legacy types is when spending bitcoin that was received into an older address, or when a counterparty requires a specific address format for compatibility reasons.
Enterprise Implications
For institutions running custody operations, the choice of transaction type is an operational decision with compounding cost implications.
- Multisig type selection: A 2-of-3 multisig P2WSH input saves roughly 60% on fees compared to the same multisig in P2SH. For an operation processing hundreds of transactions daily, this translates directly to lower operating costs. Taproot multisig with MuSig2 saves even more and hides the multisig nature of the custody setup from chain analysis.
- Fee savings at scale: The difference between P2PKH and P2WPKH might be a few hundred sats per transaction. Multiply that by 10,000 transactions per month, and the savings are substantial. Organizations that standardized on SegWit early have saved significant amounts over the years. Organizations adopting Taproot for cooperative multisig will see the next generation of savings.
- UTXO management and address type standardization: Mixing address types within the same wallet creates larger, more expensive transactions when inputs of different types are consolidated. Standardizing on a single address type (preferably P2WPKH or P2TR) simplifies UTXO management, produces more predictable fee estimates, and reduces the operational complexity of treasury workflows.
How Transaction Types Relate to the Scripting System
Every Bitcoin transaction type is ultimately an expression of Bitcoin's scripting language, Script. Understanding how the pieces fit together clarifies why each type exists and what tradeoffs it makes.
Locking Scripts and Unlocking Scripts
Every transaction output contains a locking script (also called scriptPubKey) that defines the spending conditions. Every transaction input contains an unlocking script (scriptSig for legacy types, or witness data for SegWit types) that satisfies those conditions. When a node validates a transaction, it combines the unlocking and locking scripts and executes them. If the combined script evaluates to true, the spend is valid.
The different transaction types are different templates for these scripts:
- P2PKH locking script:
OP_DUP OP_HASH160 <pubkey hash> OP_EQUALVERIFY OP_CHECKSIG - P2SH locking script:
OP_HASH160 <script hash> OP_EQUAL - P2WPKH locking script:
OP_0 <20-byte pubkey hash> - P2WSH locking script:
OP_0 <32-byte script hash> - P2TR locking script:
OP_1 <32-byte tweaked public key>
The progression from P2PKH to P2TR represents a trend toward simpler, smaller locking scripts with more of the complexity moved off-chain (into the witness, into Merkle trees, into key aggregation protocols). Simpler on-chain scripts mean lower fees and better privacy.
Wrapped SegWit: The Transition Format
During the transition to SegWit, a compatibility format called P2SH-P2WPKH (wrapped SegWit) was widely used. It wraps a SegWit script inside a P2SH output, allowing older wallets that could send to 3-prefixed addresses (but could not parse native SegWit addresses) to interact with SegWit recipients. Wrapped SegWit offers partial fee savings (less than native SegWit, more than pure legacy) and was the default in many wallets from 2017 to roughly 2020.
Wrapped SegWit served its purpose as a bridge. With native SegWit support now nearly universal, there is no reason to use wrapped SegWit for new transactions. It exists in the wild because many UTXOs were created during that transition period and have not yet been spent.
Frequently Asked Questions
Can I send bitcoin from one address type to a different address type?
Yes. All Bitcoin transaction types are fully compatible with each other at the protocol level. You can send bitcoin from a P2PKH address (starts with 1) to a P2TR address (starts with bc1p) or any other combination. The Bitcoin network validates the spending script of the input and the locking script of the output independently. The only compatibility concern is wallet and exchange support: some older services may not recognize bech32m (bc1p) addresses. In that case, use a P2WPKH (bc1q) address as the fallback.
Why are Taproot transactions cheaper than legacy transactions?
Two reasons. First, Taproot uses Schnorr signatures, which are 64 bytes compared to 71-72 bytes for ECDSA signatures used in legacy and SegWit transactions. Second, Taproot's witness data benefits from the SegWit discount (counted at one-quarter weight), and cooperative multisig spends use key aggregation to produce a single signature regardless of how many signers participated. Less data on-chain means less block weight, which means lower fees.
How can I tell what transaction type a Bitcoin address uses?
The address prefix tells you. A 1 prefix is P2PKH (legacy), 3 is P2SH (could be multisig, wrapped SegWit, or other scripts), bc1q is native SegWit (P2WPKH if 42 characters, P2WSH if 62 characters), and bc1p is Taproot (P2TR). You can verify the transaction type for any address or transaction on Blockstream Explorer by looking at the script type field.
Does the transaction type affect my privacy?
Yes, significantly. Legacy and SegWit transactions reveal the full spending script when the output is spent, including the number of public keys and signatures in multisig setups. Taproot key path spends hide this information entirely: a cooperative 3-of-5 multisig spend looks identical to a singlesig payment on-chain. Taproot script path spends reveal only the branch used, not the full set of possible spending conditions. For privacy-conscious users and organizations, Taproot is a meaningful improvement.
Should I move my bitcoin from legacy addresses to SegWit or Taproot addresses?
If you plan to spend the bitcoin eventually, consolidating from legacy addresses to native SegWit or Taproot addresses during a low-fee period will save you fees on every future transaction. The consolidation itself costs a fee (you are spending legacy inputs, which are more expensive), but the long-term savings on all subsequent spends outweigh that cost. Do the consolidation when the mempool is quiet and fee rates are low.
What is the difference between P2WSH and P2TR for multisig?
P2WSH multisig reveals the full multisig script (all public keys, the threshold, and all required signatures) on-chain when spent. P2TR multisig using key aggregation (MuSig2 for n-of-n, FROST for m-of-n) produces a single public key and single signature on-chain, hiding the multisig structure entirely. P2WSH multisig is simpler to implement and has broader tooling support today. P2TR multisig is more private and more fee-efficient but requires interactive signing protocols between cosigners.