TRUC transaction

TRUC is a relay policy a sender opts into by setting a transaction's version to 3, not a consensus rule. Bitcoin Core 28.0 made it standard under BIP 431, which caps the transaction at 10,000 virtual bytes and its child at 1,000. You will not set it yourself: BIP 431 aims the policy at protocols such as Lightning, whose commitment transactions are presigned and fee bumped at broadcast time.

How it works

TRUC is six rules bolted onto an ordinary transaction, and a sender turns all six on at once by setting the version field to 3.

Rule one makes the transaction replaceable whether or not it signals the old BIP125 way, a distinction the same release made moot anyway by defaulting to full replace-by-fee. Rule two makes the choice sticky: every unconfirmed ancestor of a TRUC transaction must be TRUC, and every descendant of an unconfirmed TRUC transaction must be TRUC too, so nobody slips past the limits by attaching an ordinary child, though confirmed coins are exempt in both directions. Rule three is the restriction the name comes from, one unconfirmed ancestor and one unconfirmed descendant, with no CPFP carve out. Rule four caps the transaction at 10,000 virtual bytes, against a standardness ceiling of 100,000 for everything else. Rule five caps the child at 1,000 virtual bytes, which with taproot inputs still leaves room for 15 inputs and 2 outputs. Rule six lets the transaction sit below the node's minimum relay fee, including at zero, provided the package around it pays enough.

The reason for all of it is pinning: somebody else's junk making your transaction unbumpable. Replacement rules ask a replacement to pay more absolute fee than everything it displaces, and refuse outright any replacement that would evict more than 100 transactions. BIP 431 puts a number on how easily that is abused. If you want to replace five of your own transactions and a counterparty has attached 21 descendants to each, your replacement is rejected on the count alone, whatever it pays. Whoever can bolt cheap descendants onto your unconfirmed transaction is setting the price of your own fee bump.

The 1,000 virtual byte child limit is the direct answer to that. Under the default descendant limits a fee bumping child can itself be 100,000 virtual bytes, and at one satoshi per virtual byte that is 100,000 satoshis or more a replacement must cover before it competes on merit. Capping the child at 1,000 cuts the upper bound by a factor of one hundred.

Two mechanisms ride along with the rules. Sibling eviction lets a node meeting a second and better paying child evict the first under replacement rules instead of rejecting the newcomer, and since only one child can ever exist there is no guessing about which to drop. Package replace-by-fee, which Bitcoin Core 28.0 enabled for connected groups of size two, then works on TRUC transactions because that shape is guaranteed.

Why this matters when you buy bitcoin

TRUC reaches an ordinary bitcoin owner at one moment, when a Lightning channel has to be closed on chain and the fee has to be raised after the transaction was signed.

Buying is not where it bites. Of the 41 wallet reviews on this site, the ones that put a real Lightning node on your phone are where the policy stops being trivia. Phoenix, from ACINQ, is rated 4.0 here and runs a self-contained node behind a 12 word seed, and the emergency path ACINQ documents is to force close, wait roughly 720 blocks, about five days, and recover the funds on chain with a tool such as Electrum. That close broadcasts a commitment transaction, which BIP 431 names as what leans on the CPFP carve out to avoid pinning. A commitment transaction that cannot be pushed into a block before a timeout expires does not simply sit there: the money it was protecting becomes claimable by the other side.

Custody moves the exposure, which is the difference between our records. Strike, rated 4.6, lets you withdraw over Lightning and adds no fee of its own on transfers, but balances are custodial while they sit in the app, so the channels and their closes belong to Strike. Muun, rated 3.8, shows on-chain and Lightning as one balance and moves between the two with submarine swaps. The more of a channel you actually hold, the more a reliable fee bump is your problem, and TRUC is the policy written to deliver one inside the set of nodes that run it.

A Phoenix force close, pinned and unpinned

A Phoenix force close is the clearest place to watch TRUC do its job, because the transaction being broadcast was signed long before anyone knew what the fee market would look like.

Take the old arrangement first. Your commitment is an ordinary transaction that does not declare version 3, broadcast with a child that pays for both. Your counterparty holds the second anchor output, which exists so that either side can fee bump, and they use it to attach a child of their own that is 100,000 virtual bytes and pays one satoshi per virtual byte. Nothing they did is invalid. The CPFP carve out let you squeeze one extra child past the descendant limit, but the replacement rules do not care: displacing their child means paying the 100,000 satoshis of fee it already carries before your own fee counts for anything, and the carve out granted exactly one extra child, so it failed the moment a third party shared the transaction. Your close is pinned by junk that cost its author almost nothing.

Now set both transactions to version 3. The commitment is allowed to pay nothing at all, because rule six accepts it below the relay floor as long as the package clears the bar, which is what a transaction signed months in advance needs. Only one child may exist, and it cannot exceed 1,000 virtual bytes, so the worst bill anyone can hand you is a hundredth of the old one. If the counterparty gets their child in first, yours evicts it by paying more. And the pair travels as a unit, because Bitcoin Core 28.0 shipped one parent one child package relay in the same release, with TRUC parents allowed below the minimum relay feerate.

The honest caveat is adoption. BIP 431 says the anti-pinning benefit is limited to an individual node's mempool, and how safe your transaction is depends on how much of the network runs the policy. Version 3 was nonstandard before Bitcoin Core 28.0, so a node still on an older release will not relay it at all, and the release notes call that new package relay limited and not yet reliable under adversarial conditions.

TRUC transaction vs transaction version number

The transaction version number is a field carried by every bitcoin transaction, and TRUC is the bundle of rules that one value of that field now buys.

Setting the version to 3 is how a sender opts in, but the field is not where the rules live. It is a flag; everything that matters happens in a node's policy code, which is why an upgraded node relays the transaction an older one refuses. Consensus never took a view either way. BIP 431 records that version 3 was previously nonstandard with no known conflicts with earlier usage, so what changed in Bitcoin Core 28.0 was relayability, not validity.

TRUC transaction vs cluster mempool

Cluster mempool applies topology limits to every transaction in a node's mempool, while TRUC applies much tighter ones only to transactions that ask for them.

The two are related work rather than rivals, and BIP 431 says so directly: cluster mempool limits cluster size for all transactions, not only the opt-in ones, and is much less restrictive than the TRUC limits. It also leaves gaps that BIP 431 names: cluster mempool does not resolve pinning through absolute fees or through the number of conflicts, and it is incompatible with the CPFP carve out the older Lightning channel design leaned on. TRUC, sibling eviction and package replacement are the path offered to the protocols that relied on it.