(BOB) Roadmap — Following Bitcoin Core's Evolution

[MWOWM]

(BOB) DOBBSCOIN — the modernization map
Reposted and expanded from MWOWM. Kicked off by BtcBob's roadmap thread: Following the Bitcorn Evolution. Background: (BOB) in early crypto history — the map below is that "Chain Resurrection".

Where we actually are. (BOB) is a Bitcoin Core 0.10 fork struck in January 2014 and effectively frozen around 2015: scrypt PoW, v1-only transactions (src/main.cpp:643 rejects v2), 2-minute blocks, a KGW+DigiShield retarget, and a flat 1.5 (BOB)/block subsidy forever. Bitcoin Core has shipped roughly nineteen more releases since. This thread maps that gap — not as a wishlist to clone, but as a set of decisions.

The one load-bearing idea: we do not rebase onto modern Core. We cherry-pick. And every upstream feature sorts into exactly one of two bins:

• Non-consensus — node internals, wallet, networking, build system. These change how the software runs, not what the chain agrees on. We can adopt them freely, one PR at a time, with zero coordination risk. This is most of Core's last decade of work.
• Consensus — SegWit, CSV/BIP68, Taproot. These change the rules every node must agree on. On a low-hashrate community coin they are governance calls, not code merges. This is where "we don't need to be clones" actually bites.

What we never clone away. The 2-minute scrypt cadence, the KGW+DigiShield hybrid retarget, and the flat-1.5 uncapped subsidy are (BOB)'s identity, not tech debt. No upstream release touches those, and neither do we.

The sections below are each their own post so you can reply to one without dragging the rest:

• Strategy — cherry-pick, not rebase
• Node internals & validation (0.10 → 0.15)
• The SegWit fork-in-the-road (consensus)
• Wallet modernization — and killing the BDB 4.8 albatross
• Network & privacy (0.19 → 0.28)
• Taproot & script upgrades (dependent)
• Build & maintainability — the "less work" answer
• Proposed sequencing

NOT FINANCIAL ADVISORS. NOT FINANCIAL ADVICE. Praise "Bob".

[MWOWM]

1 · Why we port features instead of merging Core

The tempting move is git merge upstream and take everything. It would be a disaster here.

(BOB)'s consensus diff is welded into the two files a rebase touches most: src/pow.cpp (KGW at block 13579, DigiShield at 31597, the 2-minute regime at 68425) and src/main.cpp (flat subsidy at 951753). Modern Core has rewritten those same areas repeatedly. A rebase would put us in permanent merge-conflict against our own identity.

So the method is: treat each upstream improvement as a discrete, backportable change; open it as its own PR against dobbscoin-source; keep the (BOB) consensus diff sacred and untouched. Small, reviewable, revertible.

Reply surface: does everyone agree with per-feature porting over a big rebase, and with the non-consensus / consensus taxonomy from the opening post? Everything downstream assumes that split.

[MWOWM]

2 · The highest-value, lowest-risk wins

All non-consensus. All make (BOB) a better node without changing a single chain rule.

• libsecp256k1 for validation (Core 0.12) — replaces OpenSSL EC verify with Bitcoin's own hardened, much faster library. Same results, so it is not a consensus change. Adopt early; it also shrinks our OpenSSL surface.
• Compact blocks / BIP152 (0.13) — matters more for us than for Bitcoin. At 2-minute spacing on low hashrate, fast block propagation directly cuts orphan rate. High value.
• assumevalid + sync refinements (0.14) — skips signature re-checking below a buried checkpoint during initial sync. Faster bootstrap, no rule change.
• Per-UTXO chainstate database (0.15) — the single biggest node improvement Core ever shipped. It replaces the old per-block undo model and slashes sync/reindex time and memory. Zero consensus impact. This is the marquee port.
• RPC modernization — we are stuck on the pre-0.12 dialect (no getblockheader; getblock takes a bool for verbose). Bringing RPC forward unblocks explorers, wallets, and every downstream tool.

Reply surface: I would make the 0.15 chainstate port the flagship of node work. Objections, or a different first target?

[MWOWM]

3 · The one that is a decision, not a merge

SegWit is Core 0.13 (code) / 0.16 (wallet). For us it is not one change — it is a chain of consensus changes, because we start further back than Bitcoin did.

The dependency nobody mentions: SegWit assumes CSV / BIP68-112-113 (relative timelocks). (BOB) never shipped those — we are v1-only, and src/main.cpp:643 rejects v2 transactions at the mempool. So the real sequence is: ship CSV (consensus), then activate SegWit (consensus), then bech32 addresses, then wallet migration.

For: fixes transaction malleability (the prerequisite for Lightning / any L2), adds block-weight capacity, and is the gateway to Taproot.
Against: a multi-stage consensus change on a low-hashrate chain carries real activation risk, needs genuine community coordination, and churns every address and wallet.

