[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.

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

[ABCbits]

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.

Sometimes i hear people avoid JavaScript or browser based wallet or cryptography apps, because different engine implementation and browser version may lead to security bug or different output. Is such risk also exist on your tool?

[mixoftix]

Sometimes i hear people avoid JavaScript or browser based wallet or cryptography apps, because different engine implementation and browser version may lead to security bug or different output. Is such risk also exist on your tool?

Yes, ABC—that risk exists for any browser-based tool, which is one of the main reasons we strongly advise against using this simulator to generate real wallets or cryptographic keys.

There are two separate aspects to consider here:

1. Self-Contained Code (No External CDNs)
Many web wallets rely on external third-party libraries (such as ECC or crypto packages fetched from CDNs) and require HTTPS contexts for WebCrypto APIs. By contrast, Decent Dice is completely self-contained using vanilla JavaScript with zero external dependencies. If anyone wants to inspect or run the exact source locally offline, the entire website root is published on GitHub for public review:

https://github.com/mixoftix/net_mixoftix/blob/main/src/workshops/entropy_lab_decent_dice.asp

Inside the page, the physics calculations are handled by internal helper functions driven by two main entry points (where the silent one bypasses UI rendering for fast batch streaming):

Code:

dropDice()
dropDiceSilent()

2. JS Engine, Precision & Compiler Differences
Because the rigid-body simulation relies heavily on floating-point math and transcendental functions (Math.sin, Math.cos, Math.tanh), different JavaScript engines (V8, SpiderMonkey, JavaScriptCore) or browser versions can introduce tiny ULP (unit in the last place) rounding differences. In a multi-bounce physics simulation, even a tiny rounding difference can cause an exported session replay to diverge onto a different trajectory on a different engine.

On the other hand, what makes physical dice interesting to model is that each throw is memoryless—independent of previous outcomes. Even when a 32-bit single-precision environment (such as an AVR microcontroller running BASCOM) settles on a different top face than a 64-bit IEEE-754 double-precision browser engine for the exact same exported session configuration, that divergence does not hurt the statistical randomness of independent drops.

These two logs illustrate how floating-point precision differences between the browser's 64-bit math engine and the AVR's 32-bit math engine shift the impact timing and trajectory (columns from left to right: Time, X, Y, Theta, Vx, Vy, Omega):

Code:

JS impact - before: 1.9954161643981934,0,0.03403683751821518,-5.791137218475342,0,-0.5745140314102173,-2.90936279296875
JS impact <- after: 1.9954161643981934,0,0.03403683751821518,-5.791137218475342,0,-0.5745140314102173,-2.90936279296875
JS impact - before: 1.9959161281585693,0,0.03374950587749481,-5.7925920486450195,0,-0.5746579766273499,-2.90936279296875
JS impact <- after: 1.9959161281585693,0,0.033829063177108765,-5.7925920486450195,0.026268474757671356,0.07304549217224121,-16.74576759338379
JS impact - before: 1.9964160919189453,0.000013134237633494195,0.033865511417388916,-5.800965309143066,0.026268474757671356,0.07290157675743103,-16.74576759338379
JS impact <- after: 1.9964160919189453,0.000013134237633494195,0.033865511417388916,-5.800965309143066,0.026268474757671356,0.07290157675743103,-16.74576759338379

Code:

AVR impact - before: 2.058911559,0.0,0.032448348,-5.922611711,0.0,-0.592733856,-2.883814094
AVR impact <- after: 2.058911559,0.0,0.032448348,-5.922611711,0.0,-0.592733856,-2.883814094
AVR impact - before: 2.059411522,0.0,0.032151933,-5.92405319,0.0,-0.592877742,-2.883814094
AVR impact <- after: 2.059411522,0.0,0.032190498,-5.92405319,0.026621398,-0.054789123,-19.706443784
AVR impact - before: 2.059911485,0.000013288,0.032163019,-5.933906075,0.026621398,-0.054933009,-19.706443784
AVR impact <- after: 2.059911485,0.000013288,0.032163019,-5.933906075,0.026621398,-0.054933009,-19.706443784

As those logs show, even our attempt to emulate 32-bit AVR register rounding inside JavaScript via Unified_Math function in the code (IEEE_754_32BIT profile) still diverges over multi-bounce trajectories because low-level compiler rounding sequences, FPU guard bits, and transcendental approximations differ across implementations.