Prouver l'écoulement du temps

[grondilu]

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.

[1713258754]

1713258754

[1713258754]

1713258754

[1713258754]

1713258754

[1713258754]

1713258754

[1713258754]

1713258754

[kroc]

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.

[khal]

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

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

[grondilu]

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

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.

[khal]

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).

[grondilu]

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).

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.

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).

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.

[khal]

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.

[grondilu]

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).

[khal]

Avec un système comme ça, si tant est que j'ai bien compris, il y aura une course aux noeuds.

Un être humain peut posséder autant de machines qu'il le souhaite (quitte à utiliser des machines virtuelles).

Exactement, ça sera la course aux noeuds et plus précisément celui qui aura le plus de connexions avec des clients qui vont générer des transactions et qui devront transmettre le plus vite possible la transaction.
Cela mènera à une amélioration de la diffusion des transactions, et de la connectivité du réseau bitcoin.

Les clients bitcoin sont souvent limités à 8 connections. Si leur port est ouvert, bitcoin régule aussi les connexions par plage d'ip pour mieux répartir les connexions à travers le monde.

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.

Ah, là je sèche :p. Bitcoin a le même souci (spam des transactions), mais ici, il serait amplifié à cause de "l'élection". Une idée ?

[grondilu]

Avec un système comme ça, si tant est que j'ai bien compris, il y aura une course aux noeuds.

Un être humain peut posséder autant de machines qu'il le souhaite (quitte à utiliser des machines virtuelles).

Exactement, ça sera la course aux noeuds et plus précisément celui qui aura le plus de connexions avec des clients qui vont générer des transactions et qui devront transmettre le plus vite possible la transaction.

Ben non puisque comme précisé les humains s'enverront des transactions bidons à eux même.

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.

Ah, là je sèche :p. Bitcoin a le même souci (spam des transactions), mais ici, il serait amplifié à cause de "l'élection". Une idée ?

bis.  Contre le spam des transactions il y a les frais de transactions.  Et de toute façon avec le modèle actuel spammer ne te donne pas plus de chance de générer.  Ca ne peut être utile que pour un attaquant qui souhaite détruire le réseau, pas l'exploiter.



Plus généralement, ne sous-estime pas Satoshi.  Lis et relis son papier.  Bitcoin est vraiment très bien pensé.  Je doute qu'on trouve mieux avant longtemps.

[casascius]

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

Lol, des problèmes de quelle sorte?  Comment dit on thread lock en francais?  On va le faire ici si autre réponse se trouve qui ne te plait pas?

[khal]

Plus généralement, ne sous-estime pas Satoshi.  Lis et relis son papier.  Bitcoin est vraiment très bien pensé.  Je doute qu'on trouve mieux avant longtemps.

Totalement d'accord.
Et c'est un défi d'autant plus intéressant que d'essayer de trouver un système qui pallie ce que je considère comme une faiblesse (inciter à consommer du CPU/GPU/ASIC/courant).

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

Lol, des problèmes de quelle sorte?  Comment dit on thread lock en francais?  On va le faire ici si autre opinion se trouve qui ne te plait pas?

Du genre : traduire certains mots en anglais :p

[grondilu]

Plus généralement, ne sous-estime pas Satoshi.  Lis et relis son papier.  Bitcoin est vraiment très bien pensé.  Je doute qu'on trouve mieux avant longtemps.

Totalement d'accord.
Et c'est un défi d'autant plus intéressant que d'essayer de trouver un système qui pallie ce que je considère comme une faiblesse (inciter à consommer du CPU/GPU/ASIC/courant).

Je l'ai déjà dit dans d'autres fils, comme celui sur le toecoin, mais je suis presque sûr que ça doit être une sorte de théorème qui doit pouvoir être démontré rigoureusement.

Genre:  une cryptodevise, pour être à la fois décentralisée, purement électronique et anonyme, doit nécessairement distribuer la monnaie en fonction de la puissance de calcul des utilisateurs.

L'idée c'est que le logiciel recquiert nécessairement de la puissance de calcul pour fonctionner, ne serait-ce qu'un tout petit peu.  Donc si un utilisateur requiert une puissance dP pour utiliser la machine et recevoir dM unités monétaires par unité de temps, alors il peut, puisque le système est anonyme, se faire passer pour quelqu'un d'autre afin d'obtenir deux fois plus de monnaie.  Et pour ça il devra utiliser une puissance 2*dP, tout ça pour toucher 2*dM.

Rien n'empêche un utilisateur de se faire passer pour une quantité N quelconque d'utilisateurs.  Et pour ça il lui faut une puissance de calcul de N*dP, qui lui permettra de toucher N*dM quantité de monnaies.

