Gli agenti avversari possono lanciare monete?


9

Stavo pensando ai giochi peer-to-peer considerando un semplice gioco di lancio di monete.

Apri la tua versione di P2PCoinFlipping Beta 2.3 e viene visualizzato un elenco di server dei nomi dei giocatori. Dopo aver scelto il server più vicino, viene visualizzato un tabellone dei giocatori più fortunati. Scegli il giocatore con il punteggio più alto e il gioco inizia. Da quando hai iniziato la battaglia, il giocatore avversario sceglie il lato della moneta, la testa e ti vengono assegnate le code. Viene visualizzata una bella grafica che mostra una moneta che cade alla fine atterrando sulle teste. Peccato, tu perdi.

Ma come fai a sapere che il risultato è giusto?

Se il risultato viene scelto sul tuo computer, puoi modificare il programma per scegliere di vincere e lo stesso vale per l'avversario. Il gioco non è deterministico, quindi non riesci a convalidare il risultato.

È possibile avere più agenti avversari indipendenti d'accordo su un evento non deterministico?


Sebbene non risponda alla domanda, questo è il motivo per cui il multiplayer basato su server è buono: lascia che il server sia l'arbitro. Un'idea interessante sarebbe quella di fare affidamento su un servizio di terze parti come gettoniera. Si potrebbe ad esempio utilizzare un generatore di GUID online (come guidgenerator.com ) come base per un sistema?
Tim Holt,

Risposte:


6

Questa procedura farà il lavoro:

  1. ciascuno dei due peer genera un numero casuale.
  2. ogni peer crea un hash salato del suo numero e lo invia all'altro peer.
  3. uno dei peer rifiuta la richiesta se ha lo stesso hash che ha inviato.
  4. una volta che entrambi i peer confermano la ricezione degli hash reciproci, ognuno invia all'altro il proprio numero casuale effettivo.
  5. ogni peer verifica che l'hash inviato dall'altro sia in realtà un hash del numero casuale. respingere lo scambio.
  6. il risultato del lancio della moneta è lo XOR del bit meno significativo di ciascun numero, ovvero

    (a & 1) ^ (b & 1)

Una soluzione alternativa:

  1. Ognuno dei due colleghi decide tra di loro per decidere chi dovrebbe andare per primo. Chiamiamoli A e B, solo per essere originali.
  2. Il peer A genera il suo numero casuale, crea da esso un hash salato e invia l'hash al peer B.
  3. B genera il suo numero casuale e lo invia ad A.
  4. A invia il suo numero casuale a B.
  5. B verifica che l'hash salato sia l'hash del numero che ha ricevuto.
  6. il risultato del lancio della moneta è lo XOR del bit meno significativo di ciascun numero, come sopra.

Ho posto questa domanda sul sito di crittografia e ho stabilito che è abbastanza sicuro. Apparentemente questa è una variazione del regime di impegno .


1
Questo protocollo, come descritto, è vulnerabile a un attacco di riproduzione, in cui un peer fa eco ai messaggi dell'altro peer per forzare il risultato a 0. Tuttavia, è possibile apportare diverse semplici modifiche per impedire questo attacco.
Ilmari Karonen,

Questa versione dovrebbe andare bene.
Michael Slade,

In che modo ciò impedisce a un peer di scegliere semplicemente un numero anziché generarlo casualmente?
Kylotan

@Kylotan: Non lo è, ma fino a quando almeno uno dei peer sceglie a caso, il risultato sarà casuale.
Ilmari Karonen,

2
Un peer non ha nulla da guadagnare anche se si sceglie 0 sempre, perché in questo modo si ottiene un vantaggio per l'altro peer. Il risultato finale dipende ugualmente dai numeri forniti da entrambi i peer.
Michael Slade,

2

Si scopre che non solo gli agenti avversari possono lanciare monete, ma gli agenti avversari possono giocare a poker .

Detto questo, tende ad essere estremamente costoso dal punto di vista computazionale e abbastanza difficile da ottenere. Probabilmente non vale lo sforzo di implementazione. Guarda quanti protocolli multiplayer sono esilaranti e vulnerabili a un server dannoso (vale a dire: tutti quelli di cui sono a conoscenza) e quanto sono ancora popolari, e semplicemente non sembra un uso pratico del tempo.

StarCraft II è un buon esempio. È un gioco in cui lo scouting è fondamentale e sapere cosa sta facendo il nemico può dare un vantaggio fenomenale e premi a cinque cifre o maggiori poggiano regolarmente sui risultati. . . eppure entrambi i computer hanno lo stato di gioco memorizzato in ogni momento! È banale scrivere un programma che ti consenta di guardare direttamente l'avversario e ottenere una gamba enorme su di loro.

Si scopre che nessuno dei seri concorrenti utilizza questi programmi. È troppo facile da rilevare ("hey, Jim, come fai a sapere cosa sto costruendo nell'istante in cui lo sto costruendo?") E non vale la pena.

Detto questo, se vuoi maggiori informazioni, ti consigliamo di esaminare la crittografia in dettaglio - questo non è davvero nel regno dello sviluppo del gioco.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.