BIP-110 Bitcoin Deadline: Saylor, Miners and Fork Risk

BIP-110 would temporarily impose seven new Bitcoin consensus restrictions on large data pushes, Taproot constructions and other script features. With block 961,632 projected for approximately August 9, miner signaling remains near zero, while Michael Saylor and Adam Back have publicly opposed the proposal—but weak dominant-chain support does not eliminate the possibility of a disruptive minority fork.

At 08:34 UTC on July 13, 2026, Bitcoin stood at block 957,822, leaving 3,810 blocks before BIP-110’s mandatory-signaling window begins at block 961,632. At the recent observed average of approximately 10.16 minutes per block, that points to around August 9, 2026, although the projected date will move with block production.

The latest accessible monitoring showed no signaling blocks in the first 223 blocks of the current difficulty period, against an early lock-in threshold of 1,109 out of 2,016 blocks, or 55%. Michael Saylor’s central objection is that turning a dispute about non-payment data into a consensus change creates a precedent more dangerous than the disputed transactions themselves. Low support makes adoption on Bitcoin’s dominant chain appear unlikely, but it does not remove the operational risk for nodes configured to enforce BIP-110.

Countdown note: The countdown is an estimate based on current block production. BIP-110 is governed by block heights, not a fixed date or time.

Live BIP-110 countdown

Countdown metric	Live result
Snapshot	July 13, 2026, 08:34 UTC
Current Bitcoin block height	957,822
Mandatory-signaling start	Block 961,632
Blocks remaining	3,810
Recent average block interval used	Approximately 10.16 minutes
Estimated arrival	August 9, 2026, approximately 05:44 UTC
Estimated time remaining	Approximately 26.9 days
Projection warning	Bitcoin block production varies, so the date will move.

Key takeaways

• BIP-110 is a documented proposal, not an approved Bitcoin upgrade. Its “Complete” status describes the BIP document, not network adoption.
• Early activation requires 1,109 signaling blocks in one 2,016-block difficulty period. Current miner support is nowhere close.
• At block 961,632, BIP-110 software begins rejecting non-signaling blocks. Other Bitcoin software does not automatically do so.
• A restrictive soft fork can still produce a practical chain split when enforcing nodes reject the chain followed by most miners and economic actors.
• Saylor and Back have influence, but neither has a formal protocol vote or unilateral veto.
• An open Ordinals pull request already demonstrates a BIP-110-compatible inscription envelope, suggesting the data dispute may continue as a technical cat-and-mouse contest.

What BIP-110 would actually change

The first distinction I would make is between a Bitcoin Improvement Proposal and an adopted Bitcoin upgrade.

BIP stands for Bitcoin Improvement Proposal. BIP-110 is formally titled the Reduced Data Temporary Soft Fork and is listed as “Complete” in the BIPs repository. That status means the proposal document has completed its BIP process stage. It does not mean Bitcoin Core endorsed it, miners approved it, exchanges accepted it or the Bitcoin network activated it.

Bitcoin Core has not merged an implementation of BIP-110. Implementation proposals submitted to the Bitcoin Core repository were closed, while the principal enforcing software is based on Bitcoin Knots. The Knots implementation makes the proposed rules available through an explicit consensusrules=rdts configuration rather than silently enabling them for every Knots operator.

The proposal would apply seven additional consensus restrictions for 52,416 blocks—approximately one year:

1. New output scripts would be restricted to 34 bytes, except for OP_RETURN outputs of up to 83 bytes.
2. Most data pushes and qualifying witness elements would be limited to 256 bytes.
3. Spending undefined witness or Tapleaf versions would be invalid during enforcement.
4. Taproot annexes would be prohibited.
5. Taproot control blocks larger than 257 bytes would be invalid.
6. Tapscripts containing OP_SUCCESS opcodes would be invalid, even when the opcode is not executed.
7. Executing OP_IF or OP_NOTIF inside Tapscript would be invalid.

Outputs confirmed before activation are intended to be grandfathered. The restrictions would apply to UTXOs created at or after the activation height and would expire after the temporary deployment. The proposal’s authors say this preserves known monetary use cases and prevents existing confirmed coins from becoming unspendable merely because activation occurred.

