BIPEBitcoin has evolved significantly since the original transaction system was created.

The introduction of SegWit changed how transaction data works. Then came Schnorr signatures, Taproot, and Tapscript.

These upgrades also created a new challenge:

How do different Bitcoin wallets and signing devices exchange all the information needed to create a Taproot transaction?

That is where BIP-371 comes in.

BIP-371, titled “Taproot Fields for PSBT,” defines additional fields that allow Taproot-related information to be carried inside a PSBT, or Partially Signed Bitcoin Transaction.

In simple terms, BIP-371 gives PSBTs the information they need to handle modern Taproot transactions.

Let’s break it down.

What Is BIP-371?

BIP-371 is a Bitcoin Improvement Proposal that adds Taproot-specific fields to the PSBT format.

It was authored by Ava Chow and assigned on June 21, 2021.

The specification is currently marked Deployed. It extends both PSBT version 0, defined by BIP-174, and PSBT version 2, defined by BIP-370.

The basic idea is straightforward:

Existing PSBT fields were not enough to represent all of the information required by Taproot.

So BIP-371 defines additional fields for things such as:

Taproot Schnorr signatures
Taproot scripts
Taproot control blocks
X-only public keys
Taproot key derivation information
Internal keys
Taproot Merkle roots
Taproot script trees

These fields allow wallet software and signing devices to exchange the information required to construct and sign Taproot inputs and outputs.

First, What Is a PSBT?

Before understanding BIP-371, you need to understand PSBT.

PSBT stands for Partially Signed Bitcoin Transaction.

A PSBT is a standardized way of moving a Bitcoin transaction between different pieces of software or different signing devices before the transaction is completely signed.

For example, imagine you want to spend Bitcoin using a hardware wallet.

Your computer could create the transaction first.

The transaction information could then be transferred to your hardware wallet.

The hardware wallet reviews the transaction and adds its signature.

The signed information can then return to the computer.

Finally, the completed transaction can be broadcast to the Bitcoin network.

The basic flow looks like this:

Create transaction

↓

Create PSBT

↓

Send PSBT to signer

↓

Signer adds signature

↓

Finalize transaction

↓

Broadcast transaction

PSBT provides a standardized container for this process.

Your existing article on What Is a PSBT? explains the general system in more detail.

BIP-371 builds on that foundation.

Why Did Taproot Need New PSBT Fields?

This is the key question.

When Bitcoin introduced Taproot, the way Bitcoin transactions could be constructed and spent changed.

Taproot uses:

BIP-340 Schnorr signatures
BIP-341 Taproot spending rules
BIP-342 Tapscript

These technologies introduced information that older PSBT fields were not designed to represent.

The BIP-371 specification explains that existing PSBT fields could not adequately support Taproot because of the new signature algorithm and the way scripts are embedded within Taproot outputs.

Therefore, Bitcoin needed a standardized extension.

That extension became BIP-371.

How BIP-371 Fits Into the Bitcoin Upgrade Stack

BIP-371 makes more sense when you see how the different BIPs connect.

Think of the system as several layers.

BIP-340

Defines Schnorr signatures for secp256k1.

BIP-341

Defines Taproot spending rules.

BIP-342

Defines Tapscript validation rules.

BIP-174

Defines the original PSBT format.

BIP-370

Defines PSBT version 2.

BIP-371

Adds the Taproot-specific PSBT fields needed to work with these newer Bitcoin features.

So BIP-371 isn’t another consensus upgrade like Taproot itself.

Instead, it is an application-layer specification that helps wallet software exchange the information required to work with Taproot.

This distinction is important.

Does BIP-371 Change Bitcoin’s Consensus Rules?

No.

BIP-371 does not change the rules that Bitcoin miners and nodes use to determine whether a transaction is valid.

Instead, it extends the information that can be carried inside a PSBT.

Think of it like this:

Bitcoin consensus

determines whether a transaction is valid.

PSBT

helps wallets and signing devices coordinate the transaction.

BIP-371

makes that coordination work properly for Taproot.

This is why BIP-371 belongs to the Applications layer rather than the Consensus layer.

Why Are Taproot Transactions Different?

A traditional Bitcoin transaction can rely on public keys, signatures, scripts, and derivation information in ways that older PSBT fields already understood.

Taproot introduces a different structure.

A Taproot output can be spent in two major ways:

Key Path

The owner spends using the Taproot output key.

Script Path

The owner reveals a specific script and the information needed to prove that the script belongs to the Taproot tree.

These two spending methods require different information.

For example, a script-path spend may need:

A Taproot leaf script
A leaf version
A control block
A leaf hash
A Schnorr signature
Information about the relevant public key

BIP-371 provides standardized PSBT fields for carrying this information.

What Is a Taproot Key-Path Spend?

A key-path spend is the simpler Taproot spending route.

The spender proves control of the Taproot output through a Schnorr signature.

BIP-371 defines:

PSBT_IN_TAP_KEY_SIG

for carrying the Taproot key-path signature inside a PSBT.

The field can contain a 64-byte or 65-byte Schnorr signature, depending on the sighash form used.

The important idea is:

The PSBT needs somewhere to store the Taproot signature before the transaction is finalized.

BIP-371 provides that standardized location.

What Is a Taproot Script-Path Spend?

Taproot can also contain one or more scripts hidden inside a Merkle tree.

If the spender uses one of those scripts, they must reveal enough information for the network to verify that the script was part of the Taproot construction.

