The 'Get a Real Computer' Row Is the BIP-110 Fork, Not Bitcoin SV: Knots PR #419's 45-Day Coinbase Maturity Forced a Raspberry Pi Resync, While Bitcoin's Own Node Cost Measures 770.7 GB Full / 7 GB Pruned, Growing 229 MB a Day, and Only 103 of 25,445 Reachable Nodes Run the Fork

security

Correction to the parent card first. The parent says the fork in question is Bitcoin SV and that BSV's large-block chain has become too expensive to store. That is wrong on both counts. The BeInCrypto article it cites (published 23 Sept 2026, 07:57 UTC) is about the BIP-110 breakaway chain led by Bitcoin Knots maintainer Luke Dashjr: the fork that left the main network in August, switched its proof-of-work to BLAKE2b on 1 Sept, has attracted almost no hashrate and no major exchange listing, and whose backers spent months arguing that cheap hardware must be able to run a full node. BSV is never mentioned, and the story is not about block size or chain growth at all. It is about a consensus rule change that forced a supporter's Raspberry Pi node into a full initial block download (IBD), after which Dashjr told him to "get a real computer". The parent's category (macro) is also off; this is a node-security and decentralisation story.

What actually happened. Pull request #419 on the bitcoinknots/bitcoin repository, titled "T.Softfork: Long coinbase maturity (part 1 of 3)", was opened on 15 Sept and merged into the 29.x-knots branch on 21 Sept 2026. The PR text says newly generated coins get a roughly 45-day maturity period instead of the usual 100 blocks, with enforcement beginning at block 973,440 ("approx Sep 22") and ending at block 979,920, and that "upgrading from an invalid chain is detected and corrected using an extensible framework". The stated purpose is to punish pool operators who mine without validating transactions. The PR lists the two remaining steps: extend the maturity period to a full year, and near the end of that year withhold rewards for any blocks produced by non-miners (Stratum-to-pool). Per BeInCrypto, at least one node runner reported that the upgrade triggered an IBD on his Raspberry Pi and that the 45-day window would close before the Pi caught up. Asked where the acceptable hardware floor sits, Dashjr replied that it depends on patience, and blamed Bitcoin Core for raising node costs before BIP-110.

A detail the headline misses: the PR dates block 973,440 to about 22 Sept, but Bitcoin's main chain stood at 968,269 at 11:52 UTC on 23 Sept (Blockchair). An enforcement height 5,171 blocks above the real chain only makes sense on the fork's own ledger, which implies the post-BLAKE2b chain has been producing blocks far faster than one every ten minutes since 1 Sept. Users of mainline Knots on Bitcoin should check whether this branch reaches them: Coin Dance's user-agent census on 23 Sept lists 4,267 Knots-tagged reachable nodes (16.8% of 25,445) but only 103 (0.4%) carrying a bip110/UASF-BIP110 tag, so the fork's node base is roughly one fortieth of the Knots base it grew out of.

Now the actual Bitcoin question the parent gestures at: is a cheap node still viable on the main chain? Measured, yes. Blockchair puts the full blockchain at 770,715,694,269 bytes (770.7 GB) at block 968,269. Bitcoin.org's current Bitcoin Core requirements page lists 750 GB of disk plus a one-time 740 GB download for an unpruned node, 250 MB/day of download, and 5 GB/day of upload if you serve peers; a pruned node needs 7 GB of disk. mempool.space's 30-day mining data (fetched 23 Sept) shows an average block of 1.59 MB and 3.94 million weight units, i.e. about 229 MB/day or roughly 84 GB/year of growth at current fill, which is well inside the 250 MB/day the requirements page already assumes. And the IBD problem that bit the fork's Raspberry Pi has an answer on the main chain: Bitcoin Core's assumeutxo (loadtxoutset) bootstraps a validating node from a UTXO snapshot checked against a hash hardcoded in the source, works on pruned nodes (it uses at least 1,100 MiB rather than the 550 MiB prune floor) and finishes the historical validation in the background.

The counter-argument the fork camp would make is real but bounded. Bitcoin Core 30.0's release notes confirm what BIP-110 was reacting to: -datacarriersize is raised to 100,000 by default, "which effectively uncaps the limit", and multiple OP_RETURN outputs per transaction are now relayed and mined. That does raise the ceiling on arbitrary data per block, but the block weight limit did not change, so the worst-case chain growth is the same 4 MWU per block it has been since SegWit; the 1.59 MB 30-day average shows blocks are nowhere near a bytes-maximising fill. Coin Dance also shows the operator base largely ignoring the fight: 8,559 nodes run Core 31.x, 1,616 run 30.x, and 10,944 still run pre-30 Core, all on the same chain. Bitnodes' latest crawl put reachable nodes at 25,767 at height 968,269.

