[INFO - DISCUSSION] Decent Dice — 2D Rigid-Body Physics Entropy Simulator

[mixoftix]

Warning & Disclaimer (Update)
This tool is designed as a physically-influenced simulation for educational purposes and entropy research. Although it runs 100% client-side in JavaScript inside the user's browser, it is always possible for the code to be manipulated via unauthorized access on the server side—therefore, you SHOULD NOT use its output to generate real cryptographic keys or Bitcoin wallets under any circumstances.

Decent Dice (Entropy Lab) — 2D rigid-body physics drop simulation running client-side.

Decent Dice

I built an interactive, browser-based physics entropy simulator called Decent Dice to explore how chaotic rigid-body dynamics, material contact physics, and timer jitter combine to generate high-entropy raw bitstreams for cryptographic key derivation:

Simulator Link: https://mixoftix.net/workshops/entropy_lab_decent_dice.asp

How the Physics & Entropy Model Works
Instead of pulling directly from a single static PRNG call, the simulator models a 2D square die falling and bouncing under configurable environmental and physical parameters:

• Material & Contact Physics: Models restitution, surface friction, and adhesion across 4 die materials (plastic, wood, metal, rubber) and 6 surface materials (wood, carpet, glass, metal, rubber, felt).
• Environmental & Initial State Space: Incorporates temperature (°C), humidity (%), altitude (km, dynamically adjusting gravity g), drop height (m), initial angular velocity (rad/s), initial top face, and a millisecond Timer / Counter jitter factor routed through selectable noise mixers (trigonometry, xor-xor-mix, mix-mix-xor, tri-mix-xor, xcs-tri-xor).
• 100% Client-Side Execution: Everything executes locally inside the browser—zero data is ever transmitted to a server. Full session parameters can also be exported and re-imported for deterministic replay and auditing.

The Math: Covering the secp256k1 Keyspace
A valid Bitcoin private key lies in the range [1, n - 1] where n ≈ 1.1579 × 10^77 (256 bits of security). To avoid keyspace collapse, the raw entropy source must comfortably exceed 256 bits of Shannon entropy before key derivation:

• Single Die Drop (d6): Yields log2(6) ≈ 2.585 bits of entropy per outcome (requiring at least ⌈256 / 2.585⌉ = 100 independent rolls to reach 256 bits).
• Default Batch Run (16 Sequences × 10 Batch Size = 160 Drops):
  — In Dice mode (1–6): 6^160 ≈ 3.17 × 10^124 possible sequences, equal to ~413.6 bits of combinatorial state space.
  — In Hex mode (0–f): 16^160 = 2^640 ≈ 4.56 × 10^192 possible sequences, providing 640 bits of raw output space—more than 2.5× the 256-bit secp256k1 scalar field.
• Initial Condition Sensitivity: Because rigid-body corner impacts amplify tiny variations in drop height, angular spin, restitution, and timer jitter across multiple bounces, slight perturbations in initial physical parameters diverge into completely different trajectory histories.

Key Derivation & Educational Companion Tool
The output of this simulator should be treated strictly as raw entropy, not as a raw private key directly. For converting extracted dice sequences into valid elliptic-curve private keys (secp256k1 / secp256r1), raw rolls should be passed through a standard Key Derivation Function (such as PBKDF2-HMAC-SHA512 with a user-supplied salt, HKDF, or BIP-39) inside a trusted offline environment.

You can explore how base-6 conversion and salted PBKDF2-HMAC-SHA512 (200,000 iterations) map raw dice sequences onto valid secp256k1 scalars in our companion client-side demonstration tool:
Dice to Private Key (Entropy Lab): https://mixoftix.net/workshops/entropy_lab_dice_to_prvkey.asp

Sample Physics Simulation Telemetry Log
Each die drop records the timer-driven parameter offsets, rigid-body trajectory steps (Time, X, Y, Theta, Vx, Vy, Omega), impact events, and final settled orientation:

Code:

================================================
DICE DROP – INITIAL PARAMETERS
================================================
Simulator profile          : WEB_JS_64BIT
Label mode                 : dice
Random mode                : weak
Noise mode                 : trigonometry
Timer (ms) at drop         : 188168
Counter at drop            : 1711
Noisy factor               : 0.910981
Geometric faces --> Labels:
  Face 0  -->  4
  Face 1  -->  5
  Face 2  -->  2
  Face 3  -->  3
