This guide explains BIP 372 pay-to-contract PSBT in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 372 is a Draft proposal for carrying pay-to-contract key-tweak information in PSBT version 0 or 2 inputs. A P2C output commits to external data by tweaking a public key; later spending requires the signer to apply the same scalar tweak to the corresponding private key.
- Why it matters: BIP 372 addresses a real external-signer gap for pay-to-contract outputs, but its Draft status and missing vectors demand conservative interoperability testing. A signer must verify the tweak against the spent script before using any secret key.
- Current position: BIP 372 is a Draft proposal for carrying pay-to-contract key-tweak information in PSBT version 0 or 2 inputs.
BIP 372 pay-to-contract PSBT in simple English
BIP 372 pay-to-contract PSBT: A contract message is hashed into a scalar and added times G to an original public key. Spending needs the original secret plus the same tweak modulo the curve order.
Simple example
A node operator is checking BIP 372 pay-to-contract PSBT. PSBT_IN_P2C_TWEAK uses key type 0x19, a 33-byte compact original public key as keydata and a 32-byte tweak as valuedata.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- PSBT:
- A portable format for passing an unsigned or partly signed Bitcoin transaction between tools and signers.
- Taproot:
- A Bitcoin upgrade that added new signature and script options for spending outputs.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Status and scope
BIP 372 remains Draft, requires BIP 174 and has a work-in-progress implementation with test vectors still marked TBD. Do not advertise interoperable support without bilateral version testing.
P2C concept
A contract message is hashed into a scalar and added times G to an original public key. Spending needs the original secret plus the same tweak modulo the curve order.
PSBT field
PSBT_IN_P2C_TWEAK uses key type 0x19, a 33-byte compact original public key as keydata and a 32-byte tweak as valuedata. BIP 340 keys are represented with a prefixed compressed form.
Signer duty
The signer should identify a controlled original key, apply the supplied tweak, verify that the result matches the key committed in the input script and only then produce ECDSA or Schnorr signature material.
Supported boundary
The draft describes several bare, legacy and SegWit v0 scripts. Its compatibility discussion warns that post-v0 witness forms, including Taproot, may need extra treatment despite broader motivation text.
Security
A malicious or mistaken tweak can redirect signing authority. Never apply an unverified scalar, accept zero or out-of-range encodings or sign without matching the resulting public key to the actual spent output.
How specialists test it
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
Frequently asked questions
What is the main point of BIP 372 pay-to-contract PSBT?
BIP 372 pay-to-contract PSBT: A contract message is hashed into a scalar and added times G to an original public key.
For BIP 372 pay-to-contract PSBT, what should a beginner know about status and scope?
BIP 372 remains Draft, requires BIP 174 and has a work-in-progress implementation with test vectors still marked TBD.
For BIP 372 pay-to-contract PSBT, what should a beginner know about p2c concept?
A contract message is hashed into a scalar and added times G to an original public key.
For BIP 372 pay-to-contract PSBT, what should a beginner know about psbt field?
PSBT_IN_P2C_TWEAK uses key type 0x19, a 33-byte compact original public key as keydata and a 32-byte tweak as valuedata.
Conclusion
BIP 372 addresses a real external-signer gap for pay-to-contract outputs, but its Draft status and missing vectors demand conservative interoperability testing. A signer must verify the tweak against the spent script before using any secret key.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.



Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.