Ya sabes: el tiempo esperado entre dos bloques de Bitcoin es en promedio \(10\) minutos. Ahora está haciendo una transacción importante de Bitcoin y esperando ansiosamente ver si aparece en el siguiente bloque y cuándo.:
e50bfacc95975a4e7545d83d8954645f
Dado que no ha verificado cuándo se completó el bloque anterior, en realidad espera un promedio de \( \frac{t}{2} = \frac{10}{2} = 5 \) minutos de tiempo de espera. Después de que hayan transcurrido \(5\) largos minutos, verifique cuándo se completó realmente el último bloque:
e50bfacc95975a4e7545d83d8954645f
El último bloque ya se completó hace \(7\) minutos. Ahora que conoce esta información, el tiempo esperado cambia de \(5\) minutos a un total de \(10\) minutos. Eso significa: en unos \(3\) minutos probablemente estará tan lejos. Emite el comando una y otra vez. Y espera. Después de otros \(10\) minutos, tiene la sensación de que algo anda mal.
Pero luego recuerdas eso Esperando paradoja:
Si los autobuses pasan cada \(t\) minutos en promedio, el tiempo de espera para un tiempo de llegada aleatorio en la parada de autobús no corresponde a \(\frac{t}{2}\) minutos, pero en el caso de distribuidos exponencialmente distancias \(t\) .
Las ocurrencias de bloques de Bitcoin son un proceso de Poisson y, por lo tanto, se distribuyen exponencialmente. Dado que los procesos de Poisson no tienen memoria, el siguiente bloque también se completa en un promedio de \(10\) minutos. Eso siempre se aplica, no importa cuánto tiempo hayamos estado esperando. La cualidad de la falta de memoria se aplica tanto hacia atrás como hacia adelante en el tiempo.
¿Como puede ser?
Para hacer esto, consideramos las siguientes dos declaraciones:
- A) El tiempo de espera promedio real entre dos bloques es \(10\) minutos, no \(20\) minutos.
- B) Si uno elige un punto aleatorio en el tiempo, esperamos que el bloque anterior \(10\) minutos en el pasado y el siguiente bloque \(10\) minutos en el futuro. Entonces podemos esperar un tiempo de espera de \(20\) minutos entre los bloques.
Comprobamos ambas declaraciones.
Para hacer esto, primero extraemos los datos relevantes, específicamente las horas en las que se completaron los bloques, en un archivo TXT (que se llevará a cabo con un nodo completo de ejecución local basado en bitcoind ):
e50bfacc95975a4e7545d83d8954645f
Esto nos da el siguiente archivo de texto , que ahora procesamos más y almacenamos en /time.txt . El siguiente programa de Rust se utiliza para esto con el archivo /Cargo.toml:
e50bfacc95975a4e7545d83d8954645f
El archivo /src/main.rs contiene la lógica de prueba real:
e50bfacc95975a4e7545d83d8954645f
Instalamos las dependencias, construimos el programa y lo iniciamos:
e50bfacc95975a4e7545d83d8954645f
De hecho, ambas afirmaciones son verdaderas cuando analizamos la salida:
e50bfacc95975a4e7545d83d8954645f
Esto también se puede explicar intuitivamente de la siguiente manera: si los tiempos de bloqueo varían significativamente, el tiempo de espera específico varía; si realizamos la transacción en un momento aleatorio, la probabilidad es mayor de que terminemos en un intervalo en el que la El tiempo de espera es superior a 10 minutos se debe a que estos intervalos también ocupan más espacio en la línea de tiempo debido al mayor tiempo.