(Je n'avais jamais essayé ce truc d'article X auparavant)
Laissez-moi commencer par dire que je ne suis ni pro-BIP110, ni anti-BIP110. Si cela réussit à obtenir un véritable consensus au sein du réseau et finit par être appliqué par une majorité du réseau… cool. Si c'est le cas, alors nous suivrons car le réseau a parlé et l'a accepté, et tous les nœuds, y compris ceux qui ne sont pas BIP110, seront entraînés dans l'aventure.
Malheureusement pour les partisans de la proposition, ce n'est tout simplement pas le cas actuellement, selon toute mesure, et rien n'indique que cela va changer non plus.
Il y a eu beaucoup d'informations trompeuses sur tout cela, surtout dans le contexte du minage. Voici quelques points clés rapides pour contrer brièvement certaines exagérations des partisans :
- BIP110 n'est PAS inévitable. Il PEUT échouer.
- BIP110 peut et va provoquer une scission/division de chaîne en situation de hashrate minoritaire.
- BIP110 n'est PAS sans risque pour les mineurs qui choisissent de l'adopter.
- Les mineurs qui ne soutiennent pas BIP110 ne minent soudainement pas des blocs « invalides » simplement parce qu'une proposition qui n'est pas encore adoptée existe.
- Vous n'êtes pas une mauvaise personne ou maléfique simplement parce que vous n'aimez pas ou ne soutenez pas BIP110.
(Le fait que je ressente le besoin de souligner cette dernière partie est en fait un peu triste…)
J'allais écrire un long article pour aider à informer les mineurs sur les choses dont ils doivent rester conscients pendant que tout cela se déroule… avant de réaliser que je l'avais déjà fait il y a des mois sous la forme d'un document que j'ai rédigé et que j'espérais pouvoir publier comme un document d'éducation des mineurs chez OCEAN. Malheureusement, il n'a jamais été publié. Alors je l'ai mis à jour, et le voici :
https://docs.google.com/document/d/14DfMSVYBHTHIOmW32JTOR6BAP7AITbinvrhl8rJuvvc/edit?usp=sharing
Encore une fois, gardez à l'esprit que cela a été écrit il y a des mois, avec l'intention d'être aussi neutre que possible dans le but de le rendre acceptable comme un article d'entreprise. Cet effort a échoué, donc je le publie aujourd'hui comme un document personnel.
En tant que mineur prenant des décisions importantes concernant vos opérations, vous devez être conscient de tout cela sans le sucre et les informations carrément trompeuses qui viennent de certains partisans du BIP110. Vous devez être vigilant, et décider ce qui est bon pour vous. Bien qu'il y ait aussi certaines informations trompeuses de la part de l'opposition, rien de ce que j'ai vu n'est aussi flagrant que les déclarations de victoire extrêmement prématurées et l'exagération qui les accompagne, poussées par le camp BIP110.
En résumant un peu mon document, mon conseil personnel aux mineurs est le suivant :
- Signalez si vous soutenez BIP110
- Ne signalez pas si vous ne soutenez pas BIP110 ou si vous vous en fichez
- Dans tous les cas, surveillez le réseau aux alentours/avant/après le bloc 961632.
- Si vous continuez à voir des blocs non signalés provenant de grands pools, vous pouvez être raisonnablement certain qu'ils ne vont pas soudainement décider plus tard de jeter des millions de dollars de revenus pour faire marche arrière et signaler BIP110.
- Si par hasard ils commencent à signaler BIP110, vous devez surveiller cela et envisager de changer de pool si nécessaire pour rester sur la chaîne la plus lourde.
Le point clé étant que, réalistement, un seul camp peut gagner. Soit BIP110 réussit et les mineurs qui ne sont pas du côté BIP110 échouent, soit BIP110 échoue et les mineurs du côté non-BIP110 réussissent.
Passons à autre chose, plongeons dans une petite partie de ma justification.
🟠FAIT RAPIDE : Entre 7 et 15 % des nœuds Bitcoin signalent leur soutien au BIP110.
Selon le crawler centralisé que vous consultez… impossible de savoir avec certitude. Mon crawler privé personnel place ce chiffre beaucoup plus bas, mais c'est une discussion pour un autre jour. Qu'il suffise de dire que je pense qu'il est logique et correct de dire que même 15 % n'est pas une majorité.
« Mais Jason ! L'UASF a activé Segwit avec moins de nœuds ! »
Oui, parce que de nombreux mineurs, commerçants, utilisateurs, etc. voulaient réellement Segwit. Il y avait un poids économique et communautaire énorme derrière. Sans revenir sur tout cela (de nombreuses ressources sur le sujet d'avant BIP110 valent la peine d'être lues), qu'il suffise de dire que BIP110 et les activations de Segwit ne sont pas tout à fait comparables, comme beaucoup l'ont déjà souligné. Segwit, par exemple, est entré dans son territoire UASF avec environ 1/3 du hashrate du réseau qui signalait déjà son soutien. Avec un tel soutien, l'UASF pour aider à pousser le MASF au-delà du point de basculement avait beaucoup de sens.
Cela n'a pas de sens ici pour BIP110.
🟠FAIT RAPIDE : 0,6 % des blocs des 60 derniers jours ont signalé un soutien au BIP110.
Contraste assez frappant même avec le faible soutien de base de Segwit. Oui, je sais que cela a légèrement augmenté ces dernières semaines, mais aucun nouvel entrant. Juste plus de hashrate loué clairement de la part d'un des mêmes petits partisans.
Quelque chose à garder à l'esprit est que miner des blocs de signalisation BIP110 via DATUM sur OCEAN ne comporte pratiquement aucun risque pour le mineur jusqu'au point de fork au bloc 961632. Le coût est négligeable, car vous êtes effectivement assuré de récupérer les coûts de location, etc.
C'est génial que cette capacité existe, et je ne voudrais pas qu'il en soit autrement… mais c'est juste quelque chose à garder à l'esprit lorsque vous évaluez la signalisation de tels blocs dans l'ensemble des choses du point de vue risque/récompense/argent sur la table.
« Mais Jason ! Les mineurs n'ont aucune incitation à signaler jusqu'à la dernière minute ! »
Je ne vois également aucune preuve suggérant que cela pourrait être le cas. Subjectivement, je ne suis pas d'accord avec le postulat, car ce n'est pas dans l'intérêt d'un pool minier de déstabiliser le réseau de cette manière. Une partie de la raison des périodes de signalisation précoce et de verrouillage est d'aider à coordonner les mises à niveau de manière fluide. Attendre la dernière minute annule complètement cet avantage. Je ne vois aucune raison convaincante ou avantage à le faire.
En continuant sur ce sujet, dans le cadre de ma configuration personnelle de surveillance des nœuds, je surveille spécifiquement les nœuds connus pour appartenir à diverses entités, comme d'autres pools miniers, des échanges, de gros nœuds Lightning, des commerçants, etc. Une supermajorité d'entre eux sont surveillés avec une autorisation explicite et une confirmation/coordination.
🟠FAIT RAPIDE : Tous les principaux pools miniers que je surveille exécutent actuellement une variante de Bitcoin Core v30 ou v31 (sauf OCEAN).
Pour développer, la plupart ont mis à jour leurs nœuds depuis la prolifération de la sortie de BIP110, même depuis la sortie de Knots 29.3. De plus, on sait que de nombreux pools miniers exécutent des versions modifiées de leur logiciel de nœud pour faciliter diverses exigences de leur infrastructure spécifique. Ces changements devraient être portés vers un client compatible BIP110, testés, évalués et déployés à l'avance. Je ne vois actuellement aucune preuve que cela soit le cas.
Pour autant que je sache, les pools sont au courant mais ignorent.
« Mais Jason ! Les mineurs ne déterminent pas le consensus ! Ce sont les nœuds ! Sinon, ils vont simplement annuler les halvings ! »
C'est l'un des arguments les plus drôles et les plus ridicules que j'aie entendus de la part des partisans du BIP110. Comparer un changement de consensus qui peut être imposé unilatéralement au réseau par les mineurs et accepté par 100 % des nœuds existants (un soft fork), avec un hard fork qu'aucun nœud existant n'acceptera… est au mieux trompeur.
Resserrer les règles (comme BIP110) : Soft fork, peut être imposé par les mineurs s'ils le décident. Assouplir les règles (comme annuler un halving) : Hard fork, ne peut pas être imposé par les mineurs sans un accord effectif de 100 % de l'ensemble du réseau… ce qui n'est pas susceptible de se produire.
Comparer les deux est, franchement, tout simplement stupide.
« Mais Jason ! Si vous ne mettez pas à jour vers les dernières règles de consensus, vous êtes en insécurité ! Vous perdrez des fonds ! Vous minerez des blocs invalides ! Vous [insérez une hyperbole supplémentaire ici] ! »
Ce serait vrai pour un changement de consensus qui a, eh bien, le consensus. Bien que BIP110 ait fait un effort vaillant pour obtenir ce consensus, il n'a pas encore de majorité mesurable à ce qui est maintenant sans doute la onzième heure. Ni dans les nœuds, ni dans le hashrate, ni dans les couches sociales (consensus.health a une visualisation sympa là où vous me trouverez au milieu).
Si d'une manière ou d'une autre BIP110 obtient 51 %+ du hashrate du réseau au bloc 961632 ou avant… alors, d'accord. Il est appliqué, puisque en tant que soft fork, une majorité de mineurs peut l'imposer unilatéralement en l'absence d'un URSF pleinement adopté (ce qui est effectivement un abus de langage, car ce serait une sorte de hard fork).
« Mais Jason ! Il ne peut pas obtenir le consensus en ayant déjà le consensus ! Vous devez lui donner une chance ! »
Premièrement… non, je ne le dois pas, même si je l'ai fait. Deuxièmement, c'est une proposition précipitée qui n'a jamais eu le temps d'essayer d'obtenir un véritable consensus. Sept mois se sont écoulés depuis la sortie du premier client BIP110. Il reste environ trois semaines avant le début de la signalisation « obligatoire » (moins au moment où vous lirez ceci). 90 % du temps disponible s'est écoulé sans changement de sentiment général de la part des acteurs concernés. Si cela n'a pas obtenu une adoption suffisante au cours des 7 derniers mois, il est peu probable que cela se produise dans les 3 prochaines semaines.
« Mais Jason ! CSAM ! CSAM ! Pédophiles ! CSAM ! »
Je serai le premier à dire que j'ai personnellement exagéré le risque au début lorsque Core a proposé son changement d'OP_RETURN. Je m'attendais personnellement à ce que quelque chose de particulièrement odieux frappe la chaîne presque immédiatement, et à ma connaissance, cela n'est pas encore arrivé. Cela pourrait-il encore arriver ? Oui, je suppose.
Mais en considérant d'un point de vue technique, octet par octet, les mêmes données arbitraires contiguës peuvent être stockées de manière prouvable dans la chaîne actuelle ou dans la chaîne BIP-110 sans trop de problème… cet argument particulier pour BIP-110 me semble assez plat à ce stade.
Est-ce que je veux du CSAM dans la chaîne ? Bien sûr que non. Suis-je un pédophile si je ne soutiens pas BIP110 ? Non plus.
…
Je pourrais continuer encore et encore, mais je vais m'arrêter là. J'ai déjà perdu assez de temps là-dessus. Je suis sûr que j'ai fait beaucoup pour ennuyer les deux côtés du débat BIP110 à ce stade, car je n'adopte aucune position. Je suis sûr que je vais me faire tirer dessus de tous les côtés simplement pour avoir osé dire ce que je pense.
Dans l'ensemble, je pense surtout qu'il était idiot d'aborder un vrai problème (le changement par défaut d'OP_RETURN dans Bitcoin Core) avec une proposition de soft fork basée sur un manifeste anti-spam maximal… qui ne peut prouver qu'il arrête le spam, les données arbitraires, etc. 🤦♂️ (Oui, je sais, les partisans diront qu'il ne s'agit pas de spam… et feront aussi des arguments sémantiques selon lesquels il arrête aussi les données… ce qui ne semble pas être correct dans les deux cas.)
Je terminerai en concédant que je pourrais me tromper. Je ne suis pas Nostradamus, et je ne peux pas prédire avec précision le résultat avec une certitude à 100 %. Je ne peux que me fier à ce que les données me disent, et donc je donne au succès de BIP110 moins de 5 % de chances de réussir… et je considère cela comme généreux.
Vous pouvez prendre mes opinions comme vous le souhaitez, mais je vous recommande vivement de ne pas ignorer les points de données réels, de rester vigilant et de faire ce qui est le mieux pour vous et vos revenus miniers. Ne vous laissez pas manipuler par l'un ou l'autre côté du débat, et prenez vos propres décisions.
Voici un lien vers le même document lié ci-dessus pour un accès facile : https://docs.google.com/document/d/14DfMSVYBHTHIOmW32JTOR6BAP7AITbinvrhl8rJuvvc/edit?usp=sharing
