Geiger entropy

Entropy32 Plus

Entropy32 (aka The Universe Bifurcator) is a dedicated Bitcoin seed phrase generator that uses radioactive decay as its entropy source. It's completely open source and designed to be simple, auditable, and buildable by anyone with readily available components.

Why radioactive decay?

Pseudo-random number generators are deterministic — given the same seed, they always produce the same output. True randomness for something as consequential as a Bitcoin wallet's seed phrase should come from a physical process nobody can predict or manipulate. Radioactive decay is quantum-mechanically random: the timing of individual decay events is fundamentally unpredictable, making it an ideal entropy source for generating cryptographic secrets.

How it works

1. A Geiger counter detects decay events from a radioactive source (or background) and outputs a pulse via a 3.5mm audio jack.
2. An LM393 comparator IC then takes the 0-1.5V pulse and compares it to a bias of ~0.5V via a voltage divider such that if V>0.5V we get HIGH else LOW.
3. The timing between events is captured and compared in non-overlapping pairs (each inter-arrival time feeds exactly one comparison, so adjacent output bits never share an input interval). Each resulting bit passes two continuous NIST SP 800-90B health tests (Repetition Count Test and Adaptive Proportion Test) before it's fed through SHA-256 conditioning to whiten the raw entropy and remove any bias — if either test trips, the device halts rather than generating a seed from a degraded source.
4. The conditioned entropy is mapped to words from the standard BIP39 English wordlist.
5. A simple button-driven, state-machine UI walks you through generating and displaying your seed phrase — entirely offline, with no wireless connectivity, no persistent storage of the seed, and no software dependencies beyond the device itself.

How long does it take to generate a seed?

The firmware always fills a 512-bit raw pool before conditioning — that's true whether you pick a 12-word or 24-word phrase, since the seed length only changes how many of the whitened bits get used afterward, not how much raw entropy gets collected. Because of the non-overlapping interval pairing described above, each output bit costs two Geiger pulses, so at a steady count rate the pool fills in roughly:

minutes ≈ 1024 / CPM

The device's collection screen shows live CPM and a running ETA using this same math, so you don't need to do it by hand. Actual CPM depends heavily on your specific tube, source activity, distance, and shielding — treat the table below as a rough guide, not a spec, and follow appropriate safety/legal practices for any check source you use:

Hardware

• Custom PCB built around an ATmega328P microcontroller, designed in KiCad
• Geiger counter module as the entropy source (currently designed to take the 3.5mm output of the GQ Electronics GMC-320S)
• LM393 comparator IC
• Push-button interface for on-device operation
• Serveral common passives i.e. resistors, capacitors, and LEDs
• 16MHZ crystal oscillator
• 0.91" OLED display with I2C adaptor
• PJ320E 3.5mm audio jack
• USB-C receptacle 6 pin
• header pins

3D printed case

I have included a custom designed basic case which you can 3d print to protect your device. The design works by allowing the board to slide on tracks into the case, once inserted all the way, a small prong prevents the board from sliding back out. If you plan to use this case be sure to hold the board down while unplugging the USB and/or the 3.5mm audio cable as this would otherwise put excessive strain on the prong to the point it may break off and fail.

Repository contents

Building it yourself

The Arduino sketch (entropy32_plus.ino) and its accompanying .h/.cpp files must remain in the same top-level folder for the Arduino IDE to compile correctly — it doesn't recurse into subfolders for sketch code. Open entropy32_plus.ino in the Arduino IDE, verify your board settings for the ATmega328P, and flash as normal.

Use the KiCad files to tailor the board to your liking before fabrication or use the premade production files to order your board and/or pick and place from your preferred fabrication plant i.e. JLCPCB or PCB Way etc.

Programming a bare ATmega328P

A freshly fabricated board has a blank ATmega328P — there's no bootloader on it and no USB-to-serial chip to flash it through, so the usual "select a port and hit upload" Arduino flow doesn't apply until it's been programmed once via the ICSP header exposed on the board.

1. Wire up an ISP programmer. Either a second Arduino running the ArduinoISP example sketch, or a dedicated programmer such as a USBasp, connected to the ICSP header. If using a USBasp, make sure it's set to 5V logic to match this board.
2. Burn the bootloader. In the Arduino IDE, select Arduino Uno or Arduino Nano as the board type (either is a stand-in for a bare ATmega328P at this stage), select your ISP programmer under Tools → Programmer, and run Tools → Burn Bootloader. This also sets the fuses for running off the board's 16MHz external crystal rather than the internal oscillator.
3. Flash the firmware. With the bootloader in place and the board running at 16MHz external clock, open entropy32_plus.ino and upload it via Sketch → Upload Using Programmer (still through the same ISP connection — the board has no onboard USB-serial chip for a normal serial upload).

