[DUBP V12] RFC approved

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

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

  • rename DUP -> DUBP.
  • Indicates the possibility of invalid signatures in blocks with version 10 or 11.
  • Remove rule BR_G106.
  • Update rule BR_G102: Obtaining the REF_BLOCK by number only (removal of the constraint on hash).
  • Update transactions local validation: addition of a minimal amount on outputs for transactions in blocks version 12.
  • Update of the expected version for each document.
  • Adding local and global validations in the outline.
  • Update rule BR_G27 : fix #11 (Certifications being replayed are counted twice)

You can see all the differences with version 11 here: https://git.duniter.org/nodes/common/doc/merge_requests/10/diffs?commit_id=ed256c43e1313ad3eed91d478ffadbe9268de555

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, I am setting up my development environment for Duniter :slight_smile:

These changes are the result of the following discussions :

4 Likes

On the recommendation of @moul, I separated the changes into several small atomic commits :

  • d2c6dbe3 - Exact copy of DUBP v11
  • 816a9f05 - [ref] rename UCP/DUP -> DUBP + make implementation agnostic
  • 485f842f - Update of the expected version for each document
  • 463e72a9 - Indicates the possibility of invalid signatures in blocks with v10 or 11
  • dc3dbf39 - Add min amount for each transaction output & remove rule BR_G106 (reported in v13)
  • 4277f34d - Update rule BR_G102: Obtain REF_BLOCK by number only, rm hash constraint
3 Likes

In view of the ongoing discussions on the issue of removing hash control from the blockstamp of transaction documents; this proposal is deleted from DUBP v12.

1 Like

A commit has just been added to this RFC to fix a specification flaw :

  • 32b1d55e Update rule BR_G27 : fix #11 (Certifications being replayed are counted twice)
2 Likes

Reviewed. For me the formula in 32b1d55e is not correct currently.

1 Like

Thanks for the review :slight_smile:

I’ve addressed all of your remarks except for one for which I have a question.
When I process one, I answer the remark with an « ok », I do not pass the remark as resolved, it is up to the author of the remark to consider whether it is resolved or not :slight_smile:

An exception: if the remark is not a request for change but just a compliment (example « good point »), I pass it as resolved myself (because all remarks must be resolved to be merged).

1 Like

Answered.

1 Like

This commit is reported in v13.

@cgeek I’ve processed all your returns, can you check every comment you made and mark it as resolved if it is? Or make a clarification if it isn’t?

If all remarks are resolved then you can officially merge this rfc :slight_smile:

Done. :slight_smile: Thanks for this work.

1 Like

Thank for the review :slight_smile:

I have updated the README to bring this RFC to the approved state and create a new MR for DUBP v13, I’m closing this thread.

DUBP v12 has been implemented in the duniter software:

  • Update rule BR_G27 : fix #11 (Certifications being replayed are counted twice)
  • Upgrade tweetnacl : fix #1390 ( Duniter uses a buggy version of TweetNaCl)

A new version of Duniter with these changes will be released soon.

2 Likes