[a-shannon]

Add opt-in native Bitcoin Cash scanning, separate observation/extractor entry, bounded fee readiness and proposed finality checks before signing/broadcast. Configuration forwards scanner work budgets and records endpoint/finality diagnostic health without granting eligibility from health alone.

Independent runtime/build and persisted queue-height fixes are extracted into separate prepared prerequisites. The exact retained BCH retry fails on the unpatched baseline and passes with the height-only update; three generic SQLite stale-state cases also pass. The separate installed build preparation passes 19 cases, including real SQLite/Snappy and source-entry loading. Those results do not establish a released BCH installation, default CI/image build or accepted runtime direction.

Earlier composed Watcher startup and cleanup observations depend on the now-separated prerequisites; they do not certify the restored baseline entry. Required packages, runtime/build/retention integration and ordinary lock regeneration remain pending.

This updates an existing draft's scope and operator-review evidence. Related RCS document and matrix review, finality/design acceptance, independent endpoints and operational activation remain open. It does not request chain-code review before RCS review.

Coordinated drafts: Utils #11, Scanner #16, Guard #29, Health Check #5, UI #33.

[odiseusme]

Reviewed at watcher #17 fff071b, scanner #16 d7bc0912eb, utils #11 19f49e906d, from the watcher-operator side, using the Zcash review as a checklist.

Good: BitcoinCashConfig returns unless the network is bitcoin-cash, so existing watchers don't need a BCH section; block-level failures don't advance the cursor; and the new test suites are a clear step up.

A consensus-valid block can stall BCH scanning indefinitely: bitcoinCashValidation.ts sets local limits of 10,000 txs per block, 4,096 inputs/outputs per tx and a 64 MB RPC response. Exceeding any of them throws before the block is saved, and the scanner retries the same height forever, with no override or distinct alert. What should a watcher do when a consensus-valid block exceeds these, and do guards hit the same wall at the same block?

Failed BCH fee init leaves the process partially started: any failed fee-box read or deadline expiry makes MinimumFeeHandler.init throw, and the init.ts catch only logs. API and scanners keep running, but no commitment, reveal, redeem or health-update jobs start. Could this exit non-zero or retry instead? Is BCH intended to require a fee box for every token, unlike the other chains?

Commitment safety under the cleanup rule: the Rosen team confirmed (2026-09-29) that a guard-rejected trigger is fraud-spent after cleanup-confirm (~30 days) without re-verification, slashing the merged watchers. The PR ships no BCH depth guidance. With stock BCHN, finalization isn't a fixed confirmation count: maxreorgdepth=10 and finalizationdelay=7200 mean even a block 10-deep can remain unfinalized until the delay has elapsed. Separately, BCHN parks by default a branch whose activation would rewind more than one block, and automatic unparking is enabled if that parked branch later gains sufficiently more work. Could the commitment gate require the observed block to be an ancestor of getfinalizedblockhash, rather than use only a count, and fail closed while getchaintips reports a relevant parked competing branch? It also trusts a single BCHN endpoint with no cross-check.

Shared-path changes for every chain: utils #11 adds @bitauth/libauth (top-level-await WASM) to rosen-extractor and address-codec, so every watcher and guard loads it at startup — hence the async-entry and Rollup changes. Could BCH/libauth load only for bitcoin-cash? The abstract-scanner cleanup fix looks legitimate, but because it and the extended-typeorm/codec changes affect every scanner, could they be split into separate PRs/release notes? The Node/npm bump is already being discussed from the Zcash PR.

RPC exposure: any HTTP(S) URL is accepted, including plain http: to a remote host with username/password — credentials in clear text. BCHN itself binds JSON-RPC to localhost by default and explicitly warns against exposing it to untrusted networks. Could this match the Zcash scanner's loopback-only rule, or require HTTPS for remote hosts?

Node and release: which BCHN release and config are qualified? BCHN announced v29.2.0 on 2026-10-02 and says it will refuse to start if excessiveblocksize remains in the config. Is a pruned node supported, given that BCHN deletes old block data when pruning and makes pruning incompatible with txindex? Has the extractor been tested against the broader P2S locking-script forms made standard by the May 15, 2026 upgrade?

Release order: at these pinned SHAs, the lockfile has no entries for the BCH packages or libauth, so npm ci and the Docker build fail. BCH is also source-only at these SHAs; when its destination index is assigned, every non-BCH watcher will need a rosen-extractor upgrade to observe →BCH transfers — worth planning as one fleet-wide release.

Smaller: the codec is mainnet-only while config offers test/regtest; initial.height: -1 defaults to scanning from genesis; the 10 s RPC timeout applies to a full verbosity-2 block.

[odiseusme]

Took another look at ecc8abb (scanner 10e951c46b; matrix at guard-service 5a33942061).

Finality gate: this looks right to me — exact persisted block on active ancestry at or below getfinalizedblockhash, parked forks below the observed height rejected, start/end snapshot consistency, a required witness, and a re-check before queue broadcast of both commitments and triggers. Four operator-side points:

1. The invariant that matters for watchers under the current cleanup rule is compatibility on the BCH finality dimension: assuming the other event-validity checks pass, guards should not reject an event solely because they apply a stricter or different BCH finality/branch rule than this gate. Could the guard-side BCH finality rule be specified so that, on this dimension, it accepts everything this gate passes?
2. Witness cost: for the finality witness specifically, the RPCs used here appear prune-safe — they use chain/header/index state rather than historical block bodies — so a pruned BCHN should be sufficient. Could you confirm that as a supported deployment and document it? And, if I'm reading the two-endpoint rule correctly, could the docs state that the witness is an additional veto only: it cannot make an event pass unless the primary endpoint passes too, so compromise of the witness alone affects liveness rather than safety?
3. Visibility: am I reading the current behavior correctly that a normal wait for finalization, witness failure, endpoint disagreement, and parked-fork rejection all go through the same retry/error path? If so, separate health states would let operators distinguish routine waiting from an actual fault.
4. Latency: for a freshly observed deposit block, default BCHN settings mean it cannot pass this gate until both its header has been known to the node for 7,200 seconds and it is at least 10 blocks behind the tip (maxreorgdepth=10). So the normal floor is about two hours, and it can be longer if block production is slow. Worth stating explicitly for Rosen's UX and timer assumptions.

Shared-module boundary: from the operator side I'd support the dedicated BCH extractor entry or package rather than accepting the eager root export, with an acceptance test that a non-BCH watcher's emitted startup graph never loads libauth. That keeps the BCH runtime risk with the BCH deployment.