RFC GVA > TX compatible avec plusieurs branches

[elois]

@kimamila

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 ?

Oui, de mon point de vue les règles de résolution des fork devraient être protocolaires, je les présentent d’ailleurs dans ma présentation du protocole DUBP réalisée aux rml13
Il me semble important que les différents serveurs blockchain du réseau G1 respectent les mêmes règles de détermination de la branche “gagnante” sinon on peut se retrouver dans des fork systématiques qui ne pourrons pas se résoudront automatiquement et demanderons une action manuelle de la part des propriétaires de noeuds très régulièrement.

Je constate que beaucoup de propriétaires de noeuds (membres ou miroirs), les surveillent assez peu une fois qu’il semblent bien tourner, du coup si chaque implémentation résolvait le fork différemment beaucoup de membres ne surveillerait pas suffisamment leur noeuds et l’on aurait des instabilités réseau fortes et régulières.

@kimamila

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.

En effet.

@kimamila

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

Ce serait comme dire “les frais sur les transactions sont autorisés” car rien n’empêche un noeud de n’accepter dans sa mempool que des transactions qui reversent des frais a tel ou tel clé.
Hum… dire « enlever le hash autorisera les TX dans le futur » est donc en effet tout aussi vrai, de là a dire que ce soit souhaitable, je ne sais pas.

@kimamila

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.

Seulement des DU déjà perçues. Puisque les DU a venir on ne sais pas quel numéro de bloc vas les créer, le temps entre 2 bloc restant aléatoire même si l’algo de diff du réseau le fait pointer vers un temps cible moyen de 5min.

Mais ça me semble plus une feature qu’un braquage pour le coup

@kimamila

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…

Dsl je ne comprend pas le lien avec ce que tu dit juste au dessus, peut tu préciser ?

@kimamila

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.

Je suppose que tu voulais dire “ne sont pas prédictives” ? Les sources de la G1 ne sont elle aussi pas prédictives, quelle différence ?

@kimamila

Et la date de signature alors ?

On la retrouve a partir du blockNumber indiqué dans le document transaction. Oui du coup on peut mentir sur la date de signature de la tx, tout comme on peut le faire pour un chèque, et je pense que ce n’est pas gênant, ça me semble même préférable de pouvoir le faire

@kimamila

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.

Oui ça semble fonctionner, bien vu

[kimamila]

@elois

Oui, de mon point de vue les règles de résolution des fork devraient être protocolaires, je les présentent d’ailleurs dans ma présentation du protocole DUBP réalisée aux rml13
Il me semble important que les différents serveurs blockchain du réseau G1 respectent les mêmes règles de détermination de la branche « gagnante » sinon on peut se retrouver dans des fork systématiques qui ne pourrons pas se résoudront automatiquement et demanderons une action manuelle de la part des propriétaires de noeuds très régulièrement.

Franchement, je ne vois pas comment cela peut être protocolaire. La résolution est propre à chaque implémentation, qui peut etre potentiellement modifié par chaque propriétaire de noeud.
Je ne vois rien qui permet de controler ce que décide un noeud en interne.
Par exemple, un noeud peut très décider de faire avancer telle branche, parcequ’il a intéret à le faire.

Du coup, ce que tu dis sur l’implémentation des résolutions de fork, vis à vis des documents dans le futur, me semble bien hypothétique.
D’autant que tu reconnais (dans ton dernier post) qu’il est inévitable qu’un jour ou l’autre des gens acceptent les transactions dans le futur sur leur noeud.
Sans blockHash, le protocole ne pourra pas se prémunir contre le “mensonge sur la date de signature”, contrairement à ce que tu as dit plus haut (“il suffira d’exclure les TX dans le futuru de la mempool, etc.”).

Après, je ne dis pas que c’est grave ou pas. Je chercher juste à clarifier ces points précis. Sinon, impossible d’avancer ensemble dans la discussion.

@elois

Hum… dire « enlever le hash autorisera les TX dans le futur » est donc en effet tout aussi vrai, de là a dire que ce soit souhaitable, je ne sais pas.

