Commit c15d7008 authored by Cédric Moreau's avatar Cédric Moreau
Browse files

Initial commit

# Duniter website
Public site available at
## Reproduce it locally
You may want to reproduce this website locally, for developement purposes for example. Here are the instructions.
Clone the sources
git clone
Install python stuff
cd website
virtualenv .
source bin/activate
pip install pelican pelican-youtube markdown beautifulsoup4
Generate the site
Serve it
./ restart 8556
The website should be available at http://localhost:8556.
## Generate production site
You just need to give the production configuration file to Pelican:
pelican -s
You may want to change the production parameters, like the domain name: just edit `` and modify the `SITEURL` to whatever value you want.
For example if you want to host the site at ``, set:
Title: uCoin at the 5th Freedom Money Meeting
Date: 2015-02-05
Category: RML
Tags: RML, RML5
Slug: ucoin-at-the-5th-freedom-money-meeting
Authors: cgeek
Thumbnail: /images/calendar.svg
The uCoin project will be in the spotlight of the 5th Freedom Money Meeting (FMM) on coming **4th & 5th June 2015 in Paris**! This will be a great occasion for us to:
* make _a live demo_ by creating our FMM5 currency!
* present with more details both _core_ and _client_ softwares
* give plans of the project for the coming months
* explain more precisely the project's philosophy
So if you are a potential developer, tester or promoter of this project, do not hesitate to subscribe this event! Below is the original announcement made on []( website, with subscription & organization details. Looking forward to see you there!
> # 5th Freedom Money Meeting 4th to 7th June 2015 Paris
> ###### *Posted on [February 5, 2015]( 08:49 by [Galuel]( "View all posts by Galuel")*
> The 5th freedom money meeting (FMM5, “Rencontres des Monnaies Libres”) will take place in France / Paris – Montreuil, 4th, 5th, 6th and 7th June 2015\. You can subscribe emailing [galuel at glibre dot org](mailto:galuel at glibre dot org "mailto galuel at glibre dot org"). You can also contribute to the event by publishing those informations in your own website. The program is an indication, and will be modified during next months.
> * **4th June 2015 : uCoin core (for developpers only)**
> * Introduction, presentation and running uCoin core
> * Review of different WoT algorithm and how to code them in uCoin core
> * Code review of Nodejs, uCoin, objects, class and code architecture
> * How to compile and produce full uCoin package
> * RoadMap and more…
> * **5th June 2015 : Cutecoin + uCoin Apps (mobile) (for developpers only)**
> * Introduction and presentation of Cutecoin code architecture (Python etc…)
> * Compiling and Running last Cutecoin version, joining a uCoin free money community
> * Introduction and presentation of uCoin Apps, a uCoin mobile client
> * RoadMap and more
> * **6th June 2015 : Game “La Corbeille” new version 3.0 ! (Open to any contributor)**
> * morning (9h00) : subscriptions to the game and rules explanations, choice of money models to play
> * morning (10h00) : Game start with first money code played 80 years
> * Morning (13h00) : Lunch
> * Afternoon (14h00) : Game with next money code played 80 years
> * Afternoon (18h00) : collecting game data, first comments towards video and text production
> * **7th June 2015 : Other contributions**
> * Morning (10h00): Relative Money Theory conference about demonstration a new RTM Theorem “Law of transformation RdB/DU” : full equivalence (not completion) of referentials between free money and basic income based systems + how to contribute to RTM development
> * Afternoon (14h00) : Contributors to freedom money meet developers and exchange about how to join project and testing money community with CuteCoin.
> * How to play “La Corbeille 3.0″, collect data, developp the game community and development of a “Corbeille game data” internet site.
> * How to produce conference about freedom money, with return of experiences, sharing data and graphics.
> France / Paris – Montreuil (near [Métro Mairie de Montreuil]( "Mairie de Montreuil on OpenStreet Map") more details after subscription).
> <iframe src=";layer=mapnik&amp;marker=48.8615527456014%2C2.4410247802734375" width="425" height="350" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe>
> <small>[Afficher une carte plus grande](</small>
> Propositions of organisation for 6th Freedom Money Meeting, **must be sent before 31st August 2015**. The event needs to take place around November 2015, just send mail to any [OpenUDC]( "OpenUDC") or[uCoin]( "uCoin") contributor or connect to the XMPP chatroom.
Title: Recap of the 5th FMM: 4 days focusing on money systems!
Date: 2015-06-09
Category: RML
Tags: RML, RML5
Slug: recap-of-the-5th-fmm-4-days-focusing-on-money-systems
Authors: cgeek
Thumbnail: /images/calendar.svg
There we are! **5th FMM is now over**. It has been [a very rich experience of 4 days]( "uCoin at the 5th Freedom Money Meeting") focusing on money systems. Below is quick recap of what happened during these days for those of you who could not be here with us.
## First day: a dive into uCoin protocol
The very first day was a presentation made by your servitor (cgeek) about uCoin software & protocol. This was a travel across technical details about how is uCoin working, which are the rules and what is the life of currency propulsed by uCoin protocol.
The presentation was in French, but I took the time to translate it in case you wanted to read it. You can dowload the file here: [FMM5\_Presentation\_en](/files/FMM5_Presentation_en.odp "FMM5 uCoin presentation by cgeek").
## Second day: more about CuteCoin & uCoinApps softwares!
This day was an opportunity for client softwares to be presented. Let's see the two firsts: *CuteCoin* and *uCoinApps*.
### Cutecoin
The morning was dedicated to [Cutecoin](, the very first client of uCoin software. We steped through:
* Current state of the application
* Work to be done
* Development process (unit tests, continuous integration)
* And incoming features
Currently, Cutecoin allows you to do all the core operations made possible by uCoin software. It is also the first allowing to have an overview of the network!
<center> ![Web of Trust view from cgeek to inso](/content/images/2015/08/Capture-du-2015-06-09-21-38-05.png) <i>Web of Trust view from cgeek to inso</i> </center> <center> ![Overview of the meta_brouzouf currency network](/content/images/2015/08/network2.png) <i>Overview of the meta_brouzouf currency network</i> </center>
The presentation is also available for download here: [FMM5 Cutecoin Presentation (fr)](/files/FMM5 Cutecoin Presentation \(fr\).odp).
[![cutecoin_pres](/content/images/2015/08/cutecoin_pres.png)](/files/FMM5 Cutecoin Presentation \(fr\).odp)
### uCoinApps
The afternoon was dedicated to uCoinApps, the little brother of Cutecoin as it is the second client for uCoin. uCoinApps is an Android application that allows you to:
* Connect to an existing currency network
* Create your personal account
* Publish your identity
* Certificate other members
* See your account's balance
* Transfer money
The application is available on [Google Play]( You may also find [a tutorial (french)]( for using it at [](
The author of the application also made a presentation avaialble for download: [FMM5 uCoinApps Presentation (fr)](/files/FMM5-uCoinApps-Presentation-fr.odp).
## Third day: simulation of 160 years of money systems
This day was an opportunity for non-developers to discover a french game called [La Corbeille]( This game consists in simulating an **economy** by producing values using the only available currency system. The goal is to understand the underlying code of a currency system and see the consequences of using it. During this session, we have tried 2 money systems:
* Debt Money system (the one used by almost all currencies over the world, including € and $) in the morning
* Freedom Money system (the one used by uCoin) in the afternoon
The results of this session are available for download on GitHub: [LibreOffice Calc file](
Also, you can access the project [Ğeconomicus]( which provides a set of free graphics & tools to create your own economy simulations based on 80 years human lifetime. Here is a recap video of this journey (french), so as another resume on []( :
<iframe width="560" height="315" src="" frameborder="0" allowfullscreen></iframe>
## Fourth day: non-technical contributions
A last day was dedicated to other contributions than coding. These are more around the project, for example explanations, theoretical fundamentals, etc.
### A new mathematical demonstration
The morning has seen the demonstration by Stéphane Laborde, the author of the RTM (Relativity Theory of Money), that a currency with a given rate of money creation and providing a Basic Income to its people by using a tax **have an equivalent Freedom currency** that only uses money creation. This mathematical demonstration can be found in the last version of the RTM in this file: [Relativity Theory of Money (french)](
### Presentation of David Chazalviel: "The RTM in color" and "The RTM for the kids"
[David Chazalviel]( gave us a presentation about his 2 last contributions for spreading about Freedom Money:
**The RTM in color** ([english]( or [french]( version) is a brilliant web application to simulate and explore the concepts of a Freedom Money.
**The RTM for the kids** (available in [french]( only) is an interactive presentation trying to explain what is a Freedom Money and the RTM to kids, thanks to Elise and its fairy friend:
### Subscription to metab_brouzouf currency
The afternoon was the occasion for people to try Cutecoin and [subscribe to metab_brouzouf currency](! As you can see, we now are about 23 active members testing uCoin:
And here is the currency overview:
## Conclusion
This 1st edition of 2015 FMM was a very successful meeting with a lot of new people met and introduced to money codes, many technical details were explained and **the very first client applications** Cutecoin & uCoinApps have been presented and tested by final users! What will await us for [next FMM in Valence during November 2015](,4.9135516,11z/data=!4m2!3m1!1s0x47f55799c63221c7:0x408ab2ae4bfb580)? Coming months will tell us, but be sure a lot of work is to be achieved until then!
Title: The Meta_Brouzouf experiment is over!
Date: 2016-03-22
Category: Technique
Tags: Technical
Slug: bye-metabrouzouf
Authors: cgeek
There we are! 14 months after the launch of testing money named *Meta_Brouzouf* on January 21th 2015, it is now time for us to abandon this money and "stop" this experiment in order to go one stage further!
But why? What will happen to this money? And more importantly, what's next?!
Pieces of answer.
## Recalls about Meta_Brouzouf
For those who hadn't followed closely this experiment, here are some recalls to situate the context.
### The initial goal: the birth of new client softwares
The uCoin project started during summer 2013. After a year and a half of development, on January 2015, the bases were considered established and the first pieces of code ready to be tested. It was then important to propose a first currency, was it a testing one, to allow other developers to produce *client softwares* equiped with graphical interfaces easing the money usage.
<center>[![](](</center> <center>_Logo of the first client: Sakia software_</center>
Indeed, even if uCoin is the software at the heart of the money, its role *is not* to manage *your* transactions specifically, *but to handle any document* making it possible to live.
It is the client softwares that allows usage of money supported by uCoin software, by producing the documents corresponding to your actions and *then send these to the network* in order to treat them: it could be a transaction to pay someone, a certification of some individual from the web of trust or even a membership demand to the monetary community.
The uCoin software, on its side, only treats these documents and adds them to the common register of the currency named *Blockchain* which contains the whole set of the money network data: monetary units, made transactions and individuals of the web of trust.
<center>![image](</center> <center>_Logo of "Android App" application_</center>
#### The first clients
We can only observe that this objective, at the end of the experiment, was reached! Brave developers gave their body and soul to produce the following precious softwares:
* [Sakia](, a complete desktop software for Linux, Mac and Windows
* [uCoin App](, an Android application for your smartphone
* [uCoinWallet](, another Android application for your smartphone
* [Cesium](, a multiplatform client which works in your favorite browser
#### And even a first server packet!
It's worth noting an active contributor of [YunoHost]( team also developed [a uCoin packet for YunoHost]( greatly easing the installation of uCoin for self-hosting addicted people!
### The known limits
Nevertheless, this is experiment was though and built from the start to constitute a **testing currency**. So it had no vocation to last, but instead to test the application in more realistic conditions with the aim to fix the most early and rough bugs.
For this case, we chose parameters which are not compliant with long term working:
* a monetary growth of **10% per day** rather than year
* a minimum number of **3 certifications** to be a member
* a certification and membership expiry delay **limited to 1 month**
It has to be understood that **10% per day** rather than per year is tremendous, indeed the monetary mass grows exponentially: by a year (that is, after a complete revolution of the Earth around its orbit), we create in reality **1,166,641,437,000,000 times more money** than in a normal case. Yes, you read it right: it is a **1 million of billion of times** quicker than 10% a year. The money cannot take value at such a rythm, which prevent it to be used as a medium of exchange for both medium and long term.
As well, the minimum number of **3 certifications** to be a member is enough for a dozen member community but becomes way to light for a bigger community because the rules becomes too easy to pass, and fake accounts are no more bothered by this contraint (these still are bothered by distance rule, however).
Finally, the lifetime of **1 month** for certifications and memberships is way too light. Serveral members of the testing community were rapidly excluded just because of this duration, their certifications and membership being expired. A value of **6 months** would be more acceptable.
For these reasons, no chance for this money to stay in time.
## The experiment results
Despite these parameters which promised the early end of this testing currency, this latter totaly played its role notably because [several client software were borns](#thefirstclients), but also no less than **115 users** have actively participated the currency, and this despite of the project youth which requires a certain effort to reach the status of individual creating money.
Indeed to succeed its account creation it was required by each of them to:
* install Sakia client software
* follow an [english tutorial]( to create their identity in Sakia, connect to the network and publish their membership demand to the community (and most users were frenchies!)
* make an explicit demande, written on the [uCoin forum]( with few identity proofs in order to receive certifications
It is thanks to these people that we could find a good number of bugs, minors or majors, but also identify the limits of the protocol in its initial version which necessited to be modified to handle bigger community sizes, which is important for the currency to have a real efficience.
### Some numbers
To end this post and mark the end of this testing currency, we propose you some numbers extracted from [Blockchain](, the public database shared by the whole currency network, and which you could yourself consult and exploit:
* **424** simulated year
* **137 identities** published with **115 identities** who reached the member status (and so created money)
* **1676 certifications** of identities were made
* **466** membership / actualizing demands were sent
* **1191 transactions** realized
* **7193** dividends (UD) were created (1 dividend / day / member)
* **1,820,920,587,213,340,000,000** Meta_Brouzouf (money units) created
### The currency stop
> I don't get it, I thought uCoin was based on a peer-to-peer model (P2P) and so this tool was not centralized? How could "stop" the experiment if I, with my personal node, decide to make the adventure going on?
In reality, **we cannot force the stop of the currency**. Indeed, its infrastructure is actually P2P. So if 3 members decide to continue to make the currency live by adding each one there node working and also keep up certifying themselves mutually, then the currency won't stop working.
Simply, these 3 members will have a money "belonging to them", they will be the only ones able to create it and probably the only ones to use it and accept it.
This P2P aspect is crucial to our eyes since it makes extremely hard to take over the control of a libre currency, our common tool of exchange whose lifetime expectancy aims at exceeding human's one.
Yet if we wish to realize a libre currency, this one has to be robust enough and be time proof: for us, only decentralized systems (peer-to-peer) are able to fit this goal. That's why uCoin is P2P software.
### Why stopping this money?
The objectives were reached, and more importantly we were meeting technical limits which no more allow to ensure a good software functionality.
Despite the fact the software still works and users can make it live forever, we do not want to ensure data consistency for this currency anymore.
It might occur to have incorrect amounts of money transfered, or even stranger events! Don't be surprised, we won't: we are already looking in a new direction.
## What's next?
As said earlier, this testing currency was an occasion to discover the limits of this 1st version of the protocol, soberly tagged **0.1**.
We have already implemented its next version **0.2** which carries a lot of newness. And so, what will happen?
The next couple of weeks will tell you.
<center><div style="width: 400px">![](</div></center>
Title: An overview of 0.2 protocol : transactions
Date: 2016-04-04
Category: Technique
Tags: transactions, protocol
Slug: transactions-0-2-overview
Authors: inso
Thumbnail: /images/code.svg
This one will let us realize many new things, like creating advanced applications based on ucoin blockchains or even interface with existing crypto-currencies !
What was missing in 0.1 protocol ? Why did this lacks had to be fixed ? This article, oriented to the developers, should be of interest for anyone interested in blockchains and linked technologies.
## What was missing in 0.1 protocol
We created 0.1 protocol with a really simple goal. To create a blockchain able to track the origin of money, to ensure that [double-spending](( ) abuses are not feasible, and only individuals could co-create money. To do so, we used the principle initiated by [Bitcoin]( : a blockchain, which let us, from block to block, track the money, from address to address. Money is trackable from present to its creation. We can check that it was created by a member of the community at this date, and that it was spent only once at a time. This protocol let us develop really fast simple applications using the universal dividend. Any individual member co-creates money, and can transfer it to another address. The form of a transaction was as the following :
ISSUERS: List of identifiers of issuers signing this transaction
INPUTS: List of source transactions, to which the signers must be the owners
OUTPUTS: Identifiers of the recipients of this transaction
But this protocol didn't let us create advanced features really important about money. To understand, we have to get back to a choice realized on the design of our monetary software.
uCoin is a software which identifies its users thanks to a [web of trust]( For the individuals to be identified, they certify a trust of existence and uniqueness. This act, from individual to individual, composes a web which lets anyone knowing who is recognized by whom. However, for the individuals to be recognized, and to stop [sybil attacks]( from happening, this web has to be tense and tight. A sybil attack consists in creating many fake identities to take the control of the network and the monetary community. Important efforts have to be executed for a cheater to multiply identities, so that cheating remains a minor factor.
The consequence is that individuals have to be able to create many communities (and so, many moneys). Indeed, the web of trust is of a limited diameter (we will talk in details about it in a later article). Individuals need to be able to create many monetary communities so that any individual has the right to co-create a free money. Furthermore, creating many communities let us test many web of trust rules, looking for the best parameters. Thus, dozens of communities could potentially exist, and will have to exchange their money thanks to change rates. This exchange relationships has to be as automated as possible so that it is transparent for the users. Also, we would like to avoid having to introduce any trusted third party.
<center>![Swap exchange](</center>
In protocol 0.1, it is not possible to automate this inter-community exchange. Indeed, the exchange needs both party to trust each other because no transactional lock is possible in the blockchain :
<center>![Protocol swap exchange with protocol](</center>
You see : we had to find a solution and enhance our blockchain.
## Never reinvent the wheel
Bitcoin universe is rich, after 7 years of experimentation, their blockchain suffered by defects. Developers had to answer to many limitations, and had to create new features often. Even today, Bitcoin community continues to evolve and to think about developments to realize to enhance this software.
In Bitcoin blockchain, it is notably possible to program [scripted transactions]( in a language which is not [turing complete]( This scripting language let us experiment and realize new features using Bitcoin blockchain, without having to develop new versions of the software.
Bitcoin universe has also seen many [alternate crypto-currencies]( appear. Often, these forks are realized using simple cipher algorithm changes, or consensus algorithms. These alternative currencies let them users get their part of monetary creation, because Bitcoin does not anymore. Indeed, first miners have reaped everything, and one must now work for them to get his share.
For users to realize safe places of change, the algorithm of crosschain transactions appeared. It makes users of distinct moneys be able to exchange between them monetary units without trusted third party, and without the need to trust each other. These units are present in different blockchains, and yet, crosschain exchange will link the exchange between the two blockchains.
<center>![Protocol 0.2 swap transactions](</center>
Previous example presents an ideal case, where Alice and Mark exchange their money without any interruption in the process. You should note that money can here get stuck in the blockchain : if Mark sends his money to Alice, and Alice does not answer anymore, Mark cannot get his money back. This is why it is necessary to introduce refund documents in the process. These documents are transactions which refund money owners. The algorithm is a bit more complex, so hang on :
<center>![protocol 0.2 refund](</center>
## Keep It Simple
To develop a scripting language into our transactions would have necessitate to much efforts, while we do not want our blockchain to transform in an application blockchain. We decided to develop this transaction mechanism in his simplest form : a writable condition in the blockchain.
How does it works concretely ? Transactions still have a form of *Input* -> *Output*. Input his what is available for spending, while the output corresponds to money which will become available for spending for the recipient. But new elements makes their apparition : *Unlock parameters* and *locking conditions* of the money placed in this transaction. In practice, this change is simple. The transaction is now of the form of *Input* -> *Unlock* -> *Output lock*. The form a transaction is like the following :
ISSUERS: List of identifiers of the signers of this transaction
INPUTS: List of source transaction, to which the signers must be the owners
UNLOCKS : List of unlock paremeters of the inputs
OUTPUTS: Locking conditions of the money
2 types of locks are possibles.
* A lock **SIG(PUBKEY)** which means *The signature of PUBKEY is necessary to use this money*.
* A second lock is **XHX(HASH)**, which means *X number generating HASH is necessary to use this money*.
These locks can be combined with operators **OR** and **AND**. Finally, it is possible to place a temporal lock **LOCKTIME** on a transaction. This lock prevents a transaction from being written in the blockchain before a fixed time.
## Some examples of the new possibilities
Our simple transaction of 0.1 protocol transforms into a new form. To send money to public key **A** we place a locking condition **SIG(A°** meaning *Transaction has to be signed by pubkey A for this money to be unlocked*.
To send money to a pubkey **A**, while retaining control of the time it will be spendable, we will use a lock **XHX(HASH)** combined with a **SIG(A)**. We will choose a number **X** which, hashed, will generate the **HASH**. We will give this number **X** to **A** only when we will want him to be able to spend his money, for example when he did do his part of a contract.
We can also consider to implement *consumable* bills. A bill will be locked on a money consumable only by a secret number hidden in the bill. Physical destruction of the bill will reveal the number and let one get the money. A lot of physical destruction means are possible, like tickets to scratch, a chemical revealer, etc.
These are only first ideas we had while discussing between us. These new protocol rules will allow a lot of new systems to be developed, always more decentralized. The developers only need to appropriate these new means and develop new applications, for individuals to become always more free !
Article redacted by [@Inso](, uCoin contributor and founder of Sakia client
Title: uCoin becomes Duniter!
Date: 2016-04-24
Category: Divers
Tags: uCoin
Slug: ucoin-rename-duniter
Authors: cgeek
Thumbnail: /images/duniter-logo.png
From now, and for the release of protocol 0.2, the project *uCoin* becomes *Duniter*. uCoin was a name chosen at the begining by its creator cgeek, and with hindsight we thought it did not represent anymore the software we aimed to develop.
## Why wasn't uCoin the right name ?
The name uCoin was here to remind cryptocurrencies like Bitcoin. The U of uCoin (pronounced "You") wanted suggest the idea that "You, the user, are going to create the money". But this link with Bitcoin was wrongly chosen for many reasons :
* The term « coin » indicated that uCoin was a money, and more over *only one* money whereas the software is able to create many of them
* the « you » term could suggest it was about individual currencies, where a uCoin money is common and co-produced by its users, and so is not individual
* our software may use a blockchain, but this one is particular in the way where there is no run for power
* a money named uCoin was initiated during our developments but based on Bitcoin, bringing then a confusion with our project *from which it is not apart*
Last point but not the least, was finding a [logo idea]( for uCoin extremely difficult. After more than a hundred comments on the forum, we were not satisfied. We understood that the current name wasn't communicating enough the founding principles of the project. And since the sixth edition of the free money meetings, we were looking for an alternative name.
## Let's present Duniter
« Duniter » for « Dividend Uniter » : the software which *makes* the Dividend unit.
The name we were looking for had to pass multiples ideas :
### The Concept of Flow
This concept is fundamental to us. Indeed, we acknowledge that humans have a limited life expectancy, and that arrival and departure of individuals in the economy form a continuous flow. This software takes this aspect into account through the form of the money and its members, the individuals.
<center>![flux]( <br/>*Human flow in France from 1920 to 2020*</center>
Renewal within the flow *through life expectancy* is used to deduce the monetary growth rate which imply a monetary symmetry, spatially and temporally, between the individuals.
### Relativity Concept
A growth rate of 10 % imply a 0.8 % growth of the numbers each month. In this referential, it is not easy to compare values years apart by comparing these numbers. But in our software, individuals issue a universal dividend (abbreviated « UD »). This one is stable and does not change : it is always worth 10 % of the monetary mass each year. Thus, by comparing the numbers *relatively* to the created UD, we can compare and measure in a stable referential in time.
<center>![Relative and Quantitative](</center>
That's why « Duniter » means « Dividend Uniter », because this name wish to evoke the dividend unit, particular to free moneys : the Universal Dividend or « UD » .
### A software to generate moneys, in plural
The name of the software was supposed to mean it would generate free moneys. This is then each one, by initializing its own Duniter network, that will be able to create and give a name to a new money. This name had to suggest a "software" name instead of a "money" name. This is why this new name is sounding like this, and does not suggest the money anymore through the removal of the « coin » term.
Dividend Uniter, or Duniter, express better the concept of a tool to create free moneys with universal dividends.
## Duniter Logo
With this new name, more evocative, this logo was found fast. It evokes the sand dune swept by the wind. The dune is an invisible flow, a perpetual entity. Each new grain of sand feed constantly the dune represented by the Duniter logo, while others are brought away by the wind, making of it a changing but stable entity.
<center>![Duniter logo](×250.png)</center>
## Changes
### A new protocol
This name change is the occasion for us to use a new version of the protocol (0.2), not reverse-compatible with the 0.1. Duniter becomes the new reference implementation which fixes and enhance its ancestor uCoin decisively.
This protocol will notably permit the [inter-money exchange]( *without any trusted third-party*, a feature particularly interesting to convert a money in another easily, freely and in a totally secured way.
### A graphical interface !
Duniter will introduce a graphical interface to use the software, whose you can have a preview underneath ! *Finally*, the software is available to a wider range of users than the ones used to the Linux terminal.
<center>![Duniter UI](</center>
### A new money !
Soon, we will start a new money. This one will aim to being used a real conditions : it will be an **experimental** as was Bitcoin 7 years ago.
The launch will be announced on the blog, forum, newsgroup, Diaspora*, Twitter, and others, follow-us to remain informed as early as possible ! And for the more impatient, you can also come on the [XMPP room]( where you will be able to obtain all the latest information .
### Migration of our tools
As the project name changes, the web addresses of our tools change too :
* Development repositories : –>
* Website : –>
* Forum : –>
* Translation tool : –>
* Hosting of our XMPP server, chat room : –>
Please note that any past link using will be automatically redirected to the same link with, so that they remain valid while we switch to a new name.
Do not hesitate to tell us what you think about this new name on the [forum]( or by participating to the [7th money meeting in Laval from the 2th to the 5th of June]( !
Now, you can tell everyone that uCoin name has changed and is now Duniter !
Title: Introducing members management
Date: 2016-05-13
Category: Toile de confiance
Tags: wot, toile de confiance
Slug: introduction-a-la-toile-de-confiance
Authors: greyzlii
Thumbnail: /images/network.svg
Duniter is a software which allowing the creation of a free money as described by the RTM (Relative Theory of Money). This theory implies that monetary units are co-produced by each of the members of a given community. It is therefore essential that the members of the community are identified and recognized.
In a word without dishonest people, a simple declaration of identity could be enough to become a member (and thus co-produce monetary units). But in our world, when it is about money, cheating cases can potentially come.
Actually, it is tempting to register with many identities and thus produce a surplus of monetary units for its own advantage. This is even more true when it is about digital identities and when it is easy to create as much as we wish. We call such a thing a *« sybil attack »*.
One should ensure sure that the members are disposing of only one digital identity.
## Who is to trust ?
How to ensure that the members are disposing of only one digital identity ? Which organization is necessary ?
There are two types of possible organization : the organizations with a trusted third-party, and the self-regulated organizations.
To illustrate the organization with a trusted third-party, let's take the example of population census. These is the administration of the state which « creates » the identities and registers them in different files (aka, data bases) of the state. These officials are acting like « trusted third-party » in the name of the state. The control means used can be administrative documents (maternity declaration, proof of address, ...). These means are far from being foolproof since it is trivial to create fake documents (and then obtain real-fake papers). This system is based on the judiciary system to deter fraudulent behaviors.
To illustrate an auto-regulated organization, we can use the example of the queue area. People arrive one after the others, even if no one is really delighted to wait for his turn, each one respects the rule, which regulates a queue ; first-come, first-served. Given that everyone knows who came first and who came later, anyone is able to control that there is no cheating. To violate these rules expose us to a strong social disapproval, and an exclusion of the queue.
## Web of trust
Duniter makes the choice of a self-regulated system by its own members.
Let's not forget the goal which is to ensure that the individuals are able to register with only one digital identity.
The system distinguish two types of digital identities : the *member identities* and the *non-member identities*. Only the members identities are co-producers of money.
Any individual which is already a member is in capacity, thanks to a signed digital document, to certify identities (members and non-members). That is to deliver **certificates of authenticity**.
These certificates, given from ones to the others, makes a mesh called « **web of trust** ». This web of trust is used by Duniter to determinate who is a member and who is not.
<center>![Global Web of trust of the test money Meta Brozouf in June of 2015](</center>
## Operating rules of the web of trust
Rules governing the web of trust of a Duniter money is parametrized when the money is being created (initialized) by it's founders, and *cannot be modified later*. It is thus important to pay a particular attention to these parameters.
**Self-declaration of a digital identity**
An individual, who whishes to become a member of a community, has to issue its digital identity.
On Duniter, a digital identity is composed of :
* a private cryptographic key, knew only by the individual and not broadcasted to the network, is used to sign digital documents
* a public cryptographic key, knew be anyone, is used to check that a document has been signed by the private key of the individual
* a pseudonym
The self-declaration of identity by itself is not enough to become a member but is the first step of the process.
As any identity card, a digital identity has an **expiration date**. If it is not renewed regularly, it becomes invalid.
In a money created with Duniter, the maximum validity duration of a member identity is configured with the parameters *msValidity (Membership expiry Delay)*
To become a member, an individual must collect a given number of certifications from existing members. These certifications have an expiration date. To keep a member status, a digital identity must be continually re-certified by members.
The number of necessary certifications to become a member is configured by the parameter *sigQty (Min Required Certs)*. The life expectancy of a certification is configured with the parameter *sigValidity (Cert Expiry Delay)*.
**Anti-sybil protections**
Complementary rules are applied to ensure the safety of the web of trust against a group of attackers.
* The number of steps
A group of members could associate to create fake identities and certify them to let them become members. Even more, they could use these fake members to certify new fake identities, creating then a really big number of illegitimate members.
<center>![Sybil Network](</center>
To prevent this attack, Duniter ensures that members are close enough one to the others in the web of trust. In the example below, the member C is two steps from A.
<center>![2 steps](</center>
When an individual is susceptible to become a member (that is, he obtained enough certifications), Duniter runs the following verification procotol :
* Members who issued enough certifications are used as « points of control » (*sentries*).
The number of issued certifications depends of the number of current members. N is the number of members, Y(N) is the number of issued certifications required for the members to be considered « point of control ».
N Y(N)