BKillings commited on
Commit
e4b5ded
·
verified ·
1 Parent(s): feb0202

Upload 2 files

Browse files
Files changed (2) hide show
  1. RECOVERY.md +39 -0
  2. STORAGE.md +28 -0
RECOVERY.md ADDED
@@ -0,0 +1,39 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # Verified backup and recovery
2
+
3
+ Run from the package directory on Linux, with cryptography installed:
4
+
5
+ ```sh
6
+ python3 bkillings_backup.py backup /var/lib/bkillings/chain.sqlite /safe/location/backup.sqlite > /safe/location/checkpoint.json
7
+ python3 bkillings_backup.py restore /safe/location/backup.sqlite /safe/location/restored.sqlite --checkpoint /safe/location/checkpoint.json
8
+ ```
9
+
10
+ Check the command exit status before treating a backup as successful. Use unique
11
+ filenames; the tool refuses to overwrite existing destinations. Do not redirect
12
+ output onto an existing trusted checkpoint file. Keep the checkpoint in an
13
+ independent trusted location: a checkpoint stored beside a backup is not evidence
14
+ against an attacker who can replace both. It records height, block hash, and
15
+ state/nonce commitment. It is not a Bitcoin anchor or a signed certificate.
16
+
17
+ The tool uses SQLite's online backup API, verifies SQLite and chain integrity,
18
+ compares the supplied checkpoint on restoration, and publishes a standalone
19
+ mode-0600 database only after verification. Missing or empty source databases
20
+ are rejected rather than initialized. Linux hard-link and directory-fsync
21
+ semantics are required. A filesystem error after publication can leave the
22
+ output present even if the command reports failure; inspect before retrying.
23
+
24
+ Restore into a new path first. Stop the service before switching its configured
25
+ database path. Check readiness and the expected height/commitment after starting.
26
+ Never replace a live SQLite database or copy just its main file while WAL is active.
27
+
28
+ Verified September 26, 2026: 26 unittest tests pass, including four new backup
29
+ checks: live-WAL snapshot and restore followed by continued writes; checkpoint
30
+ mismatch refusal; missing/empty input refusal; existing destination preservation.
31
+ The HTTP process restart test also passes. Original pytest baseline tests,
32
+ physical power loss, systemd installation, remote deployment, and off-host
33
+ recovery remain unverified.
34
+
35
+ Deployment access checked: Hugging Face account BKillings authenticates. The
36
+ current connected credential grants read-repos and jobs but not repository
37
+ write, so it cannot upload this package to a Space. No cloud resources were
38
+ created or changed. Hosting, persistent storage, and remote service checks
39
+ remain outstanding. Existing protocol limitations in PILOT.md still apply.
STORAGE.md ADDED
@@ -0,0 +1,28 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # BKILLINGS durable runtime v3
2
+
3
+ This package adds SQLite storage to the locally tested runtime adapter. It is not deployed.
4
+
5
+ ## Use
6
+
7
+ Install dependencies from requirements.txt. From the extracted bkillings directory:
8
+
9
+ ```python
10
+ from bkillings_store import BKillingsStore
11
+ from deepcore_blockchain import Transaction
12
+ from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey
13
+
14
+ # Demo key only; production key custody must be configured independently.
15
+ key = Ed25519PrivateKey.generate()
16
+ with BKillingsStore("bkillings.sqlite") as store:
17
+ tx = Transaction.sign(key, 1, "OBSERVATION", {"value": 10})
18
+ store.add_block([tx])
19
+ print(store.snapshot().verified_commitment())
20
+ ```
21
+
22
+ Reopen the same database to recover the chain. Each operation reloads verified state under a SQLite transaction. Writes use BEGIN IMMEDIATE, WAL, and synchronous=FULL. Use one connection per thread or process; separate writers serialize through SQLite. Keep the database on a local filesystem with correct SQLite locking and sync semantics. Back up with SQLite's backup API; do not copy only the main file while WAL is active.
23
+
24
+ Verification on this turn: 21 unittest tests passed (7 mathematical, 8 runtime integration, 6 storage). The six storage checks cover restart equality, invalid-batch rollback, separate-writer reload, injected SQL failure, stored-commitment tampering, and subprocess termination before commit. The prior turn reported 24 additional baseline tests passing; they were not rerun here because pytest was unavailable.
25
+
26
+ Run the current suite with `python -m unittest -v test_math test_integration test_store`. Run all tests, including the original baseline, with `python -m pytest -q` when pytest is installed.
27
+
28
+ Limits: process-exit testing does not establish power-loss durability on every storage device. Stored hashes detect inconsistent edits, not an attacker rewriting all data and hashes or truncating a valid suffix. An empty database initializes genesis; external trusted checkpoints and backups are required to detect deletion or rollback. Full-prefix replay during loading is expensive (quadratic verification work); this is a small-chain prototype. It has no distributed consensus, signer service, persistent key custody, authenticated API, or Bitcoin broadcaster. Existing network-binding and clock-dependent replay limitations remain. No repository, deployment, or live chain was changed.