That safeguard is important, but it is not the same as saying there is zero wallet risk. BIP-110 acknowledges theoretical edge cases involving pre-signed Taproot transactions, deep Taproot trees and Miniscript-generated Tapleaves. Under a narrow combination of conditions, a newly created post-activation output could become temporarily difficult or impossible to spend on the enforcing chain.

The proposal presents these cases as unlikely. Critics argue that introducing even limited uncertainty into Bitcoin mainnet consensus is unnecessary.

The August deadline is a block height—not a fixed date

BIP-110’s dates should always be described as estimates because its activation mechanism operates on block heights.

Stage	Block height	Estimated date	What miners do	What BIP-110 nodes do	Main risk
Voluntary signaling	Before 961,632	Live now	May signal version bit 4	Continue monitoring	Low support
Mandatory signaling	961,632–963,647	Approximately Aug. 9–23, 2026	Must signal to satisfy enforcing nodes	Reject non-signaling blocks	Chain divergence
Mandatory lock-in	963,648	Approximately Aug. 23	Prepare for new rules	Enter locked-in state	Operational uncertainty
Grace period	963,648–965,663	Approximately Aug. 23–Sept. 6	Update templates and systems	Await activation	Wallet and exchange preparation
Activation	965,664	Approximately Sept. 6	Mine compliant transactions to remain on the enforcing chain	Apply the seven restrictions	Competing chains
Expiry	Activation + 52,416 blocks	Approximately Sept. 2027	Return to prior rules unless extended	Stop applying temporary restrictions	Renewed governance debate

These calendar dates use the recent 10.16-minute block interval and are not protocol guarantees. The official rules are the block heights.

Why miner support remains far below the 55% threshold

BIP-110 uses version bit 4. During ordinary voluntary signaling, it needs 1,109 signaling blocks in a 2,016-block difficulty period, equal to 55%. Reaching that threshold locks in the change, with activation following one retarget period later.

The available data shows nothing resembling that level of coordination. The most recently completed period reportedly produced approximately 1% signaling, while the current period began with no reported signaling blocks. Earlier monitoring also found only isolated blocks and no publicly committed major mining pool.

Metric	Current result	Required level	Gap	Interpretation
Signals this period	0 reported in the first 223 blocks	1,109	1,109	Early lock-in is not on a credible trajectory
Signaling percentage	0.00% reported	55%	55 percentage points	Measurable miner participation is near zero
Previous difficulty period	Approximately 1%	55%	Approximately 54 percentage points	No evidence of broad pool coordination
Major pools signaling	None publicly identified as broadly committed	Broad coordination	N/A	Individual pool-routed blocks do not equal pool endorsement
Visible enforcing nodes	No reliable current range independently reproduced	No formal threshold	N/A	Node count does not establish economic backing

Miner signaling should not be overinterpreted. A miner can route a block through a pool without the pool endorsing the proposal. A pool may test signaling, attribution may be uncertain, and individual hashers may select templates differently. But the broader conclusion remains: isolated blocks are not remotely sufficient for early lock-in.

For readers reviewing our guide to Bitcoin mining pools, the key distinction is between a pool’s infrastructure, the miners directing hashrate to it, and the version bits appearing in produced blocks. A pool label attached to one block is not proof of a company-wide fork policy.

What “mandatory signaling” really means

If early lock-in fails, BIP-110’s unusual feature begins at block 961,632.

From that height through block 963,647, nodes enforcing BIP-110 reject any block that does not signal bit 4. The enforcing software therefore treats signaling as mandatory and reaches lock-in no later than block 963,648. Full application of the seven restrictions is scheduled for block 965,664.

The word mandatory applies only from the perspective of software enforcing BIP-110. It does not compel Bitcoin Core nodes, non-enforcing Knots nodes, miners, exchanges, wallets or custodians to follow the same chain.

That distinction is the central fact of this dispute.

Suppose most miners continue producing valid Bitcoin blocks without signaling. Existing Bitcoin Core nodes would accept those blocks. BIP-110 nodes would reject them. Unless enough compatible mining power builds on the BIP-110 tip, enforcing nodes could stall at the last accepted block or follow a much lower-hashrate minority chain.

The proposal can therefore “activate” according to its own state machine without becoming the rule set used by the economically dominant Bitcoin network.

Why a soft fork can still split Bitcoin

BIP-110 is technically a soft fork because it narrows the set of valid blocks. A block satisfying the new restrictions remains valid under the older rules. The reverse is not necessarily true: a BIP-110 node may reject a block that an older node accepts.

