Solo Mining Calculator: Estimate Odds and Timeframes
Use a solo mining calculator correctly: enter productive hashrate, network conditions, uptime and time horizon, then read expected time and probability without.
Read article
ASIC mining knowledge centre
BIP 60 Fixed-Length Version Messages Explained
BIP 60 fixed-length version messages explained: review the optional relay flag problem, proposed protocol 70002 change and safe parser testing.
BIP 60 Fixed-Length Version Messages: This guide explains BIP 60 Fixed Length "version" Message (Relay-Transactions Field) 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 60 proposed making the BIP 37 relay-transactions Boolean a fixed part of the Bitcoin version message for a new protocol version. The concern was that optional trailing fields complicate strict length checks and stream deserialisation.
- Why it matters: BIP 60 captures a real parser-design tension between fixed layouts and backwards-compatible trailing fields, but its proposed transition is closed. Current nodes need specification-accurate, length-bounded parsing proven with cross-version wire tests.
- Current position: BIP 60 is Closed and its proposed protocol-version transition is historical; current implementations must follow the deployed handshake rules rather than forcing this abandoned format.
What this means in simple English
BIP 60 Fixed-Length Version Messages is the Bitcoin proposal covered here. A BIP is a document that proposes or explains a Bitcoin idea, standard or rule. A BIP number does not mean the idea is active. Some BIPs are widely used, while others are drafts or historical proposals.
You do not need to read code to understand the main point. Start with the status, the problem being addressed and the practical effect on ordinary users, wallets, miners or node operators.
Simple example
Think of the transaction as a form passed between several authorised signers. Each person or device checks the same payment details before adding approval. Passing the form around does not make the payment safe unless every signer checks what it contains.
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.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
The optional relay field problem
BIP 37 added a Boolean indicating whether a peer wanted transaction announcements. Because it appeared as an optional trailing byte in version messages at protocol 70001, a parser needed to know how many payload bytes remained. BIP 60 argued that fixed fields per protocol version would make validation simpler and stricter.
Proposed protocol transition
The document listed the established version fields and included relay as a mandatory byte at the end for version 70002. Peers exchanged version messages before other communication and then sent verack. The proposal did not redefine what transaction validation meant; it addressed handshake framing and relay preference.
Relay preference semantics
A false relay flag requests that the remote peer not announce transactions, originally supporting filtered-client setup before a filter was loaded. It is not a promise that the node will never receive transaction data through other paths, and it does not alter consensus. Monitoring should describe it as per-connection relay behaviour.
Strict parsing trade-off
Fixed-length layouts allow exact payload checks and straightforward stream readers. Backwards-compatible protocols often accumulate optional fields, however, and deployed parsers already need version gates and bounded remaining-length logic. Strictness must match the live specification or it becomes a self-created interoperability failure.
Closed status and current behaviour
BIP 60 did not become the enduring rule represented by its text. A current node may accept the deployed optional-field layout and negotiate later features through separate messages and service flags. Software must not increment a protocol number or require a byte solely because this BIP once proposed it.
Security boundary
The version payload is untrusted network input. Parsers need overall message-length bounds, field-specific length limits, integer checks and deterministic handling of truncation and surplus bytes. A malformed handshake should end one peer connection without corrupting shared state or consuming unbounded memory.
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 BIP 60 Fixed-Length Version Messages?
BIP 60 proposed making the BIP 37 relay-transactions Boolean a fixed part of the Bitcoin version message for a new protocol version. The concern was that optional trailing fields complicate strict length checks and stream deserialisation.
Is BIP 60 Fixed-Length Version Messages active or supported today?
BIP 60 is Closed and its proposed protocol-version transition is historical; current implementations must follow the deployed handshake rules rather than forcing this abandoned format.
Why does BIP 60 Fixed-Length Version Messages matter?
BIP 60 captures a real parser-design tension between fixed layouts and backwards-compatible trailing fields, but its proposed transition is closed. Current nodes need specification-accurate, length-bounded parsing proven with cross-version wire tests.
Do beginners need to use the technical details?
No. Most readers only need to understand the idea and its current status. Developers and node operators can use the primary sources when they need the exact technical rules.
Conclusion
BIP 60 captures a real parser-design tension between fixed layouts and backwards-compatible trailing fields, but its proposed transition is closed. Current nodes need specification-accurate, length-bounded parsing proven with cross-version wire tests.
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.
On this page
Search More Guides
BIP-110 Explained: Rules, Signalling and Why It Closed
BIP-110 Explained made simple. See the main facts, costs, risks and practical checks before you make a decision.
Read article
Bitcoin Core 29.4 Release: Chainstate Disk I/O Guide
Bitcoin Core 29.4 guide covering repeated chainstate rewrites, regular compaction, LevelDB seek compaction, transaction-data lifetime and wallet sizing fixes.
Read article
Need Advice for Your Mining Setup?
Use our guidance to build your shortlist, then speak to our team when you want help comparing hardware, power, hosting or repairs.