Bitcoin Forum
September 15, 2024, 06:20:26 PM *
News: Latest Bitcoin Core release: 27.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Question à propos de la création d'un block - Architecture [RESOLUE]  (Read 723 times)
onepix (OP)
Full Member
***
Offline Offline

Activity: 171
Merit: 100


View Profile
November 11, 2013, 10:56:45 PM
Last edit: November 11, 2013, 11:21:16 PM by onepix
 #1

Bonsoir,  Smiley

Alors je fais un petit exposé en anglais (je suis étudiant) et j'ai trouvé trèèèèès interessant de le faire sur cette monnaie virtuelle.
Je me base donc sur plusieurs site et je me trouve aujourd'hui face à une incompréhension entre deux texts qui j'espère sera résolu grâce à vous.

( On parle ici de la création d'un nouveau bloc )
"Le bloc contiens aussi un hash du bloc précédent (en vert¹ sur mon image). Le mineur a aussi dû vérifier que la page précédente est valide, c-à-d que toute les transactions sur la page sont valides, que le mineur précédent ne s'est pas attribué plus de bitcoins que prévu par le protocole et que le hash de la page précédente est suffisamment petit." source : http://linuxfr.org/users/gof/journaux/comment-fonctionne-bitcoin

Et

"Les transactions reçoivent une confirmation lorsqu'elles sont incluses dans un bloc et pour chaque bloc subséquent" source : http://bitcoin.org/fr/vocabulaire#confirmation

Question :
- Pour terminer la formation d'un nouveau bloc, celui-ci dois trouver et ajouter une nonce(valeurs hash tel qu'il doit être inférieur à une certaine valeur[difficulté]) dans celui-ci. (si j'ai bien compris)
Alors pourquoi dans la première citation il est dit qu'un nouveau bloc doit vérifier le "nonce" du précédent ?

- Pour qu'une transaction soit considéré comme "validé" elle doit être au minimum dans un bloc "finalisé".(si j'ai bien compris)
Alors pourquoi dans la première citation il est dit que l'on doit vérifier que les transactions du précédent bloc soit valides ?