This is exactly where we don't need to be clones. A scrypt community coin can rationally decide to stay legacy-script and skip SegWit entirely — or to do it deliberately, as a headline event with a real activation plan. Both are defensible. What is not defensible is drifting into it by accident.

Reply surface: does SegWit go on the roadmap at all? If yes, headline upgrade or someday-maybe? This one is a governance call, so it wants more than one voice.

[MWOWM]

4 · Descriptor wallets, and the end of the db-4.8.30 dance

Mostly independent of the SegWit question — legacy descriptors work fine without SegWit — so this can proceed on its own track.

• HD + multiwallet (0.15), descriptor wallets (0.17 → 0.21), PSBT (0.17), migratewallet legacy→descriptor (0.24).
• The storage win: Core moved wallets from Berkeley DB to SQLite descriptor wallets (default from 0.23). That is our single most annoying build dependency — the whole static db-4.8.30.NC compile documented in doc/build-unix.md exists only to open old wallet.dat files. SQLite descriptor wallets retire the BDB albatross entirely.

Reply surface: I would pursue descriptor + SQLite wallets regardless of what happens with SegWit, purely for maintainability and to drop BDB. Agree, or keep BDB compatibility for legacy wallet.dat holders during a transition window?

[MWOWM]

5 · Resilience features that matter more for a small chain

All non-consensus, all node-level, and every one of them is worth more to a low-peer-count coin than to Bitcoin.

• Compact block filters / BIP157-158 (0.19) — lets light clients sync privately against our nodes. Groundwork for real (BOB) mobile/SPV wallets.
• asmap addrman bucketing (0.20) — buckets peers by network topology to resist eclipse attacks. On a chain with few honest peers, this is cheap insurance with an outsized payoff.
• Tor v3 + I2P (0.21) — censorship-resistant reachability; nodes that survive a hostile network.
• BIP324 v2 encrypted transport (0.27 → 0.28) — opportunistic P2P encryption, defeats trivial traffic analysis and tampering.

Reply surface: I would sequence asmap + Tor v3 early — both are low-effort and high-resilience. Different priority?

[MWOWM]

6 · Downstream of the SegWit decision

Taproot (BIP340/341/342, Core 0.21 / 22.0) is a soft fork layered on top of SegWit v1. There is no Taproot without SegWit — the witness structure it upgrades does not exist on a legacy-script chain.

So this section has no independent decision: it is entirely gated on section 3. If we skip SegWit, Taproot is simply off the table, and that is a perfectly coherent place to land. If we ever do SegWit, Taproot becomes the natural follow-on (better multisig, key-path privacy, cheaper scripts).

Reply surface: confirm we park Taproot behind the SegWit decision and spend zero effort on it until then.

[MWOWM]

7 · The section that answers the actual motivation

The reason to follow Core at all — in BtcBob's words, to avoid "a shit ton of extra work with zero C++ skill" — lives here. These lower the cost of every other item.

• The CMake migration (Core's Autotools → CMake, ~v29) — modern, faster, genuinely cross-platform builds. This directly retires the fragile autogen.sh / configure / static-BDB ritual that makes (BOB) painful to build today.
• libbitcoinkernel — Core is extracting the consensus engine as a reusable library. Long term this lets explorers and tooling reuse validation without shipping a whole node.
• assumeUTXO (0.26) — bootstrap a usable node from a signed UTXO snapshot in minutes instead of a full replay.
• Modern CI, functional test suite, sanitizers — the highest-leverage item for a small team. Good tests catch regressions without deep C++ fluency; they are how you modernize safely without being a Core dev.

Reply surface: I would make build + test + dependency modernization milestone zero — before any feature port — precisely because it makes everything after it cheaper and safer. Agree?

[MWOWM]

8 · The order I would actually run this

Non-consensus work first, because it is safe and compounding. Consensus last, on its own governance track.

• Milestone 0 — Foundation. CMake build, drop BDB via descriptor + SQLite wallet, modern CI/tests. (sections 7, 4)
• Milestone 1 — Node internals. libsecp256k1, per-UTXO chainstate DB, compact blocks, RPC modernization. (section 2)
• Milestone 2 — Network & privacy. asmap, Tor v3, block filters, BIP324. (section 5)
• Milestone 3 — Wallet UX. finish descriptors / PSBT. (section 4)
• Governance track (parallel, separate thread + community vote). CSV → SegWit? → Taproot? (sections 3, 6)

Held sacred throughout — never cloned away: 2-minute scrypt PoW, KGW+DigiShield retarget, flat-1.5 (BOB)/block subsidy, no-21M-cap inflation. Modernize the engine; keep the soul.

Reply surface: is this the right order? The one real dependency is that Milestone 0 comes first — after that, the rest can reshuffle to whoever is doing the work.

— MWOWM. Backed By Nothing, Powered By Everything.