Server seed, client seed e nonce são nomes de entradas, não garantia universal de justiça. O significado depende do protocolo e da versão do jogo. Este guia trata de copiar e interpretar essas entradas corretamente, incluindo codificação, escopo do contador e rotação de sementes. Usamos strings públicas completas num modelo educativo. Não pedimos segredo ativo, prometemos semente vencedora ou afirmamos que todo jogo crash exige nonce.
1. Encontre a especificação antes de copiar a semente
A semente do servidor é uma entrada fornecida pelo lado do servidor. Em alguns sistemas seu hash aparece antes da aposta e o valor original é revelado depois. Original e compromisso são campos diferentes. Uma string de 64 caracteres pode ser digest SHA-256, texto hexadecimal de semente ou outro valor. O comprimento não identifica o papel nem comprova 256 bits de entropia aleatória. Copie nome do campo e contexto junto do valor.
O momento de revelação também varia. Uma semente aposentada pode aparecer depois da rotação, não após cada aposta. Não presuma que sair da conta, jogar certo número de rodadas ou abrir um histórico genérico revele o valor. Consulte o ciclo documentado do jogo escolhido. Sem a entrada revelada, a reprodução retrospectiva pode ficar incompleta. É melhor manter um campo sem resposta do que substituir um valor de outra rodada.
A descrição da SPRIBE e a implementação da Stake ilustram sistemas diferentes. Nossa função de Aviator usa cálculo separado SHA-512 sem nonce. O modelo HMAC educativo não a substitui. Um gerador geral de bytes do fornecedor também não deve ser confundido com a conversão final do multiplicador de todos os jogos.
| Entrada | Papel no modelo educativo | Não deduzir |
|---|---|---|
| Semente do servidor | Chave HMAC em texto UTF-8 | Entropia pelo comprimento |
| Semente do cliente | Parte da mensagem | Imprevisibilidade garantida |
| Nonce | Contador inteiro não negativo | Nova entropia ou multiplicador único |
2. Semente do cliente não é senha ou configuração lucrativa
A semente do cliente é uma entrada associada ao jogador conforme o protocolo. Alguns produtos permitem editá-la; jogos coletivos podem usar várias entradas de participantes. Quem fornece, quem consegue ver e quando ficam fixadas precisa ser documentado. Não deduza que o valor só surge no último instante ou seja desconhecido do servidor. Uma palavra familiar ou frase escolhida pessoalmente não significa automaticamente alta entropia.
A contribuição do cliente pode limitar a seleção de resultados por uma parte apenas sob condições relevantes de compromisso e imprevisibilidade. Se o operador conhece todas as entradas enquanto escolhe candidatos de servidor, chamar uma delas client seed não impede pré-seleção. São condições de protocolo, não constatação de que determinado operador seleciona sementes. O hash não fornece a evidência ausente sobre o processo de geração.
Não há string vencedora validada aqui. Testar exemplos públicos e escolher aquele com passado favorável é seleção depois de observar resultados, não vantagem prospectiva. Trocar a semente não aumenta o parâmetro de retorno de um modelo fixo. Pode também mudar o registro necessário para reproduzir uma aposta encerrada. Preserve identificador do par antigo e entradas históricas em vez de substituí-los pelas configurações atuais.
3. Entenda o que o nonce conta
No modelo educativo, nonce é inteiro não negativo incluído em clientSeed:nonce. Mesma chave e mesma mensagem geram o mesmo HMAC. Alterar um contador é uma forma de mudar a mensagem; usar novas sementes por rodada é outra. Portanto nonce não é indispensável em todo jogo. Um contador público determinístico também não fornece nova entropia aleatória independente só porque aumenta.
Descubra o escopo e o valor inicial. O contador pode pertencer a um par de sementes, conta ou outro agrupamento documentado. Começar em zero não dá a mesma entrada que começar em um. O cursor para selecionar bytes adicionais é outro parâmetro, não apenas outro nome do nonce. Não acrescente ou remova campos sem a especificação correspondente. Um registro completo identifica par, contador e cursor necessário.
Uma lacuna não estabelece manipulação sozinha. Outras apostas elegíveis, outro jogo no mesmo escopo ou reinicialização podem precisar de consideração. Uma sequência contínua também não demonstra que um histórico separado esteja completo. Peça a definição do escopo e mantenha a sequência original. O cálculo abaixo confere um conjunto de entradas; não examina todo histórico da conta nem explica automaticamente um número ausente.
4. Strings e bytes precisam corresponder exatamente
Funções criptográficas recebem bytes. Neste exemplo, as sementes são texto literal UTF-8. A string 6162 vira quatro bytes dos caracteres 6,1,6,2. Decodificá-la como hexadecimal produziria dois bytes correspondentes a a,b. Ambas as convenções são possíveis, mas são entradas diferentes. Um protocolo real precisa especificar a esperada; aparência não resolve a questão.
Espaços, maiúsculas, Unicode e separadores também importam. Copiar uma quebra de linha, mudar uma letra ou inverter clientes pode mudar o digest. O programa público não remove espaços nem normaliza sementes silenciosamente. O nonce precisa ser inteiro seguro não negativo e é formatado em decimal comum. Assim, o inteiro 2 produz :2, não :02. Outro protocolo pode prescrever outra representação.
Não corrija uma divergência alterando repetidamente a evidência até coincidir. Preserve o registro original, documente uma hipótese de codificação e calcule-a separadamente. Uma coincidência com entradas modificadas não mostra que foram usadas naquela rodada. Inversamente, uma divergência inicial pode ser erro de cópia ou versão, não diagnóstico de fraude por si só.
5. Acompanhe o cálculo educativo completo
O arquivo illustrative_crash.mjs usa HMAC-SHA256 com chave UTF-8 do servidor e mensagem clientSeed:nonce. Os primeiros 13 caracteres formam inteiro I, com N=2^52 e u=I/N. O multiplicador é max(1, floor(100(1-E)/(1-u))/100), onde E=0,03. A aritmética inteira calcula centésimos equivalentes max(100, floor(97N/(N-I))). Não há regra extra de divisibilidade.
{
"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"
}Manter frações e porcentagens consistentes importa. Com u=0,5, o modelo produz 1,94x. Escrever 100-E com E=0,03 usaria 99,97 no numerador e não representaria margem de 3%. Com I=1, o piso inferior mantém 1,00x em vez de 0,99x. A massa exibida em 1,00x é aproximadamente 3,9604% após arredondamento, não simplesmente 3%. O guia de compromisso e conversão apresenta a derivação completa da grade finita.
| Nonce | Digest completo | Multiplicador do modelo |
|---|---|---|
| 33 | 6ee2ea7bf800e1fe442daf393072494c01e0390e0c5f9c4efbb448fef81b98e7 | 1,71x |
| 38 | 6f5edd047e570bce458ebc9f916514f88ac3e3af767006664b06ee19971fce62 | 1,71x |
Os dois nonces do exemplo têm digests completos diferentes, mas o mesmo multiplicador arredondado. Não é colisão de hash. É uma conversão de várias entradas para um valor mostrado. Prometer resultados distintos para todos os nonces seria incorreto mesmo com hashes diferentes. São controles sintéticos, não rodadas reais observadas ou comprovação de pagamento a jogador.
6. Separe rotação e conferência histórica
Um ciclo possível contém compromisso, uso ativo, aposentadoria, revelação e conferência retrospectiva. É um modelo explicativo; controles e momentos reais precisam vir do produto escolhido. Conserve compromisso e identificador do par antes de rotacionar, se quiser conferir a relação depois. A revelação não demonstra quando o hash original apareceu na interface.
Não existe exigência universal de rotacionar após 200 ou 300 rodadas, nem garantia de privacidade decorrente disso. A rotação não apaga registros da conta, esconde metadados de rede ou autentica liquidação. Também não impede sozinha qualquer reenvio de solicitação. Identificadores de apostas, autorização e estado do servidor são assuntos separados. Incrementar nonce não deve ser apresentado como neutralização de toda ameaça.
7. Interprete honestamente o estado de cálculo
O cálculo de hash no navegador calcula seu modelo selecionado. Não tem campos separados de compromisso esperado e resultado registrado para coincidência automática. Seus contextos HMAC são ilustrativos, com divisibilidade diferente do exemplo baixável sem módulo. Aviator permanece uma função separada. Escolha a especificação antes de comparar; um nome conhecido de jogo não basta.
Um hash calculado não comprova compromisso anterior sem o valor salvo independentemente. Multiplicador reproduzido não prova aceitação ou pagamento. Para comparação real, guarde compromisso esperado e resultado registrado, declare quais verificações foram possíveis e deixe as ausentes sem validação. Nunca forneça semente ativa não revelada a serviço desconhecido apenas para preencher formulário. Dados históricos públicos bastam para aprender.
8. Termine com um registro utilizável
Um registro útil identifica jogo, versão, rodada ou par, compromisso original e momento, entradas reveladas, codificação exata e conversão. Distingue digest calculado do registrado e multiplicador calculado do exibido. Se faltar campo necessário, anote. É possível parar sem outra aposta ou suposta chave secreta de um vendedor de sinais.
Nosso conjunto sintético público permite praticar reprodução, não certificar operador. Ferramentas de valor esperado exploram premissas declaradas, sem otimizar uma semente sortuda. Cadastro direto de parceiro é separado e não exige terminar o exercício. Conhecer entradas melhora a qualidade da conferência; não cria expectativa positiva nem garante privacidade, pagamentos ou resultados futuros.
