Provably fair no Mines

Escolha o protocolo correto

O exemplo trata do processo documentado de Mines da Stake. Não é instrução SPRIBE nem método universal para todo Mines.

A Stake documenta server seed, client seed, nonce da rodada e cursor para geração de bytes. O hash do server seed existe antes; o seed é divulgado após a troca. Reproduzir o resultado exige o original, não só o hash. Implementação da Stake.

Salve as evidências no momento certo

Guarde hash anterior à rodada, client seed, nonce, minas e registro do resultado. Depois da divulgação, calcule o hash do server seed e compare com o compromisso anterior. Reproduza então o resultado pelo protocolo da versão.

Um hash copiado só depois do resultado não demonstra, sozinho, o compromisso anterior à rodada.

Exemplo sintético com uma mina

As entradas abaixo foram inventadas para esta explicação. Não representam conta, rodada jogada ou auditoria do serviço real da Stake.

O hash SHA-256 do texto do server seed é:

afbc5f0cca7198f1b14ca26cf9b6dfcca1f827be1bae43e4f60ab0ca47bee56c

Para o primeiro bloco, use HMAC-SHA256 com o texto do server seed como chave e editorial-example-client:0:0 como mensagem. O resultado é:

e52daa798ed2dc8b0f6d7c7beda965baf40fe5435032dba18df23ba17d09c5ed

Os quatro primeiros bytes são 229, 45, 170 e 121. A conversão da Stake combina os bytes assim:

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

Isso produz o primeiro número de ponto flutuante. Conversão de bytes da Stake.

Multiplique pelas 25 posições inicialmente disponíveis e tome a parte inteira: floor(0,8952280564699322 × 25) = 22. Contando do zero, da esquerda à direita e de cima para baixo, a posição 22 é linha 5, coluna 3. Nesse exemplo de uma mina, essa é sua posição. Mapeamento de eventos Mines da Stake.

Implementações separadas em Python e Node produziram o mesmo hash, HMAC, número e posição inicial. Uma mina limita o exemplo ao primeiro evento; várias exigem também reproduzir a prevenção de posições duplicadas.

Compare com o campo registrado

Uma verificação real compararia a posição gerada ao resultado salvo com os mesmos seeds, nonce e configuração. Em caso de diferença, confira entradas, codificação, índices e versão do protocolo. Comparar imagens com ajustes diferentes não basta.

Este exemplo sintético não tem rodada real para comparar. Demonstra cálculo, não pagamento de cassino verificado.

Verificar não é prever

O cálculo usa server seed. Client seed e hash anterior não fornecem esse dado. Reproduzir após divulgação é diferente de identificar uma casa oculta antes do fim da rodada.

Mines é manipulado, legítimo ou seguro?

São perguntas distintas. Uma verificação provably fair de Mines pode comparar um resultado a um compromisso e procedimento. Sozinha, não prova ausência de viés, pagamento de saques ou elegibilidade regional.

Identifique o protocolo e salve os registros exigidos. Uma conferência de seeds bem-sucedida é evidência daquela rodada, sem garantia sobre toda operadora Mines. Selo ou captura sem explicação não bastam para classificar um cassino como legítimo ou fraudulento.

O diretório de cassinos separa evidências regionais e de operadora; o guia de avaliação de preditores distingue conferir resultado divulgado e prever resultado oculto.