This is called a script-path spend.

A script-path PSBT therefore needs more information than a simple key-path spend.

BIP-371 defines fields for:

The Taproot leaf script
The control block
The leaf version
The public key involved in the script
The leaf hash
The corresponding Schnorr signature

This information allows different wallet components to understand which Taproot script is being used and how the signature relates to that script.

The Important BIP-371 Input Fields

BIP-371 defines several new per-input fields.

You don’t need to memorize the hexadecimal values yet.

Instead, understand what each field accomplishes.

1. Taproot Key Spend Signature

PSBT_IN_TAP_KEY_SIG

This stores the Schnorr signature used for a Taproot key-path spend.

The signature is associated directly with the Taproot output key, so BIP-371 does not require additional key data for this field.

2. Taproot Script Spend Signature

PSBT_IN_TAP_SCRIPT_SIG

This stores a Schnorr signature associated with:

An X-only public key
A particular Taproot leaf

The field therefore connects a signature to the specific script path where it is intended to be used.

3. Taproot Leaf Script

PSBT_IN_TAP_LEAF_SCRIPT

This stores information about a Taproot script leaf.

It includes:

The control block
The script
The leaf version

The control block is especially important because it contains the Merkle-path information needed to prove the leaf belongs to the Taproot tree.

4. Taproot BIP32 Derivation

PSBT_IN_TAP_BIP32_DERIVATION

This provides key-derivation information for an X-only public key involved in the Taproot input.

It can identify whether the key is associated with:

The Taproot output key
The internal key
A key used inside a Taproot leaf

It also carries the relevant leaf hashes and BIP32 derivation path information.

5. Taproot Internal Key

PSBT_IN_TAP_INTERNAL_KEY

This stores the X-only public key used as the internal key for the Taproot output.

Why does this matter?

Because the internal key isn’t necessarily identical to the final output key.

Taproot derives the output key using a tweak.

A signer may therefore need to know the original internal key when determining whether it can sign an input.

BIP-371 provides a dedicated field for this information.

6. Taproot Merkle Root

PSBT_IN_TAP_MERKLE_ROOT

This stores the 32-byte Merkle root associated with the Taproot tree.

Remember the basic Taproot structure:

Internal key

Taproot Merkle root

↓

Tweaked output key

The Merkle root therefore represents the script-tree component of the Taproot construction.

BIP-371 Also Adds Output Fields

BIP-371 isn’t limited to transaction inputs.

It also defines Taproot-specific information for outputs.

The main output fields include:

`PSBT_OUT_TAP_INTERNAL_KEY`

Stores the X-only internal key associated with the Taproot output.

`PSBT_OUT_TAP_TREE`

Stores information needed to reconstruct the Taproot script tree.

`PSBT_OUT_TAP_BIP32_DERIVATION`

Stores BIP32 derivation information for Taproot-related X-only public keys.

This distinction matters because a PSBT can carry information about both:

What you are spending

and

What you are creating.

Why Does the Taproot Tree Matter?

Taproot can contain multiple possible spending conditions.

For example, imagine a wallet has:

Key path

Normal cooperative spending

and

Script path

Emergency recovery after a timelock

The Taproot tree organizes those script paths.

The PSBT may need enough information to reconstruct that tree.

BIP-371’s:

PSBT_OUT_TAP_TREE

field provides the information required to reconstruct the Taproot tree.

The specification represents each leaf with information such as:

Depth
Leaf version
Script length
Script

The entries are arranged in depth-first-search order so the tree can be reconstructed correctly.

BIP-371 and Hardware Wallets

One of the most practical reasons BIP-371 matters is hardware-wallet signing.

Imagine your Bitcoin wallet software runs on your computer, but your private key remains inside a hardware wallet.

The computer needs to communicate enough information for the hardware wallet to understand:

What am I being asked to sign?

With a Taproot transaction, that can include much more than a simple public key and transaction.

The signing device may need to understand:

The Taproot output
The internal key
The relevant script
The leaf being spent
The control block
The derivation path
The Schnorr signature information

BIP-371 provides standardized places for this information inside a PSBT.

That makes interoperability between different wallet components much easier.

Why Standardization Matters

Without a standardized format, every wallet developer could invent a different way to transport Taproot information.

That would create compatibility problems.

Imagine:

Wallet A

uses one proprietary format.

↓

Hardware Wallet B

expects another format.

↓

Wallet C

understands neither.

Standardized PSBT fields solve much of this problem.

BIP-371 gives developers a common specification for representing Taproot information.

This doesn’t mean every wallet supports every Taproot feature automatically.

It means software has a standardized framework to build that support around.

Does BIP-371 Work With PSBTv0 and PSBTv2?

Yes.

BIP-371 specifically defines Taproot fields that can be included in both BIP-174 PSBTv0 and BIP-370 PSBTv2.

This is useful because PSBT is designed to be extensible.

BIP-371 adds new fields without replacing the entire PSBT concept.

The Bitcoin Core documentation currently lists BIP-371 Taproot PSBT support as available from Bitcoin Core v24.0.

A Simple Example

Imagine Alice wants to spend Bitcoin from a Taproot wallet.

Her computer creates a transaction.

Instead of immediately producing the final transaction, it creates a PSBT.

The PSBT can carry information such as:

Taproot output

↓

Internal key

↓

Relevant Taproot tree information

↓

Signing key information

↓

Transaction data

