[DUBP V13] Need for a review of the RFC

@cgeek @Moul @Inso and any contributor who feels able to review a DUBP protocol RFC.

I have just published a draft RFC for version 13 of the DUBP protocol, it includes the following changes:

  • Add complete list of blocks with invalid signature
  • Add min amount for each transaction output & remove rule BR_G106
  • Update rule BR_G102: Obtaining the REF_BLOCK by number only (removal of the constraint on hash).
  • Change CSV definition to make it compatible with Lightning Network
  • Remove constraint txWindow
  • fix: BR_G08 : medianTime’s computation formula is outdated
  • fix: if HEAD.version <12 then sigQty=1 and stepMax=7

You can see all the differences with version 12 commit by commit here : https://git.duniter.org/documents/rfcs/-/merge_requests/1/commits

I need a review by @cgeek at least, and other contributors if possible :slight_smile:

If you validate the changes in this RFC, I would implement them in Duniter 1.8.

These changes are the result of the following discussions :

3 J'aimes

Ne faudrait-il pas aussi intégrer les signatures dans la liste des blocks invalides ? Pour éviter des attaques qui s’appuyeriaent sur le fait qu’on ne peut pas vérifier les signatures de ces blocks, on pourrait au moins les « hardcoder ». Je ne suis pas certain que ce soit nécessaire, vu que les blocks ultérieurs couvrent déja ces blocks erronés.

Possible d’ajouter un raisonnement du pourquoi dans la RFC ? Pour avoir le suivi de l’historique du raisonnement pour les futurs lecteurs. (Peut-être via une release note en haut de la RFC, pas forcément à l’intérieur).

Sinon c’est ok pour moi.

1 J'aime

Ça ne me semble pas nécessaire car un attaquant ne pourrais pas modifier le contenu de ses blocs, le champ previousHash des blocs suivants deviendrais alors invalide.
La vérifiabilité du chaînage des hashs à toujours bien fonctionnée, et a elle seule garantie la validité du contenu, a condition que l’on ai confiance en le hash d’un bloc plus loin (ce qui est le principe de la sync rapide). on peut a la limite inscrire en dur le hash du 1er blocs suivant le dernier bloc invalide, ça suffit :slight_smile:

Si quelqu’un veut bien la rédigée cette release note je suis preneur :slight_smile:

1 J'aime

Review réalisée ce matin.

1 J'aime

Je comprends pas ce correctif. Que signifie stepMapx ? La distance maximale entre deux nœuds WoT ? Ça limite le calcul à 7 ?


Autrement, c’est review pour ma part. C’est bon pour moi. Great job :+1:

Tu a pourtant liké le post a son origine : https://forum.duniter.org/t/blockchain-g1-invalide/7090/6

1 J'aime

Merci @cgeek, je viens de traiter tes retours. Notamment, j’ai finalement supprimé la règle BR_G103 qui n’a plus de raison d’être en v13 :slight_smile:

Question concernant la condition de dépense DESTROY().

De la monnaie envoyée avec cette condition est-elle retirée de la masse monétaire monetaryMass ? Ou bien est-elle toujours prise en compte pour le calcul du DU ?

Il me semble logique que de la monnaie détruite soit retirée de la masse monétaire. Mais je n’en vois sans doute pas toutes les conséquences. Et la TRM ne prévoit pas de destruction de monnaie.

1 J'aime

non

oui

Exactement, d’où les 2 réponses au dessus, impacter M (et donc le calcul du DU) ne serait pas conforme a la TRM.
Il s’agit ici d’une destruction similaire au fait de brûler un billet UNL, la banque centrale émettrice de ce billet le comptabilisera toujours dans la masse monétaire en circulation.

2 J'aimes

@cgeek je viens de voir que tu avais répondu le 1er mai à mon traitement de tes retours, je n’avais pas été notifié par gitlab. je viens de supprimer la règle BR_G102 comme demandé :slight_smile:

Je compte commencer l’implémentation de DUBP v13 dès maintenant, peut tu relire une ultime fois la MR afin d’être certain que nous sommes toujours d’accord sur les changements ? Merci :slight_smile:

1 J'aime