ShopSince launch, Bitcoin has added functionality through the Bitcoin Improvement Proposal process. The standards behind how you back up your wallet, how addresses are generated, how hardware wallets sign transactions, and how on-chain privacy works all came from specific BIPs proposed, reviewed, and voluntarily adopted by the Bitcoin community.
This article covers the most important BIPs that define how self-custody wallets work today. For a full explanation of the BIP process itself, see Bitcoin Improvement Proposals.
The Key BIPs at a Glance
The BIPs covered in this article address key generation and derivation, transaction signing, and output scripting. This is not an exhaustive list. The table below gives a quick reference. This is not an exhaustive list. The table below gives a quick reference.
| BIP | Name | What it defines | Status |
|---|---|---|---|
| 21 | Bitcoin URI Scheme | Standard format for payment request links and QR codes | Final |
| 32 | Hierarchical Deterministic Wallets | Key tree derivation from a single root seed | Final |
| 39 | Mnemonic Code | 12/24-word seed phrase encoding | Final |
| 44 | Multi-Account Hierarchy | Legacy (P2PKH) derivation path | Final |
| 49 | P2WPKH-in-P2SH derivation | Wrapped SegWit derivation path | Final |
| 84 | P2WPKH derivation | Native SegWit derivation path | Final |
| 86 | P2TR derivation | Taproot derivation path | Final |
| 141 | Segregated Witness | SegWit upgrade. Witness data separation | Final |
| 173 | bech32 | Native SegWit address encoding (bc1q...) | Final |
| 174 | PSBT v1 | Partially signed bitcoin transaction format | Final |
| 340 | Schnorr Signatures | Schnorr signature scheme for secp256k1 | Final |
| 341 | Taproot | P2TR spending rules | Final |
| 350 | bech32m | Taproot address encoding (bc1p...) | Final |
| 370 | PSBT v2 | Extended PSBT for multisig and CoinJoin | Final |
| 380–386 | Output Descriptors | Wallet spending policy language | Final |
For self-custody users, the most critical BIPs are BIP39 (seed phrase format), BIP32 (key derivation), BIP84 or BIP86 (derivation path for the address type in use), BIP174 (transaction signing format), and BIP380–386 (descriptors for multisig recovery).
HD Wallet and Key Derivation BIPs
The BIPs in this group define how a single seed phrase deterministically generates every key pair, address, and account in a wallet. The full BIP list can be found here.
BIP32: Hierarchical Deterministic Wallets
BIP32 defines how a single root seed generates an entire tree of key pairs through a parent-child derivation algorithm. Before BIP32, wallet software generated each private key independently. Backing up a wallet meant exporting every individual key, and any new address generated after the last backup was not included.
BIP32 changed this by having one root seed that generates every address in the wallet deterministically, past and future, from the same starting point. You back up the seed once, and everything derived from it is recoverable.
BIP32 also introduced the "xpub" (extended public key) format, which allows watch-only wallet software to monitor balances and generate new receive addresses without ever holding a private key. For derivation paths in detail, see Bitcoin Derivation Paths.
BIP39: Mnemonic Seed Phrases
BIP39 defines how a random seed is converted into a human-readable sequence of 12 or 24 words drawn from a standardized 2,048-word list. Before BIP39, a wallet backup was a raw hexadecimal string of characters, easy to mis-copy, impossible to verify at a glance, and difficult to engrave on metal.
BIP39 made backups something a person can write, read back, and verify word by word. Every word in the list is unique within its first four letters, which means words can be abbreviated on metal backup plates without any ambiguity.
BIP39 also defines the optional passphrase, sometimes called the "25th word," which derives an entirely separate wallet from the same seed words. A wallet with a passphrase and a wallet without one are completely different wallets, even from the same seed. For how this works in everyday use, see What is a Bitcoin Seed Phrase?.
Derivation Path Standards
The derivation path BIPs define which path to follow when generating addresses of each type. Knowing the correct path for your wallet is essential for recovery in a different application.
-
BIP44. Legacy (P2PKH) Derivation Path (2014). BIP44 defines
m/44'/0'/0'as the standard derivation path for Legacy addresses, recognizable by their "1..." prefix. Legacy is the original Bitcoin address format. Spending from a Legacy address reveals the full public key on-chain, which is a weaker privacy property than any of the SegWit or Taproot formats. BIP44 is no longer recommended for new wallets, but it remains the correct path to try when recovering older wallets created before Native SegWit became the standard. -
BIP49. Wrapped SegWit Derivation Path (2016). BIP49 defines
m/49'/0'/0'for Wrapped SegWit addresses, recognizable by their "3..." prefix. Wrapped SegWit was a transitional format introduced during early SegWit adoption. It provided lower fees than Legacy addresses while remaining compatible with exchanges and wallets that could not yet receive to native SegWit addresses. It is less common for new wallets today, but still the correct recovery path for wallets created roughly between 2017 and 2020. -
BIP84. Native SegWit Derivation Path (2017). BIP84 defines
m/84'/0'/0'for Native SegWit addresses, recognizable by their "bc1q..." prefix. Native SegWit is the current standard for most singlesig wallets. It offers lower fees than Legacy or Wrapped SegWit, is widely supported across wallets and exchanges, and is the default derivation path for most new Coldcard wallets unless the user selects Taproot. -
BIP86. Taproot Derivation Path (2021). BIP86 defines
m/86'/0'/0'for Taproot (P2TR) addresses, recognizable by their "bc1p..." prefix. Taproot provides the best on-chain privacy of any current address type. Key path spends look identical on-chain regardless of whether the underlying wallet is singlesig or a complex multisig policy. BIP86 is the derivation standard for Taproot wallets.
| Address type | Prefix | Derivation path | BIP |
|---|---|---|---|
| Legacy (P2PKH) | 1... | m/44'/0'/0' | 44 |
| Wrapped SegWit (P2SH-P2WPKH) | 3... | m/49'/0'/0' | 49 |
| Native SegWit (P2WPKH) | bc1q... | m/84'/0'/0' | 84 |
| Taproot (P2TR) | bc1p... | m/86'/0'/0' | 86 |
A wallet that follows BIP39, BIP32, and the appropriate derivation path BIP can be recovered in any compatible software. A wallet with proprietary derivation can only be recovered using the original vendor's software.
BIP21: Bitcoin Payment URI
BIP21 defines the standard format for payment request links and QR codes. A BIP21 URI looks like bitcoin:ADDRESS?amount=0.01&label=Label. Every wallet that generates a QR code for receiving payment uses BIP21, which is why scanning a payment request in one wallet works in any other BIP21-compatible wallet.
BIP21 is also the foundation for PayJoin. BIP-78 extends the URI with a pj= parameter pointing to the PayJoin endpoint. Understanding BIP21 matters when troubleshooting wallet compatibility and cross-wallet payment links.
Transaction Signing BIPs
BIP174 and BIP370 define the PSBT format, the standard that makes hardware wallet signing, multisig workflows, and air-gapped signing possible by separating transaction construction from transaction signing.
BIP174: Partially Signed Bitcoin Transactions
Before BIP174, there was no standard format for passing an unsigned transaction between a watch-only wallet on a computer and a signing device.
Hardware wallet vendors each implemented their own proprietary protocol, which meant software and hardware from different manufacturers often could not interoperate. BIP174 fixed this by defining a container format that carries a transaction from creation through signing to broadcast. The six defined roles are Creator, Updater, Signer, Combiner, Finalizer, and Extractor. Each role can run on a completely separate device.
This separation is what enables air-gapped signing. The unsigned PSBT travels to the hardware wallet over a physical channel (QR code, MicroSD, or NFC), the hardware wallet adds its signature without a network connection, and the signed PSBT travels back to the watch-only wallet for broadcast. Any BIP174-compatible software and hardware can interoperate, regardless of vendor. For a full explanation of the PSBT workflow, see What is a PSBT?.
BIP370: PSBT v2
BIP370 extends BIP174 with fields that allow transaction inputs and outputs to be added after the PSBT is first constructed. In BIP174, the transaction structure must be fully specified at creation time. BIP370 removes that constraint. This enables CoinJoin coordination workflows, where multiple participants contribute inputs independently to a single transaction, and fee negotiation scenarios where the final transaction structure is not yet known when signing begins.
BIP141: Segregated Witness
SegWit is the most significant soft fork upgrade before Taproot. BIP141 restructured how transaction data is stored in a block by separating signature data (the "witness") from the main transaction body. This solved two problems.
The first was transaction malleability. A Bitcoin transaction's ID is derived from its contents. Pre-SegWit, a third party could alter the witness portion of a transaction in a way that changed its ID without invalidating the signature. The Lightning Network requires pre-signing a refund transaction that references the funding transaction's ID before the funding transaction is broadcast. If an adversary could change that ID after broadcast, the pre-signed refund became invalid, meaning funds locked in the channel could be stranded. SegWit moved signatures out of the data used to compute the transaction ID, making IDs stable and pre-signing safe.
The second was block capacity. Pre-SegWit, Bitcoin enforced a strict 1 MB block size limit. SegWit replaced it with a weight limit of 4 million weight units. Non-witness data counts at 4 weight units per byte, while witness data counts at only 1 weight unit per byte, a 75% discount. In practice, post-SegWit blocks typically contain between 1.3 MB and 2 MB of actual data, with the theoretical maximum approaching 4 MB.
Taproot and Schnorr BIPs
The Taproot upgrade, activated in November 2021, is Bitcoin's most significant protocol change since SegWit. It introduced Schnorr signatures, a new address type (P2TR), and a new scripting approach (Tapscript) that together improve privacy, efficiency, and spending flexibility.
BIP340: Schnorr Signatures
BIP340 defines the Schnorr signature scheme for Bitcoin's secp256k1 curve, replacing the ECDSA scheme Bitcoin used from inception. Schnorr signatures have three significant advantages over ECDSA.
First, they are roughly 10-12% smaller than ECDSA signatures, reducing transaction fees. Second, they support key aggregation via MuSig, where multiple signers' public keys and signatures can be combined into a single key and a single signature, making a multisig vault look identical to singlesig on-chain. Third, Schnorr signatures are formally provably secure under standard cryptographic assumptions in a way ECDSA is not.
BIP341: Taproot
BIP341 introduced P2TR ("bc1p...") addresses with two spending paths, a key path and a script path.
The key path works like a standard single-signature transaction. Because Taproot supports key aggregation, a 3-of-5 multisig vault can combine its signers' keys into a single on-chain key, making the spend look identical to a regular single-key payment. Chain analysis tools see a standard signature and cannot tell whether one person or a large committee signed, which significantly improves privacy for all Taproot key path spends.
The script path supports more complex conditions such as timelocks or threshold schemes, but reveals only the specific condition that was used to spend, not the full range of conditions written into the address. Taproot activated at block 709,632.
BIP342: Tapscript
BIP342 defines how Bitcoin scripts work inside Taproot's script path. The most significant change is how multisig validation works. The original multisig instruction (OP_CHECKMULTISIG) processed every possible signing key in sequence, incurring overhead for each key regardless of how many signatures were actually required. A 2-of-5 multisig still checked all five keys even when only two signatures were needed.
BIP342's replacement (OP_CHECKSIGADD) checks each signature against its corresponding key and increments a running count, stopping once the threshold is met. This reduces transaction weight, enables more flexible spending conditions, and makes Taproot's scripting layer more extensible for future improvements.
BIP350: bech32m
BIP350 defines the encoding format for Taproot addresses, meaning how an address is represented as human-readable text. The original bech32 format (BIP173) had a flaw where certain mistyped characters could produce an address that appeared valid when it was not, allowing a corrupted address to slip past error detection unnoticed. Bech32m corrects this. Taproot addresses use bech32m and begin with "bc1p." Native SegWit addresses use the older bech32 format and begin with "bc1q." The two formats are not interchangeable. A wallet that cannot send to "bc1p..." addresses cannot send to Taproot addresses.
BIP380-386: Output Descriptors
These BIPs define the output descriptor, a single portable document that captures everything needed to reconstruct a wallet.
For singlesig wallets, the seed phrase alone is enough for recovery because all other parameters can be inferred from it. For multisig wallets, the descriptor is a required second backup that no individual seed phrase can replace. It stores the script type, the public keys from every co-signer, all derivation paths, and the signing threshold (for example, 2-of-3).
Without the descriptor, even holding all three seed phrases for a 2-of-3 multisig does not guarantee recovery, because each seed phrase only encodes its own key, not the keys of the others. Sparrow exports the descriptor under Wallet, then Export. Store it in at least two separate physical locations.
Related articles
Bitcoin Improvement Proposals (BIPs)
The conceptual framework for how BIPs work. Covers what they are, how they become standards, and what the BIP process looks like.
What is a Bitcoin Seed Phrase?
BIP39 in everyday use. Covers how the mnemonic standard defines your wallet's root and what the word list uniqueness means for backups.
Bitcoin Derivation Paths
BIP32 and BIP44/84/86 in detail. Covers how HD wallets derive every key from a single seed and what the path numbers mean.
What is a PSBT?
BIP174 in depth. Covers how the partially signed bitcoin transaction format coordinates signing across devices and enables air-gapped workflows.