Bring main onto the line this project actually ships

main had drifted to a history with no ancestor in common with the tree we
build and deploy. It sat at be63e83 (2026-08-09) with 28 commits; the shipped
line, deploy/soak-2026-08-21, had 383. The two shared nothing -- git
merge-base returns no result at all -- so anyone cloning this repository
landed on a default branch that was neither current nor related to the
running node.

The 28 commits on main were audited before this merge: every one is already
present in the tree by content, including the two that are hardest to see
because they were rewritten afterwards -- the payout reorg-safety work
(PayoutBlockStillOnChain, since evolved to re-check on every retry rather
than once at maturity) and the nostr relay certificate verification
(SSL_set1_host, now with a Windows root-store path). Nothing on main is lost
by this merge.

Recorded as a merge rather than a force-push: main only ever moves forward,
its old history stays reachable as the first parent, and this is revertible.
The tree is taken wholesale from the merged branch, so main's content is now
exactly what was built and tested.

What this brings onto main:

- compactblock: BIP152-style compact block relay ported from upstream 1.2.23,
  primitives and unit test only, with the RAND_bytes failure path closed and
  the reconstruction allocation bounded.
- upstream/main 17741d9: isolated testnet parameters and genesis, optional
  2 MB large pages for RandomX. Mainnet genesis verified byte-identical
  through upstream's BuildGenesisBlock() refactor.
- deploy: every image built on bookworm so binaries run on Debian 12, and the
  container build now honours the RandomX and libsecp256k1 pins it had been
  silently ignoring since before 1.2.15.

Gates at this tree: 15/15 selftests, compactblock's 17 checks, consensus
constants unchanged against e4f898c apart from the pre-existing
MAX_BLOCK_SIZE_GEN, mainnet genesis intact, money-log check ok.

1 files changed, 237 insertions, 18 deletions

diff --git a/README.md b/README.md
index 9a55a5b..4453529 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,20 @@
-## Bitflash `BTF`
+<div align="center">
+
+<img src="docs/social.png" width="820" alt="Bitflash"/>
+
+# Bitflash `BTF`
+
 CPU-only cryptocurrency. A revival of Bitcoin 0.1.0 with RandomX proof of work and anonymous `.btf` addressing over Nostr.
 
