Je weet wel: de verwachte tijd tussen twee Bitcoin-blokken is gemiddeld \(10\) minuten. Nu doe je een belangrijke Bitcoin-transactie en wacht je gretig af om te zien of en wanneer deze in het volgende blok verschijnt:
e50bfacc95975a4e7545d83d8954645f
Aangezien je niet hebt gecontroleerd wanneer het vorige blok klaar was, verwacht je eigenlijk gemiddeld \( \frac{t}{2} = \frac{10}{2} = 5 \) minuten wachttijd. Nadat \(5\) lange minuten zijn verstreken, controleert u wanneer het laatste blok daadwerkelijk is voltooid:
e50bfacc95975a4e7545d83d8954645f
Het laatste blok is \(7\) minuten geleden voltooid. Nu u deze informatie kent, verandert de verwachte tijd van \(5\) minuten naar \(10\) minuten totaal. Dat betekent: het zal waarschijnlijk binnen ongeveer \(3\) minuten klaar zijn. Je geeft het commando steeds opnieuw. En wacht. Na nog eens \(10\) minuten begin je het gevoel te krijgen dat er iets mis is.
Maar dan onthoud je dat Wachten paradox:
Als bussen gemiddeld elke \(t\) minuten rijden, komt de wachttijd voor een willekeurige aankomsttijd bij de bushalte niet overeen met \(\frac{t}{2}\) minuten, maar bij exponentieel verdeelde afstanden \(t\) .
Het voorkomen van Bitcoin-blokkades is een Poisson-proces en is daarom exponentieel verdeeld. Omdat Poisson-processen geheugenloos zijn, is het volgende blok ook gemiddeld in \(10\) minuten voltooid. Dat geldt altijd - hoe lang we ook wachten. De kwaliteit van geheugenloosheid geldt zowel achteruit als vooruit in de tijd.
Hoe kan dat zijn?
Om dit te doen, beschouwen we de volgende twee uitspraken::
- A) De werkelijke gemiddelde wachttijd tussen twee blokken is \(10\) minuten, niet \(20\) minuten.
- B) Als er een willekeurig tijdstip wordt gekozen, verwachten we dat het vorige blok \(10\) minuten in het verleden en het volgende blok \(10\) minuten in de toekomst. We kunnen dus rekening houden met een wachttijd van \(20\) minuten tussen de blokken.
We controleren beide stellingen.
Om dit te doen extraheren we eerst de relevante gegevens, met name de tijdstippen waarop de blokken voltooid waren, in een TXT-bestand (uit te voeren met een lokaal draaiende full node op basis van bitcoind ).:
e50bfacc95975a4e7545d83d8954645f
Dit levert ons het volgende tekstbestand op, dat we nu verder verwerken en opslaan in /time.txt . Hiervoor wordt het volgende Rust- programma met het bestand /Cargo.toml gebruikt:
e50bfacc95975a4e7545d83d8954645f
Het bestand /src/main.rs bevat de eigenlijke testlogica:
e50bfacc95975a4e7545d83d8954645f
We installeren de afhankelijkheden, bouwen het programma en starten het:
e50bfacc95975a4e7545d83d8954645f
Beide uitspraken zijn inderdaad waar als we de output analyseren:
e50bfacc95975a4e7545d83d8954645f
Dit kan intuïtief ook als volgt worden verklaard: Als de bloktijden sterk variëren, varieert de specifieke wachttijd - als we de transactie op een willekeurig tijdstip uitvoeren, is de kans groter dat we in een interval terechtkomen waarin de wachttijd langer is dan 10 minuten komt doordat deze intervallen door de langere tijd ook meer ruimte innemen op de tijdlijn.