Le protocole ne l’empechera pas (ou plus, car aujourd’hui c’est impossible), donc l’autorisera.
On s’en fou que ce soit souhaitable ou non, car c’est relatif à chacun. S’il s’avère qu’une attaque est possible la dessus, alors c’est souhaitable… pour l’attaquant Bref.

@elois

Seulement des DU déjà perçues. Puisque les DU a venir on ne sais pas quel numéro de bloc vas les créer, le temps entre 2 bloc restant aléatoire même si l’algo de diff du réseau le fait pointer vers un temps cible moyen de 5min.

Justement, les sources de DU sont bien prédictifs, puisque le numéro est déterminable a peu de chose près (un mouchoir de poche). Un algo très simple permet de calculer les quelques numéros qui a coup sur générèreront le DU. Ce n’est pas le cas des autres crypto, car leur sources dépendent du issuer qui a miner le bloc.

@elois

Je suppose que tu voulais dire « ne sont pas prédictives » ? Les sources de la G1 ne sont elle aussi pas prédictives, quelle différence ?

Ben si justement, la G1 est prédictive. Cela ne veut pas qu’on connait le numéro exact, mais on connait la fourchette de numéro.
Il est donc très simple de générer des TX de captation des DU à l’avance (en générant tous les numeros potentiels). Il reste alors à l’attaquant à faire signer le document, en exploitant une autre faille.

Les attaques utilisent très souvent de multiples failles. La prédiction des résultats de ces failles facilitent beaucoup les choses, tandis que l’aléatoire les complique.

Bah, je suis surement trop parano… alors d’autres me reprochent d’être trop laciste (ex: sur l’éhebergement de Cesium en ligne, etc.). Cependant je penses essentiellement à l’avenir, et conséquences long terme.

Un point qui pourrait me rassurer est :

• admettons que l’on supprime le blockHash dans les TX
• si nous trouvons une faille lié à l’émission de document dans le futur (spams, vols de DU, etc.)
• pourront nous facilement réactiver le blocHash ?

Une autre solution étant que les deux soit autorisés (avec ou sans). Cela permet de garder l’usage d’un document signé avec une date vérifiable, mais pas de manière obligatoire.
Ca me parait simple, non ?

Plutôt que d’enlever une feature potentiellement utile (date de signature vérifiable) contre une autre (TX compatible multi-branche). On en ajoute simplement une.

[kimamila]

@kimamila

Une autre solution étant que les deux soit autorisés (avec ou sans). Cela permet de garder l’usage d’un document signé avec une date vérifiable, mais pas de manière obligatoire.
Ca me parait simple, non ?

Plutôt que d’enlever une feature potentiellement utile (date de signature vérifiable) contre une autre (TX compatible multi-branche). On en ajoute simplement une.

Ca me fait penser aux outputs conditions: elle sont quasiment optionnelles (SIG étant le minimum) et cela n’a dérangé personne.

L’important pour moi est de savoir ce qu’en penses @cgeek, pour Duniter ?
En deuxième lieu (car pas encore concernés par la production) @elois, pour DunitRust ? et @Junidev pour Juniter ?
@Moul, @inso, etc. pour les clients.

Est-ce que cette solution te conviendrait à toi aussi, @Looarn ?

[Moul]

D’un point de vue client, je vois pas bien comment le hash du bloc te permet d’avoir la date d’envoi du document en mempool. Selon moi la date du bloc est suffisante pour afficher l’historique des transactions, c’est imprécis, mais Silkaj fait avec. Ça correspond à la date d’entrée de la tx en chaîne, à la génération du bloc, pas quand elle a été émise sur le réseau. Comment fais-tu pour déterminer la date de réception/émission d’une tx à partir du hash de bloc ? Elle ne peut être que dans les logs du nœud qui a généré une ligne de log à la réception de la tx.
Y’a surement quelque chose que j’ai pas compris dans votre discussion, je veux bien des éclaircissements.

[kimamila]

Je n’ai jamais parlé de la date de réception par le noeud. cf ce post :

• date de signature = TX.blockstamp (blockNumber + blockHash)
• date de valeur (ou d’écriture) = Block.medianTime

Sans le blockHash dans la TX, cela devient :

