Topic: Prouver l'écoulement du temps (Read 4405 times)

Merci pour ces précisions (qui confirment ce que j'ai compris du protocole). En fait mon post concernait une suggestion d'"amélioration" du protocole btc (de khal je crois) qui me semblait douteuse.

L'important n'est pas tant le temps exact mais l'ordre des transactions.
Le timestamp est toutefois vérifié par les pairs qui peuvent considérer comme invalides les blocks avec un timestamp fantaisiste.

Concernant la diffusion de plusieurs blocks au même moment c'est géré sans problème, chaque reçoit un des deux blocks avant l'autre et le considère comme le dernier block valide, ce n'est que le block suivant qui arbitrera en faveur d'un block ou l'autre étant donné qu'il aura pris pour base un des deux ex-aequo.

J'y travaille jour et nuit ces derniers temps.  Cf mon fil sur l'information de Shannon.

j'ai un peu de mal à comprendre ce thread car des phrases du genre "au bout de 30 s chaque mineur envoie son meilleur hash sur le réseau" n'ont pas grand sens.
 Il n'y a pas de timestamp serveur central donc les écarts entre les horloges peuvent être significatifs.
Si tous les mineurs envoient leur hash en même temps comment on évite la congestion ?(dans le proctocole bitcoin il faut avoir résolu le block pour envoyer son hash)
Peut être faut il rester modeste et considérer que 35 ans de recherche en cryptographie (depuis la thèse de PhD de Ralph Merkle) ont produit un protocole qui est tout simplement incroyable de simplicité et d'efficacité.
En tout cas si quelqu'un pense qu'il a un meilleur système, il doit être un peu plus rigoureux.

Quelques détails techniques...

<<<
En fait, d'après ce que j'ai compris du code, le client bitcoin utilise à différents endroits une horloge (fonction GetAdjustedTime) qui s'appuie sur l'horloge système, mais décalée d'un "nTimeOffset".

Ce "nTimeOffset" est calculé uniquement grâce aux horloges des clients voisins.
Il est volontairement limité à 70 minutes.
Au delà, ce décalage est supprimé, et un avertissement est transmis à l'utilisateur.

C'est cette horloge "corrigée" qui est utilisée pour les timestamps des block générés.
Par contre un bloc qui est daté plus de deux heures dans le futur sera rejeté par les autres clients (cf CheckBlock).
Et la date doit être cohérente avec celle des blocs précédents (cf AcceptBlock).
Un mineur qui voudrait introduire une fausse date dans l'un de ses blocs a donc peu de marge de manoeuvre .

Dans tous les cas (pour la cohérence évoquée précédemment et pour le calcul de la nouvelle difficulté), les éventuelles irrégularités des timestamps trouvés dans les blocs (ordres inversés par exemple) sont amorties par un calcul de médiane sur une dizaine de blocs (cf GetMedianTimePast).
>>>

Conclusion:

La mesure du temps réel qui est inclue dans la chaîne n'est donc fiable qu'à quelques heures près.
Et l'astuce de la médiane permet d'avoir plus de précision, mais cela suppose que la majorité des mineurs ont une horloge correcte (celle-ci peut être modifiée de 70 min par leurs voisins s'ils utilisent le client standard).

Je trouve tout ce système un peu trop compliqué à mon goût.
Cela dit, je n'y vois bien sûr pas de faille grave dans le cadre strict de bitcoin, car l'impact à l'air d'être limité aux dates affichées pour les transactions et au calcul des nouvelles difficultés.

Bien sûr, il faut le stocker dans la chaîne pour que les nœuds soient parfaitement d'accord sur la difficulté.

https://en.bitcoin.it/wiki/Block_hashing_algorithm

Il fait parti aussi de la creation du "block header" que les mineurs doivent résoudre.

Il me semble que l'horodatage (en secondes) est utilisé uniquement pour ajuster la difficulté.
Je ne sais pas à quel point il est possible de faire dériver cette estimation du temps réel en rajoutant des nœuds dépourvus de capacité de calcul.

(J'essaye de vérifier/eclaircir tout ça ce soir.)

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.

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?

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


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.

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

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.

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.

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.

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

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

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.

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


Du genre : traduire certains mots en anglais :p

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?

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


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 ?