Encore un peu de désordre de @Excellion Quelques points : - CORE a effectivement modifié le consensus avec Taproot et SegWit. La combinaison des deux a donné lieu à un spam d’Ordinals sur la chaîne. - CORE a effectué un changement de politique non soutenu en supprimant la limite d’OP_RETURN. Il y a eu un vote de 4 contre 1, mais la modification a quand même été imposée, et celui qui l’a initiée a quitté CORE peu après. - CORE prétendait que cela visait à offrir une alternative permettant de diriger le spam vers un chemin pouvant être supprimé… mais ils ont aussi affirmé que les spammeurs ne l’utiliseraient probablement pas, car abuser de SegWit était moins coûteux. Je crois que cela est documenté dans la série de captures de @hodlonaut, et de nombreux posts et tweets de @murchandamus confirment cela (ainsi que le fait que personne n’utilise cette modification)… ce qui soulève la question : pourquoi l’avoir débloquée en premier lieu ? @BitcoinKnots est apparu comme une réponse permettant aux utilisateurs de rétablir par défaut la limite de 83B sur leurs nœuds. Les utilisateurs ordinaires ont été moqués, Knots a été considéré comme une blague, et on a affirmé qu’il fallait cette puissance de minage. Cela a conduit à la croissance de @ocean_mining jusqu’à devenir l’un des 10 principaux pools de minage, et le client Knots à couvrir environ 1 nœud sur 5 de l’ensemble du réseau. Pendant cette période de croissance, nous avons été confrontés à des allégations de « peering préférentiel » afin que le spam puisse atteindre la chaîne, et seul un changement de consensus solide pouvait l’arrêter… BIP110 est alors apparu comme réponse. Voilà ce qui s’est passé au cours des trois dernières années pour nous amener à où nous en sommes aujourd’hui. En résumé, @Excellion simplifie et minimise des problèmes sérieux en ignorant une grande partie de l’histoire corrompue et difficile.