⬡ BSAHI ⚪
Last updated: —
Mainnet
Loading fork data...
🔍 Understanding the Difference
Relay Policy (Core30)
Bitcoin Core v30 — Already Deployed
Changed the default datacarriersize from 80 to 100,000 bytes. This raised the OP_RETURN relay limit — a policy change, not a consensus rule.
Nodes can configure different relay policies without affecting consensus. Blocks remain valid regardless of an individual node's relay policy. This is already active and does not require miner signaling.
Policy · Non-consensus
Consensus Rule (BIP-110)
BIP-110 — Proposed Soft Fork
Restricts arbitrary data at the consensus level for ~1 year. Limits scriptPubKey sizes, witness item sizes, and other data-bearing constructions node operators must enforce.
Requires 55% miner signaling within a 2016-block period. Upgraded nodes enforce these additional consensus rules. After activation, blocks violating the new limits are considered invalid by upgraded nodes.
Consensus · Requires signaling
Status
—
Tracking BIP-110
Signaling
—
of sampled blocks
Required
55%
Threshold for lock-in
Remaining
—
in current period

Signaling Timeline

Daily Signaling — Bit 4 Share
Observed share of sampled blocks signaling bit 4, per day, with the 55% lock-in threshold. Bars use only captured blocks (no fabricated values). Data: data/bip110_daily.json.

Recent Blocks

0

Impact Analysis

⚙️

If Activated

Transactions using constructions restricted by BIP-110 would become consensus-invalid under the proposal. Applications relying on those constructions would need to modify their transaction format or use alternative approaches.

📈

Potential Effects

Potential effects include changes to block space demand, transaction fee dynamics, and the behavior of data-bearing protocols. The magnitude and direction of these effects depend on adoption, user behavior, and miner incentives.

⏳

Timeline

Temporary ~1 year deployment. Includes 2016-block signaling period (55% threshold), 2016-block grace period, then mandatory enforcement if activated. Automatically expires after deployment period.

📋 What Actually Changes?

Aspect Before After (if activated)
Relay Policy Can differ between nodes Consensus rules become stricter for upgraded nodes
Validity Large data transactions remain consensus-valid Certain oversized constructions become consensus-invalid
Block Acceptance Miners decide via policy Validity determined by new consensus rules
Duration Ongoing ~1 year, then automatic expiration

👤 Who Is Affected?

Persona Possible Impact
Bitcoin User Usually none unless using affected transaction types
Wallet Developer May need to update transaction creation logic
Miner Decide whether to signal and enforce the proposal
Node Operator Choose whether to upgrade
Data Protocols May need to adapt transaction formats or migrate activity
Researcher Monitor adoption, signaling, and economic effects

📋 Possible Scenarios

📊

Lock-in

55% signaling threshold reached within a 2016-block period. BIP-110 locks in, grace period begins, then activates for ~1 year before automatic expiration.

Depends on miner adoption · Track signaling % above
⏸

No Lock-in

Threshold not reached during the signaling period. BIP-110 does not activate. Core30 relay policy remains the de facto standard. Debate could continue in subsequent periods.

Depends on miner signaling behavior
🔀

Contentious Activation

Activation occurs while a portion of the ecosystem continues using previous rules, potentially resulting in competing chains if economic actors support both.

Depends on consensus breadth at activation

❓ Known Unknowns

  • 🔸 Miner participation — which pools will signal and enforce remains uncertain
  • 🔸 Exchange and wallet support — adoption by infrastructure providers is unknown
  • 🔸 Fee market effects — impact on transaction fees cannot be predicted precisely
  • 🔸 Ecosystem response — how applications and users adapt depends on economic incentives
  • 🔸 Chain split risk — whether a minority chain persists depends on economic support