================================================

Actual noise applied (timer-driven):
  Angle offset      : -1.402°
  Spin offset       : 0.507 rad/s
  Height offset     : 0.0077 m
  Restitution offset: -0.0074
  Friction offset   : -0.0057
  Adhesion offset   : 0.0051
  Altitude offset   : -0.45 km
  Time offset       : 0.798 s
================================================

Initial geometric top face : 0
Initial label on top       : 4
Initial label on bottom    : 2

Drop height (center)       : 1.4077 m
Unified_Math.PI            : 3.141592653589793°
Base angle                 : 3.14°
Initial angle              : 178.60°
Initial spin (Omega)       : 9.907 rad/s

Dice material              : rubber
Surface material           : felt
Temperature                : 31.0 °C
Humidity                   : 52.0 %
Altitude                   : 32753 km
Gravity (g)                : 0.2601 m/s²
Simulation time (requested): 23.6 s
Simulation time (effective): 24.40 s
Effective restitution      : 0.590
Effective friction         : 0.379
Effective adhesion         : 0.262
================================================
JS_titles:      Time,      X,      Y,   Theta,     Vx,      Vy,    Omega
JS_zoom_out: 0.00000,0.00000,1.40772,3.12703,0.00000,-0.00026,9.90691
JS_zoom_out: 0.05000,0.00000,1.40737,3.62237,0.00000,-0.01327,9.90691
JS_zoom_out: 0.10000,0.00000,1.40638,4.11772,0.00000,-0.02627,9.90691
JS_zoom_out: 0.15000,0.00000,1.40473,4.61306,0.00000,-0.03928,9.90691
JS_zoom_out: 0.20000,0.00000,1.40244,5.10841,0.00000,-0.05229,9.90691
JS_zoom_out: 0.25000,0.00000,1.39949,5.60376,0.00000,-0.06530,9.90691
JS_zoom_out: 0.30000,0.00000,1.39589,6.09910,0.00000,-0.07830,9.90691
.
.
JS_trigger: [settled 100 < 100] / [speed] 0.09598 < 0.2 / [Y] 0.02543 < 0.02550
JS_zoom_XD: 12.23050,-0.99459,0.02541,29.86278,-0.06479,-0.05534,0.21718
JS_impact+: 12.23050,-0.99459,0.02544,29.86278,-0.06476,-0.05527,0.21456
JS_trigger: [settled 101 < 100] / [speed] 0.09587 < 0.2 / [Y] 0.02544 < 0.02550
JS_titles:      Time,      X,      Y,   Theta,     Vx,      Vy,    Omega
JS_settled: 12.23050,-0.99459,0.02544,29.86278,-0.06476,-0.05527,0.21456

================================================
RESULT
================================================
Simulation time            : 12.23 s
Final theta (radians)      : 29.86278230894412
Final geometric top face   : 1
Final label on top         : 5
Final label on bottom      : 3
Final angle                : 271.0°
================================================
>>>  TOP FACE SHOWS: 5  <<<
================================================

-- Feedback on the physics model, noise-mixing modes, and statistical distribution (Dice vs. Hex vs. Bin output streams) is very welcome!

[odolvlobo]

Fun, but overkill.

Overall the security is only as good as the entropy in the jitter plus the secrecy or search space of the initial conditions. I am assuming that if you enter the same initial conditions, you will get the same results.

[gmaxwell]

One should, of course, not use this to actually generate keys.  At best a tool like this could have entropy no better than its original binary input seed, so you can just use that directly.  At worst there is plenty of opportunity for it to do worse.

It might be interesting to use to study what the entropy of actual dice might be in idealized conditions and how that entropy changes with changes to the conditions to give more refined advice on using actual dice.

raw rolls should be passed through a standard Key Derivation Function (such as PBKDF2-HMAC-SHA512 with a user-supplied salt, HKDF, or BIP-39) inside a trusted offline environment.

No. Rolls from this should not be used to generate cryptographic keys for actual use *at all*.  And the suggestion to do so makes me concerned that the tool might either be malicious or ignorantly constructed.  A person capable of competently constructing such a thing would not tell someone to use it to generate keys.