Flash footprint

Geiger pulse capture, the SP 800-90B runtime health tests, SHA-256 conditioning, the full BIP39 wordlist, the OLED driver, and the entire menu/boot UI all fit on the ATmega328P's 32KB of flash — with 486 bytes to spare:

Sketch uses 30234 bytes (98%) of program storage space. Maximum is 30720 bytes.
Global variables use 1061 bytes (51%) of dynamic memory, leaving 987 bytes for local variables. Maximum is 2048 bytes.

Breakdown of where it all goes, pulled from the compiled .elf with avr-size/avr-nm:

The wordlist alone is 43% of the chip. Adafruit_GFX + Adafruit_SSD1306 don't fit alongside it — see the note in entropy32_plus.ino — which is why the firmware talks to the display through U8x8's text-only mode instead.

Validation

The firmware runs the two minimal continuous health tests NIST SP 800-90B requires of a noise source at runtime — a Repetition Count Test and an Adaptive Proportion Test (see runHealthChecks() in entropy32_plus.ino) — which will halt the device rather than generate a seed if the raw source looks stuck or degraded. Runtime health tests are not the same as validating the source's entropy.

Full-length entropy assessment (2,000,000 edges)

A 23-day capture (2026-10-03 to 2026-10-26) was logged with Entropy32 Recorder. The recorder is a separate board that timestamps the same post-LM393 D2 rising edges the firmware reads. It captured 2,000,000 edges (~61 CPM average) with zero buffer overruns or transport drops. The source was a GMC-320S Geiger counter beside a glass jar of cut-up 2% thoriated tungsten welding electrodes, on top of background radiation.

The intervals were put through the firmware's exact bit derivation from this repository at 2b9893a: 200 µs minimum interval, non-overlapping pairs and ties discarded. No intervals fell under the 200 µs cutoff (the detector's dead time is ~750 µs) and there were no ties. That produced 999,999 comparison bits (500,205 zeros, 499,794 ones, within 0.4 standard deviations of a fair coin). Those bits were assessed with NIST's ea_non_iid (v1.1.8):

The assessed min-entropy is the lowest of these: H ≈ 0.828 bits per comparison bit, set by the compression estimator. At that rate, the 512-bit raw pool holds about 424 bits of min-entropy before SHA-256 conditioning. That is well above the 256 bits a 24-word phrase needs.

What this does and doesn't show:

• The dataset is one bit short of the 1,000,000-sample size. 2,000,000 edges give 1,999,999 intervals and so 999,999 non-overlapping pairs. ea_non_iid prints a warning about it, and the recorder's verify_evidence.py therefore labels the package a pilot. The missing sample makes no practical difference to the estimates, but the recorder now stops captures on the comparison-bit count so the next run will clear the threshold.
• Only the sequential-dataset non-IID estimators were run. The SP 800-90B restart tests were not.
• It covers one device, one Geiger tube, one source and one environment. The enriched source ran at ~61 CPM; a background-only setup is slower, and this run says nothing about other builds or sources.
• It is an entropy assessment, not NIST certification or formal validation.

The raw edges, derived bits, full tool output, manifest and SHA-256 checksums are all published in the evidence directory. Running python tools/verify_evidence.py entropy32_sp80090b_2026-10-03a in that repository re-derives the bits from the raw edges and checks every count and hash.

Earlier pilot (10,000 edges)

Before the full-length run, a 10-hour pilot captured 10,000 edges (~17 CPM) and was derived with this repository at 311c859. That produced 4,999 comparison bits (2,543 zeros, 2,456 ones). ea_non_iid assessed them at H ≈ 0.738 bits per comparison bit (collision estimator; compression was not run at that size). That is lower than the full-length result because the estimators' 99% confidence bounds are wide with so few samples. The source and setup details for that run were not recorded. Its evidence directory is kept for reference.

Please verify the entropy source you intend to use; otherwise, understand that you are using the device at your own risk.

Disclaimer

This is a hobbyist/educational project. If you use it to generate a real Bitcoin seed phrase, understand the risks: verify the entropy quality yourself, review the code, and never trust a seed-generating device (this one included) with significant funds without independent auditing.

Licenses

• For firmware/software, see MIT LICENSE.
• For hardware, see CERN-OHL-S v2 LICENSE.