BIP-110 — State of Play
THE PROPOSAL
A one-year temporary soft fork limiting arbitrary on-chain data — inscriptions, BRC-20-style tokens, large
OP_RETURN outputs. Author: dathonohm. Activation: modified BIP-9 bit-4 with a 55% miner-signaling threshold, plus a BIP8-style mandatory-signaling window before max-height. (BIP-9 = miner signals via coinbase, fork can fail to activate if the threshold isn't reached. BIP-8 = activation becomes mandatory at max-height regardless of signaling.)SIGNALING %
Period 470 (current): 0 / 759 blocks as of block 948278, 2026-05-07 06:48 UTC. Peak: 0.15%. Threshold: 55%.
KNOTS NODE SHARE
~21–22% of public reachable nodes by mid-April.
WHERE THE CODE LIVES
(1) dathonohm's fork client (v0.4.1, 2026-03-10)
(2) Bitcoin Knots, via in-flight pull requests
(3) two Bitcoin Core PRs (#34929, #34930) auto-closed by DrahtBot 2026-03-26, no reopen
(2) Bitcoin Knots, via in-flight pull requests
(3) two Bitcoin Core PRs (#34929, #34930) auto-closed by DrahtBot 2026-03-26, no reopen
May 1 — Luke Dashjr APPROVED Knots PR #238
WHAT HAPPENED
On 2026-05-01, Luke Dashjr submitted a formal APPROVED review on bitcoinknots/bitcoin#238 — "Reduced Data Temporary Softfork, implemented as a modified BIP9 temporary deployment." The PR is still open, not yet merged, but Luke's approval is the gate for landing BIP-110 enforcement in mainline Knots.
EFFECT
Until #238 lands, BIP-110 enforcement only ships in dathonohm's fork client. Once merged, Knots (~22% of reachable nodes) would include the enforcement code path in a future release; exact build/runtime defaults are tied to the consent-gate PRs. Approval ≠ merge.
ALSO IN THE WINDOW — RDTS_CONSENT
SIGNALING UNCHANGED
Miner signaling stays well under 1% regardless of where the code lives.
Where the Debate Is Active — and Where It Is Quiet
DELVING BITCOIN — THREAD #2360 · CRITIQUES
The April debate on the v0.4.1 release thread:
• Apr 7 — ArmchairCryptologist: "the BIP does not accomplish its stated objective since the restrictions are easily bypassed."
• Apr 7 — neonrooks: "Part of a permissionless system is allowing users to waste their money on whatever transactions they choose."
• Apr 10 — Antoine Riard, on an academic paper BIP-110 supporters cite for node-runner legal risk: "I fear it's more a paper written by computer scientists … who were just seeking a sophisticated justification to write more papers."
• Apr 7 — ArmchairCryptologist: "the BIP does not accomplish its stated objective since the restrictions are easily bypassed."
• Apr 7 — neonrooks: "Part of a permissionless system is allowing users to waste their money on whatever transactions they choose."
• Apr 10 — Antoine Riard, on an academic paper BIP-110 supporters cite for node-runner legal risk: "I fear it's more a paper written by computer scientists … who were just seeking a sophisticated justification to write more papers."
AUTHOR'S RESPONSE — DATHONOHM, APR 20
Three replies (#12–#14):
On "the BIP doesn't stop data": "Please point me to where the BIP states that its objective is to prevent all data insertion." Cites BIP-148 (2017 SegWit UASF) as precedent for skepticism-then-success.
Storm-damage analogy: "If your roof was damaged by a storm 50× less severe than the worst case, and it stopped raining, would you take the opportunity to reinforce your roof to prepare it for the worst case, or would you say 'it's not raining now, so there's no need to do anything'?"
On the Tor comparison: "Operating a Tor node is nowhere close to operating a Bitcoin node." Argues that tolerating arbitrary-data storage narrows the node-runner population and drives centralisation.
On "the BIP doesn't stop data": "Please point me to where the BIP states that its objective is to prevent all data insertion." Cites BIP-148 (2017 SegWit UASF) as precedent for skepticism-then-success.
Storm-damage analogy: "If your roof was damaged by a storm 50× less severe than the worst case, and it stopped raining, would you take the opportunity to reinforce your roof to prepare it for the worst case, or would you say 'it's not raining now, so there's no need to do anything'?"
On the Tor comparison: "Operating a Tor node is nowhere close to operating a Bitcoin node." Argues that tolerating arbitrary-data storage narrows the node-runner population and drives centralisation.
WHERE IT IS QUIET
•
• Bitcoin Core PRs #34929 / #34930: auto-closed by DrahtBot 2026-03-26, no reopen
• bitcoin-dev mailing list: no BIP-110 / OP_RETURN / datacarrier threads
bitcoin/bips repo: zero edits to bip-0110.mediawiki since 2026-03-05• Bitcoin Core PRs #34929 / #34930: auto-closed by DrahtBot 2026-03-26, no reopen
• bitcoin-dev mailing list: no BIP-110 / OP_RETURN / datacarrier threads
Signaling Has Stalled
| Period | Approx. dates | Signal blocks | % |
|---|---|---|---|
| 465 | early–mid Apr | 1 / 2016 | 0.05% |
| 466 | mid Apr | 0 / 2016 | 0.00% |
| 467 | late Apr | 3 / 2016 | 0.15% |
| 468 | late Apr – early May | 2 / 2016 | 0.10% |
| 469 | early May | 0 / 2016 | 0.00% |
| 470 (current) | rolling | 0 / 759 | 0.00% |
PEAK vs THRESHOLD
Peak: 0.15%. Threshold: 55%. Source: bip110monitor.com, accessed 2026-05-07.
NO SECOND POOL · NO REJECT TAG
All bit-4 signaling blocks came through Ocean's DATUM template path. No second public pool signaled BIP-110:
• Foundry
• Antpool
• F2Pool
• ViaBTC
• Luxor
• SBI
• MARA
• Braiins
Equally, no pool added an explicit "REJECT BIP-110" coinbase tag as a counter-signal.
• Foundry
• Antpool
• F2Pool
• ViaBTC
• Luxor
• SBI
• MARA
• Braiins
Equally, no pool added an explicit "REJECT BIP-110" coinbase tag as a counter-signal.
Ocean Hashrate Rose; Signaling Did Not
~14.5 EH/s
OCEAN · APR 7
22.75 EH/s
OCEAN · MAY 7
~1.87%
NETWORK SHARE (24H)
THE NUMBERS
Ocean.xyz dashboard reads 22.75 EH/s on 2026-05-07, up from ~14.5 EH/s a month ago. mempool.space reports a more conservative 24h figure of ~19.8 EH/s and ~1.87% network share. Hashrate Index's Apr 13 roundup put Ocean + Braiins Pool together at "just over 4%" of blocks for Apr 3–17.
THE GAP
Ocean's pool hashrate roughly 1.5×'d over the month — but per-period signaling stayed under 0.20%. Most Ocean blocks aren't built from DATUM templates with the bit-4 flag set. Pool affiliation ≠ signaling.
FROM OCEAN
On 2026-04-16, Ocean called the rent-hashrate-to-DATUM pipeline "an unexpected use of DATUM we love." No pool roadmap change announced.
The Hashrate-Rental Pattern
Rent → Datum → Ocean.
1
Rent on Braiins Hashpower in sat-denominated chunks. ~47k sats / PH·day typical.
2
Point at a DATUM-compatible stratum. Public path: PyBlock at
stratum+tcp://pool.pyblock.xyz:23334 (Knots + BIP-110 templates). Advanced path: your own Knots/BIP-110 node + DATUM gateway.3
Hash submits to Ocean on PPLNS. Coinbase signals BIP-110 if the template was built from a Knots-with-BIP-110 node.
@VENORUSPRIME · MAR 22
Scaled 100 TH/s home gear → 1.1 PH/s rented. Routed through his own DATUM. Frames the cost gap as protocol "dues."
@FIELDNAS · APR 6
First-time rental: 15 PH/s for 7 hours via PyBlock. "That's equivalent to 20+ days running an ASIC S21+."
EFFECT ON SIGNALING
Monthly signaling stayed under 0.20%. To hit 55% via rentals alone — ~47k sats/PH/day across ~1,000 EH/s of network hashrate — you'd need 500+ EH/s of rented hash daily. Subsidy-scale, not pleb-coordination scale. F2Pool's Wang Chun on Apr 4: "This is one of the reasons I rejected BIP-110."
Bitprojects' 3,000 Nodes — and What Node Counts Mean
WHAT HAPPENED · MAR 31, 00:12 UTC
b10c's BNOC monitors saw ~220 new IPv4 peers appear within ~3 minutes. The cause: a single operator — bitprojects-io — had pulled ~3,000 nodes offline simultaneously. Half-rack of colocation, ~$2,000/month, IPs at $0.30–0.40 each. Run for two years. Switched to Knots+BIP-110 about two weeks before shutdown.
80,526
INBOUND CONNECTIONS
35,127
UNIQUE SOURCE IPs
3,040
CONTROLLED NODES
"I actually did control 3k nodes, and I chose to signal BIP-110."
— bitprojects, BNOC forum
WHY IT MATTERS
PoW secures blocks, not the P2P transport layer. A peer-graph-dominant attacker can eclipse a victim node — surrounding it with attacker-controlled peers so it sees only the attacker's view of the chain, mempool, and policy signals — as well as delay propagation network-wide. Reachable-node signaling carries no economic weight. The Knots ~22% figure is post-disclosure (bitprojects nodes removed); other undisclosed Sybil operations are unknown.
ACTION 01
Make your node IPv4-reachable
Open
TCP/8333. The network's worst weakness today is that few nodes accept inbound IPv4.ACTION 02
Increase outbound connections
Default 8–12 → 24–48. Diverse outbound makes eclipse attacks dramatically harder per-victim.
Late April — A Larger Drop, Reportedly
A second, larger end-of-April drop — figures circulated, primary post not retrieved.
THE CHART
An all-nodes "Node Count by Implementation" chart (counts non-listening peers, ~10× the reachable figures on Bitnodes / Coin Dance) circulated in late April, attributed to @bitprojects_io. Bitcoin Knots rose from ~20,000 in early February to ~50,000 mid-April, then dropped sharply at end-of-month; Bitcoin Core dipped at the same moment. Primary post not retrieved — figures as reported.
~20k
KNOTS · FEB · ALL-NODES
~50k
KNOTS · MID-APR PEAK
~30k
END-APR DROP
IF IT HOLDS UP
March 31 disclosure was ~3,040 nodes. A ~30,000-node drop is an order of magnitude larger. Possible reasons: the original admission understated scale; the fleet kept growing after disclosure; or other operators ran parallel infrastructure on the same economics. Earlier Jan–Mar drop-spikes on the same chart would look like start/stop cycles, not a one-off. All-nodes counts are noisier than reachable counts.
Voices — Conferences, Opposition, Pro
MIT EXPO · APR 11–12
• Poinsot (Core): "low-likelihood/high-impact fixes that impose reasonable resource costs" are also valuable.
• Rubin: BIP-110 as "ecosystem conventions rather than top-down control."
• Rubin: BIP-110 as "ecosystem conventions rather than top-down control."
BITCOIN 2026 LV · APR 27–29
• Saylor: risk of "iatrogenic protocol changes" (the cure causes more harm than the disease).
• Back: "could open the door to transactional censorship logic."
• Bailey (BTC Inc): olive branch to BIP-110 supporters — the only on-the-record position change this month.
• Back: "could open the door to transactional censorship logic."
• Bailey (BTC Inc): olive branch to BIP-110 supporters — the only on-the-record position change this month.
"BIP 110 is a misguided and unusually careless softfork proposal. I do not expect nor support adoption. It also is on-topic, had substantial review and public discussion, and the authors made reasonable efforts to address raised issues."
— Murch (BIP editor, Bitcoin Core) · X
| # | Convergent opposition line | Loudest voices |
|---|---|---|
| 1 | It doesn't work. Habovštiak image-bypass demo; filter rules can be evaded by anyone determined. | Habovštiak, ArmchairCryptologist |
| 2 | 55% threshold without broad consensus is the real problem. | Lopp, Back, Murch |
| 3 | Filtering invites the regulator. | Lopp, Riard |
| 4 | Iatrogenic risk. | Saylor |
PRO SIDE — STILL TALKING
Most active recent pro-BIP-110 voice: Renaud Cuny (Block Space Weekly; Once Bitten! #594, Apr 14). Framing: "miners can accelerate but cannot prevent" the proposed flag day; "node-is-law" rather than "miner-is-law."