Skip to content
Snippets Groups Projects
Commit 39f2bf19 authored by Cédric Moreau's avatar Cédric Moreau
Browse files

Update protocol

parent a4eb4a91
No related branches found
No related tags found
No related merge requests found
......@@ -26,9 +26,8 @@
* [Keyblock](#keyblock-1)
* [Status](#status-1)
* [Forward](#forward-1)
* [Transaction](#transaction-1)
* [Implementations](#implementations)
* [Requirements](#requirements)
* [APIs](#apis)
* [References](#references)
## Vocabulary
......@@ -43,7 +42,7 @@ Monetary Contract | A document gathering the informations defining the community
UCP aims at defining a data format, 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 does not defined all of the currency parameters' value but only the rules over it.
This document is describing UCP in a bottom-up logic, so you will find first the details (data format) of the protocol to end with general protocol requirements.
This document is describing UCP in a bottom-up logic, so you will find first the details of the protocol (data format) to end with general protocol requirements.
## Conventions
......@@ -662,7 +661,16 @@ members | Synonym of `members(t = now)`, `wot(t)`, `community(t)`, `keychain(t
### Neutral documents
> TODO
Some documents are to be considered *neutral*, i.e. they do not have specific rules of interpretation nor rules impact. If a P2P node receives such document, it is free on how to handle it.
Here is the list of neutral documents:
* Public Key
* Amendment (not an exchanged document)
* Peer
* Wallet
Other documents are all subject to interpretation and described in the following paragraphs.
### Keyblock
A Keyblock can be accepted only if it respects the following rules.
......@@ -722,25 +730,46 @@ To be valid, a block fingerprint (whole document + signature) must start with a
> Those 2 rules, and notably the second, ensures a specific member won't keep the control too long
### Status
The network needs to be able to discover new peers inside it and eventually know their state to efficiently send data to them. For that purpose [Status](./#status) messages are used to introduce nodes to each other and keep a bilateral state of the connection.
> TODO
Protocol is the following: for a given node receiving `Receives` message, it should answer `Answers` status type and apply `Impacts` rules.
Receives | Answers | Impacts
-------- | ------- | --------
`ASK` | | Answer the estimated status of the node toward asking node. Answer can be any status other than `ASK`.
`NEW` | `NEW_BACK` | Remove any existing route for transactions to node emitting the `NEW` message. Consider the emitter as able to receive data. Send `NEW_BACK` as a response. May also send new `Forward` rule.
`NEW_BACK` | | Remove any existing route for transactions to node emitting the `NEW_BACK` message. Consider the emitter as able to receive data.
`UP` | | Consider the node as able to receive data.
`DOWN` | | Consider the node as *no more* able to receive data.
### Forward
> TODO
The network also need *multicast* features for efficiently distributing transactions over the network (which can be numerous). Rules is the following.
## Implementations
#### Authenticity
When receiving a Forward from another peer, receiving peer *SHOULD* verify forward authenticity (using his local public key store).
If document cannot be authentified, receiving peer *SHOULD NOT* interprete the document.
> TODO
#### Interpretation
### Requirements
If `To` field matches the receiving peer, message *SHOULD* be interpreted. Otherwise, it *SHOULD NOT* be interpreted.
> TODO
A forward document asks `From` peer to be forwarded any transaction concerning a set of keys. This set is either all keys (`Forward: ALL`) or a set of known keys using (`Forward: KEYS`, plus `Keys:` list).
So if a transaction is received thereafter, and either `Sender` or `Recipient` field of the transaction matches the set of keys, then the transaction *SHOULD* be forwarded to `From` peer.
### Transaction
## Implementations
### APIs
> TODO
UCP does not imposes a particular API to deal with UCP data. Instead, UCP prefers to allow for any API definition using [Peer](#peer) document, and then leting peers deal themselves with the API(s) they prefer.
At this stage, only [uCoin HTTP API](/HTTP_API.md) (named BASIC_MERKLED_API) is known as a valid UCP API.
## References
> TODO
* [Relative Money Theory](http://fr.wikipedia.org/wiki/Th%C3%A9orie_relative_de_la_monnaie), the theoretical reference behind Universal Dividend
* [OpenUDC](www.openudc.org), the inspiration project of uCoin
\ No newline at end of file
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment