Vous savez : Le temps attendu entre deux blocs Bitcoin est en moyenne de \(10\) minutes. Maintenant, vous effectuez une transaction Bitcoin importante et attendez avec impatience de voir si et quand elle apparaîtra dans le prochain bloc:
e50bfacc95975a4e7545d83d8954645f
Comme vous n'avez pas vérifié quand le bloc précédent a été terminé, vous vous attendez en fait à une moyenne de \( \frac{t}{2} = \frac{10}{2} = 5 \) minutes d'attente. Après \(5\) longues minutes se sont écoulées, vérifiez quand le dernier bloc a été réellement terminé:
e50bfacc95975a4e7545d83d8954645f
Le dernier bloc était déjà terminé il y a \(7\) minutes. Maintenant que vous connaissez ces informations, le temps prévu passe de \(5\) minutes à un total de \(10\) minutes. Cela signifie : dans environ \(3\) minutes, ce sera probablement le cas. Vous exécutez la commande encore et encore. Et attendre. Après encore \(10\) minutes, vous avez le sentiment que quelque chose ne va pas.
Mais alors tu te souviens que Paradoxe d'attente:
Si les bus circulent toutes les \(t\) minutes en moyenne, le temps d'attente pour une heure d'arrivée aléatoire à l'arrêt de bus ne correspond pas à \(\frac{t}{2}\) minutes, mais dans le cas d'une distribution exponentielle distances \(t\) .
Les occurrences de blocs Bitcoin sont un processus de Poisson et sont donc distribuées de manière exponentielle. Comme les processus de Poisson sont sans mémoire, le bloc suivant est également terminé en \(10\) minutes en moyenne. Cela s'applique toujours - peu importe combien de temps nous avons attendu. La qualité de l'absence de mémoire s'applique à la fois en arrière et en avant dans le temps.
Comment cela peut-il être ?
Pour ce faire, considérons les deux affirmations suivantes:
- A) Le temps d'attente moyen réel entre deux blocs est de \(10\) minutes, et non de \(20\) minutes.
- B) Si un moment aléatoire est choisi, nous nous attendons à ce que le bloc précédent \(10\) minutes dans le passé et le prochain bloc \(10\) minutes dans le futur. On peut donc s'attendre à un temps d'attente de \(20\) minutes entre les blocs.
Nous vérifions les deux déclarations.
Pour ce faire, nous extrayons d'abord les données pertinentes, notamment les heures auxquelles les blocs ont été complétés, dans un fichier TXT (à effectuer avec un nœud complet fonctionnant localement basé sur bitcoind ):
e50bfacc95975a4e7545d83d8954645f
Cela nous donne le fichier texte suivant , que nous traitons maintenant davantage et stockons dans /time.txt . Le programme Rust suivant est utilisé pour cela avec le fichier /Cargo.toml:
e50bfacc95975a4e7545d83d8954645f
Le fichier /src/main.rs contient la logique de test réelle:
e50bfacc95975a4e7545d83d8954645f
Nous installons les dépendances, construisons le programme et le démarrons:
e50bfacc95975a4e7545d83d8954645f
En effet, les deux affirmations sont vraies lorsque nous analysons la sortie:
e50bfacc95975a4e7545d83d8954645f
Cela peut également s'expliquer intuitivement comme suit : si les temps de blocage varient de manière significative, le temps d'attente spécifique varie - si nous effectuons la transaction à un moment aléatoire, la probabilité est plus élevée que nous nous retrouvions dans un intervalle dans lequel le le temps d'attente est supérieur à 10 minutes parce que ces intervalles prennent également plus de place sur la chronologie en raison du temps plus long.