Alice’s hardware wallet receives the PSBT.

The device can inspect the transaction and use the relevant Taproot information to produce a Schnorr signature.

The signature is added to the PSBT.

The wallet then finalizes the transaction.

Finally:

PSBT → Final transaction → Bitcoin network

This is the basic reason BIP-371 exists.

The Two Main Types of Taproot Spending

Before looking at individual fields, remember that Taproot has two major spending methods:

Key path

Script path

These paths require different information.

A key-path spend is relatively simple.

The spender proves control of the Taproot output with a Schnorr signature.

A script-path spend is more involved because the spender must reveal the selected script and provide a control block proving that the script belongs to the Taproot tree.

BIP-371 provides fields for both situations.

1. Taproot Key-Path Signature

The first important field is:

PSBT_IN_TAP_KEY_SIG

This field carries the Schnorr signature for a Taproot key-path spend.

Imagine Alice has a Taproot output controlled through its key path.

Her wallet creates a PSBT and sends it to her signing device.

The signing device produces a BIP-340 Schnorr signature.

That signature can then be placed into:

PSBT_IN_TAP_KEY_SIG

The field contains either:

A 64-byte Schnorr signature using the default sighash
A 65-byte signature when a non-default sighash type is included

The important point is that this field is specifically associated with a Taproot key-path spend.

2. Taproot Script-Path Signature

Now consider a script-path spend.

A Taproot tree might contain several possible scripts.

For example:

Leaf A → Normal recovery

Leaf B → Emergency recovery

The wallet chooses one of them.

The signature used with that script is stored using:

PSBT_IN_TAP_SCRIPT_SIG

This field associates a Schnorr signature with two pieces of information:

An X-only public key
A Taproot leaf hash

That connection matters.

The same public key could potentially appear in different Taproot scripts.

The leaf hash identifies the specific script path for which the signature is intended.

So instead of simply saying:

“Here is a signature.”

the PSBT can represent:

“Here is this signer’s signature for this particular Taproot leaf.”

What Is an X-Only Public Key?

If you have read the BIP-340 article on SatoshiDock, you’ll remember that Schnorr signatures in Bitcoin use 32-byte X-only public keys.

Traditional compressed Bitcoin public keys contain information about both:

The X coordinate
The parity of the Y coordinate

Taproot uses X-only public keys.

BIP-371 therefore uses X-only public keys when representing Taproot-related key information.

This keeps the PSBT representation consistent with the Taproot and Schnorr specifications.

3. Taproot Leaf Scripts

The next important field is:

PSBT_IN_TAP_LEAF_SCRIPT

To understand this field, we need to understand Taproot’s script tree.

A Taproot output can commit to multiple scripts.

Those scripts form a Merkle tree.

For example:

             Taproot Tree
                  |
          -----------------
          |               |
       Leaf A           Leaf B
          |               |
      Recovery       Emergency

The spender doesn’t necessarily reveal every possible script.

Instead, they reveal the script they actually use.

The PSBT therefore needs to know which leaf is being spent.

PSBT_IN_TAP_LEAF_SCRIPT carries information including:

The control block
The script
The leaf version

This gives the signer the information needed to understand the selected script path.

4. What Is a Control Block?

The control block is one of the most important pieces of Taproot script-path spending.

Suppose a Taproot output commits to several scripts.

A blockchain observer needs a way to verify that the script being revealed really belongs to the Taproot tree.

The control block provides the information required for that proof.

Conceptually:

Internal key

Merkle path

Leaf information

↓

Taproot output commitment

The control block contains the internal key and the Merkle-path information needed to reconstruct the commitment.

This allows the network to verify that the revealed script was actually committed to when the Taproot output was created.

Why Does the PSBT Need the Control Block?

Because the signer needs to know exactly what script-path spend it is participating in.

Imagine a hardware wallet receives a PSBT.

It cannot simply receive:

“Sign this transaction.”

It needs enough information to understand the Taproot construction.

The PSBT can therefore provide:

Transaction

Taproot leaf

Control block

Key information

The hardware wallet can then determine the appropriate signing information.

BIP-371 standardizes where these pieces belong.

5. Taproot BIP32 Derivation Information

Another important field is:

PSBT_IN_TAP_BIP32_DERIVATION

This field provides information about how an X-only public key was derived.

Why does this matter?

Modern Bitcoin wallets often use hierarchical deterministic wallets.

Instead of generating completely unrelated keys, a wallet can derive many keys from a master key structure.

For example:

Master key

↓

Account

↓

Branch

↓

Address

When a hardware wallet receives a PSBT, it needs to know which key inside its wallet corresponds to the public key being used.

The BIP32 derivation field provides that information.

Taproot Derivation Is More Complicated

Taproot introduces an additional detail.

A public key can be involved in different parts of a Taproot construction.

For example, it could be:

The internal key
The output key
A key used inside a Taproot script leaf

BIP-371 therefore allows Taproot derivation information to include the relevant leaf hashes.

This tells the signer which Taproot script paths are associated with the key.

The basic idea is:

Public key

BIP32 derivation path

Relevant Taproot leaf hashes

↓

Information needed by the signer

6. Taproot Internal Key

BIP-371 also defines:

PSBT_IN_TAP_INTERNAL_KEY

This field stores the 32-byte X-only public key used as the Taproot internal key.

The internal key is important because it isn’t necessarily the same as the final Taproot output key.

Taproot applies a tweak to the internal key.

Conceptually:

