create RFC DUBP V12

• 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

-# DUP - Duniter Protocol
-
-> This document reflects Duniter in-production protocol. It is updated only for clarifications (2017).
+# DUBP - DUniter Blockchain Protocol
 
 ## Contents
 
@@ -32,7 +30,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 +39,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
 
@@ -105,7 +103,7 @@ No new line character exists in a signature. However, a signature may be followe
 
 ## 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 +115,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 +248,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 +318,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:
 
@@ -460,9 +458,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)`, `DESTROY()` functions
 * ` ` space
 
+**A condition that associates `DESTROY()` 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 +474,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)))`
+* `DESTROY()`
 
 #### Condition matching
 
@@ -827,6 +828,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:
+
+    DESTROY()
+
+Unlock: no unlocking function.
+
+###### Condition
+
+`DESTROY()` 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:
@@ -1038,9 +1057,9 @@ The document must be ended with a `BOTTOM_SIGNATURE` [Signature](#signature).
 
 ### 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
@@ -1413,7 +1432,7 @@ Each transaction input produces 1 new entry:
         consumed = true
     )
 
-Each transaction output produces 1 new entry:
+Each transaction output for which `OUTPUT_CONDITIONS != DESTROY()` produces 1 new entry:
 
     SINDEX (
         op = 'CREATE'
@@ -2718,30 +2737,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 +2862,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