Imagine a Bitcoin withdrawal form rejecting an address beginning with bc1p. The receiving wallet says the address is valid. Both can be behaving as designed: the wallet may support Taproot while the sending service does not support that destination format. Trezor’s account-type guide identifies this compatibility issue when explaining its native SegWit default.
Before changing anything, separate three questions: which Bitcoin network is intended, what address format the sender accepts, and whether the recipient controls the resulting funds. An address prefix helps with diagnosis, but cannot answer all three.
What an address represents
A Bitcoin address gives wallet software information for constructing a payment output. That output contains an amount and spending conditions. Later, the recipient spends it by satisfying those conditions. The address is a convenient representation used between people and software; the transaction contains the underlying script. Bitcoin’s transaction guide
Different input and output types can participate in the same payment. The practical implication is that two people do not need matching address prefixes to transact. The sender needs software capable of constructing the requested output, and the recipient needs the information required to spend it. Mixed input handling in BIP141
Reading the common mainnet prefixes
An address beginning with 1 ordinarily represents pay-to-public-key-hash, or P2PKH, commonly called legacy. Spending such an output involves providing a public key and a valid signature. P2PKH mechanics, Trezor’s prefix guide
An address beginning with 3 represents pay-to-script-hash, or P2SH. The destination commits to a script whose conditions are revealed when spent. P2SH can accommodate different arrangements, including multisignature. BIP13’s address specification, P2SH examples
Some 3 addresses hold SegWit spending conditions inside that older P2SH wrapper. Wallets may call this nested SegWit or legacy SegWit. The prefix alone does not prove that an address uses SegWit: P2SH has other applications. BIP141’s native and P2SH witness rules
An address beginning with bc1q is a native version-zero SegWit address. It uses Bech32 encoding and can represent either pay-to-witness-public-key-hash or pay-to-witness-script-hash, abbreviated P2WPKH and P2WSH. These outputs avoid the P2SH wrapper. BIP173, BIP350’s version-zero rules
Taproot addresses begin with bc1p and use the newer Bech32m encoding. Taproot is a version-one SegWit output type, so the common wallet-menu distinction between “SegWit” and “Taproot” is shorthand. Bech32m changes the checksum and is required for witness versions one and above. Taproot’s specification, Bech32m’s encoding rules
These prefixes describe Bitcoin mainnet. Bech32 addresses for testnet instead use tb as their human-readable network component. A familiar-looking address still needs validation for the intended network. BIP173’s network identifiers
A newer address does not set the whole fee
SegWit’s fee advantage comes from transaction structure. Its weight calculation discounts witness data relative to other transaction data, and virtual size expresses that weight in fee-accounting units. The inputs being spent remain important, alongside the outputs being created. BIP141’s transaction-size definitions
The practical consequence is that choosing a receiving address cannot retroactively convert the sender’s existing inputs. Compare the actual transaction estimate rather than applying a fixed savings percentage to every payment. A receiving choice also influences the structure of a future spend from that output.
Taproot provides key-path and script-path spending. A key-path spend can conceal whether the arrangement involved one party or several; a script-path spend reveals the script used and supporting proof. Its privacy properties depend on how it is spent. There is no basis for reading bc1p as a promise that every transaction will look identical or have the lowest fee. BIP341’s spending and privacy analysis
Resolve compatibility at the wallet
If a sender rejects a valid destination, check its documented supported formats. Bech32 support alone does not establish Bech32m support: the newer encoding intentionally requires different validation. BIP350’s compatibility discussion
Our recommendation is to have the recipient generate a fresh address of a mutually supported type using their own wallet, if available. Do not edit the prefix or submit funds to an unfamiliar “conversion” service. A different address needs to come from the wallet that will receive and control the payment. Treat the replacement as a new payment instruction and confirm it with the recipient before using it.
A checksum detects transcription problems; it supplies no assurance about the recipient’s identity. BIP13 explicitly discusses that identity limitation, while BIP173 warns that automatically correcting an address can produce a valid but unintended destination. BIP13, BIP173’s correction warning
The useful habit is to resolve the format question before sending, then verify the complete destination against the recipient’s original instruction. Recognizing four prefixes helps you ask better questions. It never replaces establishing where the payment will go.