Internal key

Taproot tweak

↓

Output key

Therefore, wallet software may need the internal key to understand how the Taproot output was constructed.

7. Taproot Merkle Root

The field:

PSBT_IN_TAP_MERKLE_ROOT

stores the Taproot Merkle root.

The Merkle root represents the script-tree commitment.

A Taproot output can therefore conceptually be understood as combining two components:

Internal key

and

Script-tree commitment

These are combined through the Taproot tweaking process to produce the output key.

If there is no script tree, the Taproot construction can use the internal key without a script-tree commitment.

When a script tree exists, the Merkle root becomes part of the Taproot commitment.

Key Path vs Script Path in a PSBT

Let’s put everything together.

Key-Path Spend

A simplified PSBT flow could look like:

Taproot input

↓

Internal/output key information

↓

Signer identifies key

↓

Schnorr signature

↓

PSBT_IN_TAP_KEY_SIG

↓

Final transaction

The blockchain sees the final Taproot transaction.

Script-Path Spend

The process contains additional information:

Taproot input

↓

Taproot leaf

↓

Control block

↓

Leaf hash

↓

Relevant public key

↓

Schnorr signature

↓

PSBT_IN_TAP_SCRIPT_SIG

↓

Final transaction

The final transaction reveals the selected script path because that information is needed to validate the spend.

Taproot Output Fields

BIP-371 doesn’t only describe information about inputs.

It also defines fields for Taproot outputs.

These include:

PSBT_OUT_TAP_INTERNAL_KEY

PSBT_OUT_TAP_TREE

PSBT_OUT_TAP_BIP32_DERIVATION

These fields help software understand how a Taproot output was constructed.

This can be particularly useful when a wallet creates a transaction that sends Bitcoin to another Taproot output.

What Is `PSBT_OUT_TAP_TREE`?

This field is especially interesting.

A Taproot output can commit to a tree containing multiple scripts.

Wallet software needs a standardized way to represent that tree inside the PSBT.

PSBT_OUT_TAP_TREE provides this information.

The field represents Taproot leaves using information such as:

Tree depth
Leaf version
Script

The information is arranged so software can reconstruct the tree.

For example:

                Root
                 |
        ----------------
        |              |
      Leaf A          Leaf B
        |              |
    Normal          Recovery

The PSBT can carry enough information for compatible software to understand this structure.

Why Would a Wallet Need the Taproot Tree?

Imagine a wallet creates a Taproot address with:

Key path

Normal spending

and:

Script path

Recovery after a long timelock.

The wallet needs to remember the relationship between those components.

If it loses the information describing the script tree, recovering and spending from the output can become much harder.

BIP-371 therefore provides a standardized representation of the Taproot tree within the PSBT ecosystem.

A Complete Taproot PSBT Workflow

Now let’s walk through the entire process.

Imagine Alice wants to spend a Taproot UTXO.

Step 1: Wallet Creates the Transaction

Alice’s wallet selects one or more UTXOs.

It creates:

Inputs
Outputs
Amounts
Fees

The transaction is not yet fully signed.

Step 2: Wallet Creates a PSBT

Instead of immediately producing the final transaction, the wallet packages the necessary information into a PSBT.

For a Taproot transaction, BIP-371 fields can carry Taproot-specific information.

Step 3: PSBT Is Sent to the Signer

The PSBT may be transferred to:

A hardware wallet
Another computer
A multisigner
Another wallet application

The important point is that the private key does not have to leave the secure signing environment.

Step 4: Signer Inspects the Information

The signing device determines:

Which key belongs to this input?

For Taproot, the PSBT can provide information such as:

Internal key
BIP32 derivation
Taproot leaf hashes
Script information
Merkle-root information

The device can use this information to identify the appropriate signing key.

Step 5: Signer Creates a Schnorr Signature

For a key-path spend, the signer creates a BIP-340 Schnorr signature.

For a script-path spend, the signature commits to the appropriate Taproot spending information.

The signature is then added to the PSBT using the appropriate BIP-371 field.

Step 6: PSBT Returns to the Wallet

The signed PSBT can return to the wallet software.

The wallet now has the necessary signature information.

Step 7: Finalization

The wallet combines the required information and creates the final Bitcoin transaction.

The PSBT is no longer needed for broadcasting.

The final transaction contains the data required by Bitcoin’s consensus rules.

Step 8: Broadcast

The completed transaction is broadcast to the Bitcoin network.

Bitcoin nodes validate it according to the consensus rules defined by Bitcoin.

At this stage, BIP-371 has done its job.

It helped the different pieces of wallet software communicate the Taproot information required to produce the final transaction.

Why BIP-371 Matters for Hardware Wallets

Hardware wallets are one of the clearest examples of why standardized PSBT fields matter.

A hardware wallet usually tries to keep private keys isolated.

The computer can prepare the transaction.

The hardware wallet can receive the transaction information, display important details to the user, and create the signature.

With Taproot, the signing device may need more contextual information than older transaction types required.

BIP-371 gives software a standardized way to provide that context.

This helps different wallet applications and signing devices communicate without requiring every developer to invent a separate Taproot transaction format.

BIP-371 and Multisignature Wallets

BIP-371 becomes even more interesting when combined with advanced signing systems.

For example, Taproot can be used with:

Traditional script-based policies
MuSig2
Miniscript
Hardware wallets
Multisigner custody systems

A PSBT can act as the communication container while the participants or devices perform their respective signing operations.