• date de signature = TX.blockNumber (non vérifiable; moins précis; peut être dans le futur, y compris porter sur des sources de DU non encore générés)
• date de valeur = Block.medianTime (inchangé)

[Moul]

Merci pour la précision. Je comprends mieux la discussion.
J’avais compris à tort que le hash servait à avoir la date d’émission de la tx. Or, c’est pas le sujet.
Je comprends pas encore très bien ton point.
Je ne vois pas ce qui pourrait poser problème dans l’enlèvement du hash de bloc dans la tx.
J’ai besoin d’y penser à tête reposée pour me forger un avis et/ou relire la discussion.

[Looarn]

@kimamila

Est-ce que cette solution te conviendrait à toi aussi, @Looarn ?

Ca pourrait etre le bon compromis.

De façon pragmatique si le hash est optionnel, ça me facilite la vie, et je n’ai plus a craindre des forks, donc oui ça marche.

Mon coté “smallblockiste” considère que l’espace dans les blocs est précieux et qu’il ne faut pas le gacher, aussi ajouter un champ qui fait à mon sens doublon (BlockNumber = déclaratif de à partir de quand la TX est valide (de currentBlock - 6 jours à endOfTimes) et blockID = à partir de quand la tx est valide de currentBlock - 6 jours à currentBlock)

La complexité est déscendu sur les noeuds (rien d’insurmontable, mais ça induit un peu de complexité).

Finalement pour le marchand, la date qui fait fois et qui est importante est la date de réception du paiement et non sa date d’emission.
En tant que client, la date d’emission pourrait etre une donnée lié au compte utilisateur et non une donnée blockchain.

Mais possiblement je vais trop loin là.

[kimamila]

Avec le dernier fork, je crois qu’il devient important de statuer sur l’avenir des TX multi-branches…

Concernant la suppression du hash du bloc dans le document TX, le point négatif important selon moi est l’écriture possible de TX dans le futur, avec le risque de s’accaparer les DU futurs (par exemple par braquage), car les numéros de blocs (sans le hash) sont prédictifs (à un delta près).

Une solution simple serait de consommer les DU en indiquant le blockstamp plutot que le numéro du bloc :
AMOUNT:BASE:D:PUBLIC_KEY:BLOCKSTAMP (BLOCKSTAMP au lieu BLOCK_ID)

On garderait ainsi tous les avantages de la suppression du blockHash au niveau global de la TX, sans le problème de consommation futur des DU.
Le risque de perte des TX (en cas de fork) serait toujours présent uniquement s’il l’on consomme tous les derniers DU des branches, ce qui me parait acceptable, et par ailleurs facile à gérer dans les clients (avertissement utilisateur, etc.)

Qu’en pensez vous ? Il faudrait un changement de protocole, mais la suppression du blockHash est équivalent de ce point de vu là.

[elois]

Si je reformule ta proposition serait de :

1. Référencer les sourdes de DU par blockstamp plutot que par block
2. Dater les tx par blockNumber

Est ce que c’est bien ça ? Sinon, peut tu formuler précisement ta proposition de changement complète ? Merci

[cgeek]

@kimamila

alors il est inévitable que certains accepteront ces documents dans leur piscine un jour ou l’autre

En fait c’est déjà possible même avec le hash, puisque la piscine est hors protocole.

@elois

Oui, de mon point de vue les règles de résolution des fork devraient être protocolaires, je les présentent d’ailleurs dans ma présentation du protocole DUBP réalisée aux rml13

Personnellement je n’arrive pas à mettre la résolution de fork dans le protocole, de la même façon que WS2P. Je crois que c’est un problème d’espace logique (tiens, @Galuel aura peut-être un avis là-dessus).

Parce que si j’adopte le protocole DUBP, alors il m’est garanti le respect de ce même protocole par les autres utilisateurs à un instant donné. Tandis que ce n’est pas vrai de la résolution de fork dans la mesure où l’état distant des autres nœuds est ambigu (déjà définir instant et ensemble des nœuds est hyper ambigu). Je crois que c’est ce problème de définition d’espace-temps qui rend la résolution hors-scope du protocole.

