Block bizarre

[guigui371]

Je regardait la mempool  via ce lien : https://mempool.space/

Les blocks font en general 1.2Mb avec 2200 tx

Et la je vois un block avec 0 fees  - 0 tx   et seulement  366b au lieu de 1.2Mb.




https://mempool.space/block/000000000000000000082baa535caa96bb46f27bc567185fc84bd9d5eaf10578

Block : 640258


Qui sait m'expliquer ce qu'il se passe ?

[1715042760]

1715042760

[1715042760]

1715042760

[1715042760]

1715042760

[yogg]

Je regardait la mempool  via ce lien : https://mempool.space/

Les blocks font en general 1.2Mb avec 2200 tx

Et la je vois un block avec 0 fees  - 0 tx   et seulement  366b au lieu de 1.2Mb.




https://mempool.space/block/000000000000000000082baa535caa96bb46f27bc567185fc84bd9d5eaf10578

Block : 640258


Qui sait m'expliquer ce qu'il se passe ?

Les mineurs ne sont pas obligés d'inclure des transactions dans les blocks qu'ils minent.
Tant que tout ce qui touche au consensus de Bitcoin est valide, le block sera accepté.
Techniquement, il contient une transaction, la coinbase transaction (transaction de création de nouveaux BTC).

Maintenant quant au pourquoi ?
Je suis pas sûr car je mine pas, mais peut être que c'est plus rapide de compléter la génération d'un sha256(sha256(block)) si le block contient moins de données.
Dans ce cas précis, la pool F2Pool doit considérer que c'est plus important de trouver un block pour récup' la coinbase transaction, plutôt que de trouver un block contenant des transactions car les frais rattachés aux transactions ne sont pas assez appétissants.

Une courte visualisation du fonctionnement de l'algo sha256 (en anglais) : https://youtu.be/mbekM2ErHfM?t=106


Un block BTC est constitué ainsi :