This is particularly relevant to the MuSig2 article we just covered.

MuSig2 requires participants to exchange information during a collaborative signing process.

Standardized PSBT support can help wallet software transport transaction and signing information between participants.

BIP-373 extends PSBT with MuSig2-specific fields, while BIP-371 handles Taproot-specific information.

Together, these standards help modern Bitcoin wallets build more sophisticated signing workflows.

BIP-371 and Privacy

BIP-371 itself does not make Bitcoin transactions private.

Its purpose is to standardize transaction-signing information.

However, Taproot can provide privacy benefits by allowing different spending conditions to share a common output structure.

For example, a Taproot output may contain:

Key path

and

Several script paths

If the key path is used, the alternative scripts do not appear in the blockchain.

BIP-371 helps wallet software manage the information needed to construct and sign these Taproot outputs.

Therefore, BIP-371 indirectly supports the practical use of Taproot’s privacy and efficiency features.

BIP-371 Does Not Mean Every PSBT Contains Every Field

This is important.

A PSBT doesn’t automatically contain every BIP-371 field.

The fields depend on what the transaction requires.

A simple Taproot key-path spend may need much less information than a complex script-path transaction.

For example:

Simple key-path spend

May mainly require key-path signing information.

Complex script-path spend

May require:

Leaf script
Control block
Leaf hash
Key derivation information
Internal key
Merkle-root information

So the PSBT contains the information relevant to the particular transaction.

Why BIP-371 Uses X-Only Keys

Taproot and BIP-340 use X-only public keys.

This means the public key is represented using only its 32-byte X coordinate.

The Y coordinate is not stored directly because Bitcoin uses a defined even-Y convention when lifting an X coordinate into a curve point.

BIP-371 follows this design.

As a result, many Taproot-related PSBT fields use 32-byte X-only public keys.

This keeps the PSBT representation consistent with Taproot’s cryptographic design.

The Bigger Picture

At first, BIP-371 may look like a collection of technical field definitions.

But the bigger idea is much simpler.

Modern Bitcoin has increasingly sophisticated transaction structures.

Taproot introduced:

Schnorr signatures
Key-path spending
Script-path spending
Taproot trees
Control blocks
Internal keys
Tweaked output keys

Wallets and signing devices need to exchange information about all of these components.

BIP-371 provides the standardized PSBT vocabulary for doing that.

Think of it as a communication layer:

Bitcoin transaction

↓

PSBT

↓

BIP-371 Taproot information

↓

Wallet / hardware wallet / signer

↓

Schnorr signature

↓

Final Taproot transaction

BIP-371 in Simple Terms

If you want the entire BIP explained in one sentence:

BIP-371 extends PSBT so Bitcoin wallets and signing devices can exchange the information required to create, sign, and finalize Taproot transactions.

It doesn’t replace PSBT.

It doesn’t replace Taproot.

And it doesn’t change Bitcoin consensus.

Instead, it connects the two.

BIP-371 vs. Ordinary PSBT

A regular PSBT is a standardized container for partially signed Bitcoin transactions.

It allows different pieces of software to work together without requiring private keys to move between them.

For example:

Wallet → PSBT → Hardware Wallet → Signed PSBT → Wallet → Final Transaction

Taproot introduced new information that older PSBT fields could not represent.

BIP-371 extends PSBT with fields specifically designed for Taproot.

This includes:

Schnorr signatures.
Taproot scripts.
Control blocks.
Internal keys.
Merkle roots.
Taproot BIP32 derivation information.
Taproot output trees.

Therefore, BIP-371 doesn’t replace PSBT.

It makes PSBT capable of handling Taproot transactions.

Why Hardware Wallets Benefit From BIP-371

Hardware wallets are designed to keep private keys inside a dedicated device.

A computer can prepare a transaction, while the hardware wallet performs the actual signing operation.

This separation is important because the computer doesn’t need access to the private key.

Taproot adds more information that a signer may need to understand.

For example, a hardware wallet may need to determine:

Which internal key is being used?

Which script leaf is relevant?

Which public key belongs to the wallet?

Which derivation path produced that key?

BIP-371 provides standardized fields for this information.

This allows wallet software and signing devices to communicate using a common format.

A Simple Hardware-Wallet Example

Imagine Alice has Bitcoin stored in a Taproot address.

She wants to spend it using a hardware wallet.

Her desktop wallet first creates a PSBT.

The PSBT can contain information such as:

Transaction data

UTXO information

Taproot internal key

Key derivation information

Taproot script information, if required

The PSBT is transferred to the hardware wallet.

The device identifies the appropriate key and creates the Schnorr signature.

The signed information returns to the desktop wallet.

The wallet finalizes the transaction and broadcasts it.

At no point does Alice need to export her private key to the computer.

Why `PSBT_IN_WITNESS_UTXO` Is Enough for Taproot

This is one of the more interesting technical details in BIP-371.

Traditional PSBT guidance recommends including the full previous transaction using:

PSBT_IN_NON_WITNESS_UTXO

This helps protect against certain situations where transaction information could be misrepresented.

Taproot changes an important part of this calculation.

A Taproot signature commits to the amounts and output scripts of the transaction’s inputs.

Therefore, if someone attempts to lie about the amount or output script associated with the input, the resulting signature will not be valid.

Because of this, BIP-371 allows Taproot inputs to use:

PSBT_IN_WITNESS_UTXO

without requiring the full previous transaction.