That one-way compatibility is what makes the change a soft fork. It does not guarantee a single chain.

If most mining power and economically important services enforce the tighter rules, non-upgraded nodes can continue following the same chain without understanding the added restrictions. If enforcing nodes reject the chain followed by most miners, exchanges and custodians, however, those nodes can separate onto a minority chain.

A technically soft-fork rule change can therefore produce a practical chain split. This is why I see the deadline as an operational event even though dominant-chain activation currently appears unlikely.

Michael Saylor’s opposition matters, but it is not a veto

Michael Saylor publicly opposed BIP-110, writing that there are “110 things more dangerous to Bitcoin than spam.” His larger argument was that invalidating transactions that are valid and fee-paying under today’s consensus rules would establish a more dangerous precedent than the data use BIP-110 is intended to discourage.

His direct public statement is available here.

Saylor’s view receives attention because Strategy is a major institutional Bitcoin holder and because he has substantial influence among corporate and institutional Bitcoin advocates. That influence is social and economic, not constitutional.

I would not describe Saylor as deciding the result. Bitcoin has no shareholder vote in which Strategy’s holdings translate into protocol ballots. Saylor cannot prevent a node operator from enforcing BIP-110, stop a miner from signaling or prohibit an exchange from supporting a minority asset.

His opposition matters because governance involves coordination. Miners care which chain buyers value. Custodians care which asset their clients recognize. Exchanges care which network has liquidity and settlement demand. A prominent holder can affect those expectations without controlling consensus.

No separate operational announcement from Strategy, its custodian or associated infrastructure was independently verified for this article. His post should therefore be treated as a public position, not as a confirmed technical fork policy.

Why Adam Back expects BIP-110 to become a minority fork

Adam Back also rejected the proposal’s approach. He argued that BIP-110 supporters are free to run and mine their preferred rules but predicted that the broader network would not follow them, writing that “Bitcoin won’t be joining it.”

His direct public statement is available here.

Back’s standing comes from his long involvement in Bitcoin’s technical community and from Hashcash’s place in Bitcoin’s proof-of-work history. But his statement remains a forecast about coordination, not a binding protocol ruling.

His forecast is consistent with the current signaling picture: a mandatory-activation campaign without visible mining or economic backing is more likely to isolate its enforcing nodes than to reorganize the dominant chain.

That conclusion could change if major pools, exchanges, custodians and wallet providers coordinate before the deadline, but there is little public evidence of that today.

The real fight: spam prevention versus transaction neutrality

BIP-110 grew from the conflict over inscriptions, arbitrary data and Bitcoin Core relay-policy changes. Supporters argue Bitcoin should prioritize censorship-resistant money, that non-payment data adds storage and bandwidth burdens, and that node operators absorb those costs without receiving miners’ transaction fees.

Their strongest technical argument is that relay policy cannot bind miners. A node can refuse to relay a transaction, yet a miner receiving it through another channel can still include it in a valid block. BIP-110’s own text says policy remains the preferred place to fight unwanted data but cannot guarantee that miners follow the filter.

Critics respond that fee-paying transactions should compete in an open block-space market and that consensus rules should not classify transactions according to purpose. In their view, subjective restrictions weaken neutrality, disrupt future upgrade hooks and introduce wallet risk without permanently preventing data storage.

Readers unfamiliar with the underlying use case can review how Ordinals inscriptions and BRC-20 tokens work. Whether inscriptions are valuable collectibles, wasteful data or something in between is a market and cultural judgment. The consensus question is narrower: should otherwise valid blocks become invalid because they contain particular constructions?

BIP-110 supporters sometimes frame their campaign as a kind of Bitcoin “Boston Tea Party”—a grassroots revolt against what they see as institutional acceptance of arbitrary data. The analogy captures their attempt to use node enforcement rather than waiting for Bitcoin Core or major miners.

It also has limits. Bitcoin has no central government, Bitcoin Core cannot unilaterally impose consensus rules, relay policy is not consensus validity, and running visible software does not automatically give every node equal economic influence.

Would BIP-110 actually stop Ordinals?

No. Even the official proposal says it cannot eliminate data storage completely. Users can split information into smaller pushes or disguise it inside constructions that have another script-level interpretation. BIP-110 is designed to make common inscription methods harder and more expensive, not mathematically impossible.

