Peter Todd est un développeur de Bitcoin, auteur de la proposition de verrouillage temporel BIP 65, coauteur des règles de remplacement BIP 125 et développeur d’OpenTimestamps. Ses contributions portent sur des garanties différentes : conditions de dépense, état d’un paiement et existence vérifiable de données. Aucune ne fournit à elle seule toutes les autres.
Imaginez devoir prouver qu’une certaine version d’un contrat existait avant le début d’un litige. OpenTimestamps, un projet associé à Peter Todd, répond à ce besoin. Son annonce historique de 2016 présentait une version publique expérimentale et remerciait Riccardo Casatta pour le développement et les tests. Elle témoigne de cette collaboration, sans signifier que le projet est resté expérimental. Todd a aussi travaillé sur les conditions de dépenses futures et sur les paiements encore en attente de confirmation. Commençons par ces deux sujets. [1]
Le BIP 65 de Todd a introduit OP_CHECKLOCKTIMEVERIFY, ou CLTV. Cette instruction permet de conditionner une voie de dépense précise à une hauteur de bloc ou à une limite temporelle. Pensez à un accès de secours à une épargne commune, utilisable par son bénéficiaire seulement plus tard. Jusque-là, la condition temporelle bloque cet accès. Une fois remplie, elle ne déclenche aucun envoi automatique : il faut encore une transaction valide et satisfaire les autres exigences, par exemple fournir une signature. Si une autre voie de dépense existe, elle suit ses propres conditions ; le verrou ne couvre pas nécessairement tout usage des fonds. [2]
Le verrou ne suit pas simplement l’horloge affichée dans le portefeuille. BIP 65 vérifie la relation entre le script, qui définit les conditions de dépense, et le champ nLockTime de la transaction. Tous deux doivent exprimer la même sorte de limite : hauteur de bloc ou temps. Le champ nSequence de l’entrée ne doit pas non plus prendre la valeur finale qui neutraliserait le contrôle. Il s’agit d’une limite absolue, pas de l’âge relatif d’une sortie depuis sa confirmation. La respecter ne garantit pas une inclusion à la seconde près : un mineur doit encore inclure la transaction dans un bloc valide. [2]
Une transaction diffusée peut rester dans le mempool, l’ensemble des transactions non confirmées conservées par un nœud. Si les frais augmentent, son expéditeur peut vouloir proposer davantage avec une transaction de remplacement. David A. Harding et Peter Todd ont décrit les règles initiales de remplacement opt-in dans BIP 125. Le caractère remplaçable pouvait être signalé par nSequence ou hérité d’une transaction ancêtre non confirmée dont le paiement dépense une sortie. Les dépendances entre transactions comptaient donc aussi. Augmenter les frais peut aider, sans garantir une confirmation immédiate. [3]
Remplacer une transaction dans le mempool change le candidat qu’un nœud conserve en vue d’une confirmation. Cela ne réécrit pas l’historique confirmé. BIP 125 décrit également une politique historique opt-in, pas une règle immuable pour tous les logiciels. Des versions ultérieures de Bitcoin Core ont fait du remplacement sans ce signal le comportement standard, tout en conservant des conditions d’acceptation. Pour le destinataire, l’absence de signal ne prouve donc pas que le paiement est définitif. De même, « envoyé » dans un portefeuille ne signifie pas « inclus dans un bloc confirmé ». [3] [6]
Revenons au contrat. OpenTimestamps produit une preuve vérifiable que des données précises existaient avant une limite temporelle attestée. Il utilise un hash, une courte empreinte numérique du contenu, et une preuve ancrée dans Bitcoin. Modifier le document donne une empreinte différente lors de la vérification. L’horodatage ne prouve cependant ni l’identité de l’auteur, ni la véracité du contenu, ni l’instant exact de création. Un récit faux peut lui aussi être horodaté à temps. La preuve limite le moment le plus tardif où les données ont pu être créées ; elle ne dit pas depuis combien de temps elles existaient. [1] [4]
Le client OpenTimestamps n’envoie pas le document aux serveurs de calendrier. Il traite son empreinte avec une valeur aléatoire afin que le serveur ne puisse pas déduire le contenu de ce qu’il reçoit. Un calendrier désigne ici un service qui rassemble les demandes et aide à les ancrer dans Bitcoin. Protéger le contenu ne garantit pas un anonymat complet : la proximité dans le temps ou des preuves produites ensemble peuvent révéler des liens. Le fichier .ots n’est pas une sauvegarde du document. Conservez-le avec l’original exact ; une empreinte ne reconstitue pas un texte perdu, et une copie modifiée représente d’autres données. [5]
Un nouvel horodatage peut ne pas encore être ancré dans un bloc confirmé. Posséder un fichier .ots ne suffit donc pas à établir que le processus est terminé. Le client OpenTimestamps distingue la preuve en attente du justificatif complet, qui contient le chemin jusqu’au bloc. La commande ots upgrade peut récupérer et enregistrer le complément lorsqu’il est disponible ; elle ne force pas la production d’un bloc. Il faut ensuite vérifier la preuve avec les données originales et la chaîne Bitcoin. Comme pour un paiement en attente, l’état réel compte davantage que l’apparition d’un fichier ou d’un message. [5]
Pour une vision complète, lisez aussi Luke Dashjr, Mara van der Laan, Satoshi Nakamoto. Cette entrée est également citée par Luke Dashjr, Mara van der Laan.