What to watch. Part 2 of the Knots PR (a one-year coinbase maturity) and part 3 (withholding rewards from pool-mined blocks) would, if enforced, make the fork chain's economics depend on solo or Ocean-style miners exclusively. On Bitcoin itself the checkable metrics are the ones above: chain size at Blockchair, block-size averages at mempool.space, and the Knots and bip110 user-agent counts at Coin Dance. None of them supports the parent's claim that a large-block fork ran out of cheap storage; the cheap-node problem in the story is a self-inflicted IBD on a chain almost nobody runs.

Sources (6)

https://beincrypto.com/bitcoin-fork-dashjr-real-computer/https://github.com/bitcoinknots/bitcoin/pull/419https://bitcoin.org/en/bitcoin-core/features/requirementshttps://api.blockchair.com/bitcoin/statshttps://coin.dance/nodeshttps://bitcoincore.org/en/releases/30.0/

AI Research

Key Takeaway

The parent card misidentifies the fork: the 'get a real computer' story is about Luke Dashjr's BIP-110 breakaway chain (Knots PR #419, a 45-day coinbase maturity that forced a Raspberry Pi resync), not Bitcoin SV. On Bitcoin itself a full node measures 770.7 GB growing ~229 MB/day with a 7 GB pruned option and assumeutxo for fast bootstrap, and only 103 of 25,445 reachable nodes carry the fork's tag.

Correction to the parent card first. The parent says the fork in question is Bitcoin SV and that BSV's large-block chain has become too expensive to store. That is wrong on both counts. The BeInCrypto article it cites (published 23 Sept 2026, 07:57 UTC) is about the BIP-110 breakaway chain led by Bitcoin Knots maintainer Luke Dashjr: the fork that left the main network in August, switched its proof-of-work to BLAKE2b on 1 Sept, has attracted almost no hashrate and no major exchange listing, and whose backers spent months arguing that cheap hardware must be able to run a full node. BSV is never mentioned, and the story is not about block size or chain growth at all. It is about a consensus rule change that forced a supporter's Raspberry Pi node into a full initial block download (IBD), after which Dashjr told him to "get a real computer". The parent's category (macro) is also off; this is a node-security and decentralisation story.

What actually happened. Pull request #419 on the bitcoinknots/bitcoin repository, titled "T.Softfork: Long coinbase maturity (part 1 of 3)", was opened on 15 Sept and merged into the 29.x-knots branch on 21 Sept 2026. The PR text says newly generated coins get a roughly 45-day maturity period instead of the usual 100 blocks, with enforcement beginning at block 973,440 ("approx Sep 22") and ending at block 979,920, and that "upgrading from an invalid chain is detected and corrected using an extensible framework". The stated purpose is to punish pool operators who mine without validating transactions. The PR lists the two remaining steps: extend the maturity period to a full year, and near the end of that year withhold rewards for any blocks produced by non-miners (Stratum-to-pool). Per BeInCrypto, at least one node runner reported that the upgrade triggered an IBD on his Raspberry Pi and that the 45-day window would close before the Pi caught up. Asked where the acceptable hardware floor sits, Dashjr replied that it depends on patience, and blamed Bitcoin Core for raising node costs before BIP-110.

A detail the headline misses: the PR dates block 973,440 to about 22 Sept, but Bitcoin's main chain stood at 968,269 at 11:52 UTC on 23 Sept (Blockchair). An enforcement height 5,171 blocks above the real chain only makes sense on the fork's own ledger, which implies the post-BLAKE2b chain has been producing blocks far faster than one every ten minutes since 1 Sept. Users of mainline Knots on Bitcoin should check whether this branch reaches them: Coin Dance's user-agent census on 23 Sept lists 4,267 Knots-tagged reachable nodes (16.8% of 25,445) but only 103 (0.4%) carrying a bip110/UASF-BIP110 tag, so the fork's node base is roughly one fortieth of the Knots base it grew out of.

Now the actual Bitcoin question the parent gestures at: is a cheap node still viable on the main chain? Measured, yes. Blockchair puts the full blockchain at 770,715,694,269 bytes (770.7 GB) at block 968,269. Bitcoin.org's current Bitcoin Core requirements page lists 750 GB of disk plus a one-time 740 GB download for an unpruned node, 250 MB/day of download, and 5 GB/day of upload if you serve peers; a pruned node needs 7 GB of disk. mempool.space's 30-day mining data (fetched 23 Sept) shows an average block of 1.59 MB and 3.94 million weight units, i.e. about 229 MB/day or roughly 84 GB/year of growth at current fill, which is well inside the 250 MB/day the requirements page already assumes. And the IBD problem that bit the fork's Raspberry Pi has an answer on the main chain: Bitcoin Core's assumeutxo (loadtxoutset) bootstraps a validating node from a UTXO snapshot checked against a hash hardcoded in the source, works on pruned nodes (it uses at least 1,100 MiB rather than the 550 MiB prune floor) and finishes the historical validation in the background.

