Pré-étude d'un système monétaire ouvert, transparent et sécurisé.

Cette étude s'inscrit dans le cadre d'une réflexion sur la monnaie et les dérives du système monétaire actuel.

Elle s'appuie sur des publications de Maurice Allais, Paul Grignon et Stephane Laborde.

Elle propose, en s'appuyant sur des technologies connues, reconnues et standardisées, une solution technique pour réaliser un système monétaire plus juste.

Cette solution devrait permettre à des communautés locales telles que les SEL, ou inter-nationales, de s'échanger des biens ou des services, ou de recevoir des dons en échange de valeurs données gratuitement (e.g. codes sources et créations artistiques sous licences libres ou CC).

Elle devra être applicable aussi à la communauté entière des humains de notre petite planète.

Pour les aspects techniques de cette étude, une connaissance des signatures, certifications, chiffrements et authentifications SSL ainsi qu'une connaissance de l'architecture et du fonctionnement des DNS, sont fortement recommandées.

1. Définition d'une Unité de Monnaie.

Une unité de monnaie est définie comme une information unique. Donc un numéro de série, un nom désignant la monnaie donc propre à celle-ci, et une quantité de valeur de la monnaie. Le tout est signé par l'autorité émettrice. Pour des mesures de sécurité l'autorité émettrice ne doit pas être unique (eg. associée à une seule clé privée). Aussi l'autorité émettrice associée à la clé privée pour la signature doit faire partie de l'information de l'unité de monnaie.

Cette unité de monnaie peut donc aussi être appelée billet électronique.

Sans s'attarder sur la composition bit à bit de l'information égale à une unité de monnaie, qui devra être assez petite pour une utilisation performante par les ordinateurs d'aujourd'hui, voici le résumé du contenu de ce billet électronique :

- nom propre de la monnaie.

- quantité de valeur dans cette monnaie (eg 1, 100 , 10000 ou 1,2,4,8,16 ... ).

- nom de l'autorité émettrice du billet.

- numéro de série du billet.

- signature de l'autorité émettrice.

2. Sécurisation de la masse monétaire.

Le problème qui se pose alors est celui de la non-duplication de la monnaie. A cela nous avons déjà une solution : la même qui empêche la duplication d'un nom de domaine : DNSSEC.

3. Répartition de la masse monétaire et compte "bancaire".

L'idée d'utiliser un mécanisme similaire à DNSSEC pour empêcher la duplication de monnaie implique le mécanisme de répartition de la monnaie :

Des serveurs racines qui référencent toute une monnaie numérique donnée (peut-être à terme toute les monnaies du monde) et sa répartition dans différentes zones d'échanges de premier niveau.

Des serveurs de zone du premier niveau qui référencent toute les monnaies de leur zone et leurs répartitions dans leurs zones d'échange du second niveau.

Et ainsi de suite...

Aux extrémités de l'arbre on a des comptes de monnaies. Chaque compte est utilisable par une ou plusieurs personnes.

4. Transaction monétaire

Une transaction monétaire est donc un transfert de billets électroniques, d'un compte à un autre.

Tout comme dans le mécanisme DNSSEC chaque noeud ie chaque serveur et compte possède un ou plusieurs certificat(s) pour une durée de validité donnée et d'un ou plusieurs certificat(s) de révocation associé(s) pour des raisons de sécurité évidentes.

Rappel : un certificat numérique est un ensemble d'informations identifiant quelque chose (eg un nom de domaine ou une IP pour un site web, un nom ou un numéro de sécurité social ou une empreinte ADN pour une personne physique), plus une clé publique dont seul l'objet du certificat possède la clé privé, le tout signé par une autorité de confiance.

Dans le cas présent, chaque noeud doit se faire reconnaître de son noeud parent, ie se faire signer par lui son certificat. Et reconnaître ses noeuds fils, ie signer leurs certificats.

De plus tous doivent connaître les certificats des serveurs racines afin de pouvoir vérifier la chaîne de certification.

Une transaction devra donc parcourir l'arbre des comptes depuis le compte débiteur jusqu'au compte créditeur.

Note: une autorisation de prélèvement consistera à autoriser la programmation de certains ordres sur le compte débiteur.

