Provably fair en Mines: cómo revisar un resultado

Elige el protocolo correcto

El ejemplo corresponde a Mines de Stake documentado. No es una guía de SPRIBE ni un método universal para todos los Mines.

Stake documenta semillas del servidor y cliente, un nonce de ronda y un cursor para generar bytes. El hash existe antes de jugar; la semilla se revela tras rotarla. Reproducir requiere la semilla original, no solo el hash. Implementación de Stake.

Guarda los datos en el momento adecuado

Para una comprobación real, conserva hash previo, semilla del cliente, nonce, minas y resultado. Cuando se revele la semilla del servidor, calcula su hash y contrástalo con el compromiso anterior. Después reproduce el resultado con el protocolo de esa versión.

Un hash copiado solo después del resultado no demuestra por sí mismo qué se comprometió antes.

Ejemplo sintético con una mina

Los siguientes datos se inventaron para esta explicación. No corresponden a una cuenta, una ronda jugada o una auditoría del servicio real de Stake.

Calcular SHA-256 del texto de la semilla del servidor produce:

afbc5f0cca7198f1b14ca26cf9b6dfcca1f827be1bae43e4f60ab0ca47bee56c

Para el primer bloque usa HMAC-SHA256 con ese texto como clave y editorial-example-client:0:0 como mensaje. El resumen es:

e52daa798ed2dc8b0f6d7c7beda965baf40fe5435032dba18df23ba17d09c5ed

Los primeros cuatro bytes son 229, 45, 170 y 121. Stake combina cuatro bytes así:

229/256 + 45/256² + 170/256³ + 121/256⁴ = 0,8952280564699322

Así se obtiene el primer número de coma flotante. Conversión de bytes de Stake.

Multiplícalo por las 25 posiciones disponibles y toma la parte entera: floor(0,8952280564699322 × 25) = 22. Con índices desde cero, de izquierda a derecha y de arriba abajo, la posición 22 es fila 5, columna 3. En este ejemplo sintético de una mina, esa es su posición. Asignación de eventos Mines de Stake.

Implementaciones separadas en Python y Node dieron el mismo hash, resumen, número y posición. Una mina limita el ejemplo al primer evento; con varias también se debe reproducir el procedimiento que evita posiciones duplicadas.

Compara con el tablero registrado

Una verificación real compara la posición generada y el registro de las mismas semillas, nonce y ajustes. Si no coincide, revisa primero datos, codificación, índices y versión. No basta comparar capturas con configuraciones diferentes.

Este ejemplo no tiene un registro real con el que comparar. Demuestra un cálculo, no un pago verificado.

Verificar no es predecir

El cálculo utiliza la semilla del servidor. La del cliente y el hash previo no la sustituyen. Reproducir después de revelarla es distinto de identificar una casilla antes de terminar la ronda.

¿Mines está manipulado, es legítimo o es seguro?

Son preguntas distintas. Una comprobación provably fair de Mines puede contrastar resultado, compromiso y procedimiento. No demuestra por sí sola ausencia de sesgo, pago de retiros o elegibilidad regional de cuenta.

Identifica primero el protocolo y guarda los registros necesarios. Una comprobación correcta respalda ese resultado, no garantiza todos los operadores llamados Mines. Un distintivo o una captura sin explicación no bastan para declarar legítimo o fraudulento a un casino.

El directorio de casinos distingue fuentes de operador y región; el método de evaluación de predictores explica por qué verificar datos revelados no predice secretos.

Colombia: versión, saldo y acceso

En Colombia hay dos revisiones diferentes: reproducir una ronda con semillas y comprobar el dominio del operador. La primera no demuestra autorización local, cumplimiento de un retiro o elegibilidad de un bono. Tampoco entrega la semilla secreta de una ronda futura. Guarda los datos de la ronda que vas a comprobar y usa el procedimiento publicado para esa versión.