S’il n’y a pas consensus et que le soft-fork ne prend pas, la chaine la plus longue reste avec le protocole original et donc c’est cette chaine qui est considérée comme valide. C’est bien pour ça que l’on part sur un bit d’activation qui permet de synchroniser le lancement du soft-fork quand une grande part du réseau vote pour utiliser ce nouveau protocole.
2 Likes
Avoir du signaling c’est cool oui. Mais ça nécessite aussi de notifier et d’accompagner les nœuds et mineurs pour faire les démarches nécessaires 
Evidement.
A noter que je voulais aussi intégrer un bonus aléatoire, et ça c’est un hard fork car les anciens nœuds considéreront invalide un bloc trouvé par un membre qui bénéficiai d’un bonus.
Alors ça je ne le sens pas, on peut faire beaucoup mieux du premier coup comme l’a suggéré @nanocryk.
Il suffit de stoker un entier sur 32 bits au lieu d’un booléen, et ça permet de stocker un signal pour les 32 évolutions de protocole a venir.
Pour savoir si la 1ère évolution est gérée par le noeud il suffit de vérifier si le reste module 2 vaut 1.
Pour la 2ème évolution il suffit de vérifier si le reste module 4 vaut 1.
etc
je suis également de l’avis de @nanocryk que les features 5 à 8 doivent être faites d’un bloc.
Concernant la feature 1 comme j’ai dit j’aimerais y ajouter le bonus aléatoire, selon la règle que j’avais proposer :
- tirer au sort un tiers des membres calculant parmi l’échantillon du dernier tier de la fenêtre courante et leur donner un bonus aléatoire pouvant aller de -1 à -10.
Concrètement il suffit de convertir le hash du bloc courant en entier (par convertion string → hexa → integer) puis a chaque tirage de calculer le modulo taille de l’échantillon restant. Idem pour la valeur de bonus.
1 Like
Tu veux dire (upgrade / 2) mod 2, non ?
Ca me parait bizarre aussi, perso j’aurais simplement fait un filtre & sur le nombre pour avoir le résultat. 
1 Like
Il me semble que flags & (1 << index) != 0 est le plus simple, non ?
2 Likes
oui j’ai écris trop vite mais vous avez compris l’idée 
Surtout moins gourmant en CPU. Par contre, il me semble que c’est moins lisible pour celui qui n’a jamais fait d’assembleur dans sa vie, il faudra le commenter… 
Je n’ai jamais fait d’assembleur, mais ce sont juste des opération bit à bit. Mais oui, ça méritera son commentaire ou sa fonction dédiée.
2 Likes
Oui on peut faire avec un entier sur 32 bits si vous voulez. Peu m’importe.
Si vous voulez, mais je réitère trouver cette proposition très optimiste. J’y vois un gros risque pour l’instant.
1 Like
Vous comptez proposer les évolutions dans n’importe quel ordre ? Parce que sinon, plutôt que de proposer un entier qui contient 32 booléens, et qui va, forcément, passer de 1 à 3, puis à 7, puis à 15, etc. (car si l’on sait que le nœud qui a l’évolution n°3 a forcément la 1 et la 2, tous les bits de poids inférieurs seront forcément à 1), pourquoi ne pas enregistrer un simple numéro de version ? Ça permettra d’avoir un signal non pas pour les 32 évolutions à venir, mais pour les 2^32 !
Oui surtout si on veut faire coexister plusieurs implémentations différentes il n’est pas dit que les évolutions soient implémentés dans le même ordre sur l’une et l’autre !
1 Like
Vu la nature du nouveau protocole c’est même maintenant obligatoire.
Il n’y a rien d’obligatoire, je ne vois aucun frein conceptuel à binariser les documents avant d’implémenter quoi que ce soit de supplémentaire.
Ils ont tout revu en fait ! 
Ils prévoient actuellement un protocole généraliste, ou la couche basse (blockchain) serait abstraite, et la couche haute (duniter) serait implémentée par dessus.
Discussions à suivre par ici…
1 Like
Voir pour la plupart “à l’intérieur”
Oui voilà : c’est plus une volonté de tout revoir d’un coup qu’une quelconque obligation.
Et face à cela, je lève une alerte, c’est tout. Cela ne m’empêche pas non plus de penser qu’il y a de très bonnes idées là-dedans.
On est d’accord