Bitcoin blokeringstid

Du ved: Den forventede tid mellem to Bitcoin-blokke er i gennemsnit \(10\) minutter. Nu laver du en vigtig Bitcoin-transaktion og venter spændt på at se, om og hvornår den dukker op i næste blok:

e50bfacc95975a4e7545d83d8954645f


Da du ikke har tjekket, hvornår den forrige blok blev afsluttet, forventer du faktisk et gennemsnit på \( \frac{t}{2} = \frac{10}{2} = 5 \) minutters ventetid. Efter \(5\) lange minutter er gået, skal du kontrollere, hvornår den sidste blok faktisk blev afsluttet:

e50bfacc95975a4e7545d83d8954645f

Den sidste blok blev allerede afsluttet for \(7\) minutter siden. Nu hvor du kender disse oplysninger, ændres den forventede tid fra \(5\) minutter til i alt \(10\) minutter. Det betyder: Om cirka \(3\) minutter er det nok så langt. Du udsteder kommandoen igen og igen. Og vent. Efter yderligere \(10\) minutter får du en følelse af, at der er noget galt.

Men så husker du det Venteparadoks:

Hvis busserne i gennemsnit kører hvert \(t\) minut, svarer ventetiden for en tilfældig ankomsttid ved busstoppestedet ikke til \(\frac{t}{2}\) minutter, men i tilfælde af eksponentielt fordelt afstande \(t\) .

Bitcoin-blokforekomster er en Poisson-proces og er derfor eksponentielt fordelt. Da Poisson-processer er hukommelsesløse, afsluttes den næste blok også på \(10\) minutter i gennemsnit. Det gælder altid – uanset hvor længe vi har ventet. Kvaliteten af ​​hukommelsesløshed gælder både baglæns og fremad i tiden.

Hvordan kan det være?

For at gøre dette overvejer vi følgende to udsagn:

  • A) Den faktiske gennemsnitlige ventetid mellem to blokke er \(10\) minutter, ikke \(20\) minutter.
  • B) Hvis man vælger et tilfældigt tidspunkt, forventer vi, at den foregående blok \(10\) minutter i fortiden og den næste blok \(10\) minutter i fremtiden. Så vi kan forvente en ventetid på \(20\) minutter mellem blokkene.

Vi tjekker begge udsagn.

For at gøre dette udtrækker vi først de relevante data, specifikt de tidspunkter, hvor blokkene blev afsluttet, til en TXT-fil (der skal udføres med en lokalt kørende fuld node baseret på bitcoind ):

e50bfacc95975a4e7545d83d8954645f

Dette giver os følgende tekstfil , som vi nu behandler videre og gemmer i /time.txt . Følgende Rust- program bruges til dette med filen /Cargo.toml:

e50bfacc95975a4e7545d83d8954645f

Filen /src/main.rs indeholder den faktiske testlogik:

e50bfacc95975a4e7545d83d8954645f

Vi installerer afhængighederne, bygger programmet og starter det:

e50bfacc95975a4e7545d83d8954645f

Faktisk er begge udsagn sande, når vi analyserer outputtet:

e50bfacc95975a4e7545d83d8954645f

Dette kan også forklares intuitivt på følgende måde: Hvis blokeringstiderne varierer betydeligt, varierer den specifikke ventetid - hvis vi udfører transaktionen på et tilfældigt tidspunkt, er sandsynligheden større for, at vi ender i et interval, hvor ventetiden er længere end 10 minutter, fordi disse intervaller også fylder mere på tidslinjen på grund af den længere tid.

Tilbage