That qualification became concrete on July 2, when an Ordinals contributor opened pull request #4545. The code recognizes an alternative inscription envelope using a bare protocol push, smaller data pushes and OP_DROP or OP_2DROP, avoiding the OP_IF construction prohibited by BIP-110.

The pull request remained open at the article snapshot. Ordinals creator Casey Rodarmor commented favorably but suggested waiting until BIP-110 activates before merging it. That is not the same as a completed release, but it is evidence that inscriptions could adapt.

A separate, still-open Bitcoin Knots pull request proposes counting the new bare-data envelope under Knots’ data-carrier policy. That response is a policy countermeasure, not proof that the underlying BIP-110 consensus rules would invalidate every workaround.

The Ordinals workaround suggests this may remain a cat-and-mouse contest: one side changes transaction encoding, while the other changes policy detection.

Wallet and Taproot risks the proposal acknowledges

The proposal’s UTXO grandfathering protects outputs confirmed before activation from the seven new restrictions. That makes claims that BIP-110 will automatically freeze existing Bitcoin misleading.

The more credible risk concerns transactions and outputs created after activation on the enforcing chain. Wallet developers would need to ensure they do not construct prohibited Taproot annexes, excessively deep control blocks or Tapscripts using invalidated features.

Pre-signed transactions deserve particular scrutiny because they cannot necessarily be reconstructed after the rule environment changes.

The proposal acknowledges that edge-case Miniscript Tapleaves or experimental constructions could theoretically become temporarily unspendable when all alternative key and script paths are unavailable. Critics argue that users should not be asked to accept that risk for a temporary anti-data measure.

Supporters answer that no verified production use of the affected edge cases has been established and that the restrictions expire.

Ordinary holders do not need to move coins solely because the deadline is approaching. The sensible action is to monitor notices from the wallet, exchange or custodian already holding or spending their BTC.

Users practicing self-custody can review Bitcoin wallet and self-custody options, while node operators can compare Bitcoin node maps and monitoring tools.

Who really governs Bitcoin upgrades?

Neither miners alone nor nodes alone control Bitcoin.

Layer	What it controls	Who chooses it	What happens when actors disagree
Wallet policy	Transactions a wallet creates	Wallet developer and user	Compatibility or spending problems
Relay policy	Transactions a node forwards	Node operator and software	Different mempools and propagation paths
Miner policy	Transactions included in blocks	Miners and pools	Fee-selection and censorship differences
Consensus rules	Blocks considered valid	Enforcing nodes plus economic coordination	Potential chain split
Exchange policy	Ticker, deposits and withdrawals	Exchange or custodian	Determines market access and liquidity

Miners choose which valid transactions to include and which chain to extend. Node operators choose which software and rules they enforce. Wallet developers determine which transactions their users create. Exchanges and custodians decide tickers, deposits, withdrawals and supported networks. Holders and merchants decide which asset they value.

What matters to me is not the raw number of visible nodes, but the economic weight behind them.

Public node crawlers cannot reliably prove unique ownership. One operator can run many reachable nodes, private nodes are not counted, Tor visibility varies and crawler methodology differs. Historical BIP-110 estimates have ranged materially, and critics have raised concerns that visible totals could be influenced by Sybil activity or one operator running many nodes.

None of those figures proves exchange adoption, hashrate, BTC ownership or market demand. The more important question is whether miners and markets follow the enforcing chain.

Why exchanges and custodians cannot ignore the deadline

Even when a minority fork looks unlikely to win the BTC ticker, exchanges and custodians need an operational policy.

They must decide which chain qualifies as Bitcoin, whether deposits and withdrawals should be paused, how much confirmation depth is required, whether a minority asset will be credited, and whether transactions can be replayed or confused across networks.

A low-hashrate chain may experience slow blocks and unstable confirmation times. A service that credits deposits before identifying the chain it received can create accounting or withdrawal problems. Custodians also need consistent treatment across signing systems, blockchain monitors and client statements.

Readers comparing venues can consult our cryptocurrency exchange guide. Listing quality does not by itself predict fork policy, so users should rely on each platform’s direct operational notice if the mandatory window creates visible divergence.

Stakeholder impact matrix

