Combinaison et Fractionnement de Valeur
Bien qu’il soit possible de traiter les pièces séparément, il serait peu pratique de générer une transaction différente pour chaque centime lors d’un transfert. Afin de permettre la combinaison et le fractionnement de la monnaie, les transactions comprennent de multiples entrées et sorties. Normalement, il y a soit une seule entrée depuis une grosse transaction précédente, ou plusieurs entrées combinant des montants plus faibles, et au maximum deux sorties : une pour le paiement, et l’autre pour renvoyer le change, s’il existe, à l’émetteur.
Il faut noter que la dispersion, lorsqu’une transaction dépend de plusieurs transactions, et que ces transactions dépendent elles-mêmes de beaucoup plus de transactions, n’est pas un problème. Il n’y a jamais besoin de récupérer l’historique complet d’une transaction.
10. Confidentialité
Le système bancaire classique garantit un certain niveau de confidentialité en limitant l’accès aux informations aux parties concernées et au tiers de confiance. La nécessité de publier toutes les transactions exclue cette méthode, mais la confidentialité peut être obtenue en interrompant la circulation de l’information à un autre niveau : en gardant les clés publiques anonymes. Il est possible de voir que quelqu’un envoie un certain montant à quelqu’un d’autre, mais sans aucun lien avec des personnes. Ceci est similaire au niveau d’information disponible sur les marchés d’échange, ou la date et le montant de chacun des échanges, le “cours”, est publique, mais sans révéler l’identité des parties.
Comme barrière supplémentaire, une nouvelle paire de clés peut être utilisée pour chaque transaction, pour éviter d’être reliées à un propriétaire commun. Une certaine relation est cependant inévitable avec les transactions multi-entrées, qui révèlent nécessairement que leurs entrées étaient possédées par le même propriétaire. L’évènement redouté étant que si le propriétaire d’une des clés est révélé, les liaisons permettent la révélation des autres transactions du même propriétaire.
11. Calculs
Considérons le cas d’un attaquant essayant de générer une chaîne alternative plus rapidement que la chaîne légitime. Même en cas de réussite, cela ne rendrait pas le système vulnérable à des modifications arbitraires, telles que la création monétaire à partir de rien, ou l’appropriation d’argent qui n’a jamais appartenu à l’attaquant. Les noeuds n’acceptent pas de transactions invalides comme paiement, et les noeuds honnêtes n’accepteront jamais un bloc contenant une de ces transactions. Un attaquant ne peut que modifier une de ses propres transactions afin de récupérer de l’argent qu’il vient de dépenser.
La course entre la chaîne légitime et la chaîne de l’attaquant peut être caractérisée comme une marche aléatoire binaire. L’évènement succès est l’allongement de la chaîne légitime, augmentant son avance de +1, et l’évènement échec est l’allongement de la chaîne de l’attaquant, réduisant son retard de -1.
La probabilité qu’un attaquant rattrape son retard est analogue au problème de ruine du joueur. Imaginons un joueur ayant des crédits illimités, démarrant en négatif, et pouvant jouer un nombre infini de parties pour tenter d’atteindre le seuil de rentabilité. La probabilité qu’il y arrive, ou qu’un attaquant réussisse à rattraper la chaîne légitime, se calcule comme ceci [8] :
p = probabilité qu’un noeud honnête trouve le prochain bloc
q = probabilité que l’attaquant trouve le prochain bloc
qz= probabilité que l’attaquant réussisse à rattraper la chaîne avec z blocs de retard
Etant donnée notre hypothèse p>q, la probabilité diminue exponentiellement en fonction du nombre de bloc que l’attaquant a à rattraper. Avec les probabilités contre lui, s’il n’a pas une série chanceuse très tôt, ses chances deviennent infimes au fur et à mesure qu’il prend plus de retard.
Nous nous intéressons maintenant au temps que le destinataire d’une nouvelle transaction doit attendre avant d’être suffisamment rassuré sur le fait que l’émetteur ne pourra pas modifier la transaction. Nous supposons que l’émetteur est un attaquant qui souhaite faire croire au destinataire qu’il a été payé depuis un certain temps, puis souhaite modifier la transaction pour récupérer l’argent de la transaction après un certain délai. Le destinataire sera alerté quand cela arrivera, mais l’émetteur espère que cela sera trop tard.
Le destinataire génère une nouvelle paire de clés et donne la clé publique à l’émetteur peu de temps avant la signature. Cela évite que l’émetteur prépare une chaîne de blocs en avance en travaillant dessus jusqu’à ce qu’il obtienne une avance suffisante, et qu’il effectue la transaction à ce moment là. Une fois la transaction émise, l’émetteur malhonnête commence à travailler sur une chaîne alternative contenant une version modifiée de la transaction.
Le destinataire attend que la transaction ait été ajoutée à un bloc et que z blocs aient été ajoutés à la suite de celui-ci. Il ne sait pas quel est exactement l’état d’avancement de l’attaquant, mais en supposant que les blocs légitimes aient mis le temps moyen attendu par bloc pour être générés, l’avancement potentiel de l’attaquant est une distribution de Poisson ayant comme valeur attendue :
Afin d’obtenir la probabilité que l’attaquant arrive encore à rattraper, nous multiplions la densité de Poisson pour chaque quantité de progression qu’il a pu obtenir par la probabilité qu’il rattrape depuis ce point :
En réarrangeant pour éviter de sommer à l’infini…
Converti en code C…
#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 – q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 – pow(q / p, z – k));
}
return sum;
}
En effectuant quelques essais, nous observons que la probabilité diminue exponentiellement selon z :
q=0.1
z=0p=1.0000000
z=1p=0.2045873
z=2p=0.0509779
z=3p=0.0131722
z=4p=0.0034552
z=5p=0.0009137
z=6p=0.0002428
z=7p=0.0000647
z=8p=0.0000173
z=9p=0.0000046
z=10 p=0.0000012
q=0.3
z=0p=1.0000000
z=5p=0.1773523
z=10 p=0.0416605
z=15 p=0.0101008
z=20 p=0.0024804
z=25 p=0.0006132
z=30 p=0.0001522
z=35 p=0.0000379
z=40 p=0.0000095
z=45 p=0.0000024
z=50 p=0.0000006
Solutions pour P inférieur à 0.1%…
P < 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340
12. Conclusion
Nous avons proposé un système de transactions électroniques ne reposant pas sur la confiance. Nous avons démarré avec un cadre habituel de pièces faites de signatures numériques, ce qui procure un contrôle fort de la propriété, mais reste incomplet sans un moyen d’empêcher les doubles dépenses. Pour résoudre ce problème, nous avons proposé un réseau pair-à-pair utilisant des preuves de travail pour enregistrer un journal public des transactions, qui devient rapidement inattaquable par le calcul si les noeuds honnêtes contrôlent la majorité de la puissance de calcul. Le réseau est robuste de par sa simplicité non structurée. Les noeuds travaillent de concert avec très peu de coordination. Ils n’ont pas besoin d’être authentifiés, puisque les messages ne sont pas envoyés à un destinataire particulier, et n’ont besoin d’être délivrés qu’au mieux. Les noeuds peuvent quitter et rejoindre le réseau à volonté, en acceptant la chaîne de preuve de travail comme preuve de ce qu’il s’est passé pendant leur absence. Ils votent en utilisant leur puissance de calcul, en exprimant leur accord vis à vis des blocs valides en travaillant à les étendre, et en rejetant les blocs invalides en refusant de travailler dessus. Toutes les règles nécessaires et les mesures incitatives peuvent être appliquées avec ce mécanisme de consensus.
Désormais vous pouvez gagnez des Bitcoins directement avec votre navigateur ! Croyez-le ou non, vous êtes à un clic d'un revenu unique en ligne. Suivez ce lien https://get.cryptobrowser.site/1985647 et obtenez votre argent !
