[bkeroack]

Bumps the package to satd 0.6.1, the release with the fixes this draft (#1) waits on. Cut from chore/community-audit at 7b78382, so the review stays as it is. Same shape as #2.

What changes

• ghcr.io/epochbtc/satd:0.6.1 (manifest list for linux/amd64 and linux/arm64, digest sha256:84c09ec1c1a3b57cd5fb6d2f413b3c54ef547b31ff2074f93ee1e5c8d37e18df; cosign-signed by the satd release workflow).
• version: '#satd:0.6.1:0', release notes in all five locales.
• test/upstream/satd-init vendored from v0.6.1 (fef5294e).
• SATD_STACK_SUBNET is no longer passed. satd-init stopped reading it in 0.6.0, when the template stopped rendering a subnet into rpcallowip. The template now writes rpcallowip=0.0.0.0/0, because the same list also gates the published TLS RPC listener. The plain listener is still reachable only through the container bridge and the OS proxy, and still needs the RPC credential.
• README and instructions: dropped the advice not to interrupt the switch. Limitation 1 is now the one item still open: reindex speed.

Your three items

1. A killed reindex resumes from the block files. Fixed (An interrupted full -reindex starts over instead of resuming from the block files epochbtc/satd#906, by Continue an interrupted -reindex from the block files on any start (#906) epochbtc/satd#915). Any start continues an interrupted full -reindex from the height it last flushed. It first checks the replayed blocks against the block files, then connects the rest, downloading nothing and writing no block file. A continued reindex reads only block headers: at most 4 KiB per block rather than every file in full (A continued -reindex reads every block file in full before it connects anything epochbtc/satd#916). A full -reindex also no longer appends a second genesis block to the last block file, which on your switch was Core's (A full -reindex appends a duplicate genesis block to the last block file epochbtc/satd#931).
2. SIGTERM during block connection. Fixed (SIGTERM during -reindex / -reindex-chainstate is ignored or kills mid-batch: no handler until startup finishes epochbtc/satd#907, by Stop a startup block replay cleanly on SIGTERM, also as PID 1 (#907) epochbtc/satd#914). During -reindex, -reindex-chainstate or -upgradechainstate, satd abandons the block in hand, flushes and exits 0 within -maxshutdownsecs (30 s by default), also as PID 1.
3. Reindex throughput. Not changed in 0.6.1. It is on our list for a later release.

The satd-init in 0.6.1 adds two things you will see in the rendered bitcoin.conf, both inside the container only:

• upgradechainstate=1: rebuilds the chainstate from the block files when a release changes its format.
• A metrics TLS listener on 9336. It is not exported, and the package does not use it.

Tested

• npm run check: tsc and 11/11 tests pass. npm run build passes. Prettier is clean on startos/ and test/; README.md fails prettier --check on chore/community-audit already, and this PR doesn't change that.
• Before the tag, the same reindex fixes (from release/0.6) ran in this package on a StartOS 0.4.0.1 VM: five stop/continue cases, details in fix: run satd with RUST_LOG=info #2. That run predates the genesis-append fix, which is in 0.6.1.
• Not run by us: this exact s9pk on a StartOS box, or the Core → satd → Core switch. That is your acceptance check in chore: community intake audit, as the satd flavor of bitcoind #1.

🤖 Generated with Claude Code

[helix-a]

Changes requested on 212d5acddf5be076dec562590c3a009a2fce126b.

1. Warn about the existing-satd upgrade cost. This jump crosses 0.6.0's chainstate schema change (3 → 7). The new image's satd-init enables upgradechainstate=1, so an existing 0.5.x datadir automatically rebuilds chainstate and indexes, even without a Core/Knots flavor switch. The release notes do not mention that potentially multi-day operation. The proposal adds the warning and an upstream comparison link in every locale. It also documents the new, unexported metrics TLS listener on 9336.
2. Finish the SDK refresh already raised on #1. The pin remains 2.0.9; npm currently serves 3.0.6. A trial exact bump with a stabilized lockfile fails typechecking: removed setupDependencies, removed manifest dependencies, the required third buildManifest argument, and missing launchable fields in action results. This needs the documented 3.x dependency/toolchain migration, not a pin-only update. I reverted the trial rather than publish an uncompilable proposal. startos/index.ts is marked DO NOT EDIT under the applicable workspace rules, so that plumbing refresh needs an authorized update. This can be resolved on chore/community-audit and brought into this PR rather than duplicated here; it remains required before approval. The published proposal contains only the verified documentation/release-note changes, not a completed SDK upgrade.

Verified: clean merge with origin/chore/community-audit; the image tag resolves for amd64 and arm64; the vendored satd-init exactly matches v0.6.1. Both the submitted head and the proposal pass the package build, typecheck, all 11 tests, and Prettier for startos/ and test/ through helix-build. Inspected the returned s9pk manifest and commitment. Revalidated from a clean install after the SDK trial. The upstream compatibility pass found no concrete regressions in configuration, listener/auth paths, health probing, or full-reindex continuation. No StartOS runtime or Core → satd → Core acceptance test was run; #1's draft acceptance gate still applies.

Proposed changes: 212d5ac...proposal/3

Helix-Harness: pi
Helix-Model: openai-codex/gpt-6.1-sol

[bkeroack]

Both items are addressed.

1. Upgrade warning. 0bc5f01 takes proposal/3 as proposed, with a descriptive commit message. I checked it against v0.6.1. The chainstate schema went from 3 to 7 (node/src/storage/rocksdb_store.rs), and the vendored satd-init sets upgradechainstate=1 and binds the metrics TLS listener on 9336. The 0.6.0 notes put the rebuild at roughly an -assumevalid sync of the chain, so "allow days" is fair on StartOS hardware.
2. SDK 3.x. This is Update start-sdk to 3.0.6 #4, against chore/community-audit as you suggested. It updates to 3.0.6, the current release, and matches its package template. The minimum StartOS version goes to 0.4.0.2. A test merge of Update start-sdk to 3.0.6 #4 with this branch's head has no conflicts and passes make x86 (type check, SDK lint, 11/11 tests, Prettier, pack). Once Update start-sdk to 3.0.6 #4 lands, I'll merge chore/community-audit into this branch.

[helix-a]

Cross-review requested.

[helix-a]

Re-reviewed 0bc5f01b94f7318e8923381cf2f3a1fb066ab36f, starting with the changes since the previous review.

The upgrade-cost warning is resolved: the previous documentation proposal is incorporated, including the warning in all five locales and the unexported metrics TLS listener.

The SDK item is not yet resolved on this head. package.json and the returned s9pk still report 2.0.9; npm view @start9labs/start-sdk version reports 3.0.6. #4 is still open and chore/community-audit has not incorporated it. Please land that migration, bring the updated base into this branch, and re-request review. Opening #4 is the right approach, but it does not update the artifact under review.

The outstanding proposed implementation is already published in this same base repository as #4 (head ed20b057e7d7a634281a8e765b80989689404315). No new implementation proposal is needed for this repeat finding; the earlier proposal/3 documentation changes are already accepted. git merge-tree --write-tree confirms both this head against its current base and this head combined with #4 are conflict-free.

Verified this exact head through helix-build: typecheck, all 11 tests, Prettier on startos/ and test/, and make bitcoind.s9pk pass. Inspected the returned artifact's manifest and commitment. npm audit separately reports two high-severity dependency findings under the SDK's bundled ESLint tooling (brace-expansion and js-yaml); this is not a clean audit. Reused the prior review's upstream compatibility evidence; no StartOS runtime or Core → satd → Core acceptance test was run, and #1's acceptance gate remains unchanged.

Helix-Harness: pi
Helix-Model: openai-codex/gpt-6.1-sol
Helix-Identity: helix-b

[helix-a]

Agreed: the documentation finding is resolved, but the SDK requirement remains pending #4 and its incorporation into this branch. This session reviewed #3 and published proposal/3; @bkeroack owns the PR branch. I have not changed that branch or re-requested review. Once the SDK migration is incorporated, the updated head can be re-reviewed; #1’s runtime acceptance gate remains unchanged.

[bkeroack]

This branch now builds on SDK 3.0.6. #4 isn't merged into chore/community-audit yet, so 3f89348 merges #4's branch (edac2a3, which includes the lockfile fix) into this one. When chore/community-audit takes #4, it merges here cleanly. After a clean npm ci, make x86 passes (11/11 tests), and npm install leaves the lock unchanged. The packed manifest shows #satd:0.6.1:0, SDK 3.0.6, minimum StartOS 0.4.0.2 and empty dependencies. npm audit reports 0 vulnerabilities: the two highs you saw came from the 2.0.9 tree.

@helix-a, could you re-review?