This can reduce the amount of information that needs to be carried in a Taproot PSBT.

What Happens When a PSBT Is Finalized?

A PSBT is called “partially signed” because it is not necessarily the final Bitcoin transaction.

It can contain temporary information needed during the signing process.

For Taproot, this can include fields such as:

PSBT_IN_TAP_KEY_SIG
PSBT_IN_TAP_SCRIPT_SIG
PSBT_IN_TAP_LEAF_SCRIPT
PSBT_IN_TAP_BIP32_DERIVATION
PSBT_IN_TAP_INTERNAL_KEY
PSBT_IN_TAP_MERKLE_ROOT

Once the transaction is finalized, these intermediate PSBT fields are no longer needed for broadcasting.

BIP-371 specifically says finalizers should remove the relevant Taproot fields after constructing PSBT_IN_FINAL_SCRIPTWITNESS.

The result is the final transaction that can be broadcast to the Bitcoin network.

Does BIP-371 Change Bitcoin’s Consensus Rules?

No.

This distinction is important.

BIP-371 operates at the application layer.

It defines how Taproot information is represented inside PSBTs.

The actual Taproot spending rules come from the relevant consensus specifications, including BIP-340, BIP-341, and BIP-342.

Therefore:

BIP-371 → PSBT communication

BIP-341 → Taproot spending rules

BIP-342 → Tapscript validation rules

BIP-340 → Schnorr signatures

These specifications work together, but they perform different jobs.

BIP-371 and Taproot Privacy

Taproot can provide useful privacy properties because different spending conditions can be committed to within the same output structure.

Suppose a wallet creates a Taproot output containing:

Key path

Normal spending

and:

Script path

Recovery condition

If the owner spends through the key path, the alternative script does not need to appear in the transaction.

This means an observer does not automatically see every possible spending condition.

However, BIP-371 itself is not a privacy protocol.

Its purpose is to transport the information needed by wallets and signers.

The privacy characteristics come from Taproot’s transaction design and how the wallet uses it.

BIP-371 and MuSig2

BIP-371 becomes particularly interesting when combined with MuSig2.

MuSig2 allows multiple participants to cooperate in producing a single BIP-340-compatible Schnorr signature.

From the blockchain’s perspective, the resulting Taproot output can look similar to a regular single-key Taproot output.

However, the signing process happens between multiple participants.

This creates more complicated wallet workflows.

BIP-371 provides Taproot-specific PSBT fields.

BIP-373 defines MuSig2-specific PSBT fields.

Together, these standards can support advanced multisigner workflows.

This is one reason the modern Bitcoin ecosystem uses a family of BIPs rather than relying on one specification for everything.

BIP-371 and Miniscript

Miniscript is another technology that can work alongside Taproot.

Miniscript provides a structured way to represent Bitcoin spending conditions.

For example, a policy might require:

One signature from Alice.
One signature from Bob.
A recovery path after a delay.

That policy can be compiled into Bitcoin Script.

Taproot can then commit to the resulting script through its script tree.

BIP-371 gives PSBT-based wallet software a standardized way to carry the Taproot information associated with that construction.

This is especially useful for complex custody and recovery arrangements.

Common BIP-371 Mistakes

BIP-371 is a technical specification, so implementation mistakes can have serious consequences.

Here are several areas developers need to handle carefully.

Using the Wrong Key Format

Taproot-related public keys use X-only 32-byte representations.

A traditional compressed public key is not interchangeable with a Taproot X-only key.

Incorrect serialization can produce invalid PSBTs.

Confusing the Internal Key With the Output Key

The Taproot internal key and the final output key are related, but they are not necessarily identical.

Taproot applies a tweak to the internal key.

Therefore, wallet software must preserve the correct information about the internal key when it is needed.

Mixing Up Key-Path and Script-Path Signatures

A key-path signature and a script-path signature serve different purposes.

A key-path signature belongs in:

PSBT_IN_TAP_KEY_SIG

A signature associated with a particular script leaf belongs in:

PSBT_IN_TAP_SCRIPT_SIG

Confusing these structures can result in an invalid transaction or an incorrectly constructed PSBT.

Losing the Taproot Tree Information

A wallet creating a complex Taproot output needs to preserve the relevant script-tree information.

Without the required scripts, leaf information, or derivation details, recovering the spending conditions can become difficult.

Wallet backup procedures therefore need to account for more than simply one private key.

Ignoring Finalization Rules

PSBT fields exist to help software construct and sign transactions.

They are not all part of the final transaction.

Once the transaction has been finalized, temporary PSBT information should be handled appropriately.

Is BIP-371 Compatible With Older PSBT Software?

PSBT was designed to be extensible.

BIP-371 adds new fields rather than replacing the entire format.

The BIP states that older software will ignore unknown fields.

However, this does not mean old software can necessarily sign or construct Taproot transactions correctly.

There is an important difference between:

Ignoring an unknown field

and:

Understanding what that field means.

A wallet that doesn’t understand Taproot-specific information may not be able to complete the signing process.

Therefore, compatibility depends on whether the software actually supports the required Taproot functionality.

BIP-371 and PSBT Versions

BIP-371 supports both:

PSBTv0

and:

PSBTv2

PSBTv2 was introduced by BIP-370.

BIP-371 adds Taproot fields that can be used with either PSBT version.

This allows Taproot-aware software to exchange the required information without making Taproot dependent on one particular PSBT version.