[modrobert]

No. Rolls from this should not be used to generate cryptographic keys for actual use *at all*.  And the suggestion to do so makes me concerned that the tool might either be malicious or ignorantly constructed.  A person capable of competently constructing such a thing would not tell someone to use it to generate keys.

I've read that the background radiation is a good source for entropy. What are your thoughts on good sources of entropy?

[mixoftix]

Fun, but overkill.

Thank you for analyzing the idea.

I am assuming that if you enter the same initial conditions, you will get the same results.

This is correct. Having the same initial parameters (including the recorded noise offsets that distinguish different simulation sessions) produces the exact same output—which is intentional for reproducibility in entropy research. However, even with identical base parameters, live timer-driven noise is injected on each run, producing different outcomes. We can see this directly in the log of each session:

Code:

================================================

Actual noise applied (timer-driven):
  Angle offset      : 0.452°
  Spin offset       : -0.048 rad/s
  Height offset     : -0.0005 m
  Restitution offset: 0.0065
  Friction offset   : -0.0275
  Adhesion offset   : 0.0146
  Altitude offset   : 24.96 km
  Time offset       : -0.409 s
================================================

Overall the security is only as good as the entropy in the jitter plus the secrecy or search space of the initial conditions.

True, with one clarification:

A deterministic function cannot increase the Shannon entropy of a fixed seed. However, this simulator does not run solely from a single static initial seed—during drops and execution steps, it samples live browser runtime timing jitter. Those ongoing runtime measurements act as continuous external entropy inputs rather than part of a single static seed—at least, that is the concept I am exploring and introducing with this project.

[mixoftix]

raw rolls should be passed through a standard Key Derivation Function (such as PBKDF2-HMAC-SHA512 with a user-supplied salt, HKDF, or BIP-39) inside a trusted offline environment.

No. Rolls from this should not be used to generate cryptographic keys for actual use *at all*.  And the suggestion to do so makes me concerned that the tool might either be malicious or ignorantly constructed.  A person capable of competently constructing such a thing would not tell someone to use it to generate keys.

Thank you for the correction, Greg. I have added a clear warning block at the very top of both the OP and the webpage itself [1] so nobody mistakes the JavaScript simulator for a production key generator.

It might be interesting to use to study what the entropy of actual dice might be in idealized conditions and how that entropy changes with changes to the conditions to give more refined advice on using actual dice.

That is actually the exact observation that pushed the project forward. After building the initial rigid-body model, I simulated realistic low-energy drops (a plastic die dropped onto wood from under 50 cm with minimal spin). Even though the trajectory looked lively, the kinetic energy was too low to overcome the corner potential barrier—the die essentially vibrated in place and settled back onto its starting orientation.

That mirrors the findings in Kapitaniak et al. (2012) [2] (and related work on long-run die symmetry [3]), which demonstrated using 3D mechanics and high-speed cameras that low-energy die throws retain a measurable bias toward the initial bottom face, especially on energy-absorbing surfaces like felt or carpet. To study how different physical regimes behave in the simulator, I expanded the model to vary surface restitution, friction, adhesion, gravity/altitude, and per-drop runtime jitter offsets. Under high-energy, multi-bounce regimes, the output stream passes both NIST SP 800-22 and SP 800-90B statistical checks—which, while only a baseline sanity check for statistical uniformity rather than a proof of cryptographic entropy, helped validate the physical parameter space.

That experiment also led to a separate hardware project: taking a physical TRNG built on asynchronous crystal-oscillator phase jitter and flip-flop metastability (four free-running 8 MHz Pierce oscillators driving the D and CLK inputs of a 74HC74 dual D flip-flop into an ATmega328P) and using its raw hardware entropy to randomize the physical parameters of an embedded dice-drop mixer (HRNG mode). I shared that hardware build over in Project Development [4] in case you find the hybrid architecture interesting.


[1] https://mixoftix.net/workshops/entropy_lab_decent_dice.asp
[2] https://pubmed.ncbi.nlm.nih.gov/23278090/
[3] https://osf.io/preprints/osf/bxr3h_v5
[4] https://bitcointalk.org/index.php?topic=5599701.0