Néanmoins je ne nie pas que celui qui veut participer à l’état de la Ğ1 a tout intérêt à suivre ces protocoles supplémentaires (WS2P, résolution de fork), de même que nous avons intérêt collectivement à ce que chacun les suivent. Mais pour moi ce sont bien des entités à part du protocole Duniter en ce qu’ils ne sont pas nécessaires à son exécution.

Exemple assez courant sur la Ğ1 : le réseau se remet d’accord parce que les utilisateurs forcent la synchronisation sur un nœud particulier, et à cette occasion n’utilisent ni la résolution de fork ni WS2P (bon, WS2P est utilisé oui, mais pas nécessaire : on peut synchroniser avec BMA ou avec un simple dossier).

[cgeek]

@kimamila

Avec le dernier fork, je crois qu’il devient important de statuer sur l’avenir des TX multi-branches…

Oui, et puis j’y ai aussi réfléchi depuis (je n’avais pas trop le temps pendant les fêtes de fin d’année).

@kimamila

avec le risque de s’accaparer les DU futurs (par exemple par braquage)

En fait non il n’y a pas de problème (j’ai cru mais non). Deux cas possibles :

• soit l’utilisateur s’est fait piraté sa clé mais donc il peut aussi révoquer son compte et supprimer la génération des DU futurs
• soit c’est l’utilisateur lui-même qui produit par avance ses transactions, mais après tout il fait bien ce qu’il veut et ne vole ses DU à personne (par définition)

Aussi j’ai trouvé un argument en faveur de la suppression du hash dans les TX : cela concerne un vieil argument de @Galuel (s’il veut bien le reformuler je suis preneur) sur le fait qu’un point crucial de toute monnaie c’est la confiance dans sa stabilité/son existence. Autrement dit une monnaie où les transactions sont sujettes à l’opposition (par fork) n’inspire pas vraiment confiance à l’humain et affaiblissent celle-ci.

Bref après relecture de ce sujet, je n’ai pas vraiment d’argument qui aille contre la suppression de ce hash. La date de signature peut par ailleurs être indiquée dans le champ commentaire (pas besoin de mettre le hash entier) pour ceux pour qui cette info est importante.

De mon souvenir le hash était nécessaire sur les documents de WoT afin de protéger la communauté dans son ensemble, mais là concernant les TX je ne vois pas de problème particulier.

À ce stade je trouve effectivement que ce champ nous contraint plus qu’il nous aide.

[Galuel]

@cgeek

Tandis que ce n’est pas vrai de la résolution de fork dans la mesure où l’état distant des autres nœuds est ambigu (déjà définir instant et ensemble des nœuds est hyper ambigu). Je crois que c’est ce problème de définition d’espace-temps qui rend la résolution hors-scope du protocole.

Oui le fork est toujours ambigu, et n’a pas de rapport avec le protocole puisque les branches restent parfaitement logiques. Le fait de suivre une branche ou une autre peut avoir quantité de raisons, mais surtout n’a pas de rapport avec l’état de la monnaie, ça a plutôt un rapport avec des problématiques de connexions (quel espace de noeuds “voit” un noeud particulier ? Ce sera très souvent différent, selon le noeud, et la résolution de fork étant une affaire de consensus alors on ne peut pas trancher sur qui est majoritaire ou pas… Et le consensus peut mettre bien du temps à s’établir et le faire sur un jugement humain).

@cgeek

un point crucial de toute monnaie c’est la confiance dans sa stabilité/son existence.

Eh oui ! Cf les accords de la Jamaïque

On ne peut pas dire que l’or soit resté “monnaie courante” depuis…

Mais aussi les problèmes liés à l’impossibilité ou la limitation des transfert, des blocages récurrents, des failles, sont autant de thèmes qui font chuter la confiance et donc l’existence même de la monnaie, cela pousse à chercher d’autres solutions.

[Junidev]

si le Block hash et la précédence sont abandonnée pourquoi ne pas utiliser le median time comme reference ? c’est plus précis que le block number surtout par rapport au CSV/CLTV, c’est un entier unique et ordonnée dans la chaine (index) donc la complexité ne change pas. mais la précision de la transaction s’en retrouve amélioré.