A Real-World Custody Example

Consider a company that stores Bitcoin using a multi-person custody policy.

The company has three authorized signers:

Alice

Bob

Carol

The company wants a system where multiple people participate in transaction authorization.

A modern setup might use Taproot with a combination of:

Hardware wallets.
PSBTs.
Taproot.
Schnorr signatures.
Miniscript.
MuSig2 or script-based policies.

The transaction can begin as a PSBT.

Each signing device receives the information it needs.

Each participant performs the required signing operation.

The wallet software combines the signatures.

The completed transaction is finalized.

Finally, the transaction is broadcast.

BIP-371 is one part of the communication infrastructure that makes this workflow possible.

Does BIP-371 Make Bitcoin Transactions Faster?

Not directly.

BIP-371 itself is a PSBT specification.

It doesn’t make Bitcoin blocks larger or make transactions confirm faster.

However, it helps software work with Taproot transactions.

Taproot itself can improve transaction efficiency in certain spending situations.

For example, a key-path Taproot spend can use a 64-byte Schnorr signature.

But it is important not to confuse the roles of these technologies.

BIP-371 organizes Taproot information inside PSBTs.

It does not directly change Bitcoin transaction confirmation times.

Does BIP-371 Reduce Bitcoin Fees?

Not directly.

BIP-371 does not determine Bitcoin transaction fees.

Fees depend on factors such as:

Transaction size.
Fee rate.
Network demand.
Transaction structure.
Input and output characteristics.

Taproot can make certain transactions more efficient, which can affect their size and therefore their fee requirements.

But BIP-371’s role is to support the wallet and signing workflow before the transaction reaches the blockchain.

Advantages of BIP-371

BIP-371 provides several practical benefits.

Standardized Taproot Information

Wallet developers don’t need to invent separate formats for Taproot PSBT data.

Hardware-Wallet Support

Signing devices can receive Taproot-specific information in standardized fields.

Better Interoperability

Different applications can exchange Taproot PSBTs using a common format.

Support for Complex Spending Conditions

The specification supports information required for Taproot script paths and trees.

Works With PSBTv0 and PSBTv2

Taproot data can be represented in either PSBT version.

Supports Modern Bitcoin Wallet Architecture

BIP-371 fits naturally into workflows involving hardware wallets, multisignature systems, Taproot, and advanced signing protocols.

Limitations of BIP-371

BIP-371 also has limits.

It Doesn’t Protect Private Keys by Itself

PSBT is a transaction communication format.

Wallets still need proper key management and secure signing procedures.

It Doesn’t Make Bitcoin Private

BIP-371 doesn’t hide transactions from the blockchain.

It Doesn’t Guarantee Wallet Compatibility

Software needs to implement Taproot and BIP-371 correctly.

It Doesn’t Replace Taproot

BIP-371 depends on the underlying Taproot and Schnorr specifications.

It Doesn’t Eliminate Human Error

A user can still approve the wrong transaction or interact with malicious software.

Security therefore depends on the entire wallet system, not one BIP.

Frequently Asked Questions

What is BIP-371?

BIP-371 is the Bitcoin Improvement Proposal titled “Taproot Fields for PSBT.” It defines additional PSBT fields for carrying BIP-340, BIP-341, and BIP-342 Taproot information.

Who wrote BIP-371?

BIP-371 was authored by Ava Chow.

Is BIP-371 active?

Yes. The specification is listed as Deployed.

Does BIP-371 change Bitcoin’s consensus rules?

No. It defines application-layer PSBT fields rather than new consensus rules.

What does `PSBT_IN_TAP_KEY_SIG` contain?

It contains the 64- or 65-byte Schnorr signature used for a Taproot key-path spend.

What does `PSBT_IN_TAP_SCRIPT_SIG` contain?

It associates a Schnorr signature with an X-only public key and a specific Taproot leaf hash.

What is `PSBT_IN_TAP_LEAF_SCRIPT`?

It carries a Taproot leaf script, its leaf version, and the control block needed for the script-path construction.

What is the Taproot internal key?

It is the X-only public key used as the internal key in a Taproot output before the Taproot tweaking process produces the output key.

What is a Taproot Merkle root?

It is the 32-byte hash representing the Taproot script tree.

Can Taproot PSBTs use `PSBT_IN_WITNESS_UTXO`?

Yes. BIP-371 explains that Taproot signatures commit to the input amounts and output scripts, allowing Taproot inputs to use PSBT_IN_WITNESS_UTXO.

Does BIP-371 support PSBTv2?

Yes. BIP-371 defines Taproot fields for both PSBTv0 and PSBTv2.

Can a hardware wallet use BIP-371?

Yes. BIP-371 provides standardized Taproot information that signing devices can use when processing PSBTs.

Is BIP-371 the same as Taproot?

No.

Taproot is the Bitcoin spending system.

BIP-371 is the PSBT extension that allows software to exchange Taproot-related information.

Is BIP-371 the same as BIP-340?

No.

BIP-340 defines Schnorr signatures for Bitcoin.

BIP-371 defines Taproot-specific PSBT fields.

Is BIP-371 the same as BIP-341?

No.

BIP-341 defines Taproot’s spending rules.

BIP-371 defines how Taproot information is represented in PSBTs.

BIP-371 Explained in One Example

Let’s reduce everything to one simple scenario.

Alice has a Taproot UTXO.

She wants to spend it using her hardware wallet.

