Grok had some good insights:

原始 JSON

{
  "kind": 1,
  "id": "00000b400605c6a7a88c45b22a7307dd0a09f2fd19154bb27b303ddeeafb9e48",
  "pubkey": "64acf4055fa826bcab8457e24ef8fba7490abb1e76dbab6aa8752a53a0eb4d4a",
  "created_at": 1788296368,
  "tags": [
    [
      "e",
      "7c894747a6a0109c1d9aa8a49edd9ea079f0be7927586389d2da5ffd7d50e32a",
      "wss://nos.lol",
      "root"
    ],
    [
      "p",
      "fcf70a45cfa817eaa813b9ba8a375d713d3169f4a27f3dcac3d49112df67d37e"
    ],
    [
      "client",
      "Dark Wisp"
    ],
    [
      "nonce",
      "78753",
      "18"
    ]
  ],
  "content": "Grok had some good insights:\n\nThe rate mismatch you describe is real. Espressif documents `bootloader_random_enable()` + `esp_fill_random()` as valid true-RNG when RF is off, but `esp_random()`’s wait (`APB_CYCLE_WAIT_NUM = 16` ≈ 0.2 µs / ~5 MHz) is sized for the **RF / high-speed ADC** path. The TRM’s SAR-only max-entropy rate is ≤500 kHz (~2 µs per 32-bit read). Bootloader `bootloader_fill_random()` is much more conservative (“~1 bit per 40 APB cycles”).\n\n**v1.0.40** did exactly:\n`bootloader_random_enable(); esp_fill_random(entropy_state, 32); bootloader_random_disable();`\n\n**v1.0.41** (commit `e850c3b`) replaced that with eight `esp_random()` reads + 1 ms `vTaskDelay`. Comment: HW RNG state is 32 bits; 1 ms gives ~50× more refeed time than `esp_fill_random` and adds scheduler jitter. Commit text: change is **not** an admission that prior entropy was weak.\n\n### Answers\n\n1. **No public measurement.** Blockstream has not published a min-entropy estimate for `esp_fill_random(32)` on Classic ESP32 + SAR-only (`bootloader_random_enable`, RF off). Blog only says “multiple analyses confirmed robustness.”\n\n2. **No evidence they applied the 500 kHz SAR cap to the 1.0.40 fill.** That fill used `esp_fill_random` → `esp_random` at the 16-APB-cycle cadence.\n\n3. **No published lower bound** on min-entropy of that 256-bit `entropy_state`.\n\n4. **Stated as defense-in-depth** (refeed time + jitter), not as a fix for a known break. Practically it also removes SAR refresh-rate uncertainty: 1 ms ≫ 2 µs TRM SAR interval.\n\n5. **Not proven from the HWRNG dump alone; Blockstream treats the full pipeline as 128-bit.** A 12-word phrase is not `entropy_state` raw. After init, Jade mixes sensors, camera frames (Classic still has a camera on No-Radio), cycle-counter jitter, `strengthen()` time, host `add_entropy`, then SHA512-splits like Bitcoin Core. Isolated SAR-rate 32-byte dump is the under-specified piece; the seed path is not that dump.\n\nNo-Radio docs themselves say the CRNG “has reduced entropy” without radio and that `bootloader_random_enable()` is the mitigation. That is an API-trust claim, not a published entropy bound.",
  "sig": "8f56f84ee757db704536d15877f4d73804a1a5b3197ddda5b3c8d6e0ecb25f5068567c7331a7cd326e2d8790dc83953935d12e7af3d06eae0ec4580dedbf3287"
}