Voila. Merci !
C’est bien la date de signature (ou date d’émission) vérifiable que nous perdons comme fonctionnalité, avec le hash.
C’est l’équivalent de la date de nos chèques, que l’acheteur peut vérifier dès réception.
Si l’émetteur mettais une date rendant le chèque invalide (par exemple à T - 1 ans), l’acheteur le verrai aussitôt, et refuserai le chèque.
Oui, pourquoi pas. Il s’agit cette fois de la “date de validité” (ou d’écriture). Cela me semble néanmoins complémentaire de la date d’émission du paiement. Cela dit, la date de validité me parait plus importante pour l’utilisateur final (c’est elle qui apparaît dans nos relevés de comptes). La date d’émission sert pourla période de validité, comme dit plus haut, ou éventuellement en cas de litige, pour confirmer à peu près la date de signature. Ce “à peu près” peut effectivement être porté le blockNumber (sans le hash) : une référence grossière au temps. ok.
Tu me demandes en quoi une date liée à une heure blockchain est plus vérifiable qu’un simple numéro de bloc, dans un document de paiement ?
En quoi selon toi un chèque a t’il besoin d’avoir une date écrite dessus ? Je t’invite à signer des chèques sans mettre de date, et à laisser le destinataire le faire, puisque cela ne te parait pas un “besoin utilisateur”. Pas de problème.
Il me semble important d’analyser les usages actuels de notre économie, avant d’en proposer de nouveaux. Désolé si cela t’agace. Je n’en fais pas exprès. Je suis juste prudent.
J’essayais de voir les autres conséquences et avantages de TX émises lié à un numéro de bloc dans le futur : l’intérêt pourrait être de faire une paiement reporter (comme les chèques à encaisser “en fin de mois”). Mais comme je le dit l’intêret de ce point de vue est limité, vis à vis des outputs conditions.
Je réfléchissais tout haut, pour éluder cette partie là des “avantages”.
Non, je ne crois pas avoir mélanger les deux concepts. Cela dépends de comment est codé le rollback, dans le cas où l’on décide de supprimer la référence au blockHash dans les TX.
Soit un noeud qui peut rollbacker jusqu’à 100 blocs pour résoudre un fork. Ce noeud se trouve sur une branche B. L’origine du fork est tout juste à la limite, à dire à B-100 blocs.
Imaginons que ce noeud rollback de 100 blocs, pour rejoindre la branche majoritaire A.
Pour ma part, je coderai la fonction de rollback de manière récursive : en rollbackant jusqu’à B-100, le noeud ressortirai les documents qui sont inscrit dans sa branche B, jusqu’au point de fork, puis repartirai sur la branche A (ce qui peut lui prendre du temps, en téléchargement puis vérification de règles). A un moment, dans sa piscine, il aura donc des documents à (B-100 + 100), non ? C’est à dire des documents dans le futurs (de son point de vue à un instant t), mais pour autant valide (pour le temps humain et pour la branche A)
Je trouve cela dommage de supprimer ces documents (ceux uniquement présent dans sa branche B) dans la mesure où il seraient aussi valide pour la branche A, dans les prochains blocs.
Le même cas de figure (plus simple sans doute) s’appliquerai à une noeud qui a été éteind, et à donc du retard à ratraper. Il recoit des documents du futur dans sa piscine, mais pour autant valides.
Où est le hors sujet, donc ?