Expiration et horodatages
Chaque transaction ZooBC porte, dans ses octets signés, le moment où elle a été créée, en secondes Unix. Cet horodatage ouvre une fenêtre de validité : un bloc ne peut inclure la transaction qu’à l’intérieur de cette fenêtre, et passé ce délai la transaction est morte et doit être signée de nouveau. La fenêtre protège le signataire. Un paiement qui n’a pas pu entrer dans un bloc pendant un moment de forte activité ne traîne pas pendant des jours pour le surprendre ensuite ; il expire simplement, et le signataire peut décider à nouveau.
La fenêtre par défaut : une heure
Par défaut, un bloc peut inclure une transaction jusqu’à 3 600 secondes après son horodatage : une heure, soit 240 blocs à raison d’un bloc toutes les 15 secondes. Passé ce délai, les nœuds la refusent avec un message qui se termine par « … sign it again » (« signez-la de nouveau »).
La fenêtre a aussi un bord avant. Une transaction datée de plus de 3 600 secondes dans le futur est refusée elle aussi, avec une invitation à vérifier l’horloge du signataire. Cela détecte un appareil dont l’horloge est déréglée.
Choisir la fenêtre : la version 3
Une transaction de version 3 porte un champ d’expiration de 4 octets, juste après les frais et le champ de survie, et indique sa propre fenêtre en secondes :
- 0 signifie l’heure par défaut ;
- une valeur plus petite raccourcit la fenêtre, pour un paiement qui doit avoir lieu bientôt ou pas du tout ;
- la plus grande valeur autorisée est de 86 400 secondes, soit un jour ; une valeur plus grande est refusée.
Une transaction de version 1 ou 2 n’a pas de champ d’expiration, et celle qui indique malgré tout une expiration est refusée. Quelle que soit la version, la limite d’une heure dans le futur s’applique toujours.
Une fenêtre plus longue aide quand une signature met du temps à être réunie : sur un portefeuille matériel, ou entre les participants d’un compte multisignature.
Comment les pools et les chaînes s’y adaptent
Deux règles complémentaires rendent sûre la fenêtre d’une journée :
- le pool de transactions d’un nœud conserve chaque transaction pendant la fenêtre qu’elle déclare ;
- chaque chaîne conserve les identifiants de transaction pendant au moins 25 heures : la fenêtre la plus longue plus la tolérance d’une heure dans le futur.
Comme un nœud refuse un identifiant qu’il a déjà confirmé (voir la signature d’une transaction), une transaction ne peut jamais être rejouée tant qu’elle est encore valide.
Le temps dans les blocs
Les blocs sont vérifiés par rapport aux mêmes fenêtres, si bien que chaque nœud arrive au même verdict :
- un bloc dont l’horodatage dépasse l’horodatage d’une transaction plus sa fenêtre est invalide ;
- il en va de même d’un bloc qui porte une transaction datée de plus de 3 600 secondes après le bloc.
Certains règlements se font d’eux-mêmes, bloc par bloc : les échéances des séquestres, l’achèvement des paiements liquides, l’échéance des paiements des transferts programmés, l’expiration des ordres en attente sur un marché et les phases du vote des frais. Ils lisent l’horodatage du bloc précédent, et non celui du bloc lui-même. Un producteur ne peut donc pas dater son bloc un peu en avance pour y attirer un versement.
Pour l’espacement des blocs dans le temps, voir les blocs et le temps.