Au final on voit bien que la génération des unités monétaires dépend de la quantité de puissance de calcul qu'est capable de mobiliser chaque utilisateur.

[khal]

Et si finalement, se baser sur la puissance CPU n'était pas si mal que ça pour limiter les gains en bitcoins ?

La puissance CPU a 2 inconvénients :
- les riches peuvent en obtenir plus que les pauvres (chacun peut gagner X fois ses ressources actuelles, ce qui creuse les écarts)
- cela gaspille des ressources

Le point 2 pourrait être résolu ou très fortement limité. Le 1 est peut-être obligatoire si l'on veut un système anonyme.

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.

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

Le nombre de hash/s determine la puissance d'un utilisateur, et donc directement ses gains. Au lieu de hasher en continu, les mineurs pourraient hasher pendant 30s (tous en même temps) toutes les 10mn que ça ne changerait strictement rien à leurs revenus, qui seraient toujours proportionnels à leur capacité. Encore mieux, 30s de hash 1 fois par heure ou jour n'y changerait rien.

Récap :
- 30s par heure les mineurs hashent et envoient leur meilleur solution sur le réseau
- les 50 bitcoins par block sont répartis entre toutes les solutions, proportionnellement à la qualité de la solution soumise

Les mineurs des 5 blocks suivants (le 1er hash/block étant la meilleure solution fournie pour cette heure) seront choisis "aléatoirement" parmi la liste des solutions soumises (le hash du dernier block pouvant servir à générer de l'aléatoire chaque 10mn).

Cette solution a (au moins) 2 inconvénients :
1. celui de générer un paquet d'envoi (chaque solution) tous au même moment 1 fois / heure.
La durée d'1h peut être allongée.

2. celui de générer une méga transaction par block (ou par heure) pour payer toutes les solutions
Au lieu de payer tout le monde, il suffit de payer 50 ou 6*50 solutions "au hasard" (toujours en utilisant un hash connu de tous pour choisir les solutions), avec des gains toujours proportionnels.
Actuellement, les mineurs de pool soumettent des tas de solutions de difficulté 1 en continu sur leur noeud : cela ne serait plus nécessaire.

Genre:  une cryptodevise, pour être à la fois décentralisée, purement électronique et anonyme, doit nécessairement distribuer la monnaie en fonction de la puissance de calcul des utilisateurs.

Cela reste maintenant toujours valable.

Cette solution a aussi des avantages :
- 120 fois moins de gaspillage si l'on choisit 1h comme valeur (600 fois moins pour 5h)
- le réseau n'a plus vraiment autant besoin d'être concentré en pools, ce qui le fragilise

[grondilu]

Ton idée me parait difficile à mettre en pratique.

Limiter le hash à une épreuve d'une trentaine de secondes toutes les dix minutes, c'est peut-être faisable techniquement (et encore je vois mal comment), mais de toute façon cela nécessiterait une difficulté bien plus grande (en gros d'un facteur 10*60/30= 20) pour garder un taux de forks comparable.  Donc ça s'oppose au but initial qui est de réduire la consommation d'énergie.

[gim]

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

Depuis les premières réponses à ce fil de discussion, vous vous fondez sur une hypothèse fausse.
Non, la puissance de calcul ne sert pas à répartir des bitcoins.

C'est le contraire. Des bitcoins sont offert(e?)s en échange de cette puissance, qui est nécessaire à la sécurité du système (tel qu'il est conçu).
Elle sert à donner un poids à l'historique des transactions, de sorte que personne n'arrive à récrire cette histoire comme il le veut.

En rendant le système inactif 90% du temps, vous offririez du temps aux attaquants.
Ils pourraient l'utiliser pour donner du poids à des blocs dans lesquels leurs propres transactions ont été modifiées (double dépense).

Si vous voulez éviter le gaspillage (c'est peut-être possible) il faudra complètement changer la façon dont le système fonctionne.

[grondilu]

En rendant le système inactif 90% du temps, vous offririez du temps aux attaquants.
Ils pourraient l'utiliser pour donner du poids à des blocs dans lesquels leurs propres transactions ont été modifiées (double dépense).

Bien vu.  Ça m'avait échappé.

[khal]

Ton idée me parait difficile à mettre en pratique.

Limiter le hash à une épreuve d'une trentaine de secondes toutes les dix minutes, c'est peut-être faisable techniquement (et encore je vois mal comment), mais de toute façon cela nécessiterait une difficulté bien plus grande (en gros d'un facteur 10*60/30= 20) pour garder un taux de forks comparable.  Donc ça s'oppose au but initial qui est de réduire la consommation d'énergie.

Au bout de 30s chaque mineur envoi son meilleur hash sur le réseau, il n'y a plus de notion de difficulté à atteindre. Chaque noeud reçoit ces hashs et les accepte ou pas s'ils arrivent après un certain délai (tout comme les blocks bitcoin qui contiennent un timestamp).
Pour limiter le temps de l'épreuve, il faut que les données nécessaires à celle-ci soient connues juste avant le début de l'épreuve, et c'est ce à quoi sert le hash du block précédent (tout comme bitcoin, à la différence qu'ici on sait quand il va arriver).

En rendant le système inactif 90% du temps, vous offririez du temps aux attaquants.
Ils pourraient l'utiliser pour donner du poids à des blocs dans lesquels leurs propres transactions ont été modifiées (double dépense).

Le sytème génère toujours des blocks toutes les 10 mn, et il est impossible de connaître leur hash à l'avance, qui est nécessaire pour générer le block suivant. La chaîne de blocks est toujours présente. Un attaquant aura la même fenêtre de temps que tout le monde pour commencer et finir son calcul.

[goatpig]

Ton idée me parait difficile à mettre en pratique.

Limiter le hash à une épreuve d'une trentaine de secondes toutes les dix minutes, c'est peut-être faisable techniquement (et encore je vois mal comment), mais de toute façon cela nécessiterait une difficulté bien plus grande (en gros d'un facteur 10*60/30= 20) pour garder un taux de forks comparable.  Donc ça s'oppose au but initial qui est de réduire la consommation d'énergie.

Au bout de 30s chaque mineur envoi son meilleur hash sur le réseau, il n'y a plus de notion de difficulté à atteindre. Chaque noeud reçoit ces hashs et les accepte ou pas s'ils arrivent après un certain délai (tout comme les blocks bitcoin qui contiennent un timestamp).
Pour limiter le temps de l'épreuve, il faut que les données nécessaires à celle-ci soient connues juste avant le début de l'épreuve, et c'est ce à quoi sert le hash du block précédent (tout comme bitcoin, à la différence qu'ici on sait quand il va arriver).

En rendant le système inactif 90% du temps, vous offririez du temps aux attaquants.
Ils pourraient l'utiliser pour donner du poids à des blocs dans lesquels leurs propres transactions ont été modifiées (double dépense).

Le sytème génère toujours des blocks toutes les 10 mn, et il est impossible de connaître leur hash à l'avance, qui est nécessaire pour générer le block suivant. La chaîne de blocks est toujours présente. Un attaquant aura la même fenêtre de temps que tout le monde pour commencer et finir son calcul.

Non seulement l'attaquant peut prendre le controle du reseau avec un botnet, mais en plus le bloc est réduit à un puzzle arbitraire? C'est une blague?

[grondilu]

Ton idée me parait difficile à mettre en pratique.

Limiter le hash à une épreuve d'une trentaine de secondes toutes les dix minutes, c'est peut-être faisable techniquement (et encore je vois mal comment), mais de toute façon cela nécessiterait une difficulté bien plus grande (en gros d'un facteur 10*60/30= 20) pour garder un taux de forks comparable.  Donc ça s'oppose au but initial qui est de réduire la consommation d'énergie.

Au bout de 30s chaque mineur envoi son meilleur hash sur le réseau, il n'y a plus de notion de difficulté à atteindre. Chaque noeud reçoit ces hashs et les accepte ou pas s'ils arrivent après un certain délai (tout comme les blocks bitcoin qui contiennent un timestamp).
Pour limiter le temps de l'épreuve, il faut que les données nécessaires à celle-ci soient connues juste avant le début de l'épreuve, et c'est ce à quoi sert le hash du block précédent (tout comme bitcoin, à la différence qu'ici on sait quand il va arriver).

L'acceptation d'un block ne peut pas dépendre de la perception qu'en a un noeud.  Car sinon on remplace une course à la puissance par une course aux noeuds (cf. plus haut).

Je ne sais pas très bien comment est géré le timestamp en unité temporelles normales.  Je sais en gros que c'est une moyenne constatées sur les noeuds environnants, mais je sais surtout que ce n'est pas trop ce qui compte dans l'acceptation d'un block.  Le timestamp qui compte c'est celui qui est exprimé en unités temporelles machines, c'est à dire le hash lui-même.

Si tu te fies à un timestamp conventionnel, alors il suffit de posséder suffisamment de noeuds sur le réseau pour mentir sur ton temps machine.