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
L’heure blockchain est justement une avancé énorme, qui tend a s’approcher de l’heure humaine, tout en étant vérifiable. Quiconque essai de changer l’heure de la G1 verras que ce n’est pas si simple. Je t’invite d’ailleurs a le faire.
Se priver de cet horadatage des documents me paraît dommage.
Attention toi tu parles de l’heure dans l’historique des comptes (date de valeur), ce qui n’est pas l’unique besoin.
Le fait de savoir l’heure du document est en soi intéressant (la date d’émission) et peut répondre a des besoins de traçabilité et d’ancrage dans la réalité (dans le temps humain).
Déconnecté du temps humain, des machines pourraient tout aussi bien générer des transactions valides a l’avance, non ?
Une sorte de spam.
Je ne sais pas si cela a un intérêt, pour une attaqué par exemple, mais je vois bien que le hash nous en prémuni.
Tu va me dire qu’il y a d’autres moyens de s’en prémunir, sans doute. Mais est-ce plus simple que le hash ?
Tu as donc bien des documents dans la piscine qui sont potentiellement dans le futur (vis a vis de ton head), ou pas ? Même légèrement dans le futur.
Irais tu jusqu’à dire que le fait de savoir comment seront traités les documents estampillés dans le futur (s’il y en a), n’a rien a voir avec ta proposition (plus haut) de ne pas accepter en piscine les documents du futur ?
On frôle le n’importe quoi… Tu n’as pas l’impression que j’ai déjà réalisé un mécanisme de rollback quelque part ? Et qui est production depuis bien longtemps, d’ailleurs…
Je ne vois pas (je me répète) l’urgence de planifier quelque protocole V12 ou V40, alors on a peine réfléchi aux impacts.
Je ne suis pas contre ta proposition, mais je veux savoir où l’on met les pieds, en se deconnectant du temps blockchain pour la signature d’une TX .
Je penses qu’on pourrait aussi expérimenté un temps sur une monnaie de test, et voir les attaques possibles.
Avoir une position d’attaquant me semble préférable, pour débusquer tous les problèmes.
On ne s’en prive pas, le blockNumber tout comme le blocID sont unique, et les deux pointent sur un temps blockchain. La différence est bien que le blocID est valide uniquement sur une chaine. On ne perd pas l’horodatage.
Tout à fait, ça ouvre de nouvelles possibilités, contrat, scripting.
Oui effectivement, comme toute fonctionnalité on pourra alors en abusé, mais là on entre dans les problématique des noeuds. Chaque noeuds est libre de refuser un noeud spammeur, ou de refuser des TX dans le futur qui encombrerai leur mempool.
Ca ne doit pas, je pense, etre dans le protocol, les inconvénients liés me semble trop lourd, je renvois à ma problématique pour duniterdice. La gestion du replay des TX valide est un pur casse-tête, et je dois antidaté les TX en dehors de la fenetre de fork, pour limiter l’impact, j’antidate donc les chèques, car sur duniter des transactions valides ne sont pas rejouable en cas de fork.
Et je le vois comme un bug et non une feature à titre personnel.
On peut simplifier le protocol, et déscendre la problématique sur les noeuds.
Le spam vient naturellement comme argument, car c’est une problématique réseau et non protocolaire.
Chaque noeud peut choisir sa politique de filtrage et/ou de diffusion.
Je parlais bien entendu de l’aspect, diffusion des TX sur le réseu, et de la probléatique du spam. bitcoin fort de son réseau et de son succès expérimente largement le spam au niveau réseau. Et s’en sort sans cette contrainte forte. C’était mon point ici, désolé si c’était pas clair.
Pour le reste je pense etre libre de choisir mes monnaies qui n’ont rien d’exclusif.
Peace
EDIT: si on veut creuser et s’intéresser sur ce qui se fait ailleurs, la problématique est bien décendu sur les noeuds pour bitcoin, la mempool est bridée (par défaut) en capacité de stockage, les TX ne remplissant pas les condition minimal de fees, ne sont pas relayées, etc… etc… autant de leviers qu’on les noeuds pour se défendre en milieu hostile.
Je suis tout a fait d’accord, et c’est effectivement essentiel pour le rythme de création du DU par exemple. Mais je pense que ça n’est pas utile pour les transactions, en tout cas que ça apporte plus d’inconvénients que d’avantages dans le cas des transactions.
Oui en effet, pour moi c’est l’unique besoin.
Ça me semble un besoin très hypothétique et non réel, au détriment d’autres besoins exprimés par @Looarn qui eux ont ont intérêt réel immédiat et pas hypothétique.
Tout dépend ce que tu entend par “valides”, puisque du point de vue du protocole, la transaction ne sera valide que si elle pointe un numéro de bloc <= au bloc courant.
Je ne vois pas en quoi on devrait interdire la possibilité de générer maintenant des documents transaction qui ne seront valides que plus tard, certains y voient un cas d’usage, et je n’y vois pas de surface d’attaque possible, donc pourquoi l’interdire ?
En vue de la machinerie que demanderai le traitement correct des transactions sur toutes les branches de fork, oui les points que tu soulèvent me semblent plus simples à gérer
Non, a tout moment, tout les documents dans la piscine pointent bien un numéro de bloc inférieur ou égal au HEAD. Relis l’algo que je t’ai décrit plus haut et demande toi a chaque étape s’il est possible d’avoir ce que tu décrit, tu verra que c’est impossible.
La proposition discutée ici ne modifie pas la façon de traiter les transactions qui pointent un numéro de bloc dans le futur. C’est refusé actuellement, et ce sera toujours refusé de la même façon.
Le traitement des transactions qui pointent un numéro dans le futur n’est pas impacté par la proposition, c’est pourquoi il me semble effectivement que ce n’est pas dans le sujet.
C’est seulement les transactions qui pointent un numéro de bloc dans le passé ou le présent qui vont être traités différemment, dans le sens ou ces transactions là seront acceptés même si le hash indiqué n’existe pas.
Je suppose que tu parle des noeuds Cesium+, et bien soit le fonctionnel est légèrement différent, soit tu est parti sur des choix algorithmiques qui te font dépendre du datage des documents, du coup tu voit un problème là ou il n’y en a pas car tu te réfère a la façon dont tu a fait dans Cesium+.
Mais surtout, le problème que tu soulève dans le rollback ne concerne que les documents qui pointent un numéro de bloc supérieur au HEAD, or le traitement de ces documents n’est pas impacté par la proposition discutée. Donc le problème que tu soulève existerai déjà si les rollback étaient géré comme tu le pense dans les serveurs blockchain. C’est un problème qui me semble totalement indépendant de l’application ou non de la proposition de Looarn, d’où le fait que je l’ai qualifié de hors-sujet.
Je te rappelle @kimamila que nous nous sommes fortement inspiré du bitcoin pour la conception du protocole DUBP, notamment pour la gestion des sources.
Notre communauté technique est trop isolée des autres cryptos, qui ont pourtant beaucoup a nous apporter techniquement. C’est justement parce que @nanocryk baigne dans beaucoup d’autres cryptos qu’il nous a apporté beaucoup d’idées importantes pour le futur du protocole dont certaines seront implémentés par @cgeek et moi dans le futur.
Ta réaction fait sectaire @kimamila. A te lire, on a l’impression qu’il faudrait choisir entre la G1 ou les autres cryptos.
A choisir, je préfère être sec et inclusif plutôt que d’inviter avec bienveillance à aller voir ailleurs…
Mon point n’était pas clair, bitcoin étant à la fois le protocole et le nom de la monnaie, ça pouvait faire provocateur.
Dans mon cas, je connais Bitcoin avant Duniter, et je trouve dans la june ce qui manque dans bitcoin, l’égalité, c’est un tout autre débat non technique et hors-sujet pour le coup. ^^
Et en quoi en poser la question comme je l’ai fait te pose problème ?
Si tu ne veux pas perdre de temps s’il te plaît soit logique et arrête de répondre a ce qui te paraît inutile, comme plusieurs ici le font déjà.
C’est plus efficace et moins blessant, surtout l’auteur du post est déjà investi dans les développement.
Cesium+ rejoind la branche du noeud, et se laisse guider par lui. Le noeud peut tout aussi bien choisir un head < head précédent. Ça n’est pas son problème, car comme tu le dis ce n’est qu’une histoire d’algo, et non de protocole.
Irais tu jusqu’à dire que la résolution du fork est une question de protocole ? Ou bien est-ce un choix d’implémentation de chaque noeud ?
Par exemple, qu’est-ce qui empêche quelqu’un de coder une résolution de fork vers la branche majoritaire, même si la sienne est avance ?
Ces questions de traitement des TX dans le futur me semble lié a des choix d’implémentation des noeuds, tandis que le hash est une protection de niveau protocole (plus forte). Tu me demandes d’avoir confiance dans ton algo, mais moi je préfères d’abord analyser la question au niveau du protocole. Si l’émission de blocs dans le futur devient “utile” pour des personnes comme tu le dis, alors il est inévitable que certains accepteront ces documents dans leur piscine un jour ou l’autre. Ne serais que les leur.
Je crains que ce dernier point ne soit pas clair ici.
N’est il pas préférable de dire “enlever le hash autorisera les TX dans le futur” et l’assumer, plutôt que de laisser croire que non, on bloquera le truc parce qu’on le fait déjà, etc
Nous avions ajouter une durée de validité et un délai entre deux écritures de certification, pour éviter le “braquage des certifications” (la génération à un instant t de plusieurs documents validés).
Aussi, ne peut-il exister un braquage a la signature de TX ? Sans le hash, il est très simple de générer tous les virements des DU d’un coup, puis de distribuer au réseau au fur et a mesure.
Je penses notamment au système de signature Crypto par puce, avec code.
Cela existe maintenant pour plusieurs cryptos.
Du coup, même sans la clé secrète, il est possible de signer un document…
Sur la discussion vis a vis des autres cryptos qui “le font déjà”, ne pas oublier aussi que leur sources de nouvelle monnaie ne sont elle prédictive. Il n’est donc pas possible de construire un document validé dans le futur (qu’il reste à signer) concernant ces nouvelles sources.
Avec le G1, c’est donc très différent, il y a moins d’aléatoire sur l’origine monétaire. D’où des attaques a la signature de TX simplifiée.
Autre idée :
Nous pourrions générer des TX referencant le [Head - 100 blocs] avec une condition output bloquant les fond jusqu’à HEAD.
Il suffit que le logiciel client analyse cette condition pour rétablir la date de valeur a HEAD, plutôt que HEAD-100.
J’espère que ce tableau aidera tout le monde à poser les avantages et inconvénients, et à réfléchir ensemble, dans une réalisation collective.
Je vais essayer de passer ce message en wiki éditable par les intéressés, à déplacer ailleurs si c’est plus pratique.
).
