Merci grandement.
Je vais de ce pas parfaire mes connaissances.
Topic: Compréhension du fonctionnement du minage: (Read 1690 times)
Merci à vous pour vos réponses qui m'éclairent grandement.
Auriez vous par hasard de la doc sur la vérification du nounce ? Malgré le fait que j'ai eu cherché sur internet , je ne trouve pas d'article mentionnant le déroulement exact d'un minage et la vérifiction avec des valeurs explicites.
Voici un excellent blog avec un post expliquant le mining, les pools de minage, .... C'est illustré avec du code python, notamment pour l'algo de mining.Auriez vous par hasard de la doc sur la vérification du nounce ? Malgré le fait que j'ai eu cherché sur internet , je ne trouve pas d'article mentionnant le déroulement exact d'un minage et la vérifiction avec des valeurs explicites.
Pour des aspects plus théoriques, le wiki bitcoin est une mine mais c'est parfois bien caché. Quelques pages intéressantes: présentation générale du mining, les notions de target et de difficulté, proof of work, hashcash, ...)
Merci à vous pour vos réponses qui m'éclairent grandement.
Auriez vous par hasard de la doc sur la vérification du nounce ? Malgré le fait que j'ai eu cherché sur internet , je ne trouve pas d'article mentionnant le déroulement exact d'un minage et la vérifiction avec des valeurs explicites.
Auriez vous par hasard de la doc sur la vérification du nounce ? Malgré le fait que j'ai eu cherché sur internet , je ne trouve pas d'article mentionnant le déroulement exact d'un minage et la vérifiction avec des valeurs explicites.
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 çaLe 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é):
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.
Bonjour et merci à vous de m'avoir répondu,
donc si l'on récapitule :
On doit produire un header de 80 bytes , donc : 0x11111111111111111111111111111111111111111111111111111111111111111111111111111 111
dont l'image par la fonction SHA(SHA(0xHEADER)), commence par un nombre défini de 0 à gauche.
Le champs TIME change tous les combien ?
Le Hash du bitcoin peut il être considéré comme un SHA 256 à 64 tours ?
donc si l'on récapitule :
On doit produire un header de 80 bytes , donc : 0x11111111111111111111111111111111111111111111111111111111111111111111111111111 111
dont l'image par la fonction SHA(SHA(0xHEADER)), commence par un nombre défini de 0 à gauche.
Le champs TIME change tous les combien ?
Le Hash du bitcoin peut il être considéré comme un SHA 256 à 64 tours ?
C'est bien l'idée avec juste une petite correction. L'objectif est d'avoir
La target peut être calculée à partir de la difficulté (et inversement) grâce à la formule:
target_genesis correspond à la target du bloc 0 et à pour valeur 0x00000000FFFF0000000000000000000000000000000000000000000000000000
C'est la plus grande target possible, et ça correspond donc à la difficulté la plus basse (difficulty = 1)
Ca peut également être interprété comme une unité de travail minimale qui requiert 2**32 itérations (Les 8 zéros apparaissant au début la valeur en hex)
Demeure un mystère pour moi : pourquoi ces 2**32 itérations ont été retenues comme unité de travail ?
Plus d'infos ici et ici
Quote
f(x) < target
La target peut être calculée à partir de la difficulté (et inversement) grâce à la formule:
Quote
current_difficulty = target_genesis / current_target
target_genesis correspond à la target du bloc 0 et à pour valeur 0x00000000FFFF0000000000000000000000000000000000000000000000000000
C'est la plus grande target possible, et ça correspond donc à la difficulté la plus basse (difficulty = 1)
Ca peut également être interprété comme une unité de travail minimale qui requiert 2**32 itérations (Les 8 zéros apparaissant au début la valeur en hex)
Demeure un mystère pour moi : pourquoi ces 2**32 itérations ont été retenues comme unité de travail ?
Plus d'infos ici et ici
Bonsoir à tous,
Je me permets de solliciter l'aide de la communauté pour affirmer mon raisonnement sur le minage de bitcoin
Pour miner un block , il faut :
Effectuer f(x)=SHA(SHA(g(x)))
tel que g(x) est l'élaboration d'un block header à partir de
getblockteplate RPC et d'un nombre aléatoire.
Pour avoir f(x) en HEX tel que les d premiers bits soient des 0
avec d la difficultée donnée par le réseau.
Cela reflète t il la réalité ?
Merci d'avance
Jump to: