@inso Pour les soft-fork en effet :)

Le premier soft-fork c'est une implémentation des MAST pour avoir des scripts léger à utiliser en input comme en output.

Le 2eme consiste au chaînage de scripts MAST. En gros comme condition de dépense de ta transaction tu as l'obligation d'avoir un certain script hash. Du coup les scripts sont stateless, la blockchain donne le côté statefull et ça reste non Turing-complet.

@inso On peut alors imaginer plusieurs branches d'un contrat avec les MAST, sans exposer les branches non utilisées.

Le contrat peut être en plusieurs étapes voir même impliquer plusieurs personnes, le passage par la suite du contrat étant alors forcé par un opcode du style `NeedMerkleScript(hash)`. Comme il n'est pas possible de faire des cycles avec des hashs, alors pas de Turing-completude. Avec un bon MAST Il est même possible d'intégrer une "sortie de secours" cachée.

@nanocryk Seems interesting ;) Va falloir que tu sois précis dans tes DIP, avec de bonnes définitions et exemples. Afin qu'on perdre pas trop de temps à se comprendre et à discuter rapidement du fond !

4 DIP à rédiger, tu as pas t'ennuyer :D (Au passage tu vas devoir créer le format des DIP vu qu'on en a encore jamais fait :p )

@nanocryk De toute façon dans un premier temps je t'invite à profiter des RML pour en discuter :) (Il me semble que tu y vas non ?)

Moi je serais pas dispo pour cette édition...

@inso Je compte bien à discuter avec les autres développeurs, dommage que tu ne sois pas parmi nous :/

Oui je vais bosser sur le format des DIP en me basant sur les BIP, et faire un truc très précis sans ambiguïtés.

Il y aura de la place pour ça sur les dépôts officiels ? Que ça ne soit pas juste une initiative de mon côté.

@nanocryk
Oui ça a sa place , dit sur le dépôt Duniter, soit sur le wiki, soit dans un dépôt dédié...

@inso Pour l'instant je vais faire un dépôt `dips` dans `duniter-ts`, on pourra toujours le forker/déplacer dans le dépôt officiel plus tard.

Il sera préférable que le document soit en anglais ou c'est dispensable ?

@nanocryk
Préférable, pas indispensable :) au pire on le traduira !

@inso Okep ! Je vais déjà m'attaquer aux 2 hard-fork sur le format binaire, sachant que les autres DIP seront faisable en soft-fork grâce à eux.

@nanocryk Tu devrais nous rejoindre sur la chatroom XMPP d'ailleurs :)

@inso Je viens de rejoindre :)

@inso Après discussion avec @cgeek, j'ai une bonne application réelle des "script chain" : un système d'abonnement résiliable avec paiement automatique :D Impossible à faire pour le moment, et ça ne me semble pas encore possible sur Bitcoin ;)

@nanocryk Excellent, ça donne envie tout ça ! @cgeek , à chaud, qu'est-ce que tu penses de ses futures propositions ? :)

@inso @nanocryk Qu'il faut étudier tout cela à tête reposée 🙂

@cgeek @inso @elois Un premier draft du DIP0001 sur un nouveau système de script pour les conditions de dépenses des transactions de #duniter : https://frama.link/7KZre7rn #blockchain #smartcontract

@nanocryk @cgeek @elois
J'ai effectué une première lecture en diagonale, Ya quelques typo, globalement ça a l'air intéressant, et je suis pas d'accord avec tout :) . A voir si on peut pas utiliser le système de review de gitlab pour commenter la DIP ?

@inso @cgeek @elois Merci. Je ne sais pas pour les reviews de GitLab, mais pourquoi pas :) Sur quoi tu es en désaccord ?

@elois @cgeek @inso J'ai créé une merge request pour qu'on puisse utiliser le système de review.

@nanocryk @cgeek @elois
La politique que tu proposes sur les nœuds miroirs. Je ne suis pas forcément contre, mais il faut vérifier l'impact potentiel, que ce soit en terme d'attaque, de consensus/fork ou de performances sur le réseau.

@inso @cgeek @elois C'est une simple proposition. J'ai aussi proposé (de manière informelle, ça sera proposé dans un DIP sur le format des docs en binaire) de propose un champ avec des bits de version pour valider des changements avec des fenêtres d'activations. A ce moment là on a pas besoin de gérer cette situation. Si l'état undefined remonte à la racine de l'arbre, alors la transaction est considérée invalide. Ca peut toujours permettre d'écrire un contrat à l'avance d'une release par exemple

@nanocryk @inso @elois Sur le principe je préfère ta proposition d'arbre que l'actuelle syntaxe à parser de Duniter 1.x. C'est moins ambigu.

Après je trouve le document encore incomplet, par exemple je ne vois pas comment s'articulent les Merkle tree dans ce protocole de déverouillage, ni comment sont connus/fournis les paramètres EXT.

Mais je t'invite à continuer, tu écris peut-être ce que deviendra Duniter demain.

@cgeek @inso @elois En effet c'est prévu, il est passé en merge request pour avoir les reviews sur Gitlab :)

@elois @inso @cgeek
Merci pour les suggestions. J'ai rajouté une partie sur les arbres de Merkle et les EXT. J'ai d'ailleurs modifié certains aspects pour les rendre plus unifiés (les EXT vont en fait importer des AST, qui peuvent être un nœud de valeur ou alors un arbre).