Stakeholder	Immediate concern	Decision required	Worst credible scenario	What to monitor
Ordinary BTC holders	Conflicting fork claims or service pauses	Usually none beyond following provider notices	Temporary withdrawal delays or confusion over balances	Wallet, exchange and custodian announcements
Node operators	Whether to enforce RDTS rules	Select software and configuration	Stalling or following a low-hashrate minority chain	Peer tips, chainwork, reorganizations and signaling
Miners and pools	Which block template and rule set to follow	Signal, enforce or remain on existing rules	Orphaned blocks and lost revenue	Hashrate migration and block acceptance
Exchanges and custodians	Ticker, deposits, withdrawals and confirmations	Choose supported chain or chains	Crediting deposits from the wrong chain	Chainwork, liquidity and replay characteristics
Wallet developers	Transaction-construction compatibility	Patch prohibited post-activation patterns	Creating outputs difficult to spend on one chain	BIP test vectors and implementation releases
Lightning users	Channel-close and chain-monitoring behavior	Follow implementation guidance	Delayed or misidentified unilateral closes	Lightning implementation advisories
Taproot and Miniscript users	Restricted scripts and tree depth	Verify wallet and contract compatibility	Temporary unspendability on the BIP-110 chain	Descriptor analysis and wallet test results
Ordinals developers	Existing envelope incompatibility	Adopt an alternative encoding	Content or clients fail on one chain	Ord PR #4545 and Knots countermeasures
Institutions holding BTC	Custody, accounting and ticker treatment	Coordinate with custodians and auditors	Different providers recognize different assets	Custodian and exchange fork policies

Three ways the BIP-110 showdown could end

Scenario A: Broad support appears before the deadline

For BIP-110 to become credible on the dominant chain, signaling would need to rise dramatically toward 1,109 blocks in a difficulty period. Major pools would need to publish clear template and enforcement policies, while exchanges, custodians and wallet developers would need to announce compatibility.

That would not remove every dispute, but it would show economic coordination beyond a small number of public nodes.

Scenario B: BIP-110 nodes separate onto a minority chain

If most miners continue without signaling, BIP-110 nodes could reject the dominant chain and follow blocks produced by a small set of compatible miners. That chain could have slow confirmations, little liquidity and uncertain exchange support.

Services might pause deposits and withdrawals while deciding whether to assign a separate ticker. Coins could exist on both histories, but whether users receive access to both would depend on custody arrangements and technical handling. Replay and transaction-identification risks would require chain-specific analysis rather than assumptions.

Scenario C: The mandatory window passes with little practical disruption

The dominant chain may simply continue under existing consensus rules while BIP-110 nodes stall, disable enforcement or remain on a very small fork. Most BTC users could experience no practical change.

In that outcome, the episode would still matter. It would show that assigning a BIP number and deploying visible nodes do not substitute for mining and economic coordination.

What this means for future Bitcoin upgrades

If BIP-110 unexpectedly succeeds on the dominant chain, future campaigns may view lower signaling thresholds, temporary rules and user-activated deadlines as viable alternatives to Bitcoin Core’s conservative review process.

If it creates only a minority chain, future proposal authors may avoid mandatory activation without clear exchange, wallet and mining support. Public node counts would probably become less persuasive as evidence of consensus.

If the deadline passes quietly, the lesson may be that Bitcoin is highly resistant to contentious consensus changes—even when those changes have code, a BIP number and vocal advocates. The arbitrary-data dispute would likely return through relay policy, mining templates and wallet behavior rather than another immediate consensus campaign.

No single result will settle Bitcoin governance permanently. SegWit’s activation history cannot simply be copied onto every later dispute because the economic actors, technical change and level of coordination differ.

My conclusion: the precedent matters more than the data limit

For me, the precedent is larger than the 256-byte limit.

BIP-110’s strongest argument is that policy filters cannot constrain miners who intentionally include transactions other nodes dislike. Its weakest point is attempting a contentious consensus intervention without visible mining or economic coordination.

Saylor and Back have not killed BIP-110, because neither man has that power. The proposal’s problem is more basic: there is little public evidence that enough miners, exchanges, custodians or wallets intend to treat its enforcing chain as Bitcoin.

That makes dominant-chain adoption unlikely on current evidence. It does not make the August deadline imaginary.

At block 961,632, software configured to enforce BIP-110 will begin making a different validity decision from ordinary Bitcoin software when it encounters a non-signaling block. Whether that becomes an important minority fork, a brief stalled chain or an almost invisible experiment will reveal how much economic support exists behind the campaign.