Et question bonus : Pourquoi "Chaque nouvelle confirmation diminue exponentiellement le risque d'un renversement" ( à cause du de la double transaction ou de la création d'un bloc simultané qui scinde la chaine en deux ?)

Merci d'avance  Grin
jackjack
Legendary
*
Offline Offline

Activity: 1176
Merit: 1257


May Bitcoin be touched by his Noodly Appendage


View Profile
November 11, 2013, 11:04:52 PM
 #2

Q1 et 2: parce que le premier texte raconte n'importe quoi
Q1: pour faire un bloc, tu prends le dernier dans la blockchain, et tu utilises son hash. Tu rajoutes un nonce aléatoire et 2-3 autres trucs, et tu calcules le hash correspondant à tout ça.
Si le hash est plus petit que la cible, le bloc est valide, sinon il est invalide.
Si ton bloc est invalide tu auras beau l'envoyer à qui tu veux, tout le monde le refusera, donc il n'ira pas dans la blockchain. Donc pas de vérification supplémentaire à la création d'un bloc.

Q2: Débilité de l'article. Si les transactions du bloc précédent ne sont pas valides, comme dit au-dessus, le bloc est invalide, donc il n'a jamais été dans la blockchain. Donc, bah, il ne peut pas être un "bloc précédent" à qui que ce soit

Chaque nouvelle confirmation diminue le risque de renversement puisque le nombre de blocs à refaire augmente

Par exemple si je veux renverser ta transaction qui est dans le bloc 100, et qu'on est actuellement au bloc 103, je dois recréer une sous-chaîne à partir du bloc 99 plus longue que l'actuelle: je dois créer de nouveaux blocs 100 à 104, c'est-à-dire 5 blocs à refaire
A l'instant où un 104è bloc arrive dans la chaîne "normale", pour renverser ta transaction je dois créer une sous-chaîne 100 à 105, donc 6 blocs

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
binaryFate
Legendary
*
Offline Offline

Activity: 1512
Merit: 1012


Still wild and free


View Profile
November 11, 2013, 11:08:08 PM
 #3

Bonsoir,  Smiley

Alors je fais un petit exposé en anglais (je suis étudiant) et j'ai trouvé trèèèèès interessant de le faire sur cette monnaie virtuelle.
Je me base donc sur plusieurs site et je me trouve aujourd'hui face à une incompréhension entre deux texts qui j'espère sera résolu grâce à vous.

( On parle ici de la création d'un nouveau bloc )
"Le bloc contiens aussi un hash du bloc précédent (en vert¹ sur mon image). Le mineur a aussi dû vérifier que la page précédente est valide, c-à-d que toute les transactions sur la page sont valides, que le mineur précédent ne s'est pas attribué plus de bitcoins que prévu par le protocole et que le hash de la page précédente est suffisamment petit." source : http://linuxfr.org/users/gof/journaux/comment-fonctionne-bitcoin

Et

"Les transactions reçoivent une confirmation lorsqu'elles sont incluses dans un bloc et pour chaque bloc subséquent" source : http://bitcoin.org/fr/vocabulaire#confirmation

Question :
- Pour terminer la formation d'un nouveau bloc, celui-ci dois trouver et ajouter une nonce(valeurs hash tel qu'il doit être inférieur à une certaine valeur[difficulté]) dans celui-ci. (si j'ai bien compris)
Alors pourquoi dans la première citation il est dit qu'un nouveau bloc doit vérifier le "nonce" du précédent ?
Un nouveau block ne doit pas vérifier le "nonce" du précédent. Ne te focalise pas sur le nonce, c'est pas important, c'est juste un moyen de trouver un hash satisfaisant. Un nouveau block doit contenir une référence vers le block précédent qui doit être lui-même valide.

- Pour qu'une transaction soit considéré comme "validé" elle doit être au minimum dans un bloc "finalisé".(si j'ai bien compris)
Alors pourquoi dans la première citation il est dit que l'on doit vérifier que les transactions du précédent bloc soit valides ?
Cf question précédente, pour que le bloc précédent sois valide, un certain nombre de rêgles doivent être vérifiée, entre autre que chaque transaction incluse dans le bloc est elle même valide.

Et question bonus : Pourquoi "Chaque nouvelle confirmation diminue exponentiellement le risque d'un renversement" ( à cause du de la double transaction ou de la création d'un bloc simultané qui scinde la chaine en deux ?)
Parce que pour faire une attaque, c'est à dire dans ce cas avoir la possibilité de sélectionner les transactions qui seront validées, voir de les "dévalider" après-coup, il faut être le premier à trouver tous les blocks à la suite (pour simplifier). Intuitivement, si tu controles moins que 50% de la puissance de minage, ta chance de trouver 2 blocs à la suite sans que personne d'autre ne te prenne de vitesse est plus grande que 10 à la suite. Une autre manière de voir: l'attaquant lance un dé et poursuit son attaque s'il fait 1, et perd s'il fait autre chose. Sa chance de succès (des 1 à la suite) se réduit géométriquement avec le nombre d'essai (elle est divisée par 6 à chaque fois). Tu parirai pas ta voiture qu'il peut pas faire "1" 5 fois de suite, mais probablement qu'il peut pas faire "1" 100 fois de suite.


Monero's privacy and therefore fungibility are MUCH stronger than Bitcoin's. 
This makes Monero a better candidate to deserve the term "digital cash".
onepix (OP)
Full Member
***
Offline Offline

Activity: 171
Merit: 100


View Profile
November 11, 2013, 11:20:27 PM
 #4

Suuuper !   Grin
Je vous remercie à tout d'avoir participer malgré l'heure ! J'ai tout compris, avec 3 explications différentes en plus !
Bonne soirée  Wink
binaryFate
Legendary
*
Offline Offline

Activity: 1512
Merit: 1012


Still wild and free


View Profile
November 11, 2013, 11:32:04 PM
 #5

T'aurai du poser les questions sur la partie anglaise, ça t'aurai évité la traduction !

Monero's privacy and therefore fungibility are MUCH stronger than Bitcoin's. 
This makes Monero a better candidate to deserve the term "digital cash".
Pages: [1]
  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!