Pruned tip validation under a 300 MiB lid: BCH on Pi Zero 2 W vs Bitcoin Core control

Technical
#1

Pruned tip validation under a 300 MiB lid: BCH on Pi Zero 2 W vs Bitcoin Core control

I measured ** non-mining full validation of the tip ** — follow chain tip, enforce rules, reject junk — on ** Raspberry Pi Zero 2 W-class ** boards (~415 MiB RAM) under a ** hard systemd MemoryMax of 300 MiB **.

** Arm A — BCH **

  • Software: Bitcoin Cash Node ** 29.1 ** pruned

  • Bootstrap: sideloaded tip snapshot

  • Result under 300 MiB: ** PASS ** multi-day tip-follow

** Arm B — BTC control **

  • Software: Bitcoin Core ** 28.1 ** pruned

  • Bootstrap: assumeutxo to tip on a Mac, then sideload

  • Result under 300 MiB: ** FAIL ** — no stable tip-follow under the same lid

This is ** not ** “nodes secure the network” or “everyone must run one.” It is a ** measured operating envelope ** for optional independent tip-check on very small hardware.

TL;DR for laypeople — is this still a node?

** Yes. ** A ** node ** here means a machine that ** checks new BCH blocks under consensus rules ** and keeps a tip — not a miner, not an archive of all history, not “the thing that makes the chain secure.”

** Still a node because: **

  • Peer network + ** full validation of new tips **

  • ** Rejects invalid ** successors when tested

  • Holds the ** chainstate needed for tip-follow **

  • Runs ** days ** under a hard ** 300 MiB ** process lid

** Not a “big node” because: **

  • ** Pruned ** — old block files discarded

  • No mining / no block production

  • Not serving full IBD to others

  • Not an unlimited hardware free-for-all

** Pruned full node for tip-follow ** is the precise phrase. Pruning does not turn validation into SPV; it drops history you no longer need to check * what arrives next *. The museum job (archive) and the referee job (tip) are different. This pack measures the referee on tiny hardware.

Motivation

Non-mining full nodes mainly: download new blocks, validate, update chainstate, advance tip. Archive storage, fat mempools, and serving IBD are extra jobs. Capacity debates often blur “keep the museum” with “refuse an invalid tip.”

Related BCR threads (vocabulary we align with, not re-derive):

Shared method

  • ** Hardware: ** Pi Zero 2 W class (~415 MiB MemTotal)

  • ** Hard lid (where claimed): ** cgroup MemoryMax=300M (enforced)

  • ** Role: ** pruned tip-follow, not archival serve

  • ** Bootstrap class: ** sideload tip-capable datadir (not genesis IBD on the Zero)

  • ** Fair control: ** same bootstrap class for BTC (assumeutxo on a larger host, then copy)

Two boards: multi-day proof board left on BCH throughout; lab board used for thrash probes and the BTC control, then restored.

Arm A — BCH (PASS)

** Daemon: ** BCHN ** 29.1.0 **, pruned (prune ~5500 class), small dbcache, few peers; proof dial without wallet.

  • Continuous tip_mem window: ~** 54 h ** unbroken samples, IBD=0, height nondecreasing (Gate48)

  • Wall-clock tip-follow: ** ≥72 h ** (Gate72); honest ~** 18 h ** sample gap after MemoryMax enable/reboot

  • Memory band (Gate48 window): RSS med ~** 135 MiB , max ~ 219 MiB ** under the 300 MiB lid

  • Invalid successor challenges: ** REJECT **, tip held (lab)

** Everyday mainnet tip sizes (measurement window): ** last-500 tips max ~** 440 KiB **. Multi-MiB blocks exist in retained history; multi-day started after sideload near tip — we ** do not ** claim the Zero re-validated those historical multi-MiB ** connects ** under MemoryMax during the freeze window.

** Size envelope (lab reject path, invalid mutated real bodies, never broadcast): ** reject OK through ~** 2.7 MiB ** class; ~** 3.6 MiB ** class can thrash the host under wallet+300M dial. Stream-parse of multi-MiB blocks is easy; thrash is ** connect / UTXO path **, not “blocks are unreadable in pieces.”

Arm B — BTC control (FAIL @ 300 MiB club)

** Daemon: ** Bitcoin Core ** 28.1 **.

  • Cold IBD @ MemoryMax=300M: ** FAIL ** (OOM)

  • Assumeutxo + catch-up on Mac to tip: ** PASS **

  • Sideload to Zero: ** PASS ** (transfer completed)

  • Tip-follow under ** MemoryMax=300M ** after sideload: ** FAIL ** — never stable tip RPC; thrash during snapshot chainstate ** load ** (peaks ~250–264 MiB + swap under the lid)

Fairness note: BTC was given the same ** sideload-then-tip ** honesty class as BCH, not only “cold IBD on Zero.” Even so, Core did not enter the 300 MiB tip-court club in our tests.

Lab follow-ons (optional; not required for the comparative claim)

Same boards, documented in this pack:

  • ** Hub to edge stream packs ** (chunked block + prevouts; stream verify without thrashing tip-follow)

  • ** Multi-height proof-carrying spike ** (lab forest / bridge; honest trust limits on hub-supplied prevouts)

These are architecture probes. The headline claim remains ** stock pruned tip-follow under a hard RAM lid **.

What this is / is not

** Is **

  • A measured envelope for cheap independent tip validation on Zero-class hardware

  • Evidence that ** BCHN ** can tip-follow multi-day under ** 300 MiB ** after sideload

  • A fair ** negative ** control for ** Bitcoin Core ** under the same job + lid

** Is not **

  • Mining, archive duty, or “I secure the network”

  • “Core can never run on any Pi”

  • Unlimited any block size forever on a Zero

  • Full CashVM / future EC op-cost measurement on Zero

  • Production proof-carrying mainnet compact node

Open questions

  1. Is “tip court / cheap tip validator” a useful named role next to archive + miner, or is “pruned full node” enough?

  2. Should resource envelopes (RAM x size x op-cost) be standard artifacts for ABLA, faster blocks, or Fastsync consumers?

  3. Interest in chunked block download + stream validation as complementary work?

  4. For proof-carrying Zero tip-check: what trust bar on bridges / snapshots would you require before calling it “fully validating”?

Artifacts

Pack: https://github.com/CTM90/bch-tip-court-envelope

Happy to take methodology criticism and re-run specific dials.

TL;DR

On Pi Zero 2 W–class hardware with a hard 300 MiB RAM cap:

• BCH (BCHN 29.1, pruned, sideloaded tip): multi-day tip-follow works (Gate48 ~54h continuous, Gate72 ≥72h wall-clock). Still a real node: validates new tips under consensus rules; just pruned, not an archive/miner.
• BTC (Bitcoin Core 28.1, same job + lid): does not — never stable tip-follow after sideload under 300 MiB.

Not “nodes secure the network.” It’s a measured envelope: optional independent tip-check on tiny hardware.