# \[DUBP V13\] Need for a review of the RFC
**URL:** https://forum.duniter.org/t/dubp-v13-need-for-a-review-of-the-rfc/7069
**Category:** DUBP
**Tags:** rfc, protocole
**Created:** [29 March 2020 15:04 UTC](https://forum.duniter.org/t/dubp-v13-need-for-a-review-of-the-rfc/7069 "2020-03-29T15:04:57Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [29 March 2020 15:04 UTC](https://forum.duniter.org/t/dubp-v13-need-for-a-review-of-the-rfc/7069/1 "2020-03-29T15:04:57Z")
@cgeek @Moul @Inso and any contributor who feels able to review a DUBP protocol RFC.
I have just published [a draft RFC](https://git.duniter.org/documents/rfcs/-/merge_requests/1) 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](https://git.duniter.org/documents/rfcs/-/merge_requests/1/commits)
I need a review by @cgeek at least, and other contributors if possible 🙂
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 :
- [Interdire les transactions avec source \< 1,00 Äž1](https://forum.duniter.org/t/interdire-les-transactions-avec-source-1-00-g1/5938)
- [RFC GVA \> TX compatible avec plusieurs branches](https://forum.duniter.org/t/rfc-gva-tx-compatible-avec-plusieurs-branches/6640)
- [Paiements instantanés et garantis à 100% sans tiers de confiance : Les Lightning Network](https://forum.duniter.org/t/paiements-instantanes-et-garantis-a-100-sans-tiers-de-confiance-les-lightning-network/6814)
- [Clefs publiques commençant par "1"](https://forum.duniter.org/t/clefs-publiques-commencant-par-1/7607/15)
---
### Author:  [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [31 March 2020 05:19 UTC](https://forum.duniter.org/t/dubp-v13-need-for-a-review-of-the-rfc/7069/2 "2020-03-31T05:19:28Z")
> [@elois](#):
>
> Add complete list of blocks with invalid signature
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.
> [@elois](#):
>
> Add min amount for each transaction output & remove rule BR\_G106
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.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [1 April 2020 15:40 UTC](https://forum.duniter.org/t/dubp-v13-need-for-a-review-of-the-rfc/7069/3 "2020-04-01T15:40:52Z")
> [@Inso](#):
>
> 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.
Ç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 🙂
> [@Inso](#):
>
> 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).
Si quelqu’un veut bien la rédigée cette release note je suis preneur 🙂
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [25 April 2020 12:57 UTC](https://forum.duniter.org/t/dubp-v13-need-for-a-review-of-the-rfc/7069/4 "2020-04-25T12:57:54Z")
Review réalisée ce matin.
---
### Author:  [@Moul](https://forum.duniter.org/u/Moul)
#### Post date: [26 April 2020 16:01 UTC](https://forum.duniter.org/t/dubp-v13-need-for-a-review-of-the-rfc/7069/5 "2020-04-26T16:01:18Z")
> [@elois](#):
>
> fix: if HEAD.version \<12 then sigQty=1 and stepMax=7
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 👍
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [26 April 2020 20:28 UTC](https://forum.duniter.org/t/dubp-v13-need-for-a-review-of-the-rfc/7069/6 "2020-04-26T20:28:50Z")
> [@Moul](#):
>
> Je comprends pas ce correctif. Que signifie `stepMapx` ? La distance maximale entre deux nœuds WoT ? Ça limite le calcul à 7 ?
Tu a pourtant liké le post a son origine : [https://forum.duniter.org/t/blockchain-g1-invalide/7090/6](https://forum.duniter.org/t/blockchain-g1-invalide/7090/6)
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [28 April 2020 23:54 UTC](https://forum.duniter.org/t/dubp-v13-need-for-a-review-of-the-rfc/7069/7 "2020-04-28T23:54:50Z")
> [@cgeek](#):
>
> Review réalisée
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 🙂
---
### Author:  [@matograine](https://forum.duniter.org/u/matograine)
#### Post date: [3 June 2020 15:35 UTC](https://forum.duniter.org/t/dubp-v13-need-for-a-review-of-the-rfc/7069/8 "2020-06-03T15:35:14Z")
Question concernant la condition de dépense [DESTROY()](https://git.duniter.org/nodes/common/doc/blob/dubp_v13/rfc/0011_Duniter_Blockchain_Protocol_V13.md#output-condition).
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.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [3 June 2020 15:43 UTC](https://forum.duniter.org/t/dubp-v13-need-for-a-review-of-the-rfc/7069/9 "2020-06-03T15:43:27Z")
> [@matograine](#):
>
> De la monnaie envoyée avec cette condition est-elle retirée de la masse monétaire `monetaryMass` ?
non
> [@matograine](#):
>
> est-elle toujours prise en compte pour le calcul du DU ?
oui
> [@matograine](#):
>
> la TRM ne prévoit pas de destruction de monnaie.
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.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [11 June 2020 22:36 UTC](https://forum.duniter.org/t/dubp-v13-need-for-a-review-of-the-rfc/7069/10 "2020-06-11T22:36:21Z")
> [@elois](#):
>
> Merci @cgeek, je viens de traiter tes retours […]
@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é 🙂
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 🙂
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [26 September 2020 19:41 UTC](https://forum.duniter.org/t/dubp-v13-need-for-a-review-of-the-rfc/7069/11 "2020-09-26T19:41:56Z")
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:
> [@elois](#):
>
> - 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).
> - Remove constraint txWindow
* * *
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 :
> [@elois](#):
>
> - 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).
> - Remove constraint txWindow