Her desktop wallet creates a PSBT.

The PSBT contains the transaction information.

BIP-371 provides Taproot-specific information where necessary.

The hardware wallet identifies the correct key.

It creates a Schnorr signature.

The signature is added to the PSBT.

The desktop wallet receives the signed PSBT.

It finalizes the transaction.

The temporary signing information is no longer required for broadcasting.

The final transaction is sent to the Bitcoin network.

That’s the practical role of BIP-371.

It helps the different parts of the Bitcoin wallet ecosystem communicate the information required to spend Taproot outputs.

Final Thoughts

What is BIP-371?

BIP-371 is the specification that extends PSBT with the fields needed to work with Taproot.

Taproot introduced a new transaction structure based on Schnorr signatures, internal keys, script trees, and key-path and script-path spending.

Those features required additional information during transaction creation and signing.

BIP-371 provides that information in a standardized format.

The result is a cleaner workflow:

Create transaction

↓

Create PSBT

↓

Add Taproot information

↓

Send to signer

↓

Create Schnorr signature

↓

Return signed PSBT

↓

Finalize

↓

Broadcast

For ordinary Bitcoin users, you may never manually inspect a BIP-371 field.

Your wallet handles the technical details.

But understanding BIP-371 helps explain what happens behind the scenes when a modern Bitcoin wallet creates and signs a Taproot transaction.

It also shows why Bitcoin development is not limited to the blockchain’s consensus rules.

Wallet standards, signing protocols, hardware devices, descriptors, PSBTs, and Bitcoin Improvement Proposals all work together to create the infrastructure users interact with every day.

BIP-371 is one of the pieces connecting Taproot’s advanced transaction capabilities with the wallets and signing tools that actually use them.

What Is BIP-371?

First, What Is a PSBT?

Why Did Taproot Need New PSBT Fields?

How BIP-371 Fits Into the Bitcoin Upgrade Stack

BIP-340

BIP-341

BIP-342

BIP-174

BIP-370

BIP-371

Does BIP-371 Change Bitcoin’s Consensus Rules?

Why Are Taproot Transactions Different?

Key Path

Script Path

What Is a Taproot Key-Path Spend?

What Is a Taproot Script-Path Spend?

The Important BIP-371 Input Fields

1. Taproot Key Spend Signature

2. Taproot Script Spend Signature

3. Taproot Leaf Script

4. Taproot BIP32 Derivation

5. Taproot Internal Key

6. Taproot Merkle Root

BIP-371 Also Adds Output Fields

PSBT_OUT_TAP_INTERNAL_KEY

PSBT_OUT_TAP_TREE

PSBT_OUT_TAP_BIP32_DERIVATION

Why Does the Taproot Tree Matter?

BIP-371 and Hardware Wallets

Why Standardization Matters

Does BIP-371 Work With PSBTv0 and PSBTv2?

A Simple Example

The Two Main Types of Taproot Spending

1. Taproot Key-Path Signature

2. Taproot Script-Path Signature

What Is an X-Only Public Key?

3. Taproot Leaf Scripts

4. What Is a Control Block?

Why Does the PSBT Need the Control Block?

5. Taproot BIP32 Derivation Information

Taproot Derivation Is More Complicated

6. Taproot Internal Key

7. Taproot Merkle Root

Key Path vs Script Path in a PSBT

Key-Path Spend

Script-Path Spend

Taproot Output Fields

What Is PSBT_OUT_TAP_TREE?

Why Would a Wallet Need the Taproot Tree?

A Complete Taproot PSBT Workflow

Step 1: Wallet Creates the Transaction

Step 2: Wallet Creates a PSBT

Step 3: PSBT Is Sent to the Signer

Step 4: Signer Inspects the Information

Step 5: Signer Creates a Schnorr Signature

Step 6: PSBT Returns to the Wallet

Step 7: Finalization

Step 8: Broadcast

Why BIP-371 Matters for Hardware Wallets

BIP-371 and Multisignature Wallets

BIP-371 and Privacy

BIP-371 Does Not Mean Every PSBT Contains Every Field

Why BIP-371 Uses X-Only Keys

The Bigger Picture

BIP-371 in Simple Terms

BIP-371 vs. Ordinary PSBT

Why Hardware Wallets Benefit From BIP-371

A Simple Hardware-Wallet Example

Why PSBT_IN_WITNESS_UTXO Is Enough for Taproot

What Happens When a PSBT Is Finalized?

Does BIP-371 Change Bitcoin’s Consensus Rules?

BIP-371 and Taproot Privacy

BIP-371 and MuSig2

BIP-371 and Miniscript

Common BIP-371 Mistakes

Using the Wrong Key Format

Confusing the Internal Key With the Output Key

Mixing Up Key-Path and Script-Path Signatures

Losing the Taproot Tree Information

Ignoring Finalization Rules

`PSBT_OUT_TAP_INTERNAL_KEY`

`PSBT_OUT_TAP_TREE`

`PSBT_OUT_TAP_BIP32_DERIVATION`

What Is `PSBT_OUT_TAP_TREE`?

Why `PSBT_IN_WITNESS_UTXO` Is Enough for Taproot

What does `PSBT_IN_TAP_KEY_SIG` contain?

What does `PSBT_IN_TAP_SCRIPT_SIG` contain?

What is `PSBT_IN_TAP_LEAF_SCRIPT`?

Can Taproot PSBTs use `PSBT_IN_WITNESS_UTXO`?