Antminer X9
Monero ASIC Miner
1000KH
HASHRATE
2.47W/KH
EFFICIENCY
2470W
POWER
£861.31
EST. MONTHLY
205
DAYS
EST. ROI
This guide explains BIP 134 Flexible 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 134 proposed Flexible Transactions, a version-four transaction format using a compact tagged-field representation. It aimed to remove known malleability, make extensions easier and reduce technical debt, but required a hard fork and is Closed.
- Why it matters: BIP 134 was an ambitious closed transaction-format redesign. Its extensibility and malleability goals are historically useful, but its wire format and hard-fork rules are not part of deployed Bitcoin.
- Current position: It aimed to remove known malleability, make extensions easier and reduce technical debt, but required a hard fork and is Closed.
BIP 134 Flexible Transactions in simple English
BIP 134 Flexible Transactions: Version-four semantics would allow transactions invalid under existing consensus, requiring all economically relevant validators to upgrade. That coordination and replay boundary differs fundamentally from a soft fork.
Simple example
A node operator is checking BIP 134 Flexible Transactions. A library accepting the format could not make it safe to broadcast on Bitcoin. The proposal replaced the fixed positional serialization after the version field with named compact tokens carrying values.
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.
- Soft fork:
- A proposed tightening of Bitcoin rules that old nodes may not enforce themselves.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Tagged transaction model
The proposal replaced the fixed positional serialization after the version field with named compact tokens carrying values. Unknown optional fields could be skipped, offering extensibility. Consensus parsers would need one canonical interpretation of names, lengths, ordering, duplicates and required fields.
Malleability objective
By separating or committing fields differently, the design sought stable transaction identity and removal of known signature malleability. A claim to fix malleability must define exactly which identifier commits to which data and how signatures cover it. Application-level replacement and signer behaviour remain separate concerns.
Hard-fork requirement
Version-four semantics would allow transactions invalid under existing consensus, requiring all economically relevant validators to upgrade. That coordination and replay boundary differs fundamentally from a soft fork. A library accepting the format could not make it safe to broadcast on Bitcoin.
Parsing and resource risk
Flexible token streams create ambiguity and denial-of-service risk if lengths, nesting, repetition or unknown elements are not tightly bounded. Tests should include duplicate fields, non-canonical integers, truncated values, extreme counts and conflicting semantic tokens with predictable rejection.
Wallet and hardware impact
Signers would need a new digest algorithm, field presentation and policy model. Hardware devices must display economic meaning rather than raw tags. Backup recovery would need to recognise the format across software generations. None of those workflows should be assumed from the BIP alone.
Why SegWit differs
SegWit deployed through a soft fork, separated witness data and introduced txid and wtxid semantics while retaining a compatible base transaction structure. It addressed important malleability paths without adopting Flexible Transactions. Shared motivation does not make the formats interchangeable.
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 134 Flexible Transactions?
BIP 134 Flexible Transactions: Version-four semantics would allow transactions invalid under existing consensus, requiring all economically relevant validators to upgrade.
For BIP 134 Flexible Transactions, what should a beginner know about tagged transaction model?
The proposal replaced the fixed positional serialization after the version field with named compact tokens carrying values.
For BIP 134 Flexible Transactions, what should a beginner know about malleability objective?
By separating or committing fields differently, the design sought stable transaction identity and removal of known signature malleability.
For BIP 134 Flexible Transactions, what should a beginner know about hard-fork requirement?
Version-four semantics would allow transactions invalid under existing consensus, requiring all economically relevant validators to upgrade.
Conclusion
BIP 134 was an ambitious closed transaction-format redesign. Its extensibility and malleability goals are historically useful, but its wire format and hard-fork rules are not part of deployed Bitcoin.
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.