de plus cela évite un lookup supplémentaire pour trouvé le timestamp d’expiration. => persformance

Même commentaire pour les documents de WOT. Ca simplifierais bien des choses !

Qu’est-ce que je rate dans mon raisonnement ?

[cgeek]

Déjà merci de me faire remarquer qu’il faut bel et bien garder une référence temporelle dans la transaction pour que la condition CSV fonctionne encore.

Ce que tu rates : CSV(délai) + medianTime est strictement équivalent à CLTV(délai + medianTime). Or les cryptos existantes ont bien conservé ces deux fonctions distinctes, il y a donc sûrement un truc. Mais je ne sais pas lequel, à chaud

[Galuel]

@cgeek

Ce que tu rates : CSV(délai) + medianTime est strictement équivalent à CLTV(délai + medianTime). Or les cryptos existantes ont bien conservé ces deux fonctions distinctes, il y a donc sûrement un truc. Mais je ne sais pas lequel, à chaud

Quel est le détail des fonctions ?

[Junidev]

En fait je l’utiliserais partout le medianTime, car c’est une dépendance forte sur un entier. je le remarque au niveau des certif, le blocknumber seul, c’est la merde techniquement. ça force une dépendance sur l’index pour un timestamp.

Outre la technique, lorsque je signe un chèque ou signe un document chez le notaire je le date, c’est la date qui induit la précédence.

Antidater un document officiel c’est pénalisable, en partit pour cette raison. sur le marché financé, on imagine bien le blé qu’on peu se faire simplement en falcifiant un timestamp.

c’est pour ça que la précedance me paraissait une nécessité jusqu’à lire ce thread mais je n’y ai pas réfléchis plus que çà

[matograine]

@Galuel

Quel est le détail des fonctions ?

CLTV

CLVT(TIMESTAMP) returns true if and only if the transaction including block’s MedianTime >= TIMESTAMP .
…
CLTV 's parameter must be an integer with a length between 1 and 10 chars.

CSV

CSV(DELAY) returns true if and only if the transaction including block’s MedianTime - TxTime >= DELAY .
…
CSV 's parameter must be an integer with a length between 1 and 8 chars.

[Galuel]

Et quelle est la relation entre TIMESTAMP, TxTime et DELAY ?

[matograine]

Lapin.

Lapin compris la question.
Ce sont des temps exprimés en secondes, TIMESTAMP indiquant un nombre de secondes écoulé depuis le 1er janvier 1970 à minuit UTC (indique un moment quelconque). Le reste est exprimé au-dessus.

Notamment, il n’existe aucune relation entre TIMESTAMP et DELAY, car ce sont des paramètres de deux fonctions différentes.

Quant à TxTime (exprimé en timestamp)… Le moment où je fais une transaction a-t-il une influence sur le délai de bloquage de la monnaie ? Il me semble que non, mais peut-être qu’une étude sociologique poussée aboutirait à des conclusions différentes. Je ne suis pas sûr si TxTime est la date de la transaction ou la date de son enregistrement en BC.

Et MedianTime est le temps Blockchain, exprimée en Timestamp.

[Galuel]

@matograine

Notamment, il n’existe aucune relation entre TIMESTAMP et DELAY, car ce sont des paramètres de deux fonctions différentes.

S’il n’y a aucune relation entre TIMESTAMP, TxTime et DELAY, alors les deux inégalités (A) MedianTime >= TIMESTAMP et (B) MedianTime - TxTime >= DELAY ne peuvent pas être équivalentes.

En effet pour qu’elles soient équivalentes, il faut alors :

MedianTime >= TIMESTAMP <=> MedianTime >= TxTime + DELAY

Ce qui implique qu’il existe une relation simple qui est que si TIMESTAMP est inférieur ou égal à MedianTime, alors TxTime + DELAY doit l’être aussi, et inversement.

Ce qui signifie que TIMESTAMP et (TxTime + DELAY) doivent toujours être ensemble inférieurs ou supérieurs à TIMESTAMP, l’un ne pouvant l’être sans l’autre.

Ce qui constitue une relation entre ces trois paramètres et TIMESTAMP