Sealminer A4 Ultra Hydro
Bitcoin & Bitcoin Cash ASIC Miner
886TH
HASHRATE
9.45W/TH
EFFICIENCY
8373W
POWER
£857.66
EST. MONTHLY
NO PAYBACK
EST. ROI
This guide explains BIP 360 Pay-to-Merkle-Root (P2MR) 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 360 is a Draft consensus soft-fork proposal for Pay-to-Merkle-Root, or P2MR. The output commits directly to a tapscript tree root and removes Taproot’s key-path spend.
- Why it matters: P2MR proposes a conservative script-tree option for reducing long-lived public-key exposure. Its benefit, cost and activation status must remain separate: it removes a key path, increases some spends and does not supply full post-quantum signatures.
- Current position: This can avoid leaving an elliptic-curve public key exposed on-chain for long periods, but it does not solve short-exposure attacks against keys revealed while a spend waits in the mempool and it is not active Bitcoin consensus.
BIP 360 Pay-to-Merkle-Root (P2MR) in simple English
BIP 360 Pay-to-Merkle-Root (P2MR): The proposed output uses SegWit version 2 with a 32-byte script-tree Merkle root, producing a bech32m mainnet form beginning bc1z and scriptPubKey OP_2 plus the hash.
Simple example
A node operator is checking BIP 360 Pay-to-Merkle-Root (P2MR). BIP 360 is Draft, Specification, version 0.12.1 at the consensus soft-fork layer.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Consensus:
- The shared rules full nodes use to decide whether blocks and transactions are valid.
- Mempool:
- A node’s changing local collection of valid, unconfirmed transactions.
- 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 360 is Draft, Specification, version 0.12.1 at the consensus soft-fork layer. No wallet should create spendable P2MR mainnet outputs without an activated rule set.
Output construction
The proposed output uses SegWit version 2 with a 32-byte script-tree Merkle root, producing a bech32m mainnet form beginning bc1z and scriptPubKey OP_2 plus the hash.
No key path
Unlike P2TR, P2MR omits the internal key and tweak. Every spend uses a revealed tapscript leaf, stack and Merkle proof.
Threat boundary
It targets long-exposure quantum key recovery from persistent public keys. It does not protect a public key exposed during an unconfirmed spend from a sufficiently fast short-exposure attack.
Witness
The control block is one byte plus 32 bytes per Merkle level and omits the internal key. Annex and tapscript concepts are otherwise deliberately reused.
Depth zero
A depth-zero tree succeeds without script execution under the proposal and is effectively anyone-can-spend, so practical construction should use depth one or more.
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 360 Pay-to-Merkle-Root (P2MR)?
BIP 360 Pay-to-Merkle-Root (P2MR): The proposed output uses SegWit version 2 with a 32-byte script-tree Merkle root, producing a bech32m mainnet form beginning bc1z and scriptPubKey OP_2 plus the hash.
For BIP 360 Pay-to-Merkle-Root (P2MR), what should a beginner know about status and scope?
BIP 360 is Draft, Specification, version 0.12.1 at the consensus soft-fork layer.
For BIP 360 Pay-to-Merkle-Root (P2MR), what should a beginner know about output construction?
The proposed output uses SegWit version 2 with a 32-byte script-tree Merkle root, producing a bech32m mainnet form beginning bc1z and scriptPubKey OP_2 plus the hash.
For BIP 360 Pay-to-Merkle-Root (P2MR), what should a beginner know about no key path?
Unlike P2TR, P2MR omits the internal key and tweak. Every spend uses a revealed tapscript leaf, stack and Merkle proof.
Conclusion
P2MR proposes a conservative script-tree option for reducing long-lived public-key exposure. Its benefit, cost and activation status must remain separate: it removes a key path, increases some spends and does not supply full post-quantum signatures.
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.