Du vet: Den förväntade tiden mellan två Bitcoin-block är i genomsnitt \(10\) minuter. Nu gör du en viktig Bitcoin-transaktion och väntar ivrigt på att se om och när den dyker upp i nästa block:
e50bfacc95975a4e7545d83d8954645f
Eftersom du inte har kontrollerat när föregående blockering slutfördes förväntar du dig faktiskt ett genomsnitt på \( \frac{t}{2} = \frac{10}{2} = 5 \) minuters väntetid. Efter att \(5\) långa minuter har förflutit, kontrollera när det sista blocket faktiskt var klart:
e50bfacc95975a4e7545d83d8954645f
Det sista blocket var redan färdigt för \(7\) minuter sedan. Nu när du känner till denna information ändras den förväntade tiden från \(5\) minuter till totalt \(10\) minuter. Det betyder: Om ungefär \(3\) minuter är det förmodligen så långt. Du utfärdar kommandot om och om igen. Och vänta. Efter ytterligare \(10\) minuter får du känslan av att något är fel.
Men då kommer du ihåg det Väntar paradox:
Om bussar går varje \(t\) minut i genomsnitt, motsvarar väntetiden för en slumpmässig ankomsttid vid busshållplatsen inte \(\frac{t}{2}\) minuter, utan i fallet med exponentiellt fördelade avstånd \(t\) .
Bitcoin-blockförekomster är en Poisson-process och är därför exponentiellt fördelade. Eftersom Poisson-processer är minneslösa, slutförs även nästa block på \(10\) minuter i genomsnitt. Det gäller alltid – oavsett hur länge vi har väntat. Minneslöshetens kvalitet gäller både bakåt och framåt i tiden.
Hur kan det vara?
För att göra detta överväger vi följande två uttalanden:
- A) Den faktiska genomsnittliga väntetiden mellan två block är \(10\) minuter, inte \(20\) minuter.
- B) Om en slumpmässig tidpunkt väljs, förväntar vi oss att föregående block \(10\) minuter i det förflutna och nästa block \(10\) minuter i framtiden. Så vi kan förvänta oss en väntetid på \(20\) minuter mellan blocken.
Vi kontrollerar båda påståendena.
För att göra detta extraherar vi först relevant data, särskilt tidpunkterna då blocken slutfördes, till en TXT-fil (som ska utföras med en lokalt körande full nod baserad på bitcoind ):
e50bfacc95975a4e7545d83d8954645f
Detta ger oss följande textfil , som vi nu bearbetar vidare och lagrar i /time.txt . Följande Rust- program används för detta med filen /Cargo.toml:
e50bfacc95975a4e7545d83d8954645f
Filen /src/main.rs innehåller själva testlogiken:
e50bfacc95975a4e7545d83d8954645f
Vi installerar beroenden, bygger programmet och startar det:
e50bfacc95975a4e7545d83d8954645f
Faktum är att båda påståendena är sanna när vi analyserar resultatet:
e50bfacc95975a4e7545d83d8954645f
Detta kan också förklaras intuitivt på följande sätt: Om spärrtiderna varierar avsevärt varierar den specifika väntetiden - om vi genomför transaktionen vid en slumpmässig tidpunkt är sannolikheten större att vi hamnar i ett intervall där väntetiden är längre än 10 minuter beror på att dessa intervaller också tar mer plats på tidslinjen på grund av den längre tiden.