This guide explains BIP 337 Compressed Transactions 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 337 is a Draft specification for serialising Bitcoin transactions more compactly for bandwidth-constrained exchange. It combines packed metadata, variable-length integers and signature or public-key recovery, with an optional lossy outpoint representation based on block height and transaction position.
- Why it matters: BIP 337 aims to make transaction exchange smaller without redefining Bitcoin transactions. Safe adoption depends on deterministic reconstruction, clear handling of lossy chain references and explicit version negotiation between every sender and receiver.
- Current position: BIP 337 is a Draft specification for serialising Bitcoin transactions more compactly for bandwidth-constrained exchange.
BIP 337 Compressed Transactions in simple English
BIP 337 Compressed Transactions: For supported inputs, ECDSA signatures and public keys may be compressed using recoverable information. The decoder must reconstruct and verify the exact data before accepting the resulting normal transaction.
Simple example
A node operator is checking BIP 337 Compressed Transactions. BIP 337 is Draft, Specification, at the API/RPC layer. The encoding begins by compactly representing version, locktime, input and output counts and the information needed to choose later encodings.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- RPC:
- A command that software sends to a node to request information or a local action.
- Consensus:
- The shared rules full nodes use to decide whether blocks and transactions are valid.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Status and scope
BIP 337 is Draft, Specification, at the API/RPC layer. It defines an interchange encoding and proposed tools, not a new consensus transaction format or a deployed network requirement.
Packed metadata
The encoding begins by compactly representing version, locktime, input and output counts and the information needed to choose later encodings. Decoders must reject impossible combinations and trailing ambiguity.
Compact integers
Values that commonly occupy fixed-width fields can use compact or variable-length forms. Implementations need canonical encoding rules so two byte streams cannot silently represent the same logical value in incompatible ways.
Signatures and keys
For supported inputs, ECDSA signatures and public keys may be compressed using recoverable information. The decoder must reconstruct and verify the exact data before accepting the resulting normal transaction.
Outpoint option
The lossy method replaces a 36-byte transaction identifier and output index with block height and transaction position. Reconstruction therefore needs access to the referenced chain history and an unambiguous chain context.
Script coverage
The specification describes handling for custom scripts and common P2PK, P2PKH, P2SH, P2WPKH, P2WSH and P2TR patterns. Unknown or non-matching cases need an explicit fallback rather than guesswork.
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 337 Compressed Transactions?
BIP 337 Compressed Transactions: For supported inputs, ECDSA signatures and public keys may be compressed using recoverable information.
For BIP 337 Compressed Transactions, what should a beginner know about status and scope?
BIP 337 is Draft, Specification, at the API/RPC layer. It defines an interchange encoding and proposed tools, not a new consensus transaction format or a deployed network requirement.
For BIP 337 Compressed Transactions, what should a beginner know about packed metadata?
The encoding begins by compactly representing version, locktime, input and output counts and the information needed to choose later encodings.
For BIP 337 Compressed Transactions, what should a beginner know about compact integers?
Values that commonly occupy fixed-width fields can use compact or variable-length forms.
Conclusion
BIP 337 aims to make transaction exchange smaller without redefining Bitcoin transactions. Safe adoption depends on deterministic reconstruction, clear handling of lossy chain references and explicit version negotiation between every sender and receiver.
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.