Server seed, client seed y nonce nombran entradas, no una garantía universal de juego justo. Su significado depende del protocolo y versión. Esta guía explica cómo copiarlas e interpretarlas, incluyendo codificación, ámbito del contador y rotación de semillas. Usamos cadenas públicas completas en un modelo educativo. No pedimos un secreto activo, prometemos una semilla ganadora ni afirmamos que todos los juegos crash necesiten nonce.
1. Busca la especificación antes de copiar una semilla
La semilla del servidor es una entrada aportada por ese lado. En algunos sistemas su hash aparece antes de apostar y el original se revela después. El valor original y su compromiso son campos diferentes. Una cadena de 64 caracteres puede ser digest SHA-256, texto hexadecimal de semilla u otro valor. Su longitud no identifica el papel ni demuestra 256 bits de entropía aleatoria. Copia nombre y contexto junto con el valor.
El momento de revelación varía. Una semilla retirada puede publicarse tras rotarla, en vez de después de cada apuesta. No supongas que cerrar sesión, jugar cierto número de rondas o abrir un historial genérico revela el dato. Consulta el ciclo documentado del juego elegido. Sin entrada revelada, la reproducción retrospectiva puede quedar incompleta. Es mejor conservar un campo sin resolver que sustituir un valor de otra ronda.
La descripción de SPRIBE y la implementación de Stake ilustran sistemas distintos. Nuestra función de Aviator usa un cálculo SHA-512 separado sin nonce. El modelo HMAC educativo no lo reemplaza. Un generador general de bytes del proveedor tampoco debe confundirse con la conversión final del multiplicador de todos sus juegos.
| Entrada | Papel en modelo educativo | No deducir |
|---|---|---|
| Semilla del servidor | Clave HMAC en texto UTF-8 | Entropía por longitud |
| Semilla del cliente | Parte del mensaje | Imprevisibilidad garantizada |
| Nonce | Contador entero no negativo | Nueva entropía o multiplicador único |
2. La semilla de cliente no es contraseña o ajuste rentable
La semilla de cliente es una entrada asociada al jugador según el protocolo. Algunos productos permiten editarla; juegos colectivos pueden usar varias entradas de participantes. Quién aporta, quién ve y cuándo queda fijada necesita documentación. No deduzcas que el dato solo aparece en el último instante o es desconocido para el servidor. Una palabra conocida o frase elegida personalmente no significa automáticamente alta entropía.
La contribución del cliente puede limitar la selección de resultados por una parte solo con las condiciones relevantes de compromiso e imprevisibilidad. Si el operador conoce todas las entradas mientras escoge candidatos del servidor, llamar client seed a una no impide preselección. Son condiciones de protocolo, no hallazgo de que un operador concreto elija semillas. Un hash no aporta la evidencia que falta sobre generación.
No existe una cadena ganadora validada aquí. Probar ejemplos públicos y elegir uno con pasado favorable es seleccionar después de observar resultados, no una ventaja futura. Cambiar semilla no aumenta el retorno de un modelo fijo. También puede modificar el registro necesario para reproducir una apuesta terminada. Conserva identificador de la pareja antigua y entradas históricas, sin reemplazarlas por ajustes actuales.
3. Entiende qué cuenta el nonce
En el modelo educativo, nonce es entero no negativo incluido en clientSeed:nonce. Misma clave y mismo mensaje producen el mismo HMAC. Cambiar contador es una forma de modificar el mensaje; usar nuevas semillas en cada ronda es otra. Por eso nonce no es indispensable en todo juego. Un contador público determinista tampoco añade nueva entropía aleatoria independiente simplemente por aumentar.
Averigua ámbito y valor inicial. El contador puede corresponder a una pareja, cuenta u otro conjunto documentado. Comenzar en cero no da la misma entrada que comenzar en uno. Un cursor para seleccionar bytes adicionales es otro parámetro, no solo otro nombre del nonce. No añadas ni elimines campos sin la especificación correspondiente. Un registro completo identifica pareja, contador y cursor necesario.
Un salto no establece manipulación por sí solo. Puede requerir considerar otras apuestas elegibles, otro juego dentro del ámbito o un reinicio. Una secuencia continua tampoco demuestra que una pantalla de historial separada sea completa. Pide la definición de ámbito y conserva la secuencia original. El cálculo siguiente comprueba un conjunto de entradas; no inspecciona todo el historial de la cuenta ni explica automáticamente un número ausente.
4. Cadenas y bytes deben coincidir exactamente
Las funciones criptográficas consumen bytes. En el ejemplo, las semillas son texto literal UTF-8. La cadena 6162 se convierte en cuatro bytes de los caracteres 6,1,6,2. Decodificarla como hexadecimal produciría dos bytes correspondientes a a,b. Ambas convenciones son posibles, pero las entradas difieren. Un protocolo real debe especificar cuál espera; el aspecto no resuelve la cuestión.
Espacios, mayúsculas, Unicode y separadores también importan. Copiar un salto de línea, cambiar una letra o invertir clientes puede modificar el digest. El programa público no recorta ni normaliza semillas silenciosamente. El nonce debe ser entero seguro no negativo y se formatea en decimal ordinario. Así, el entero 2 genera :2, no :02. Otro protocolo puede prescribir otra representación.
No arregles una discrepancia modificando repetidamente la evidencia hasta coincidir. Conserva el registro original, documenta una hipótesis de codificación y calcúlala aparte. Una coincidencia con entradas modificadas no demuestra que fueran usadas en esa ronda. A la inversa, una diferencia inicial puede proceder de copia o versión, sin diagnosticar fraude por sí sola.
5. Sigue el cálculo educativo completo
El archivo illustrative_crash.mjs usa HMAC-SHA256 con clave UTF-8 del servidor y mensaje clientSeed:nonce. Sus primeros 13 caracteres forman entero I, con N=2^52 y u=I/N. El multiplicador es max(1, floor(100(1-E)/(1-u))/100), donde E=0,03. La aritmética entera obtiene centésimas equivalentes max(100, floor(97N/(N-I))). No hay regla extra de divisibilidad.
{
"serverSeed": "crashmath_demo_server",
"clientSeed": "crashmath_demo_client",
"nonce": 2,
"status": "calculated",
"model": "HMAC-SHA256, 3% reciprocal, cent floor, no divisibility rule",
"commitment": "da780fd3750c0f33a24c9db836f254463f96ca06f95e17f46b54900a442d25f7",
"roundHash": "55b8a44e6e1065c9fa7e86f9c7a073df271ba21b6307bb029cf4961ea6bb6be5",
"integer": "1508024303149318",
"multiplier": "1.45"
}Es importante mantener coherencia entre fracciones y porcentajes. Con u=0,5, el modelo da 1,94x. Escribir 100-E con E=0,03 usaría 99,97 en el numerador, incorrecto para margen del 3%. Con I=1, el límite inferior conserva 1,00x en vez de 0,99x. La masa mostrada en 1,00x es aproximadamente 3,9604% tras redondear, no simplemente 3%. La guía de compromiso y conversión ofrece la derivación completa para la cuadrícula finita.
| Nonce | Digest completo | Multiplicador del modelo |
|---|---|---|
| 33 | 6ee2ea7bf800e1fe442daf393072494c01e0390e0c5f9c4efbb448fef81b98e7 | 1,71x |
| 38 | 6f5edd047e570bce458ebc9f916514f88ac3e3af767006664b06ee19971fce62 | 1,71x |
Los dos nonces del ejemplo tienen digests completos diferentes y el mismo multiplicador redondeado. No es colisión de hash. Es una conversión de varias entradas a una cantidad mostrada. Prometer resultados diferentes para todos los nonces sería incorrecto incluso con hashes distintos. Son controles sintéticos, no rondas reales observadas ni comprobantes de pagos a jugadores.
6. Separa rotación y comprobación histórica
Un ciclo posible incluye compromiso, uso activo, retirada, revelación y comprobación retrospectiva. Es un modelo explicativo; controles y tiempos reales deben venir del producto elegido. Conserva compromiso e identificador antes de rotar si quieres comprobar la relación después. La revelación no establece cuándo apareció el hash original en la interfaz.
No existe obligación universal de rotar tras 200 o 300 rondas, ni garantía de privacidad por ese calendario. Rotar no borra registros de cuenta, oculta metadatos de red o autentica liquidaciones. Tampoco impide por sí solo cualquier reenvío de peticiones. Identificadores de apuestas, autorización y estado del servidor son cuestiones separadas. Incrementar nonce no debe presentarse como neutralización de todas las amenazas.
7. Interpreta honestamente el estado del cálculo
El cálculo de hash del navegador calcula su modelo seleccionado. No tiene campos separados de compromiso esperado y resultado registrado para coincidencia automática. Sus contextos HMAC son ilustrativos, con divisibilidad distinta del ejemplo descargable sin módulo. Aviator mantiene una función separada. Selecciona especificación antes de comparar; un nombre conocido de juego no basta.
Un hash calculado no acredita compromiso previo sin valor guardado independientemente. Un multiplicador reproducido no prueba aceptación ni pago. Para comparar de verdad, conserva compromiso esperado y resultado registrado, declara qué comprobaciones fueron posibles y deja las ausentes sin validar. Nunca entregues una semilla activa sin revelar a un servicio desconocido solo para rellenar un formulario. Los datos históricos públicos bastan para aprender.
8. Termina con un registro utilizable
Un registro útil identifica juego, versión, ronda o pareja, compromiso original y momento, entradas reveladas, codificación exacta y conversión. Distingue digest calculado y registrado, multiplicador calculado y mostrado. Anota cualquier campo necesario ausente. Puedes parar sin otra apuesta ni supuesta clave secreta de un vendedor de señales.
Nuestro conjunto sintético público sirve para practicar reproducción, no para certificar operadores. Las herramientas de valor esperado exploran supuestos declarados, sin otimizar una semilla afortunada. El registro directo de socios es separado y no requiere terminar el ejercicio. Conocer entradas mejora la calidad de comprobación; no crea esperanza positiva ni garantiza privacidad, pagos o resultados futuros.
