On doit produire un header de 80 bytes , donc : 0x11111111111111111111111111111111111111111111111111111111111111111111111111111 111
C'est bien des headers de 80 bytes (notez qu'en hex cela donne 160 digits soit 0x11111111111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111111111111
1111)
dont l'image par la fonction SHA(SHA(0xHEADER)), commence par un nombre défini de 0 à gauche.
C'est bien ça
Le champs TIME change tous les combien ?
C'est à la discrétion du mineur. En théorie le mineur agit sur le champ nonce pour faire varier le hash et trouver la solution.
En pratique, je crois que certains mineurs font également parfois varier la date lorsque les variations sur le nonce n'ont pas produit de hash "gagnant".
Les contrôles de validité effectués par les autres noeuds du réseau sur le timestamp du block sont assez souples (problème d'un référentiel temps commun dans un système distribué):
- Block timestamp must not be more than two hours in the future
- ...
- Reject if timestamp is the median time of the last 11 blocks or before
Donc ça laisse pas mal de marge au mineur pour choisir la valeur du champs !
Le Hash du bitcoin peut il être considéré comme un SHA 256 à 64 tours ?
Je ne suis pas expert en crypto mais je dirais que Bitcoin utilise bien un algo SHA256 standard avec 64 tours.