The Knots tracker

Every pull request in the fight over XBT's coinbase lock and the spam that's still getting through. Status, approvals and the latest word from each thread, quoted as written. Updates automatically from GitHub, last pulled 2m ago.

🔒 16,525 XBT locked, unlock in 1,197 blocks (about 8 days). Unlock tracker

Coinbase lock proposals

Earlier lock PRs

• Draft #397 [WIP] consensus: Relock outputs of early coinbase spends Sep 15, 2026
• Open #409 Consensus: Batched extended coinbase maturity temporary softfork /w hash based random maturity instead of deterministic height based Sep 14, 2026
• Open #404 Consensus: Batched extended coinbase maturity temporary softfork Sep 12, 2026
• Closed #469 Softfork: Continue RDTS, with a rolling 40320-block (~280-day) coinbase maturity (builds on #467) Oct 23, 2026

Spam fixes

BPUB and friends hide data in fake public keys and slip past BIP-110. These are the patches.

Latest from the threads

“Tested c705c3a on top of 58398baf33. - Build OK, ctest 146/146 - coinbasematuritytests, featurechainstaterevalidation, mempoollongcoinbasematurity, mempoolspendcoinbase: pass - rpcblockchain.py (v1 and v2 transport): FAIL. eb6e889 passes. Dropping the early return in LongCoinbaseMaturityDescPushBack makes networks that never configure the deployment (e.g. regtest) report: longcoinbasematurity {height: 2147483647, …”

geobees on #480 · 5m ago

“Re-tested eb6e889 (Ubuntu on WSL2, GCC 15.2.0, no GUI): the earlier failures are fixed. - build OK - coinbasematuritytests: pass - validationchainstatemanagertests: pass - unit suite: 146/146 - functional: featurechainstaterevalidation, mempoollongcoinbasematurity, mempoolspendcoinbase pass Only nit left: with ReleaseHeight at INTMAX, rpc/blockchain.cpp (~line 1967) returns early, so heightend / maturity appear to …”

geobees on #480 · 41m ago

“Re-tested 98f8ea8: the chainparams revert fixes validationchainstatemanagertests (passes now). One assertion left in coinbasematuritytests.cpp:48 (testnet4): testdeployment.stopheight == testconsensus.CoinbaseMaturityLongReleaseHeight fails [158110 != 158111]. It needs - 1 like the mainnet check above it.”

geobees on #480 · 51m ago

“Tested 235347e (Ubuntu on WSL2, GCC 15.2.0, no GUI). Not an ACK yet, one unit test regression: Fails: validationchainstatemanagertests/chainstatemanagersnapshotrevalidationwaitsforbackground validationchainstatemanagertests.cpp(703): check marker.stopheight == 102 has failed [103 != 102] The same test passes on the base (58398baf33, 10 test cases, no errors), so this comes from the PR. Cause: the shared helper …”

geobees on #480 · 1h ago

“I made a very similar propsal with 3 lines of code outside of tests, expires never. 480”

FlyTheElephant1 on #467 · 5h ago

“no consensus reached”

ZERODAYKEK on #469 · 6h ago

“tested ACK 83a1f681da848e9b6a4fa9661890917f5763a491 Re-tested after the end-bound commits (5f5affafe2..83a1f681da): - Built without GUI. coinbasematuritytests and the full testbitcoin suite pass. - featurerollingmaturityendbound.py, mempoolrollingcoinbasematurity.py and mempoollongcoinbasematurity.py pass. - Manual regtest with -testcoinbasematurityrolling=150:300:200:260, checked through testmempoolaccept and …”

Kilombino on #476 · 7h ago

“Concept Re-ACK. I have reviewed the NACK's and I think we still have very broad consensus to move forward. Community strongly prefers Long CBM. This gets us to 6 months rolling. And this PR has a lot of flexibility for the future. With or without a cliff, this is worth doing.”

Daamir-Al-Adel on #468 · 8h ago

“Still concept ACK, though I'd prefer letting the current rule expire and planning a proper softfork timeline.”

kwsantiago on #468 · 9h ago

“My disagreements are with @luke-jr 's NACK are: Increased CBM with as minimal credible threat of withholding rewards still arguably serves a purpose. Miners must buy-in to the network having some chances beyond the next 17 hours as they do with 100 block CBM. That's not reasonable - those are released per the existing code and it isn't incumbent on this PR to remedy that. Separate proposals by @FlyTheElephant1 seek …”

BitcoinMechanic on #468 · 9h ago

“This same proposal was designed to be able to have its activation delayed without changing the design to allow more time for review, so I would be in favor of simply doing that, if consensus cannot be reached in time to activate at block 979919. For the record I am still a Concept ACK on this, and I agree with @BitcoinMechanic that this would still be highly beneficial even if we never permanently withhold sv1 …”

chrisguida on #468 · 9h ago

“Thanks @luke-jr You’re right that locking new rewards while releasing the window coins is backwards, and 477 fixes exactly that. So that problem is no reason to drop 468 and fall back to 100 blocks. My Concept ACK on 468 stands.”

davelund110 on #468 · 9h ago

Approvals count GitHub reviews marked approved or starting with ACK. Comments are quoted verbatim and trimmed for length; follow the link for the full thread. Not financial advice.