Le compte débiteur pourra utiliser d'un certificat spécial pour chaque autorisation de prélèvement. Qu'il pourra évidemment révoquer.

L'Annexe A démontre par l'exemple le mécanisme de transaction sécurisé.

5. Création monétaire

Le montant et la répartition de la création monétaire est fait par des comptes spéciaux et dédiés uniquement à la création de monnaie.

Ces comptes là sont connues comme tel par les serveurs racines d'une devise, ils ne peuvent que créer et repartir de la monnaie, et sont les seuls à pouvoir le faire.

Il est évident que la devise d'une communauté qui partage ce contrôle de façon la plus juste donc de façon transparente et démocratique, en essayant de garder une inflation/déflation nulle, et en rétribuant à part égale, inconditionnellement, tous ses membres à chaque création de monnaie; se verra plébiscité au détriment d'autres monnaies.

A terme on peut espérer qu'une monnaie pratiquant le dividende universel pour chaque humain l'emportera.

6. Prêt

Ce système interdit d'office de prêter de la monnaie qui n'existe pas, et donc, tant que les gens n'utilisent que de la monnaie, la création d'«argent dette».

Encore une fois la transparence des noeuds du réseau, serveurs racines compris, n'est pas obligatoire. Cependant c'est un gage de confiance et les noeud, ou les devises dont les noeuds, sont moins transparent(e)s auront probablement moins de succès. Dans un arbre entièrement transparent on pourra voir où la monnaie qu'on a prêté est allé. En interrogeant les sauvegardes des journaux (logs) des machines on pourra aussi retracer le parcours de la monnaie. Là encore la politique de suppressions des journaux, tout comme leur accessibilité, est laissé à chaque noeud.

Un système équitable avec dividende monétaire pourra, en cas de défaut de paiement et si l'argent a été prêté sans usure, ie notamment si les intérêts ont été payé au moment du prêt, privé l'emprunteur de tout ou parti de son dividende, pour rembourser le prêteur.

7. Taxe

A chaque noeud du réseau une taxe pourra être prélevée. La taxe pourra être différente suivant chacun des 3 sens possibles de la monnaie (suppression, ajout, renommage). La encore chaque noeud est libre des taxes qu'il applique. Il doit cependant les déclarer en utilisant des baux (1 bail par taxe) et ne pourra donc changer ses valeurs de taxations qu'à l'expiration des baux.

Lors d'une transaction la taxe totale devrait être calculé avant l'émission de l'ordre, en fonction de la date de création de l'ordre et des baux de chaque noeuds.

8. Création de noeud

Chaque extrémités de l'arbre, c'est à dire chaque compte, pourra à tout moment se diviser en sous-comptes et devenir un noeud. Ceci est laissé à la liberté du ou des titulaires.

9. Création de compte

Toute personne est libre de créer et d'utiliser un compte à n'importe quel endroit de l'arbre, tant que le noeud l'accepte.

Ce qui limitera naturellement les taxations abusives.

10. Moyens de paiement

(- internet

- carte à puce

- impression de billet … )

---------------------------------------------

Annexe A : exemple de transaction monétaire sécurisé.

exemple: pour transférer de la monnaie depuis myaccount.mycommunity.example vers sell.carbrand.example : je crée un ordre, que je chiffre avec ma clé privé et qui devra être envoyé au serveur qui me connaît ie celui gérant la zone mycommunity.example.

Ensuite je peux envoyer moi-même cette ordre à mon serveur ce qui peut s'assimiler à un don, ou bien envoyer l'ordre au bénéficiaire ce qui s'assimile à un paiement direct, ou bien encore envoyer l'ordre à un tiers de confiance entre moi et le bénéficiaire.

Cet ordre contient donc :

- le compte débiteur.

- le compte créditeur.

- sa date de création.

- éventuellement sa date d'expiration.

- la liste des billets numériques à transférer.

- l'id de certificat du débiteur à utiliser pour vérifier la signature.

- D'autre informations optionnelles par exemple pour tracer ou non le parcours de l'la monnaie.

- signature du compteur débiteur.

Sur réception de cet ordre, le serveur de ma zone mycommunity.example

