Chaque noeud gère son propre mempool, et y inclue toutes les transactions valides dont il entend parler.
(...)
Après un certain temps, il n'est donc pas exclu que le réseau "oublie" l'existence d'une transaction non-confirmée, mais cela peut prendre beaucoup de temps.
(...)
Après un certain temps, il n'est donc pas exclu que le réseau "oublie" l'existence d'une transaction non-confirmée, mais cela peut prendre beaucoup de temps.
Tu veux dire qu'avec un peu de chances, un nœud pourrait valider la transaction, pendant qu'un autre qui l'aurait "oublié" accepterait de valider une deuxième transaction vers un autre compte ? Il faut tomber pile au bon moment, c'est sûr, mais ça me semble contraire au principe de la double dépense. J'aimerais avoir l'explication d'un spécialiste, sur ce point là.
Si j'ai bien compris c'est un peu plus compliqué que l'ordre d'arrivée, entre autre la taille de la transaction le présence de frais selon le parametrage du miner qui fait un peu ce qu'il veut pour remplir son block ...
Le mineur pioche dans le mempool au moment de la construction du bloc.
Selon mon exemple, quelques soient les critères du mineur, il ne pourra piocher que X ou Y car son mempool ne contiendra que l'une des deux.
Jette un oeil à l'implémentation de référence : https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp
C'est la fonction CreateNewBlock() qui va piocher dans le mempool, ensuite la fonction TxPriorityCompare() est utilisée pour classer les transactions par ordre de "priorité".
(la fonction ComputePriority() qui calcule les priorités est là : https://github.com/bitcoin/bitcoin/blob/master/src/core.cpp )
