[DUBP V13] Need for a review of the RFC

Protocols DUBP
,
1

@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 Postponed
    * Update rule BR_G102: Obtaining the REF_BLOCK by number only (removal of the constraint on hash). Postponed
  • Change CSV definition to make it compatible with Lightning Network
    * Remove constraint txWindow Postponed
  • fix: BR_G08 : medianTime’s computation formula is outdated
  • fix: if HEAD.version <12 then sigQty=1 and stepMax=7
  • SIG condition its now insensitive to leading 1
  • Public key format its now base58 string between 40 and 44 characters long

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 :

4 Likes
2

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.

2 Likes
3

Ç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:

2 Likes
4

Review réalisée ce matin.

2 Likes
5

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:

6

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

1 Like
7

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:

8

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.

2 Likes
9

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.

3 Likes
10

@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 Like
11

My priorities having changed, I decided to change my strategy with respect to protocol evolutions (and any changes in Duniter).

From now on, my top priority is the migration of Duniter to Rust because I don’t want to maintain Typescript code (or at least as little as possible). This means that when I have to change a treatment in Duniter, I take the opportunity to migrate it at the same time (as far as possible).

Concerning protocol changes, I only want to implement a change if I can migrate it at the same time (except if there is a bug that totally blocks the production like a blockchain stop).

So I decided to postpone to a later version of DUBP the three following points:

Mes priorités ayant changé, j’ai décidé de changer de stratégie par rapport aux évolutions de protocole (et à tout changement dans Duniter).

Désormais ma priorité n°1 est la migration de Duniter en Rust car je ne souhaite pas maintenir du code en Typescript (er tout cas le moins possible). Ce qui signifie que lorsque je dois changer un traitement dans Duniter, j’en profite pour le migrer en même temps (dans la mesure du possible).

Concernant les changements de protocole, je ne souhaite implémenter un changement que si je peux le migrer en même temps (sauf bug totalement bloquant en prod comme un arrêt de la blockchain).

J’ai donc décidé de reporter à une version ultérieure de DUBP les trois points suivants :

4 Likes