- vérifie grâce à la signature que le compte débiteur est bien l'auteur de l'ordre,

- vérifie que sa date est bien comprise entre la date de création et la date d'expiration de l'ordre,

- vérifie que le compte créditeur existe,

- et vérifie enfin que les billets de la liste me sont bien attribués et disponibles (ie non verrouillés par une autre transaction en cours).

Il verrouille alors les billets de la liste et les met en attente de validation de suppression. La validation de suppression ne pourra venir que du serveur de la zone example.

Si l'ordre est valide et la monnaie disponible, le serveur de la zone mycommunity.example envoie un ordre au serveur de la zone example en changeant le compte débiteur myaccount.mycommunity.example par la zone mycommunity.example, l'id de certificat par l'un de ceux de sa zone, et bien évidemment la signature de l'ordre. Il pourra éventuellement aussi changer les dates d'expiration et autres informations optionnelles. Il ne touchera par contre pas à la liste des billets ni au compte à créditer.

Le serveur de la zone example vérifiera alors lui aussi :

- la signature

- la date

- existence du compte créditeur

- que les billets de la liste sont bien attribués à la zone signataire de l'ordre et disponibles.

Il verrouille alors les billets de la liste et les met en attente de validation de changement de zone. La validation du changement de zone ne pourra venir que du serveur de la zone destination.

Le serveur de la zone exemple crée alors à son tour un ordre pour le serveur de la zone carbrand.example avec

- son nom de zone.

- le compte créditeur (inchangé).

- la date de création de l'ordre (inchangé).

- éventuellement sa date d'expiration.

- la liste des billets numériques à transférer (inchangée).

- l'id de certificat de la zone à utiliser pour vérifier la signature.

- D'autre informations optionnelles par exemple pour tracer ou non le parcours de la monnaie.

- signature de l'émetteur de l'ordre.

Le serveur de la zone carbrand.example vérifiera à son tour :

- la signature

- la date

- existence du compte créditeur

- que les billets de la liste sont bien absents de la zone.

Il copie alors les billets de la liste, les verrouille et les met en attente de validation de copie par le noeud fils concerné, ie dans notre exemple le compte du destinataire. La validation de copie ne pourra venir que du noeud fils concerné.

Le serveur de la zone fils (carbrand.example) crée alors à son tour un ordre pour le compte fils concerné (sell.carbrand.example) :

- son nom de zone.

- le compte créditeur (inchangé).

- la date de création de l'ordre (inchangé).

- éventuellement sa date d'expiration.

- la liste des billets numériques à transférer (inchangée).

- l'id de certificat de la zone à utiliser pour vérifier la signature.

- D'autre informations optionnelles par exemple pour tracer ou non le parcours de la monnaie.

- signature de l'émetteur de l'ordre.

Le compte sell.carbrand.example vérifie enfin lui aussi :

- la signature

- la date

- existence du compte créditeur (ah tiens, c'est moi !)

- que les billets de la liste sont valides ie que leur certificat de signature n'est ni expiré, ni révoqué.

Il copie donc la liste des billets et renvoi une validation à son serveur de zone. Une partie de cette validation retournera jusqu'au signataire de l'ordre initial pour vérifier que la monnaie a bien été encaissé par le bon destinataire.

La partie de la validation qui ne changera pas et qui se propagera en retour jusqu'au compte émetteur de l'ordre est donc :

- le compte créditeur.

- la date de création de l'ordre.

- l'id du certificat de la signature.

- la signature des 3 informations précédentes + de la liste des billets transmis.

Au fur et à mesure de la propagation de la validation retour les billets de la transaction seront donc copiés, re-attribués, ou supprimés.

Remarque : le compte créditeur n'est pas obligé de connaître l'émetteur original ie le compte débiteur. Cependant cet information peut exister dans les informations optionnelles, et dans ce cas on peut aussi ajouter la signature par le débiteur des 3 informations qui ne doivent pas changer pendant la transaction : compte débiteur, date l'ordre et liste des billets.

Ce cas de figure est particulièrement pratique dans le cas d'un paiement.

Le cas nominal s'apparentant, lui, à un don anonyme.

------------------------------