WIP: RFC 5 : New Scalable Blockchain Protocol

This document provides specifications of a new blockchain protocol which will be used power future versions of Duniter currencies. It is however a generalist protocol and could be used by other projects outside of Duniter and with little or no modifications.

rfc/0005 Duniter Protocol Rework.md

@@ -22,25 +22,43 @@ If this RFC is accepted, this document could be used as documentation with no or
 
 ## Summary
 
-1. [Conventions and common rules](#1-conventions-and-common-rules)
-1. [General document format](#2-general-document-format)
-1. [Transaction document](#3-transaction-document)
+1. [Introduction](#1-introduction)
+1. [Conventions](#2-conventions)
+1. [General document format](#3-general-document-format)
+1. [Transaction document](#4-transaction-document)
 1. Identity, Membership and Certification documents
 1. Block document
 
-## 1. Conventions and common rules
+## 1. Introduction
 
-### 1.1. Endianness
+The Duniter software aims to provide *Universal Dividend*-based crypto-currency.
+The name is made from `DU + unit + er`, as "*a tool for creating UD units*".
+
+> *DU* stands for "Dividende Universel", "Universal Dividend" in french.
+
+It's based on Stephane Laborde's [Relative Theory of Money] which aim to provide equality
+to money creation between all users, in space [of users] and time.
+
+The currency is based on a **blockchain** composed of **blocks**, linked together with
+*cryptographic hashes*; containing *documents* for *transactions* and management of the
+**Web of Trust** : a structure used to associate a human being with only one account, which is
+needed to avoid a user to have multiple UD.
+
+[Relative Theory of Money]: http://en.trm.creationmonetaire.info/
+
+## 2. Conventions
+
+### 2.1. Endianness
 
 All data fields are big-endian unless otherwise specified.
 
-### 1.2. Hashes
+### 2.2. Hashes
 
 All *cryptographic hashes* are done with *SHA256* algorithm unless otherwise specified.
 
 They are stored as raw bytes arrays and should be displayed in hexadecimal format.
 
-### 1.3. Bases
+### 2.3. Bases
 
 Some specific data is stored or displayed using these bases :
 
@@ -53,13 +71,13 @@ Some specific data is stored or displayed using these bases :
   Each character is stored on 6bits, and remove any invalid characters.
   The alphabet is `ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-`.
 
-### 1.4. Bytes alignments
+### 2.4. Bytes alignments
 
 Data should be aligned in 4 bytes blocks to improve memory speed.
 Large values should be aligned, small values packed together to form 4 bytes
 blocks and padding be used if alignement is not directly possible.
 
-### 1.5. Block identifiers
+### 2.5. Block identifiers
 
 Each block is indexed by its **block ID** stored as a *4 bytes unsigned integer*.
 The ***genesis block*** *ID* is `0`, and each following block have a *block ID* incremented by `1`.
@@ -72,7 +90,7 @@ Since hashes are stored on 32 bytes, a *blockstamp* is stored on a 36 bytes valu
 
 > Note that is says "might be" because the hash is not known in advence.
 
-### 1.6. Dates
+### 2.6. Dates
 
 All dates are stored in [UNIX timestamp format][unix-timestamp], as the number of seconds
 since 00:00:00 UTC on January 1, 1970. They are stored in a 64bit format to
@@ -90,7 +108,7 @@ It should be preferred to use *blockstamps* since its independent of any externa
 [unix-timestamp]: https://en.wikipedia.org/wiki/Unix_time
 [year-2038-problem]: https://en.wikipedia.org/wiki/Unix_time#Representing_the_number
 
-## 1.7. Keys
+## 2.7. Keys
 
 The new key format allow user to choose which *cryptographic system* he wants to use.
 Currently only Ed25519 is supported, but others like [Schnorr signature] could be added.
@@ -125,7 +143,7 @@ The complete *checksum* (hash of all other fields) of a *public key* is known as
 and can be used to designate any public key in a fixed size value.
 When a *complete public key* is used, it can be hashed and compared with the *compact key*.
 
-### 1.8. Identities
+### 2.8. Identities
 
 Each identity can be referred as its **identity hash** (or **indentity UID**) computed from the username,
 the hash of its associated *compact key* and the *blockstamp* of the identity creation document.
@@ -136,7 +154,7 @@ IdentityHash = SHA256(Username + CompactKey + Blockstamp)
 
 > The `+` operation is a raw byte concatenation.
 
-## 2. General document format
+## 3. General document format
 
 Each document is composed of an header, a payload and one or more signatures.
 The tuple `(magic value, currency code, document type)` is used for network propagation,
@@ -159,13 +177,13 @@ The header is composed of :
 
 Payload and each signatures have alignement padding.
 
-Signatures cryptographic types are not defined and use the matching public key types.
+Cryptographic systems of signatures are not provided and matching public key types are used.
 A document is valid if each public key can match a signature (with 0 bytes left and no overflows)
-and each signature is valid for the document content.
+and each signature is valid for the document content and the public key.
 
-## 3. Transaction document
+## 4. Transaction document
 
-### 3.1. Document structure
+### 4.1. Document structure
 
 A **transaction document** describes the consumption of **sources** and the creation of **outputs**.
 Since we're dealing with *Universal Dividend*s, it's possible to provide a list of UDs to spend.