Dans la mesure ou la transaction doit être incluse dans le prochain bloc pour être considérée comme définitive, ça prend plutôt de l'ordre de la trouvaille d'un bloc (donc dans la dizaine de minutes) non ?
Trés bonne question mon cher rakoo, mais c'est assez compliquée de répondre simplement mais je vais tenter
A chaque transaction tu as :
1 - émission de la transaction ( signature du débit par la clé privée ) ( > 1s )
2 - Verification de celle-ci par les mineurs du réseau ( 2-10 s environ pour une validation)
3 - Ajout de la transaction au bloc courant ( ~10 min )
4 - Ajout du bloc courant à la chaine.
La seul manière raisonnable de faire refuser une transaction de faire valider une transaction concurrente plus rapidement qui vide le compte débiteur en question. Cette technique impose d'obtenir la validation de la transaction "pirate" par N/2+1 mineurs du réseau ( N étant le nombre de mineur maximum ) avant la validation de la transaction "originale".
Les chances qu'une telle transaction se fassent acceptée décroit donc exponentiellement avec le temps, et les probabilités qu'une telle chose arrive aprés quelques minutes sont pratiquement nulles.
( Un papier ici décrit la chose : http://eprint.iacr.org/2012/248.pdf )
L'ajout de la transaction au bloc et à la chaine étant seulement le commit ultime qui l'inscrira dans les registres de manière permanente.
[^] # Re: Des bitcoins pour quoi faire ?
Posté par Firwen (site web personnel) . En réponse au journal Les Bitcoins, c'est so mainstream !. Évalué à 0.
Trés bonne question mon cher rakoo, mais c'est assez compliquée de répondre simplement mais je vais tenter
A chaque transaction tu as :
1 - émission de la transaction ( signature du débit par la clé privée ) ( > 1s )
2 - Verification de celle-ci par les mineurs du réseau ( 2-10 s environ pour une validation)
3 - Ajout de la transaction au bloc courant ( ~10 min )
4 - Ajout du bloc courant à la chaine.
La seul manière raisonnable de faire refuser une transaction de faire valider une transaction concurrente plus rapidement qui vide le compte débiteur en question. Cette technique impose d'obtenir la validation de la transaction "pirate" par N/2+1 mineurs du réseau ( N étant le nombre de mineur maximum ) avant la validation de la transaction "originale".
Les chances qu'une telle transaction se fassent acceptée décroit donc exponentiellement avec le temps, et les probabilités qu'une telle chose arrive aprés quelques minutes sont pratiquement nulles.
( Un papier ici décrit la chose : http://eprint.iacr.org/2012/248.pdf )
L'ajout de la transaction au bloc et à la chaine étant seulement le commit ultime qui l'inscrira dans les registres de manière permanente.