(https://en.bitcoin.it/wiki/Block#Block_structure)

Tant que l'en-tête (Blockheader) et le reste est valide, le block sera accepté.
Maintenant, je pense que moins il y'a de transactions, plus c'est rapide de générer l'identifiant d'un block.

[asche]

Je regardait la mempool  via ce lien : https://mempool.space/

Les blocks font en general 1.2Mb avec 2200 tx

Et la je vois un block avec 0 fees  - 0 tx   et seulement  366b au lieu de 1.2Mb.




https://mempool.space/block/000000000000000000082baa535caa96bb46f27bc567185fc84bd9d5eaf10578

Block : 640258


Qui sait m'expliquer ce qu'il se passe ?

Les mineurs ne sont pas obligés d'inclure des transactions dans les blocks qu'ils minent.
Tant que tout ce qui touche au consensus de Bitcoin est valide, le block sera accepté.
Techniquement, il contient une transaction, la coinbase transaction (transaction de création de nouveaux BTC).

Maintenant quant au pourquoi ?
Je suis pas sûr car je mine pas, mais peut être que c'est plus rapide de compléter la génération d'un sha256(sha256(block)) si le block contient moins de données.
Dans ce cas précis, la pool F2Pool doit considérer que c'est plus important de trouver un block pour récup' la coinbase transaction, plutôt que de trouver un block contenant des transactions car les frais rattachés aux transactions ne sont pas assez appétissants.

Une courte visualisation du fonctionnement de l'algo sha256 (en anglais) : https://youtu.be/mbekM2ErHfM?t=106


Un block BTC est constitué ainsi :


(https://en.bitcoin.it/wiki/Block#Block_structure)

Tant que l'en-tête (Blockheader) et le reste est valide, le block sera accepté.
Maintenant, je pense que moins il y'a de transactions, plus c'est rapide de générer l'identifiant d'un block.

Super intéressant. Mais ça veut dire quoi ? Qu'il y a eut race pour ce bloc ?

Parce que F2P ne fait pas ça pour tout les blocs, et heureusement, sinon on ne serait pas dans la merde niveau fees. Et en plus ils n'ont aucun intérêt à rendre BTC moins utilisable en augmentant les fees, au final ils restent de gros contributeurs du réseau. Ce serait carrément contre productif...

[yogg]

Super intéressant. Mais ça veut dire quoi ? Qu'il y a eut race pour ce bloc ?

Parce que F2P ne fait pas ça pour tout les blocs, et heureusement, sinon on ne serait pas dans la merde niveau fees. Et en plus ils n'ont aucun intérêt à rendre BTC moins utilisable en augmentant les fees, au final ils restent de gros contributeurs du réseau. Ce serait carrément contre productif...

Il y'a deux explications possibles.

1/
C'est un peu un race perpétuel entre mineurs pour trouver le prochain block.

Maintenant, en voyant ça :



(https://automationrhapsody.com/md5-sha-1-sha-256-sha-512-speed-performance/)

On voit bien que la taille de la donnée hashée impacte bien le temps de traitement.

Les frais moyens pour 1tx sur BTC ont évolués ainsi durant le mois de Juin :


(https://bitinfocharts.com/comparison/bitcoin-transactionfees.html)

Si hasher 1Mo+ de données (block plein) est moins rapide que hasher 366 octets (block vide), c'est économiquement plus intéressant de miner "à vide" quand les frais sont bas.
Les mineurs génèrent davantage d'identifiants de blocks, et comme c'est ce résultat qui détermine si la preuve de travail a été trouvée, ils ont plus de chance de récup' la coinbase transaction.


2/
Le block juste avant (#640257) a été trouvé la minute d'avant par ViaBTC.
Avec le temps de propagation du block sur le réseau, ça déclenche un recalibrage du block que les mineurs cherchent.
(Un peu comme quand on lance un caillou dans une mare)

Il faut sélectionner de nouvelles transactions à inclure dans le nouveau block construit;
éventuellement pendant cette compilation et construction d'un nouveau block, F2Pool minerait "à vide" pour ne perdre aucun hash.

Je ne suis pas sûr, mais je penche plus pour la seconde solution car les frais par tx ont grimpés dernièrement.

[asche]

1/
C'est un peu un race perpétuel entre mineurs pour trouver le prochain block.

On voit bien que la taille de la donnée hashée impacte bien le temps de traitement.

Les frais moyens pour 1tx sur BTC ont évolués ainsi durant le mois de Juin :


(https://bitinfocharts.com/comparison/bitcoin-transactionfees.html)

Si hasher 1Mo+ de données (block plein) est moins rapide que hasher 366 octets (block vide), c'est économiquement plus intéressant de miner "à vide" quand les frais sont bas.
Les mineurs génèrent davantage d'identifiants de blocks, et comme c'est ce résultat qui détermine si la preuve de travail a été trouvée, ils ont plus de chance de récup' la coinbase transaction.


2/
Le block juste avant (#640257) a été trouvé la minute d'avant par ViaBTC.
Avec le temps de propagation du block sur le réseau, ça déclenche un recalibrage du block que les mineurs cherchent.
(Un peu comme quand on lance un caillou dans une mare)

Il faut sélectionner de nouvelles transactions à inclure dans le nouveau block construit;
éventuellement pendant cette compilation et construction d'un nouveau block, F2Pool minerait "à vide" pour ne perdre aucun hash.

Je ne suis pas sûr, mais je penche plus pour la seconde solution car les frais par tx ont grimpés dernièrement.

Pour moi ton option 1 est pas possible. Ce serait un gros risque pour le réseau, et si les gens se mettaient à faire ça il faudrait push un BIP pour punir ce comportement.

L'option 2, si je comprends bien, c'est en partie du au fait que le block a été trouvé très rapidement, cela me semble beaucoup plus plausible.

[yogg]

Pour moi ton option 1 est pas possible. Ce serait un gros risque pour le réseau, et si les gens se mettaient à faire ça il faudrait push un BIP pour punir ce comportement.

L'option 2, si je comprends bien, c'est en partie du au fait que le block a été trouvé très rapidement, cela me semble beaucoup plus plausible.

Je pense qu'il y a un delta ou c'est profitable de miner à vide.

Pourquoi ça serait un risque pour le réseau ?
Quel genre de BIP tu voudrais implémenter pour dissuader ce comportement ?

Je ne vois pas en quoi c'est un risque.
Des blocks vides sortent, la mempool grossit, les frais augmentent pour que chacun aie son tx inclus dans la blockchain dans les quelques prochains blocks, et pouf ça redevient profitable de rajouter des transactions dans le block.

(Car c'est + rentable de prendre le temps pour executer les sha256 avec 1Mo+ que de miner à vide)

Je suis mauvais en formalisme mathématique donc je ne saurais pas te poser l'équation, mais il y'a un seuil.


C'est un système très dynamique.

Les mineurs peuvent créer des spams transactions pour remplir la mempool et n'avoir que les tx avec le + de frais qui sont inclus.
Une partie des mineurs peut s'allier aussi pour .. par exemple .. refuser d'inclure quelque tx venant de coinbase ou quelque autre source.

[asche]

Pour moi ton option 1 est pas possible. Ce serait un gros risque pour le réseau, et si les gens se mettaient à faire ça il faudrait push un BIP pour punir ce comportement.

L'option 2, si je comprends bien, c'est en partie du au fait que le block a été trouvé très rapidement, cela me semble beaucoup plus plausible.

Je pense qu'il y a un delta ou c'est profitable de miner à vide.

Pourquoi ça serait un risque pour le réseau ?
Quel genre de BIP tu voudrais implémenter pour dissuader ce comportement ?

Je ne vois pas en quoi c'est un risque.
Des blocks vides sortent, la mempool grossit, les frais augmentent pour que chacun aie son tx inclus dans la blockchain dans les quelques prochains blocks, et pouf ça redevient profitable de rajouter des transactions dans le block.

(Car c'est + rentable de prendre le temps pour executer les sha256 avec 1Mo+ que de miner à vide)

Je suis mauvais en formalisme mathématique donc je ne saurais pas te poser l'équation, mais il y'a un seuil.


C'est un système très dynamique.

Les mineurs peuvent créer des spams transactions pour remplir la mempool et n'avoir que les tx avec le + de frais qui sont inclus.
Une partie des mineurs peut s'allier aussi pour .. par exemple .. refuser d'inclure quelque tx venant de coinbase ou quelque autre source.

Parce que cela pourrait générer une perte de confiance. C'est assez qu'on qu'en effet ce serait plus rentable de miner a vide qu'avec de faible fees. Seulement vu le niveau de fee actuel cela ne tient pas.

Ou alors tous les blocs d'il y a quelques semaines seraient sortis vides.