Bitcoin Forum
November 10, 2024, 05:04:28 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Prouver l'écoulement du temps  (Read 4377 times)
gim
Member
**
Offline Offline

Activity: 90
Merit: 10


View Profile
May 17, 2011, 03:16:56 PM
 #21

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.

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.)
goatpig
Legendary
*
Offline Offline

Activity: 3752
Merit: 1364

Armory Developer


View Profile
May 17, 2011, 03:25:01 PM
 #22

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.

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

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

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

gim
Member
**
Offline Offline

Activity: 90
Merit: 10


View Profile
May 17, 2011, 03:34:16 PM
 #23

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

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

Activity: 90
Merit: 10


View Profile
May 17, 2011, 10:22:08 PM
Last edit: May 18, 2011, 11:27:50 PM by gim
 #24

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.
Boussac
Legendary
*
Offline Offline

Activity: 1221
Merit: 1025


e-ducat.fr


View Profile WWW
July 02, 2011, 10:20:21 PM
 #25

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.

grondilu (OP)
Legendary
*
Offline Offline

Activity: 1288
Merit: 1080


View Profile
July 03, 2011, 03:21:31 PM
 #26

En tout cas si quelqu'un pense qu'il a un meilleur système, il doit être un peu plus rigoureux.

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

davout
Legendary
*
Offline Offline

Activity: 1372
Merit: 1008


1davout


View Profile WWW
July 04, 2011, 09:43:23 AM
 #27

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

Boussac
Legendary
*
Offline Offline

Activity: 1221
Merit: 1025


e-ducat.fr


View Profile WWW
July 04, 2011, 10:57:01 AM
 #28

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

Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!