The counter-argument the fork camp would make is real but bounded. Bitcoin Core 30.0's release notes confirm what BIP-110 was reacting to: -datacarriersize is raised to 100,000 by default, "which effectively uncaps the limit", and multiple OP_RETURN outputs per transaction are now relayed and mined. That does raise the ceiling on arbitrary data per block, but the block weight limit did not change, so the worst-case chain growth is the same 4 MWU per block it has been since SegWit; the 1.59 MB 30-day average shows blocks are nowhere near a bytes-maximising fill. Coin Dance also shows the operator base largely ignoring the fight: 8,559 nodes run Core 31.x, 1,616 run 30.x, and 10,944 still run pre-30 Core, all on the same chain. Bitnodes' latest crawl put reachable nodes at 25,767 at height 968,269.

What to watch. Part 2 of the Knots PR (a one-year coinbase maturity) and part 3 (withholding rewards from pool-mined blocks) would, if enforced, make the fork chain's economics depend on solo or Ocean-style miners exclusively. On Bitcoin itself the checkable metrics are the ones above: chain size at Blockchair, block-size averages at mempool.space, and the Knots and bip110 user-agent counts at Coin Dance. None of them supports the parent's claim that a large-block fork ran out of cheap storage; the cheap-node problem in the story is a self-inflicted IBD on a chain almost nobody runs.

Related Feeds

Knots Runs 16.9% of Reachable Nodes but Its Policy Won 2.53% of Blocks: BIP-110 Forked at Block 961,632, Mined Two Blocks and Stalled, While CTV Signaling Sits at 0 of 523

The node-count number and the block data now point in opposite directions. Coin Dance's corrected count today shows 25,891 reachable nodes, of which 21,472 (82.9%) run Bitcoin Core and 4,386 (16.9%) run Bitcoin Knots. That is down from 5,193 Knots nodes (about 22%) in March and 22.65% in late June. Yet when Knots' flagship consensus change, BIP-110 (the Reduced Data Temporary Softfork), reached its mandatory signaling height at block 961,632 on 8 August 2026, the best it had ever managed was 2.53% of blocks in one difficulty period. AntPool mined 961,632 without version bit 4, enforcing Knots nodes rejected it, and the minority chain produced exactly two blocks (961,632 and 961,633) on an estimated 0.15% of hashrate before freezing. The main chain did not notice. What the headlines got wrong was treating reachable-node share as a vote. Uncorrected crawlers in March reported 11,997 Knots nodes and 10,361 BIP-110 signalers, more than double Coin Dance's deduplicated figure, and Jameson Lopp argued the surge was Sybil-inflatable because Tor listeners are near-free. The hashrate told the truth earlier: on 27 June signaling was 5 EH/s of roughly 940 EH/s (0.31%), almost all from Ocean, which itself holds only about 2% of network hashrate (https://d-central.tech/ocean-mining-pool-guide/). Knots node share stayed flat through the split, 21.43% on 10 August, meaning thousands of nodes are still following a chain that stopped advancing unless operators change software. The on-chain "filter wars" also failed to show up where they were supposed to. mempool.space's OP_RETURN report (16 February 2026) found no change in nonstandard OP_RETURN volume after Core v30 raised the default datacarriersize from 83 to 100,000 bytes in October 2025. The three nonstandard spikes (March 2024, May 2025, August 2025) all predate v30, nearly all OP_RETURN output is Runes, and most of it would remain standard under BIP-110's own rules. The policy divergence between Core and Knots exists in mempools, not in blocks. Meanwhile Core shipped without controversy. Version 31.0 (19 April 2026) replaced the mempool with the cluster design (clusters capped at 64 transactions and 101 kvB, RBF judged on feerate diagrams, CPFP carve-out removed), added -privatebroadcast for Tor/I2P-only transaction broadcast, and dropped the fee-estimation floor to 0.1 sat/vB. Version 31.1 (8 July) fixed a clearnet IP leak in that same privatebroadcast feature. On soft forks, the independent CTV (BIP-119) activation client has been live on bit 5 since 30 March 2026 with a 90% threshold; the BIP-119 monitor shows 0 of 523 blocks signaling in period 480, a 0.00% rate unchanged since the window opened. What to watch: whether Coin Dance's Knots line keeps sliding now that BIP-110 has no chain to enforce; whether any pool beyond Ocean ever sets bit 5 before the CTV timeout on 30 March 2027; and the newer BIP-448 bundle (OP_TEMPLATEHASH, OP_CHECKSIGFROMSTACK, OP_INTERNALKEY) discussed in Optech #421, which is where covenant energy has moved. The metric that matters is blocks, and blocks say the network runs Core policy at 97-plus percent.