Bitcoin Core 30 Data-Carrier Policy: What Changed and What Did Not

Bitcoin core 30 data-carrier policy 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 Bitcoin Core 30.0 was released on 10 October 2025. 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.

The Core 30 policy change

Bitcoin Core 30.0 increased the default datacarriersize setting to 100,000 bytes, effectively leaving transaction-size limits to bind first for ordinarily formed data-carrier transactions. It also permitted multiple OP_RETURN outputs for relay and mining. The configured size applies to the aggregate scriptPubKey bytes across those outputs, excluding the scriptPubKey size itself as specified in the release notes.

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.

What did not change in consensus

The release changed Bitcoin Core’s default mempool and block-template policy. It did not create a new Bitcoin consensus rule allowing data that had previously made a block invalid. Blocks containing consensus-valid transactions remain valid to Core 30 even when a local operator chooses a stricter relay setting. Policy controls local behaviour; consensus controls chain validity.

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.

Operators can restore a smaller limit

The release notes state that datacarriersize can be set to 83 to restore the previous limit. Operators may also maintain other policy patches or use different node implementations. As a result, the network does not gain one uniform data limit merely because a widely used release changed its default. Propagation depends on the path a transaction takes through actual peers and miners.

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.

Multiple outputs and aggregate accounting

Before Core 30, standard policy expected a single data-carrier output. The new policy can accept several, but does not give each output an independent 100,000-byte allowance. The aggregate accounting prevents that interpretation. Transaction weight, maximum standard transaction size, fees and other mempool rules continue to apply before a transaction reaches a miner’s candidate block.

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.

Implications for miners and pools

A pool upgrading to Core 30 may see transactions its previous template policy excluded. Whether it mines them still depends on feerate selection, custom filtering and upstream submission. Pool operators should compare pre-upgrade and post-upgrade templates, document overrides and make failover nodes consistent. An unplanned policy mismatch can create confusing differences without producing a consensus fork.

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.

Implications for wallets and applications

Applications should not assume broad propagation at very low fees or through nodes that retained older defaults. They should calculate transaction weight, use realistic fee estimation and handle rejection messages accurately. Calling a policy rejection invalid is misleading. Direct miner submission may bypass some relay paths, but it changes availability and counterparty assumptions.

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.

A safe upgrade review

Back up configuration, record current policy values and test mempool acceptance with representative transactions before switching production. Monitor peer count, mempool rejection logs, block-template composition and CPU or memory effects. Keep consensus validation unchanged unless the release itself documents a deployment. Publish the chosen policy so users can interpret transaction acceptance consistently.

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 Bitcoin Core 30 data-carrier policy 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

Bitcoin core 30 data-carrier policy 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.