Topic: Prouver l'écoulement du temps - page 2. (Read 4405 times)

Avec un système comme ça, si tant est que j'ai bien compris, il y aura une course aux noeuds.  Les membres du réseau feront fonctionner un maximum de machines et s'enverront des transactions à eux mêmes afin d'augmenter leurs chances d'acquérir des bitcoins.


Quelque soit la manière avec laquelle tu élis les noeuds qui auront le droit de recevoir des bitcoins, tu auras des êtres humains qui essaieront d'être élu un maximum de fois, et in fine ça reviendra à acquérir un maximum de ressources matérielles, que ce soit réseau ou CPU.

N'oublie pas que pour le réseau, un noeud n'est pas forcément un être humain.  Un être humain peut posséder autant de machines qu'il le souhaite (quitte à utiliser des machines virtuelles).

Voici une petite proposition :

Le client qui génère une transaction va l'envoyer aux 8 noeuds auxquels il est connecté.
Au lieu d'envoyer la même chose à chaque noeud, il inclut la clé publique du noeud auquel il envoie le message, puis le signe.
Les transactions sont transmises et chaque noeud du réseau va en recevoir une des 8 (car il va ignorer les transactions qu'il connait déjà).

Pour déterminer lequel comptabiliser, il faudra regarder laquelle des 8 transactions a été incluse dans le block.
If "suffit" ensuite de déterminer à partir de combien de transactions et sur combien de blocks on fait la "moyenne" qui donne droit ou non à être éligible sur la liste des noeuds qui pourront générer un block.

La chaîne du temps... hum, le but est de choisir un block et de le graver dans le marbre pour déterminer sans ambiguïté quelle transaction a la priorité sur une autre potentiellement conflictuelle (double spend). Le système actuel de bitcoin a l'inconvénient de générer des forks de la chaîne.

Imagine maintenant que tu as 50 noeuds éligibles pour le prochain block (parce qu'ils ont leur clé publique inclue dans les transactions des précédents blocks).
Pour déterminer qui va générer le prochain block, il faut utiliser une valeur aléatoire mais determinable par tous les blocks : ça peut être le hash du block précédent. Tu peux aussi générer un ordre de priorité parmi cette liste, au lieu de n'élire qu'un seul gagnant.
Le prochain block sera signé avec la clé du gagnant => pas de fork possible de la chaîne. Si le gagnant ne génère pas le block au bout de 60s par exemple, le deuxième de la liste pourra générer le block. Il aura aussi le même temps pour le faire, et ainsi de suite.

ps : l'idée de l'ip est la plus simple mais pas réellement applicable en grandeur nature, surtout avec ipv6 (/56 /64 , etc) qui arrive.

Oui mais comment tu les reconnais ?  Tu es sûr que TCP/IP est un bon moyen d'identifier à coup sûr un noeud ?  Que fais-tu pour éviter le double paiement ?

L'un des points forts de bitcoins est qu'il n'utilise pas l'infrastructure réseau pour autre chose que le partage des transactions.  La sécurité du système est dans la cryptographie contenue dans les blocs, et nul part ailleurs.


Un noeud possède des tas de clefs.  Elles sont toutes dans son portefeuille et il signe toutes les transactions envoyées au réseau.

La solution la plus logique serait de récompenser ceux qui aident le réseau en transmettant les paquets (transactions, blocks, adresses des noeuds, etc).

Mais pour comptabiliser ça, sans rajouter de surcharge, et que tout le monde ait accès aux mêmes stats (est-ce indispensable ?), je ne sais pas s'il existe une solution (un noeud peut s'identifier avec une clé publique, signer ses messages, etc).

C'est bien ici que le bât blesse.  Il n'y a pas grand chose qui interdit quelqu'un d'acquérir une autre adresse IP.  Et TCP/IP n'est pas conçu pour ça.

En fait, il faut bien comprendre que quelque soit le critère retenu pour autoriser la création de bitcoins, les membres du réseau chercheront à le satisfaire au maximum afin d'obtenir le plus de bitcoins possible.

Donc si l'attribution de bitcoin était basée sur les adresses IP, il y aurait une course à la possession d'adresses, au lieu d'une course à la puissance de calcul.

En outre, une preuve de calcul est infiniment plus facile à vérifier et digne de confiance que l'entête d'un paquet TCP/IP.

Mais bon si tu vois un moyen de créer un réseau monétaire basé sur ce principe, surtout vas-y, implémente le.  C'est clair que si on pouvait éviter de faire tourner des machines pour constamment calculer des hashs, ce serait mieux.  Mais pour l'instant aucune autre solution satisfaisante n'a été trouvée.


Par ailleurs, relis mon post initial.  Le calcul CPU ne sert pas que à élire celui qui aura le droit de toucher des bitcoins, il sert aussi à prouver l'écoulement du temps, et donc à établir une chaine chronologique pour les transactions.

C'est la chaîne des blocks qui définie l'échelle du temps. Elle est certe assurée et garantie par les hashs et la puissance de calcul, mais cela pourrait fonctionner autrement.

Dans bitcoin, la puissance de calcul est utilisée pour :
- générer de l'aléatoire dans la distribution des coins
- limiter la participation de chaque personne

On pourrait imaginer un système où la puissance de calcul n'est pas nécessaire pour résoudre ces 2 besoins.

Solution pour générer de l'aléatoire :
- utiliser le hash du dernier block comme valeur aléatoire pour déterminer la prochaine personne qui pourra générer le block

Si l'on veut faire varier la durée entre les blocks (pour faire comme bitcoin, mais ce n'est pas nécessaire, c'est même plutôt une limitation de bitcoin) :
- utiliser le hash du dernier block comme valeur aléatoire pour calculer le temps du prochain block

Solution pour limiter la participation :
- autoriser 1 participation par adresse IP
- autres ?

Pour générer des bitcoins, il faut s'investir un minimum. Si les bitcoins étaient répartis de manière aléatoire sans besoin de puissance de calcul, peut-être que le système ne serait pas aussi attractif pour les gens :p

ps : c'est un résumé, je vous ai épargné le reste de mes élucubrations

Donc la précision de l'échelle de temps correspond au temps que l'on met à trouver le prochain bloc ?

Ce qui semble regrettable (et non pas forcement absurde), c'est que tous les mineurs sont en concurrence pour trouver le prochain bloc et que le système les pousse à déployer des infrastructures toujours plus gourmandes pour être le premier.
On imagine donc que des investissements colossaux seront mis en oeuvre pour être acteur de cet écoulement du temps alors qu'ils pourraient être placés ailleurs sans dysfonctionnement du système.

Je vais écrire ça en français car ça me pose quelques problèmes en anglais.


Ceux qui découvrent bitcoin ont souvent du mal au début à comprendre à quoi sert exactement la puissance de calcul utilisée.  Ca leur parait absurde de faire tourner des cartes graphiques dans le vide juste pour calculer des hashs.  Du coup ils croient que c'est ce calcul qui donne de la valeur aux bitcoins, du fait de la dépense énergétique nécessaire.


Ce n'est bien sûr pas comme ça qu'il faut voir les choses.

La puissance de calcul est nécessaire pour donner au réseau une échelle de temps décentralisée.

Si je possède 1 bitcoin, que je l'envoie à Alice et qu'en même temps j'essaie de tricher en envoyant le même bitcoin à Bob, il faut un moyen de savoir lequel des deux ordres est valable.

Avec un système centralisé c'est simple:  c'est le premier qui arrive au serveur central.

Cette nécessité d'une chronologie sans référence temporelle unique implique de pouvoir prouver l'écoulement du temps.    Une montre mesure le temps mais ne donne aucune preuve de sa véracité.

Une peuve de calcul, elle, n'est possible à obtenir qu'avec un certain travail qui prend nécessairement un certain temps.  Dès lors, un enchainement de preuve de calculs constitue une échelle temporelle peu précise certes, mais en tout cas digne de confiance.

C'est l'idée la plus originale dans le fonctionnement de bitcoin, et elle mérite d'être plus souvent soulignée afin d'éviter les malentendus évoqués plus haut.