[ref] rename UCP/DUP -> DUBP + make implementation agnostic

- fix some typos
- 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
 
@@ -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.
 
@@ -105,7 +105,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 +117,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 +250,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 +320,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:
 
@@ -1038,9 +1038,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
@@ -1587,7 +1587,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.
 
@@ -2644,7 +2644,7 @@ For each `IINDEX[member=false] as ENTRY`:
 
     ENTRY.hasToBeExcluded = true
 
-###### BR_G103 - Trancation writability
+###### BR_G103 - Transaction writability
 
 Rule:
 
@@ -2867,9 +2867,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