-## Bitflash community
-Discord: https://discord.gg/TJG6vnXS9
+![PoW](https://img.shields.io/badge/PoW-RandomX%20(CPU)-2ea44f?style=for-the-badge)
+![Privacy](https://img.shields.io/badge/addresses-.btf%20anonymous-2ea44f?style=for-the-badge)
+![Tor](https://img.shields.io/badge/tor-onion%20service-7d4698?style=for-the-badge)
+![Fair Launch](https://img.shields.io/badge/premine-none-2ea44f?style=for-the-badge)
+[![Discord](https://img.shields.io/badge/discord-join-5865F2?style=for-the-badge)](https://discord.gg/n7B2Eamn3)
+
+**[Download](https://releases.bitflash.network/)** · **[Discord](https://discord.gg/n7B2Eamn3)**
+
+</div>
 
 ---
 
@@ -12,7 +24,7 @@ Bitflash keeps Satoshi's original consensus rules and replaces two things:
 
 **RandomX proof of work.** Memory-hard algorithm used by Monero. A laptop competes equally with a server. ASICs and GPUs have no advantage.
 
-**Anonymous addressing.** Every node has a `.btf` address derived from its public key, similar to a Tor `.onion`. Nodes reach each other through encrypted rendezvous tunnels, so no port forwarding is needed and a node behind CGNAT works normally.
+**Anonymous addressing.** Every node has a `.btf` address derived from its public key, similar to a Tor `.onion`. Nodes reach each other through encrypted rendezvous tunnels by default, and can advertise a signed direct `.onion` endpoint for Tor peers.
 
 No premine. No ICO. 50 BTF per block, halving on schedule, 21M cap, ~2 minute blocks.
 
@@ -20,27 +32,128 @@ No premine. No ICO. 50 BTF per block, halving on schedule, 21M cap, ~2 minute bl
 
 Worth being precise, because the difference matters if you are relying on it.
 
-**A peer you reach over `.btf` does not learn your IP.** All outbound connections go through a rendezvous tunnel; there is no IP-based peer dialling left in the node. The relay forwards encrypted bytes and cannot read or alter them.
+**A peer you reach over `.btf` does not learn your IP.** Outbound peer discovery uses rendezvous tunnels by default. If both sides use Tor and the peer advertises a signed `.onion` endpoint, the node connects directly to that hidden service instead. In both cases the peer does not see your clearnet IP.
 
-**The rendezvous relay does see your IP.** It has to — it is the thing your TCP connection terminates on. Relays are run by volunteers, so treat that as a party who knows you are on the network.
+**The rendezvous relay sees your IP unless you use Tor.** It has to — it is the thing your TCP connection terminates on. With `-tor`, the relay sees Tor instead. With a signed direct `.onion` peer endpoint, the relay is not on that connection path at all.
 
 **The node still listens on 8433.** Nothing dials by IP any more, but the listener is still there, so anyone who already knows your address and can reach that port may connect directly. If that matters to you, firewall it.
 
-This is unlinkability between peers, not anonymity against a network observer. It is not Tor.
+This is unlinkability between peers, not anonymity against a network observer.
+For Tor routing and direct onion peer endpoints, start the node with `-tor`;
+see [Tor mode](docs/tor.md).
+For a plain SOCKS5 proxy without Tor-specific defaults, use
+`-socks=HOST:PORT`.
 
 ---
 
 ## Quick start
 
+Download the [latest release](https://releases.bitflash.network/) and run. No
+install, no configuration — it connects automatically and starts syncing.
+
 **Linux:** make the `.AppImage` executable and run it.
 
-**Windows:** extract the `-windows.zip` and run `Bitflash.exe`.
+**Windows:** extract the `-windows-with-tor.zip` and run `Bitflash.exe`. Tor is
+bundled and a managed Tor instance starts automatically, so onion transport
+works with no separate install. Pass `-nomanagedtor` to turn it off.
+
+Every release ships a `SHA256SUMS` covering the assets. Verifying takes a second
+and is worth doing:
+
+```bash
+sha256sum -c SHA256SUMS
+```
+
+For newer signed releases, verify the checksum file itself first:
+
+```bash
+gpg --verify SHA256SUMS.asc SHA256SUMS
+sha256sum -c SHA256SUMS
+```
+
+The helper below downloads the release assets, verifies `SHA256SUMS.asc` when it
+is present, then checks the hashes:
+
+```bash
+scripts/verify-release.sh latest
+```
+
+See [release verification](docs/release-verification.md) for the full release
+audit flow and the maintainer signing step.
+
+Public mirrors should make the latest checksum files available both under the
+versioned release directory and at the release root:
+
+```text
+https://releases.bitflash.network/v1.2.20/SHA256SUMS
+https://releases.bitflash.network/SHA256SUMS        # alias to latest
+```
+
+Bitflash also ships a deterministic UTXO-set commitment tool:
+
+```bash
+python3 scripts/verify-utxo-set.py --out utxo-report.json --json
+```
+
+It reconstructs the best chain from local block files, computes the current
+UTXO root and supply, and writes canonical JSON that independent auditors can
+compare or timestamp externally with OpenTimestamps. See
+[UTXO-set commitments](docs/utxo-commitment.md).
+
+The same root can prove one unspent output without sharing the full UTXO set:
+
+```bash
+python3 scripts/prove-utxo.py TXID:VOUT --out utxo-proof.json --json
+python3 scripts/verify-utxo-proof.py utxo-proof.json
+```
+
+See [UTXO inclusion proofs](docs/utxo-proofs.md).
+
+Bitflash also ships a deterministic fair-launch verifier:
+
+```bash
+python3 scripts/verify-fair-launch.py --max-blocks 1000 --out bitflash-fair-launch-report.json --json
+```
+
+The report reads the local chain directly, checks the genesis launch baseline,
+and produces canonical JSON whose hash can be compared by independent auditors
+or timestamped externally with OpenTimestamps. See
+[fair-launch verification](docs/fair-launch.md).
+
+For a static local block explorer, generate HTML and JSON from either a data
+directory or explicit block files:
+
+```bash
+python3 scripts/build-explorer.py --datadir ~/.bitflash ./explorer-out
+python3 scripts/build-explorer.py ~/.bitflash/blk0001.dat ~/.bitflash/blk0002.dat ./explorer-out
+```
+
+The generated explorer is static and self-contained: `index.html`,
+`style.css`, `explorer.js`, `blocks.json`, `block/*.json`, and `logo.png`. It is
+safe to host behind a strict policy such as `default-src 'none'; img-src 'self';
+style-src 'self'; script-src 'self'; connect-src 'self'; base-uri 'none';
+form-action 'none'`.
 
 **Keep your node current.** Consensus rules have changed since the first
-releases — 1.0.0 fixed a bug that let anyone spend anyone's coins. A node on an older build will accept
+releases — 1.2.1 fixed a bug that let anyone spend anyone's coins, and 1.2.2
+added a per-block signature-operation cap. A node on an older build will accept
 blocks that current nodes reject, which puts it on a different chain without any
 warning.
 
+Two more reasons, both measured rather than theorised:
+
+- **Before 1.2.13** a node closed a disconnected peer's socket twice and left the
+  closed handle in its `select()` set, where it made `select()` fail on every
+  iteration. The node then spent its socket loop in an error path instead of
+  reading its peers — the deaf-node behaviour reported since 1.2.7. Two nodes
+  side by side on one machine, same network: the one without the fix held 11
+  peers and logged 741 spurious disconnections; the one with it held 21 and
+  logged none. On 1.2.13 in production, two mining nodes hold 13 and 18 peers
+  with zero.
+- **Before 1.2.11** a long-running Windows node accumulated sockets it never
+  released — 1262 of them in 26 hours on one machine, each holding an ephemeral
+  port. Restarting returned them; upgrading stops them accumulating.
+
 Your wallet and chain data live in `%APPDATA%\Bitflash` (Windows) or
 `~/.bitflash` (Linux) and are shared by every version, so upgrading is just
 replacing the binary. Never delete that directory to "fix" something without a
@@ -50,6 +163,19 @@ backup — it holds your keys.
 
 ## Your wallet: the phrase and the file
 
+Since 1.2.12 a wallet can hold twelve words that rebuild it. Since 1.2.13 those
+words also cover the address the window shows you. **Both still matter** — the
+phrase and the file back up different things, and the difference is where people
+lose money.
+
+Since 1.2.20 the file is a single self-contained `wallet.sqlite` by default. A
+fresh data directory starts on it; an existing Berkeley DB `wallet.dat` keeps
+working and the desktop app converts it in one click on first run, never
+touching the original, which stays as a fallback. Choose a backend explicitly
+with `-walletbackend=sqlite` or `-walletbackend=bdb`, recorded in a
+`wallet-backend` marker in the data directory. See
+[wallet storage](docs/storage.md).
+
 The derivation is written down in [docs/derivation.md](docs/derivation.md), with
 test vectors and a script that reproduces them from scratch. It is there so the
 twelve words keep working even if this software does not: paths, address format
@@ -63,8 +189,11 @@ bitflash -newphrase                          # create it, show it once, exit
 bitflash -restorephrase="twelve words here"  # rebuild a wallet from it
 ```
 
-`-newphrase` installs a BIP32 seed, derives the wallet's key pool and default
-receiving address from it, and prints the words once. It refuses if a phrase
+`-newphrase` installs a BIP39/BIP32 seed and derives the wallet as a BIP44 tree
+along `m/44'/4346950'/0'/…` — coin type **4346950** is `0x425446`, the ASCII
+bytes `BTF`, registered in [SLIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md).
+It builds the key pool and default receiving address from the seed, and prints
+the words once. It refuses if a phrase
 already exists: replacing one silently would strand every coin on addresses the
 written-down words no longer describe.
 
@@ -84,8 +213,17 @@ from the words. The wallet names such an address `Your Address (created before
 the recovery phrase)` so you can tell them apart. This is why file backups still
 matter.
 
+> **If you created a phrase on 1.2.12, run `-restorephrase` with the same twelve
+> words.** That release installed the seed but left the visible address and the
+> key pool random, so the wallet went on handing out addresses the words cannot
+> reproduce while the window said a phrase existed. Restoring repairs it.
+
 ### The file
 
+Under the SQLite default the wallet is one self-contained `wallet.sqlite`, and
+`-backupwallet` writes a matching `.sqlite` copy that opens on its own — no
+sidecar directory. The Berkeley DB notes below apply to a legacy `wallet.dat`.
+
 **Copying `wallet.dat` on its own is not a backup.** Berkeley DB ties the file
 to the environment in the `database/` subdirectory beside it, so a lone
 `wallet.dat` will not open elsewhere — the keys are all still in there, and the
@@ -123,7 +261,7 @@ as a verdict to somebody who has just lost a wallet.
 
 ### When wallet.dat itself will not open
 
-Everything above still runs through Berkeley DB. If the database is the thing
+A legacy `wallet.dat` runs on Berkeley DB. If that database is the thing
 that is broken — a build that will not read it, a file truncated by a bad copy,
 an environment beyond recovery — the keys are usually still fine, and you can
 take them out as text:
@@ -157,15 +295,48 @@ Open **Options** from the menu bar. Under Mining Mode:
 
 Pool announcements are published on Nostr with live status fields, so external tools can query the latest pool state by `.btf` address.
 
+Pool operators also write a local `pool_status.json` every ten seconds and a
+`pool_rounds.json` proof ledger whenever they find blocks or pay miners. By
+default both are created in the data directory; use `-poolstatusfile=PATH` and
+`-poolroundsfile=PATH` to write them somewhere a dashboard or web sync can read.
+The files are informational only: nodes still discover pools through Nostr and
+`.btf`, not through any web domain.
+See [public pool directory](docs/pool-directory.md) for the website/API shape.
+
 **Participant** — mine to someone else's pool. Enter or select the pool's `.btf` address and enable Start Mining.
 
-SRBMiner and XMRig connect to operator pools through the `.btf` path:
+The built-in participant miner connects to operator pools through the `.btf`
+path. Use it — **third-party RandomX miners such as XMRig and SRBMiner cannot
+mine Bitflash pools**, and no amount of configuration changes that. In RandomX
+mode they speak the Monero-style JSON-RPC protocol (`login`/`job`/`submit`) and
+assume a Monero-style job: the nonce at byte 39 of the blob, and a 32-byte seed
+hash given as 64 hex characters. Bitflash pools speak Bitcoin-style Stratum
+(`mining.subscribe`/`mining.notify`/`mining.submit`) over an 80-byte header
+whose nonce is at byte 76 — byte 39 falls inside the merkle root — and key
+RandomX from a fixed 36-byte string that is not a hash at all.
+
+`-stratumbridge` carries that same Bitcoin-style Stratum over the `.btf` path,
+so a miner on this machine can reach a pool it otherwise could not address. It
+is a byte relay, not a protocol translator, so it helps only a miner that
+already speaks the pool's dialect, and it does not make the miners above work:
+
+```bash
+./bitflash -nogui -stratumbridge=POOL_BTF_ADDRESS -stratumbridgeport=3333
+```
+
+Estimate rewards and electricity cost locally:
 
 ```bash
-SRBMiner-MULTI --algorithm randomx --pool POOL_BTF_ADDRESS --wallet YOUR_BTF_ADDRESS --password x
-xmrig -a rx/0 -o POOL_BTF_ADDRESS -u YOUR_BTF_ADDRESS -p x
+python3 scripts/bitflash-mining-calculator.py \
+  --hashrate 21 --hashrate-unit kh/s \
+  --network-hashrate 1.56 --network-hashrate-unit mh/s \
+  --watts 140 --kwh-cost 0.10 \
+  --price 0.001 --pool-fee 1
 ```
 
+See [mining calculator](docs/mining-calculator.md). Price is manual until
+Bitflash has a reliable public market.
+
 ---
 
 ## Headless / server mode
@@ -174,7 +345,11 @@ xmrig -a rx/0 -o POOL_BTF_ADDRESS -u YOUR_BTF_ADDRESS -p x
 ./bitflash -nogui                     # node only
 ./bitflash -nogui -gen                # node + solo mining
 ./bitflash -nogui -gen -operator      # pool operator
+./bitflash -nogui -gen -operator \
+  -poolstatusfile=/var/www/pool_status.json \
+  -poolroundsfile=/var/www/pool_rounds.json
 ./bitflash -nogui -gen -participant=POOL_BTF_ADDRESS  # mine to pool
+./bitflash -nogui -stratumbridge=POOL_BTF_ADDRESS      # Stratum over .btf (see Mining)
 ```
 
 Every option takes `-` or `/`. **Under MSYS2 use the `-` form** — the shell
@@ -190,7 +365,13 @@ Other options worth knowing:
 
 ```bash
 -datadir=PATH    # wallet and chain data elsewhere
--port=N          # P2P listen port, default 8433
+-testnet         # isolated test network genesis, datadir, port 18433, and magic
+-port=N          # P2P listen port, default 8433; testnet default 18433
+-socks=HOST:PORT # SOCKS5 for outbound Nostr, .btf relay, and onion peer dials
+-tor[=HOST:PORT] # Tor mode; default local Tor SOCKS5 proxy is 127.0.0.1:9050
+-managedtor[=PATH] # start Tor, create a hidden service, advertise its onion
+-nomanagedtor    # disable the automatic bundled-Tor startup
+-onionservice=HOST.onion:PORT # advertise this node's Tor hidden service
 -debug           # verbose log; without it debug.log is nearly silent
 -help            # full list
 ```
@@ -199,10 +380,32 @@ Other options worth knowing:
 needed — the data directory takes an exclusive lock, so a second node pointed at
 the same one will refuse to start.
 
+`-socks=127.0.0.1:9050` routes outbound Nostr discovery, `.btf` rendezvous
+dials, and direct `.onion` peer dials through a local SOCKS5 proxy such as Tor.
+When it is set, the node skips
+plain HTTP external-IP probes instead of leaking a direct request outside the
+proxy. IPv6 proxy endpoints use brackets, for example `-socks=[::1]:9050`.
+
+`-tor` is a privacy shorthand for the usual local Tor SOCKS5 listener at
+`127.0.0.1:9050`. It routes outbound Nostr discovery, `.btf` rendezvous dials,
+and signed direct `.onion` peer dials through Tor, and keeps external-IP probes
+disabled. Use `-tor=HOST:PORT` when Tor listens somewhere else.
+
+The desktop app starts a managed Tor automatically when no other Tor option is
+set, so onion transport works out of the box; `-nomanagedtor` turns that off.
+For a headless node, ask for it explicitly:
+
+`-managedtor[=PATH]` starts a Tor process for this node, writes a local `torrc`,
+creates a v3 hidden service for port `8433`, routes outbound discovery through
+that Tor instance, and signs the generated `.onion:8433` endpoint into the
+node's `.btf` descriptor. Without `PATH`, Bitflash looks for `tor/tor.exe`,
+`tor.exe`, or `tor` beside the binary and then on `PATH`. The hidden-service key
+is stored under the Bitflash data directory in `managed-tor/onion-service/`.
+
 ### When something looks wrong
 
 **Menu > Diagnostics**, and the same report in `debug.log` every ten minutes:
-peers held against peers `select()` is actually watching, blocks received and how
+peers held against peers the socket loop is actually watching, blocks received and how
 many arrived without a parent, the proof-of-work mode with the live miner thread
 count, sockets by the part of the program that opened them, and per peer how long
 since the last message each way. There is a copy button — if you open an issue,
@@ -284,6 +487,19 @@ make windows
 ```
 Installs deps via pacman, produces `Bitflash-*-windows.zip`.
 
+To build the Windows package that also carries the Tor Expert Bundle:
+
+```bash
+make windows-tor
+```
+
+That produces `Bitflash-*-windows-with-tor.zip`. The release script downloads
+the Tor Expert Bundle from the official Tor archive, verifies its pinned SHA256,
+optionally verifies the Tor Project GPG signature when `gpg` is available, and
+places `tor/tor.exe` beside `Bitflash.exe` so `-managedtor` works without a
+separate Tor install. For release builds, use `TOR_VERIFY_GPG=required make
+windows-tor` to require the extra signature check.
+
 ---
 
 ## At a glance
@@ -303,7 +519,8 @@ Installs deps via pacman, produces `Bitflash-*-windows.zip`.
 | Addressing | `.btf` rendezvous — see the caveats above |
 | Premine | None |
 | Pool server | Built-in — `.btf` rendezvous only |
-| Wallet recovery | Twelve-word phrase (BIP39 + BIP32), plus file backup |
+| Wallet recovery | Twelve-word phrase (BIP39 + BIP32 + BIP44, coin type 4346950), plus file backup |
+| Wallet storage | SQLite `wallet.sqlite` by default, or Berkeley DB `wallet.dat` |
 
 The halving interval is the number most people get wrong coming from Bitcoin.
 Same 210,000 blocks, but at two minutes instead of ten, so it arrives in about
@@ -311,4 +528,6 @@ ten months rather than four years.
 
 ---
 
+Young network. Keep your node current and don't put in more than you are willing to lose.
+
 MIT. Built on Bitcoin 0.1.0 (Satoshi Nakamoto, 2009).