Je suis d’accord avec les avantages que vous citez.
J’essaye de décrire le cas que je vois problématique pour que ce soit plus clair pour moi. Si sur une des deux branches la première transaction tx1 n’entre pas la blockchain pour une raison x, alors si la seconde transaction utilise les mêmes sources que tx1, alors tx2 ne passera pas. Au final, une des deux branche vainquera et ça se résoudra en un des deux états. Du coup, c’est pas lié aux branches, ça peut arriver sur une mono-branche ce problème. Donc, c’est bon pour moi.
Est-ce qu’on ferait la même chose pour les autres documents utilisateurs : certification, adhésion, identité et révocation ?
Je ne suis pas sûr de comprendre…
Si les sources #3 et #3’ étaient issues d’un DU, et que la Tx3 en avait besoin pour atteindre le montant escompté, nous sommes d’accord que ces 2 sources porteraient des identifiants différents ? Il faudrait donc bien émettre 2 TX, comme sur le schéma ?
En d’autres termes vous proposer de supprimer le lien fort avec le bloc, mais il y aura toujours un lien fort avec les sources, non ?
En supprimer un ne résoudra pas mon problème.
Ce cas ne peut arriver qu’en cas de mauvaise synchro des piscines. Il faut que le nœud qui forge le 1er block de la branche alternative n’est pas tx1 en mempool. Il suffit qu’un seul des nœuds sur la branche alternative est tx1 dans sa mempool pour que tx1 soit également inscrite sur la branche alternative.
Or, comme tx1 aura le même hash sur les 2 branches, tx2 pourra s’inscrire également sur les 2 branches.
Pour qu’une des 2 branches ne comporte pas du tout tx1 (et donc pas tx2 non plus), il faut que tous les nœud d’une des branches n’est pas tx1 dans leur mempool, cela n’est possible que si les nœuds de cette banche sont très minoritaires.
Dit autrement, en cas de fork, la branche gagnante est forcément majoritaire (sinon elle ne “gagne” pas), et donc il y a forcément au moins 1 nœud sur cette branche majoritaire qui a reçu tx1, sauf bug ou cas de force majeure sur le réseau (coupure de tout un pan d’internet).
la révocation n’est pas concernée car pas blockstampée. Pour les autres documents wot, oui on peut mais c’est moins prioritaire et surtout je ne proposerai que des changements que je suis moi même capable d’implémenter dans Duniter, donc je proposerai le minimum syndical (transactions uniquement).
Pas forcément. l’identifiant d’une source de Type DU c’est PUBKEY:BLOCK_NUMBER. Donc si les 2 branches ont on bloc de création du DU de même numéro c’est bon.
Il faudrait que les 2 branches prennent des rythmes de blocs très différents pour passer l’heure de création du DU a des numéros de bloc différents, 99% des fork étant court (moins de 3 blocs) c’est peu probable en pratique.
De plus, il est rare qu’une transaction consomme le dernier DU tout juste créé, il serait même possible du coté des clients de favoriser la consommation de DU ancien pour rendre ce cas rare encore plus rare.
On passe d’une situation ou il faut 2 tx dans 100% des cas (car les hashs des blocs des 2 branches sont forcément différents ne serait-ce que par variation de l’issuer) à une situation qui ne nécessiterai 2 tx que dans 0,01 % des cas, et encore.
La proposition de @Looarn résout donc ton problème dans au moins 99,99% des cas, ça me semble suffisamment acceptable pour ne pas traiter le cas a la marge de consommation du dernier DU (Quitte a modifier l’algo de sélection des sources coté client pour prioriser le choix des DU les plus anciens).
Pour le problème précis de kimamila, il me semble qu’une solution rapide et simple consiste à se reposer sur de « vieux » blocs, non seulement pour le problème du blockstamp de la transaction mais aussi le n° des sources de DU.
En effet les transactions peuvent se baser sur n’importe quelle autre (chaînage), indépendamment de la branche. Sauf pour le blockstamp, qui ne sert que pour de la mise au rebut de trop vieilles transactions.
Exactement, je me souviens avoir proposé cette solution aux rml13 déjà, il suffirait que les clients blockstamp leur transactions à 100 blocs de retard (valeur de rollback maximal). Mais @kimamila ne voulais pas le faire car il se base sur le blockstamp des transactions pour indiquer leurs dates d’émissions sur l’interface utilisateur.
Ma proposition consiste en le minimum syndical pour éviter les régressions : le format des transaction reste identique et il n’y a rien a changer coté client. Simplement, lors de la validation globale, les noeuds duniter ne vérifieront plus le hash pointé par la tx, c’est tout
Dans la pratique, modifier le code de la validation globale ne suffira pas, il faudra aussi supprimer le contrôle dans le code de génération du prochain block (et peut-être aussi dans le code qui réinjecte en mempool les transactions lors d’un rollback), mais ces portions de code ne sont pas régies par la RFC du protocole.
Si possible, j’aimerai garder une référence au temps.
Par ailleurs, j’ai plus souvent qu’on le croit le problème d’usage des toutes dernières sources (même <100 blocs). Et j’aurais aimé trouver une solution globale…
Avec juste le blockNumber sans le hash, dans la TX, ne me plaît gère. Ça permettra d’emettre des TX dans le futur, ce qui n’a aucun sens a mon avis.
Enlever le hash me paraît une perte de fonctionnalité.
Une solution que je propose est de pouvoir indiquer plusieurs blockstamp, dans la TX.
Si au moins un blockstamp est valide, alors le noeud l’accepte.
Ainsi, les TX dans le futur sont impossible, et une TX peut être émises et acceptées par plusieurs blocs.
Le numéro de bloc suffit a donner une référence au temps. On peut faire en sorte que GVA donne automatiquement le blockchainTime du numéro de block correspondant.
La solution de @Looarn est déjà globale pour les UTXOS, quand aux sources de type DU comme il n’en est créée qu’une tout les 288 blocs tu en aura au plus une seule dans les forkWindowSize derniers blocs.
Aujourd’hui tu a souvent les dernières sources car l’algo de selection des sources prend les 1ères qu’il trouve, il suffit de modifier l’algo de sélection des sources.
Non comme je l’ai indiqué plus haut il ne sera pas possible d’émettre des TX dans le futur. Si un noeud à pour bloc courant le 512 et qu’il reçoit une transaction indiquant pour bloc courant 514 celle ci sera refusée comme actuelle. La présence ou non de la contrainte sur le hash n’y change rien.
En quoi est ce une perte de fonctionnalité ? J’ai l’impression en vue de ton dernier message que tu n’a pas tout lu car tu fait des remarques qui déjà été démenties.
Trop lourd, ça ne respecte pas le principe KISS, je suis vraiment opposé a une telle idée surtout que je n’ai toujours pas entendu d’objection pertinente au retrait de la contrainte sur le hash.
Pour la référence au temps, il faut voir à quoi elle te sert. Selon le cas le temps blockchain peut être intéressant ou pas, faut voir.
Concernant le problème d’usage des toutes dernières sources j’ai déjà réfléchi au problème et je pense avoir une solution telle que les clients n’auraient même plus à se soucier de cela.
Enfin pour la TX dans le futur, tu as bien évidemment raison : il est impossible de forger une telle transaction si le hash est requis, tandis que c’est possible sans. Là-dessus c’est bel et bien une perte de fonctionnalité (mais aussi la création d’une ou plusieurs autres).
Mais à la limite, ça regarde chaque nœud de gérer ces transactions comme ils l’entend. Certains les refuseront (position que défend Eloïs), d’autres les accepteront (position qui me paraît aussi défendable car elle peut avoir son intérêt). Toutefois le protocole garantira qu’une TX dans le futur est forcément en attente de parution du n° de bloc visé.
Il me semble que pour @kimamila la référence au temps sert a indiquer la date et l’heure d’émission des transactions dans l’historique des transactions d’un compte. Cette date et heure ne peuvent pas être positionnées dans le futur pour les transactions en blockchain.
Concernant les transactions en mempool, je considère qu’il n’y a pas lieu qu’il y en ai non plus, en tout les cas Dunitrust ne le permettra pas, et Duniter ne le permet pas aujourd’hui, si j’implémente ma proposition dans Duniter, je ferai en sorte qu’il ne le permette pas. Libre a cgeek ou d’autres dev de Duniter d’autoriser un tel cas, mais je pense que la pratique restera marginale et ne faussera donc que très rarement la date et heure affichée dans l’historique des transactions et uniquement pour les transactions en attente de toute façon.
De plus, rien ne t’empêche @kimamila de borner l’affichage au temps ajusté du bloc courant, de sorte que l’utilisateur final ne verra jamais une date dans le futur.
Il conviens de peser le pour et le contre de chaque proposition pour l’utilisateur.
Conserver l’état actuel
Transactions perdue en cas de fork (ce qui arrive très fréquemment)
Impossibilité de générer un document transaction qui pointe un bloc futur (ce qui n’apporte rien a l’utilisateur final)
Remplacer le check du blockstamp par le check du blockNumber
Transactions correctement traités en cas de fork (acceptées sur toutes les branches, sauf dans le cas très marginal de consommation du dernier DU, qui viens d’être créé dans le fork en cours et avec un bloc du dividende à numéro différent dans les 2 branches).
Possibilité de générer un document transaction qui pointe un bloc futur (ce qui n’impacte en rien l’utilisateur final comme montré plus haut).
La vrai question @kimamila c’est : existe t’il au moins un besoin des utilisateurs de Cesium qu’apporte le contrôle du blockstamp des transactions et qui ne peut pas être apporté autrement ?
Si un tel besoin n’existe pas (ce que je pense), alors il me semble irrationnel de vouloir conserver le contrôle du blockstamp des transactions
Cher @elois, j’ai le sentiment qu’il ne faut pas se précipiter a retirer le hash.
C’est actuellement la seule référence au temps vérifiable. Si on garde juste le blockNumber, alors autant tout retirer car cela ne veut plus rien dire du tout.
Or, qu’essayons de bâtir ? Une économie réelle, basée sur un temps humains. Les vrais gens ne font pas de transaction dans le futur.
Certes, cela peut arriver qu’on demande a encaissé seulement a la fin du mois, mais justement de le fait de déposer directement le paiement avec une condition (output) de déblocage me paraît mieux que le système actuel, vis a vis du vendeur. Car la monnaie est comme « mise en gage ».
Tu dis que tu ne garderas pas les TX dans le futur, mais tu seras bien obligé, ne serait-ce que sur les dernier blocs N+100, on est d’accord ?
Bon, après je vois bien aussi tous les avantages de la solution de @Looarn. Notamment, on pourra faire des paiements chainés, même hors connexion, et ça s’est plutôt cool.
C’est pas tellement plus vrai qu’avec le hash, car il faut quand même connaître le numéro “a peu près courant” de la blockchain pour que la transaction soit acceptée.
Et puis je crois qu’il exite toujours la péremption au bout de 7 jours d’une transaction. Donc le n° de bloc ne peut pas être pris totalement au hasard.
Enfin concernant la référence en tant que date, pourquoi ne pas plutôt prendre la date du bloc qui inclut la transaction ? Si l’on considère que les transactions sont en moyenne intégrées quelques minutes après leur émission, alors cette date est suffisante. Non ?
Cher @kimamila, on ne se précipite pas, ça fait plus de 6 mois que l’idée a été émise. J’ai le sentiment que tu t’accroche irrationnellement a la vérification d’un hash qui apporte plus d 'inconvénients que d’avantages.
En quoi est ce plus vérifiable ? Mais surtout, qu’apporterais cette vérifiabilité supplémentaire supposée ? Dans le sens, a quel besoin répond elle ?
Je n’ai jamais dit le contraire, et ça me semble hors-sujet, en quoi cela défend t’il un besoin de garder le hash ?
Non on n’est pas d’accord, les conditions d’acceptation d’un document en mempool n’ont pas de rapport avec le rollback maximum, il me semble que tu mélange ici des aspects indépendants.
Oui cette péremption au bout de 7 jours (txWindow) sera conservée.
Oui c’est en effet ce qui peut être fait pour les transactions inscrites en blockchain.
C’est pas vraiment ce que je constate, kimamila t’as déjà répondu que le hash est une perte de fonctionnalité selon lui notamment car il s’agit du seul temps vérifiable.
Le hash permet de dire « cette transaction a été émise avant telle date » de façon certaine, qui par ailleurs combiné à la règle de 7 jours de validité donne un intervalle certain d’émission. Ce qui n’est plus possible sans celui-ci, on perd une de ces deux bornes.
Côté utilité, on peut regarder du côté des documents de WoT là où cette donnée a été explicitement voulue, par exemple les certifications : ce bornage par le hash empêche formellement la constitution d’un stock. Cela protège l’utilisateur de lui-même en limitant sa capacité de certification dans un intervalle de temps donné car une fois émise une certification est incontrôlable.
A priori je ne vois pas de cas similaire pour les transactions. Mais ça ne veut pas dire qu’il ne faut pas continuer à chercher, car une fois cette fonction perdue il existera un précédent.
Le bébé, l’eau du bain, tout ça. Et restons bienveillants.
Le contrôle du hash assure seulement de l’impossibilité de générer un document qui pointe un bloc qui n’existe pas encore, c’est bien ce que j’avais répondu a @Looarn il y a 6 mois, et après avoir tourner la question en long en large et en travers, je ne vois aucune raison d’assurer cette impossibilité.
D’ailleurs, il est déjà possible de générer un document dans le passé, et ça ne semble gêner personne
Le sujet ici se sont les transactions,restons dans le sujet svp afin de ne pas s’égarer. Concernant les documents de la wot, vous pouvez ouvrir un autre fils
J’estime justement qu’on a suffisamment cherché, surtout que cela est pratiqué dans les autres crypto rependues tel que bitcoin et que ça n’a jamais posé de problèmes connus.
Merci @cgeek de faire remarquer qu’on pert effectivement la contrainte forte qui rend impossible la diffusion de TX du futur. Et de pointer que c’est un grave handicap pour tout ce qui est question de scripting, exemple, je souhaite qu’à ma mort toutes mes junes soit envoyé au compte des developpeurs, j’ai un petit script qui est pret à envoyer la dite transaction que j’aurai pris soin d’intégrer à mon testament, elle n’attend qu’à etre émise sur le réseau.
Et là c’est le role des noeuds à mon sens et pas le role du protocole, de diffuser ou non la dite transaction, qui est à prioris valide (block hash exclu).
Tout a fait d’accord.
Ensuite il y a globalement dans l’implementation beaucoup de contrainte, la fenetre de fork, la règle des 6 jours, qui limite déjà grandement les risques de « fraude » (à voir si c’est bien de la fraude, au noeud de décider à prioris ).
Rajouter ce hash, qui complique beaucoup de chose derrière, c’est ne pas se simplifier la vie.
J’en parle sur ce forum depuis plus d’un an, alors pas de souci pour que ça prenne le temps que ce doit, mais j’appuis sur le fait que c’est structurant, et que ça fera gagner un temps fou sur le long terme.
PS : Je suis très heureux de voir plusieurs cerveaux se pencher sur cette question. C’est nécéssaire et bienvenu.
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.
En fait, je te demandais plutôt en quoi la date d’émission d’un document est plus vérifiable selon qu’il pointe un blockNumber ou un blockstamp ?
Dans les 2 cas, on n’a aucune idée de la date et heure réelle de génération du document. La seule certitude en plus le cas du blockstamp, c’est que le document ne peut pas pointer un bloc qui n’existait pas encore lors de sa création, mais ça ne nous donne pas de certitude supplémentaire sur la réelle date de génération du document, ça empêche juste la création de transactions pointant une date future. Mais comme je l’ai expliqué plusieurs fois dans mes précédents post, il y a d’autres moyens d’empêcher qu’une transaction pointe une date future.
Tu déforme mes propos, je n’ai jamais dit qu’indiquer l’heure des transactions dans l’historique d’un compte n’était pas un besoin utilisateur, c’est même tout le contraire, puisque je t’ai expliqué comment on peut couvrir ce besoin sans la contrainte du hash.
Et bien les usages actuels vont plutôt dans mon sens, puisqu’on peut mettre une date future sur un chèque, c’est même plutôt courant chez les gens qui ont peut de moyens et qui font un chèque daté du mois d’après par exemple, et c’est généralement accepté (ça a toujours été le cas dans mon vécu en tout cas).
En fait non, ce n’est pas comme cela que ce déroule la résolution des fork dans Duniter ni dans Dunitrust.
Prenons un exemple avec deux chaines ayant pour head A303 et B100 :
Le nœud Duniter/Dunitrust est a un bloc courant B300
Il prend connaissance petits a petit des blocs de la chaine 1 mais reste sur B tant que les conditions pour rollback ne sont pas réunies.
Au moment précis on les conditions permettant de rollback sont réunies, le nœud Duniter/Dunitrust à déjà connaissance de l’intégralité de la chaine A (bien qu’il n’est pas fait la verif globale dessus). Il n’y a donc aucun téléchargement pendant un rollback.
Une fois la décision de rollback, le rollback commence, mais le HEAD du nœud reste B300.
La nouvelle chaine est empilée, et si un seul bloc de la nouvelle chaine est invalide, toute la procédure est annulée et le nœud reste sur B300.
Si et seulement si la nouvelle chaine est intégralement valide, le nœud change de HEAD et passe à A 303.
ben ils ne sont pas supprimés justement, en cas de rollback tout les documents des blocs revert sont réinjectés en mempool, c’est déjà le comportement existant, et il n’est pas prévu d’en changer.
C’est déjà le cas actuellement, et ça ne pose aucun problème. Une fois que le nœud a rattrapé son retard il synchronise sa mempool avec les autres nœuds. La encore, c’est hors-sujet.
En vue des débats que suscite cette proposition, je la supprime de la v12 du protocole, je ne l’implémenterai pas. Cela laisse donc plus de temps pour creuser la question comme le souhaite @kimamila
).