Skip to content
Snippets Groups Projects

create RFC DUBP V12

Merged create RFC DUBP V12
dubp_v12 into master
Merged Éloïs requested to merge dubp_v12 into master
Viewing commit ed256c43
Show latest version
1 file
+ 59
− 54
Compare changes
  • Side-by-side
  • Inline
  • ed256c43
    Éloïs
    [enh] write DUBP v12 · ed256c43
    Éloïs authored 
    - rename DUP -> DUBP
- Indicates the possibility of invalid signatures in v10 and v11
- 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
- Update of the expected version for each document
- Adding local and global validations in the outline
rfc/0010_Duniter_Blockchain_Protocol_V12.md
+ 59
− 54
# DUP - Duniter Protocol
> This document reflects Duniter in-production protocol. It is updated only for clarifications (2017).
# DUBP - DUniter Blockchain Protocol
## Contents
@@ -23,6 +21,8 @@
* [Computed variables](#computed-variables)
* [Processing](#processing)
* [Block](#block-1)
* [Local validation](#local-validation)
* [Global validation](#global-validation)
* [Peer](#peer-1)
* [Transaction](#transaction-1)
* [Implementations](#implementations)
@@ -32,7 +32,7 @@
Word | Description
--------------------- | -------------
UCP | Acronym for *UCoin Protocol*. A set of rules to create Duniter based currencies.
DUBP | Acronym for *DUniter Blockchain Protocol*. A set of rules to create Duniter based currencies.
Signature | The cryptographical act of certifying a document using a private key.
WoT | Acronym for *Web of Trust*. A groupment of individuals recognizing each other's identity through public keys and certification mechanisms
UD | Acronym for *Universal Dividend*. Means money issuance **directly** and **exclusively** by and to WoT members
@@ -41,9 +41,9 @@ blocktime | The realtime recorded by a block.
## Introduction
UCP aims at defining a data format, an interpretation of it and processing rules in order to build coherent free currency systems in a P2P environment. UCP is to be understood as an *abstract* protocol since it defines currency parameters and rules about them, but not their value which is implementation specific.
DUBP aims at defining a data format, an interpretation of it and processing rules in order to build coherent free currency systems in a P2P environment. DUBP is to be understood as an *abstract* protocol since it defines currency parameters and rules about them, but not their value which is implementation specific.
This document describes UCP in a bottom-up logic, so you will find first the details of the protocol (data format) to end with general protocol requirements.
This document describes DUBP in a bottom-up logic, so you will find first the details of the protocol (data format) to end with general protocol requirements.
## Conventions
@@ -81,7 +81,7 @@ The block ID of the block#433 is `433`. Its UID *might be* `433-FB11681FC1B3E36C
A valid currency name is composed of alphanumeric characters, spaces, `-` or `_` and has a length of 2 to 50 characters.
#### Datesœ
#### Dates
For any document using a date field, targeted date is to be understood as **UTC+0** reference.
@@ -99,13 +99,16 @@ Here is an example of an expected signature:
H41/8OGV2W4CLKbE35kk5t1HJQsb3jEM0/QGLUf80CwJvGZf3HvVCcNtHPUFoUBKEDQO9mPK3KJkqOoxHpqHCw==
Please note: The V10 and V11 blocks and some transactions in these blocks are signed with a buggy version of TweetNaCl: [version 20131229](http://tweetnacl.cr.yp.to/software.html). As a result, some V10 and V11 blocks have an invalid signature (as well as some transactions in V10 or V11 blocks).
A complete list of invalid signatures in each currency will be compiled when the Ğ1 and Ğ1-test networks have successfully migrated to DUBP v12.
#### Line endings
No new line character exists in a signature. However, a signature may be followed by a new line character, hence denoting the end of the signature.
## Formats
This section deals with the various data formats used by UCP.
This section deals with the various data formats used by DUBP.
### Public key
@@ -117,18 +120,18 @@ Its format is a [Base58](http://en.wikipedia.org/wiki/Base58) string of 43 or 44
HsLShAtzXTVxeUtQd7yi5Z5Zh4zNvbu8sTEZ53nfKcqY
A public key is always paired with a private key, which UCP will never deal with. UCP only deals with public keys and signatures.
A public key is always paired with a private key, which DUBP will never deal with. DUBP only deals with public keys and signatures.
### Identity
#### Definition
Issuing an identity is the act of creating a link between a *public key* and *an arbitrary identity*. In UCP, this link is done through the signature of an identity string by the private key corresponding to the public key. It is exactly like saying:
Issuing an identity is the act of creating a link between a *public key* and *an arbitrary identity*. In DUBP, this link is done through the signature of an identity string by the private key corresponding to the public key. It is exactly like saying:
> « This identity refers to me ! »
#### Identity unique ID
UCP does not rely on any particular identity format, which remains implementation free. Identity simply has to be a string of length between 2 and 100 characters avoiding usage of line ending characters.
DUBP does not rely on any particular identity format, which remains implementation free. Identity simply has to be a string of length between 2 and 100 characters avoiding usage of line ending characters.
In this document *identifier*, `UserID`, `USER_ID` and `uid` will be indifferently used to refer to this identity string.
@@ -250,7 +253,7 @@ SoKwoa8PFfCDJWZ6dNCv7XstezHcc2BbKiJgVDXv82R5zYR83nis9dShLgWJ5w48noVUHimdngzYQneN
#### Definition
A *certification* in UCP refers to the document *certifying* that someone else's identity is to consider as the unique reference to a living individual.
A *certification* in DUBP refers to the document *certifying* that someone else's identity is to consider as the unique reference to a living individual.
#### Format
@@ -320,7 +323,7 @@ SoKwoa8PFfCDJWZ6dNCv7XstezHcc2BbKiJgVDXv82R5zYR83nis9dShLgWJ5w48noVUHimdngzYQneN
### Membership
In UCP, a member is represented by a public key they are supposed to own. To be integrated in a WoT, the newcomer owner of the key *has to express their will* to integrate the WoT.
In DUBP, a member is represented by a public key they are supposed to own. To be integrated in a WoT, the newcomer owner of the key *has to express their will* to integrate the WoT.
This step is done by issuing the following document:
@@ -354,7 +357,7 @@ Field | Description
A [Membership](#membership) is to be considered having valid format if:
* `Version` equals `2`
* `Version` equals `10`
* `Type` equals `Membership` value.
* `Currency` is a valid currency name
* `Issuer` is a public key
@@ -423,7 +426,7 @@ Field | Description
A Transaction structure is considered *valid* if:
* Field `Version` equals `2` or `3`.
* Field `Version` equals `10` or `12`.
* Field `Type` equals `Transaction`.
* Field `Currency` is not empty.
* Field `Blockstamp` is a block UID
@@ -436,7 +439,7 @@ A Transaction structure is considered *valid* if:
* `IN_INDEX` must be an integer value
* `UL_CONDITIONS` must be a valid [Input Condition](#input-condition)
* Field `Outputs` is a multiline field whose lines follow `AMOUNT:BASE:CONDITIONS` format:
* `AMOUNT` must be an integer value
* `AMOUNT` must be an integer value. If document `Version` is greater than or equal to `12`, then `AMOUNT` must be greater than or equal to `100`.
* `BASE` must be an integer value
* `CONDITIONS` must be a valid [Output Condition](#output-condition)
* Field `Comment` is a string of maximum 255 characters, exclusively composed of alphanumeric characters, space, `-`, `_`, `:`, `/`, `;`, `*`, `[`, `]`, `(`, `)`, `?`, `!`, `^`, `+`, `=`, `@`, `&`, `~`, `#`, `{`, `}`, `|`, `\`, `<`, `>`, `%`, `.`. Must be present even if empty.
@@ -460,9 +463,11 @@ It follows a machine-readable BNF grammar composed of
* `(` and `)` characters
* `&&` and `||` operators
* `SIG(PUBLIC_KEY)`, `XHX(SHA256_HASH)`, `CLTV(INTEGER)`, `CSV(INTEGER)` functions
* `SIG(PUBLIC_KEY)`, `XHX(SHA256_HASH)`, `CLTV(INTEGER)`, `CSV(INTEGER)`, `BLOCKED_FOR_ETERNITY()` functions
* ` ` space
**A condition that associates `BLOCKED_FOR_ETERNITY()` with other functions or operators is considered invalid.**
**An empty condition or a condition fully composed of spaces is considered an invalid output condition**.
Also, the maximum length of a condition is 1000 characters. // TODO: OK?
@@ -474,6 +479,7 @@ Also, the maximum length of a condition is 1000 characters. // TODO: OK?
* `(SIG(HgTTJLAQ5sqfknMq7yLPZbehtuLSsKj9CxWN7k8QvYJd) && CSV(3600))`
* `(SIG(HgTTJLAQ5sqfknMq7yLPZbehtuLSsKj9CxWN7k8QvYJd) && (CLTV(1489677041) || CSV(3600)))`
* `(SIG(HgTTJLAQ5sqfknMq7yLPZbehtuLSsKj9CxWN7k8QvYJd) || (SIG(DNann1Lh55eZMEDXeYt59bzHbA3NJR46DeQYCS2qQdLV) && XHX(309BC5E644F797F53E5A2065EAF38A173437F2E6)))`
* `BLOCKED_FOR_ETERNITY()`
#### Condition matching
@@ -827,6 +833,24 @@ Then the `25` units can be spent *exclusively* in a block whose `MedianTime - Tx
`CSV`'s parameter must be an integer with a length between `1` and `8` chars.
##### DESTROY function
###### Definition
Lock:
BLOCKED_FOR_ETERNITY()
Unlock: no unlocking function.
###### Condition
`BLOCKED_FOR_ETERNITY()` always return false.
###### Description
This fonction lock an output for all eternity. This makes it possible to destroy money.
#### Compact format
A transaction may be described with a more compact format, to be used in a [Block](#block) document. The general format is:
@@ -1033,14 +1057,14 @@ The document must be ended with a `BOTTOM_SIGNATURE` [Signature](#signature).
##### Data
* `Version` equals `6`
* `Version` equals `10` or `11` or `12`
* `Type` equals `Block`
### Peer
UCP uses P2P networks to manage community and money data. Since only members can write to the Blockchain, it is important to have authenticated peers so newly validated blocks can be efficiently sent to them, without any ambiguity.
DUBP uses P2P networks to manage community and money data. Since only members can write to the Blockchain, it is important to have authenticated peers so newly validated blocks can be efficiently sent to them, without any ambiguity.
For that purpose, UCP defines a peering table containing, for a given node's public key:
For that purpose, DUBP defines a peering table containing, for a given node's public key:
* a currency name
* a list of endpoints to contact the node
@@ -1101,7 +1125,7 @@ To be valid, a peer document must match the following rules:
##### Format
* `Version` equals `2` or `3`
* `Version` equals `10`
* `Type` equals `Peer`
* `Currency` is a valid currency name
* `PublicKey` is a [Public key](#publickey)
@@ -1226,6 +1250,9 @@ If HEAD.number == 0, HEAD.dividend must equal `null`.
* A block must have a valid signature over the content from `Hash: ` to `Nonce: NONCE\n`, where the associated public key is the block's `Issuer` field.
Please note: The V10 and V11 blocks and some transactions in these blocks are signed with a buggy version of TweetNaCl: [version 20131229](http://tweetnacl.cr.yp.to/software.html). As a result, some V10 and V11 blocks have an invalid signature (as well as some transactions in V10 or V11 blocks).
A complete list of invalid signatures in each currency will be compiled when the Ğ1 and Ğ1-test networks have successfully migrated to DUBP v12.
##### Dates
* A block must have its `Time` field be between [`MedianTime` ; `MedianTime` + `maxAcceleration`].
@@ -1249,11 +1276,14 @@ A block cannot contain revocations whose signature does not match the revocation
* A transaction must have at least 1 source
* A transaction cannot have `SIG(INDEX)` unlocks with `INDEX >= ` issuers count.
* A transaction **must** have signatures matching its content **for each issuer**
* A transaction's version must be equal to `3`
* A transaction's version must be equal to `10` or `12`.
* If transaction `Version` is greater than or equal to `12`, the `AMOUNT` of each output must be greater than or equal to `100`.
* Signatures count must be the same as issuers count
* Signatures are ordered by issuer
* Signatures are made over the transaction's content, signatures excepted
Please note: Some transactions in V10 and V11 blocks have an invalid signature. A complete list of invalid signatures in each currency will be compiled when the Ğ1 and Ğ1-test networks have successfully migrated to DUBP v12.
##### INDEX GENERATION
##### Identities
@@ -1413,7 +1443,7 @@ Each transaction input produces 1 new entry:
consumed = true
)
Each transaction output produces 1 new entry:
Each transaction output for which `OUTPUT_CONDITIONS != BLOCKED_FOR_ETERNITY()` produces 1 new entry:
SINDEX (
op = 'CREATE'
@@ -1587,7 +1617,7 @@ Rule:
maxTxChainingDepth <= 5
#### Global
#### Global validation
Global validation verifies the coherence of a locally-validated block, in the context of the whole blockchain, including the block.
@@ -2306,13 +2336,13 @@ EndIf
For each ENTRY in local SINDEX where `op = 'UPDATE'`:
REF_BLOCK = HEAD~<HEAD~1.number + 1 - NUMBER(ENTRY.hash)>[hash=HASH(ENTRY.created_on)]
REF_BLOCK = HEAD~<HEAD~1.number + 1 - NUMBER(ENTRY.created_on)>
If `HEAD.number == 0 && ENTRY.created_on == '0-E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855'`:
ENTRY.age = 0
Else if `REF_BLOC != null`:
Else if `REF_BLOCK != null`:
ENTRY.age = HEAD~1.medianTime - REF_BLOCK.medianTime
@@ -2644,7 +2674,7 @@ For each `IINDEX[member=false] as ENTRY`:
ENTRY.hasToBeExcluded = true
###### BR_G103 - Trancation writability
###### BR_G103 - Transaction writability
Rule:
@@ -2718,30 +2748,6 @@ For each `LOCAL_IINDEX[member=true] as IDTY` add a new LOCAL_SINDEX entry:
consumed = false
)
###### BR_G106 - Low accounts
Set:
ACCOUNTS = UNIQ(GLOBAL_SINDEX, 'conditions')
For each `ACCOUNTS as ACCOUNT` then:
Set:
ALL_SOURCES = CONCAT(GLOBAL_SINDEX[conditions=ACCOUNT.conditions], LOCAL_SINDEX[conditions=ACCOUNT.conditions])
SOURCES = REDUCE_BY(ALL_SOURCES, 'identifier', 'pos')[consumed=false]
BALANCE = SUM(MAP(SOURCES => SRC: SRC.amount * POW(10, SRC.base)))
If `BALANCE < 100 * POW(10, HEAD.unitBase)`, then for each `SOURCES AS SRC` add a new LOCAL_SINDEX entry:
SINDEX (
op = 'UPDATE'
identifier = SRC.identifier
pos = SRC.pos
written_on = BLOCKSTAMP
written_time = MedianTime
consumed = true
)
###### BR_G92 - Certification expiry
@@ -2867,9 +2873,8 @@ If all the rules [BR_G49 ; BR_G90] pass, then all the LOCAL INDEX values (IINDEX
### APIs
UCP does not impose any particular APIs to deal with UCP data. Instead, UCP prefers to allow for any API definitions using [Peer](#peer) document, and then letting peers deal with the API(s) they prefer themselves.
At this stage, only the [Duniter HTTP API](/HTTP_API.md) (named BASIC_MERKLED_API) is known as a valid UCP API.
DUBP does not impose any particular APIs to deal with DUBP data.
For inter-node communication, see [DUniter Network Protocol (DUNP)](https://git.duniter.org/nodes/common/doc#duniter-network-protocol-dunp) protocol.
## References