Bitcoin-bloktijd

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 was \(7\) minuten geleden al voltooid. Nu je deze informatie kent, verandert de verwachte tijd van \(5\) minuten naar in totaal \(10\) minuten. Dat betekent: Over ongeveer \(3\) minuten is het waarschijnlijk zo ver. Je geeft de opdracht steeds opnieuw. En wacht. Na nog eens \(10\) minuten krijg je het gevoel dat er iets niet klopt.

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.

Hiervoor extraheren we eerst de relevante gegevens, namelijk de tijdstippen waarop de blokken zijn voltooid, in een TXT-bestand (uit te voeren met een lokaal draaiende full node op basis van bitcoind ):

e50bfacc95975a4e7545d83d8954645f

Dit geeft ons het volgende tekstbestand , dat we nu verder verwerken en opslaan in /time.txt . Hiervoor wordt het volgende Rust- programma gebruikt met het bestand /Cargo.toml:

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.

Terug