Bitcoin governance is ultimately demonstrated through coordination—not declared by a BIP number, a famous holder, a developer repository, a mining pool label or a raw node count.

Frequently asked questions

What is BIP-110?

BIP-110 is a proposed temporary Bitcoin soft fork. It would impose seven additional consensus restrictions on large data pushes and certain Taproot and script constructions for 52,416 blocks.

Is BIP-110 an approved Bitcoin upgrade?

No. Its “Complete” status describes the proposal document. Bitcoin Core has not merged or endorsed BIP-110, and the dominant Bitcoin network has not activated it.

When does the BIP-110 deadline occur?

The key deadline is block 961,632, not a fixed date. Based on block 957,822 and the recent block interval, it was projected for approximately August 9, 2026.

What happens at block 961,632?

BIP-110-enforcing nodes begin rejecting non-signaling blocks. Nodes that do not enforce BIP-110 continue applying their existing consensus rules.

How much miner support does BIP-110 need?

Early lock-in requires 1,109 of 2,016 blocks, or 55%, to signal bit 4. Reported support is currently far below that level.

Does BIP-110 activate automatically?

Only within software enforcing its activation logic. It cannot automatically force miners, Bitcoin Core nodes, exchanges or wallets to follow the enforcing chain.

Could BIP-110 split Bitcoin into two chains?

Yes, a practical split is possible. It could occur if enforcing nodes reject blocks followed by most miners and economic services, although a lasting economically significant split is not guaranteed.

Why does Michael Saylor oppose BIP-110?

Saylor says the consensus precedent is more dangerous than the spam dispute. He objects to changing validity rules to reject transactions that are valid and fee-paying today.

Why does Adam Back oppose BIP-110?

Back expects supporters to end up on a separate minority fork. His statement is a prediction about network coordination, not a protocol veto.

Would BIP-110 stop Ordinals?

Not completely. An open Ordinals pull request demonstrates an alternative envelope compatible with the proposed restrictions, while Knots contributors have proposed additional policy filtering.

Can BIP-110 freeze existing Bitcoin?

It is not designed to freeze existing confirmed UTXOs. Outputs confirmed before activation are grandfathered, although the proposal acknowledges narrow risks for certain post-activation Taproot and pre-signed constructions.

Does Bitcoin Core support BIP-110?

No. Bitcoin Core has not merged or endorsed an implementation of BIP-110.

What is the difference between Bitcoin Core and Bitcoin Knots?

They are separate Bitcoin node-software projects with different development and policy choices. Bitcoin Core is the most widely used implementation, while Bitcoin Knots includes additional configuration and policy options, including the principal BIP-110 enforcing implementation.

Do BTC holders need to move their coins?

No action is justified solely by the proposal. Holders should monitor direct notices from their wallet, exchange or custodian and avoid making decisions based on unverified fork claims.

What happens to exchanges during a Bitcoin fork?

Exchanges may pause deposits and withdrawals while evaluating chainwork, liquidity, replay risks and ticker treatment. Each exchange decides which chain or chains it supports.

Who decides which chain is Bitcoin?

No single group decides alone. Miners, enforcing nodes, exchanges, custodians, wallets, merchants and holders collectively determine which chain receives the BTC ticker, liquidity and economic value.

Sources and methodology

Live-data snapshot: July 13, 2026, at 08:34 UTC. The observed Bitcoin height was 957,822. Blocks remaining were calculated as 961632 - 957822 = 3810. The estimated date used a recent average block interval of approximately 10.16 minutes.

All calendar dates in this article are estimates. The activation rules are determined by Bitcoin block heights.

• Official BIP-110 specification
• BIP-110 project website
• BIP-110 code walkthrough
• BIP-110 live monitor
• Farside BIP-110 technical Q&A
• BGeometrics signaling analysis
• Jameson Lopp’s technical criticism
• Delving Bitcoin implementation discussion
• Ordinals BIP-110-compatible envelope pull request
• Bitcoin Knots data-carrier policy pull request
• Michael Saylor’s public statement
• Adam Back’s public statement

Editor’s note: Block height, signaling totals, pull-request status and estimated dates can change. These figures should be refreshed immediately before publication if the article is published after the stated snapshot.