Sai: il tempo previsto tra due blocchi Bitcoin è in media \(10\) minuti. Ora stai effettuando un'importante transazione Bitcoin e stai aspettando con impazienza di vedere se e quando apparirà nel blocco successivo:
e50bfacc95975a4e7545d83d8954645f
Dal momento che non hai controllato quando il blocco precedente è stato completato, ti aspetti una media di \( \frac{t}{2} = \frac{10}{2} = 5 \) minuti di attesa. Dopo \(5\) lunghi minuti, controlla quando l'ultimo blocco è stato effettivamente completato:
e50bfacc95975a4e7545d83d8954645f
L'ultimo blocco è già stato completato \(7\) minuti fa. Ora che conosci queste informazioni, il tempo previsto passa da \(5\) minuti a un totale di \(10\) minuti. Ciò significa: tra circa \(3\) minuti sarà probabilmente così lontano. Dai il comando più e più volte. E aspetta. Dopo altri \(10\) minuti hai la sensazione che qualcosa non va.
Ma poi ti ricordi che Aspettando il paradosso:
Se gli autobus passano in media ogni \(t\) minuti, il tempo di attesa per un orario di arrivo casuale alla fermata dell'autobus non corrisponde a \(\frac{t}{2}\) minuti, ma nel caso di distribuzione esponenziale distanze \(t\) .
Le occorrenze dei blocchi Bitcoin sono un processo di Poisson e sono quindi distribuite in modo esponenziale. Poiché i processi di Poisson sono privi di memoria, anche il blocco successivo viene completato in media in \(10\) minuti. Questo vale sempre, non importa da quanto tempo stiamo aspettando. La qualità dell'assenza di memoria si applica sia avanti che indietro nel tempo.
Come può essere?
Per fare ciò, consideriamo le seguenti due affermazioni:
- A) Il tempo medio di attesa effettivo tra due blocchi è \(10\) minuti, non \(20\) minuti.
- B) Se viene scelto un punto temporale casuale, ci aspettiamo che il blocco precedente \(10\) minuti nel passato e il blocco successivo \(10\) minuti nel futuro. Quindi possiamo aspettarci un tempo di attesa di \(20\) minuti tra i blocchi.
Controlliamo entrambe le dichiarazioni.
Per fare ciò, estraiamo prima i dati rilevanti, in particolare gli orari in cui i blocchi sono stati completati, in un file TXT (da eseguirsi con un full node in esecuzione locale basato su bitcoind ):
e50bfacc95975a4e7545d83d8954645f
Questo ci dà il seguente file di testo , che ora elaboriamo ulteriormente e memorizziamo in /time.txt . Il seguente programma Rust viene utilizzato per questo con il file /Cargo.toml:
e50bfacc95975a4e7545d83d8954645f
Il file /src/main.rs contiene la logica di test effettiva:
e50bfacc95975a4e7545d83d8954645f
Installiamo le dipendenze, costruiamo il programma e lo avviamo:
e50bfacc95975a4e7545d83d8954645f
In effetti, entrambe le affermazioni sono vere quando analizziamo l'output:
e50bfacc95975a4e7545d83d8954645f
Ciò può essere spiegato anche intuitivamente come segue: Se i tempi di blocco variano notevolmente, varia il tempo di attesa specifico - se effettuiamo la transazione in un momento casuale, è maggiore la probabilità che ci ritroveremo in un intervallo in cui il il tempo di attesa è più lungo di 10 minuti è perché questi intervalli occupano anche più spazio sulla timeline a causa del tempo più lungo.