Caducidad y marcas de tiempo
Toda transacción de ZooBC lleva, dentro de sus bytes firmados, el momento en que se hizo, en segundos Unix. Esa marca de tiempo abre una ventana de validez: un bloque solo puede incluir la transacción dentro de la ventana, y después la transacción queda muerta y hay que volver a firmarla. La ventana protege al firmante. Un pago que no pudo entrar en un bloque en un momento de mucha actividad no se queda rondando durante días para luego sorprenderlo; simplemente caduca, y puede volver a decidir.
La ventana por defecto: una hora
Por defecto, un bloque puede incluir una transacción hasta 3600 segundos después de su marca de tiempo: una hora, o 240 bloques a un bloque cada 15 segundos. Pasado ese tiempo, los nodos la rechazan con un mensaje que termina en "...sign it again".
La ventana también tiene un borde delantero. Una transacción fechada más de 3600 segundos en el futuro también se rechaza, con una indicación para que el firmante revise su reloj. Esto detecta un dispositivo con el reloj mal puesto.
Elegir la ventana: la versión 3
Una transacción de versión 3 lleva un campo de caducidad de 4 bytes, justo después de la comisión y del campo de supervivencia, e indica su propia ventana en segundos:
- 0 significa la hora por defecto;
- un valor menor acorta la ventana, para un pago que debe hacerse pronto o no hacerse;
- el mayor valor permitido es 86 400 segundos, un día; un valor mayor se rechaza.
Una transacción de versión 1 o 2 no tiene campo de caducidad, y una que indica de todos modos una caducidad se rechaza. Sea cual sea la versión, el límite de una hora hacia el futuro se sigue aplicando.
Una ventana más larga ayuda cuando una firma tarda en reunirse: en una billetera de hardware, o entre los participantes de una cuenta multifirma.
Cómo se mantienen al día los conjuntos de espera y las cadenas
Dos reglas complementarias hacen segura la ventana de un día:
- el conjunto de espera de transacciones de un nodo conserva cada transacción durante su propia ventana declarada;
- cada cadena conserva los ids de transacción durante al menos 25 horas: la ventana más larga más la hora de tolerancia hacia el futuro.
Como un nodo rechaza un id que ya ha confirmado (véase firmar una transacción), una transacción nunca puede repetirse mientras siga siendo válida.
El tiempo en los bloques
Los bloques se comprueban con las mismas ventanas, de modo que todos los nodos llegan al mismo veredicto:
- un bloque cuya marca de tiempo supera la marca de tiempo de una transacción más su ventana es inválido;
- también lo es un bloque que lleva una transacción fechada más de 3600 segundos después del bloque.
Algunas liquidaciones ocurren por sí solas, bloque a bloque: los plazos de los escrows, la finalización de los pagos líquidos, el vencimiento de las transferencias programadas, la caducidad de las órdenes en reposo en un mercado y las fases de la votación de la comisión. Estas leen la marca de tiempo del bloque anterior, no la del propio bloque. Por tanto, un productor no puede estampar su bloque un poco adelantado para atraer un pago hacia él.
Cómo se espacian los bloques en el tiempo se explica en bloques y tiempo.