BIP 431 TRUC Transactions Explained: Pinning Limits for Bitcoin

Bip 431 truc transactions matters because Bitcoin miners are paid only for work that the network they intend to serve accepts. The labels used in an activation debate can sound political, but the operational questions are concrete: which node validates the template, which rules are active, what the block version communicates, and what happens when two systems disagree. This guide is dated to BIP 431 was assigned on 10 January 2024. It is a historical anchor, not a claim that every later development was known on that date. The current text incorporates the later specification state where the primary sources record it.

What transaction pinning is

A counterparty can exploit mempool replacement, package or topology rules so another participant cannot relay a necessary fee bump even when willing to pay. This is called transaction pinning. It matters for pre-signed protocols such as Lightning because a delayed transaction can miss a recovery deadline. BIP 431 proposes an opt-in transaction version with tighter unconfirmed topology to remove several pinning surfaces.

Start with the validating node, because the ASIC only hashes the candidate header it receives. Record the node release and the pool component that assembled the block. If those facts are unknown, the operator cannot show which rules were actually applied before electricity was committed to the work.

TRUC means restricted until confirmation

Version-three transactions are treated as topologically restricted until they confirm. The policy limits unconfirmed ancestors and descendants to a shallow one-parent, one-child shape with specified size constraints. Once confirmed, ordinary descendants are no longer constrained by the parent’s TRUC status. These are relay and mempool rules, not new Bitcoin consensus validity conditions.

Treat status dashboards as observations, not as the source of truth. Compare them with an independently operated node and retain the raw deployment or template response. Period boundaries, chain reorganisations and cached pool pages can otherwise make a correct-looking percentage describe the wrong state.

Why simple RBF rules are not enough

Absolute-fee requirements, large conflict sets and unrelated descendants can make replacing a transaction disproportionately expensive or impossible under package limits. Child fees may not count toward replacement under older rules even when they improve miner incentive. Restricting topology in advance makes the relevant replacement set small and predictable, allowing fee-bump designs to reason about worst-case cost.

Build the failure response before the boundary arrives. Define which rejection messages trigger an alert, who can pause a template source and how failover is prevented from returning miners to the same faulty validation stack. A second hostname is not independent when both endpoints share one node.

The one-parent one-child model

A TRUC transaction can have at most one unconfirmed parent and a limited number of descendants under the proposal’s policy. The child size limit constrains how much data can pin the parent. Wallets and protocols must construct the entire unconfirmed flow deliberately. Accidentally attaching another child or using an incompatible version can make later relay fail despite valid signatures.

Separate readiness, signalling and enforcement in the operating log. Readiness is a claim about software and process, signalling is data carried by blocks, and enforcement is a validation result. Combining them into a single supported or unsupported label hides the point at which revenue is actually at risk.

Relationship to CPFP carve-out

Lightning anchor outputs historically relied on a carve-out that allowed a small child in otherwise constrained ancestry. TRUC aims to provide a cleaner general topology for package replacement and fee bumping. Migration depends on wallet, node and protocol support. Do not remove an established recovery mechanism until the replacement path is implemented, tested and compatible with counterparties.

Map responsibility across the full path: validating node, template server, pool protocol, proxy, firmware and ASIC. For each layer, state what it can alter and what it merely relays. This prevents a version-bit setting in firmware from being mistaken for complete consensus-rule support. Relate that responsibility map to the pool and job-control boundary in our Stratum V2 guide.

Mining and template effects

Miners can include any consensus-valid set, but template nodes use policy to receive and organise unconfirmed transactions. TRUC rules can improve predictable relay of profitable parent-child packages and reduce adversarial clutter. Pools should inspect actual package feerates and validation, not award priority merely because a transaction uses version three. Draft status and implementation changes require version-specific testing.

Test the primary and failover paths with the same checks. Compare chain tip, chainwork, deployment state, required rules and template age, then save the result with a timestamp. The process should be repeatable by another operator without relying on an undocumented pool conversation.

Operator test matrix

Build valid and invalid version-three parent-child shapes, competing replacements, oversized children and additional descendants. Test across nodes with and without support, then verify fallback and confirmation behaviour. Record reject reasons, mempool ancestry, package feerate and template inclusion. Because BIP 431 is draft, state the exact release and policy used whenever publishing operational conclusions.

Turn the conclusion into a business decision. State which chain and settlement venues the operation intends to serve, the maximum acceptable stale-block exposure and the point at which mining pauses. This connects protocol evidence to electricity cost, pool revenue and payout finality.

Operator decision record

A concise decision record for BIP 431 TRUC transactions should name the source documents, their dates, the node release tested, the responsible pool or template provider and the exact trigger for action. Include screenshots or machine-readable output for the deployment state, but keep the raw node response as the stronger evidence. State whether a change affects policy, block construction or consensus validity, because those layers have different failure costs.

Run the check on every production and failover path. Confirm that monitoring alerts on stale templates, unexpected chain tips, rejected proposals and a rise in stale shares. Keep rollback instructions for node and pool configuration, but do not roll back across an active consensus boundary without understanding the rules the older release enforces. If the evidence conflicts, pause the affected path and investigate before committing more electricity to uncertain work.

For related background, read our plain-English BIP-110 guide and technical BIP-110 review. Those articles use a modern proposal to show why signalling, activation, template construction and accepted chain history must be examined separately.

Conclusion

Bip 431 truc transactions is best understood as a defined interaction between validating software, mining infrastructure and economic acceptance. The safest operator does not infer consensus from a dashboard percentage or a pool slogan. They verify the rule source, the activation boundary, the template fields and the chain their payouts ultimately settle on. That discipline reduces the chance of hashing an invalid or commercially unwanted block.