À mon avis, il est probable que pour de nombreux "candidats spammeurs", le gain potentiel d'un grand OP_RETURN était inférieur au coût (temps/effort) pour contourner le filtre par défaut largement répandu (principalement parce qu'une chose similaire est réalisée à moindre coût en utilisant le truc de l'inscription), d'où la fréquence relativement faible des grands OP_RETURN observés jusqu'à présent, et la forte chute au seuil du filtre. Avec le peering préférentiel et/ou la soumission directe, le coût a considérablement diminué. De plus, avec tout le débat et le drame (et la couverture inévitable des nouvelles utilisations des grands OP_RETURN), le bénéfice potentiel a augmenté. Maintenant, le coût tombe à 0 (à part le coût de la stigmatisation sociale, qui est limité à un très petit groupe). Il y a aussi une énorme valeur à ce que vos transactions entrent rapidement dans le bloc candidat de la grande majorité des mineurs, et donc le bénéfice a encore augmenté. Pour ces raisons, je pense qu'il est probable que nous verrons une augmentation de la fréquence des grands OP_RETURN dans les mois à venir, à condition que les frais restent aussi (ridiculement) bas qu'ils l'ont été ces derniers mois. Cela dit, je ne pense pas que ce soit un problème. Un mauvais OP_RETURN ne tuera pas le bitcoin, ce qui est une bonne nouvelle, car s'il devait tuer le bitcoin, alors un attaquant bien financé pourrait le faire aujourd'hui en minant un bloc. La chose la plus probable que les grands OP_RETURN vont remplacer est une charge de petits OP_RETURN frappant des shitcoins (runes) ou des txs d'inscription. Cela n'est possible qu'à l'échelle à laquelle cela se produit parce que les frais sont historiquement bas. Cela découle d'une diminution de l'activité "légitime" on-chain - à mon avis, c'est le "problème" beaucoup plus important qui mérite notre attention !

Le sous 1 sat/vB de l'été sera étudié par les générations à venir

Je vois quelques commentaires demandant ce qui peut être fait à propos de ce type d'incorporation de données (qui existe depuis longtemps). C'est un peu long, mais j'espère que cela sera utile comme référence à la question plus générale de savoir si vous pouvez aborder les "problèmes" au niveau du protocole au niveau des mineurs / des politiques. De manière réaliste, à part un soft fork, il y a très peu de choses qui peuvent être faites techniquement, et même cela aurait de sérieuses limitations et conséquences (c'est tout l'intérêt de ce design de protocole défectueux). La première réaction évidente est de demander aux mineurs d'arrêter de miner des choses comme ça. Il y a quelques façons, mais l'une d'elles serait d'augmenter leur -dustrelayfee. Par défaut, c'est 0.00003 BTC/kB (3 sat/vB), ce qui entraîne une limite de sortie de poussière de 330 sats pour P2WSH. Pour cette transaction avec 1859 telles sorties, le total bloqué dans des sorties non dépensables est de 1859*330 = 613,470 sats (736 $ à 120k/BTC). Disons que vous parvenez à convaincre la grande majorité (95%) des mineurs de multiplier cette valeur de configuration par 10, l'expéditeur devrait choisir entre payer 6.1M sats (7k $) ou envoyer tel quel et attendre jusqu'à ce que la petite proportion de mineurs (5%) utilisant l'ancien défaut. Ils feraient probablement ce dernier choix car cela représente suffisamment de hashrate pour trouver 7 blocs/jour en moyenne, et quelle est l'urgence ? Ayant échoué à arrêter cela au niveau des mineurs, vous pourriez maintenant être tenté de convaincre les opérateurs de nœuds de changer leur défaut et/ou de changer le défaut dans le core v31. Disons que vous réussissez, et que le core v31 contient un défaut plus élevé. L'expéditeur peut simplement se connecter préférentiellement pour essayer d'atteindre les mineurs dans le protocole. Donc, vous doublez la mise et vous simulez un peering préférentiel de sorte qu'il ne soit pas suffisamment fiable. L'expéditeur n'a maintenant d'autre choix que de payer un mineur OOB - s'ils doivent le faire, autant que chaque sortie soit de 0 sats. Cela pourrait en fait être financièrement bénéfique pour l'expéditeur et le mineur, car au lieu que les sats soient brûlés en tant que frais, ils iraient au mineur / seraient économisés par l'expéditeur. Pour être juste, il faudrait un effort pour établir ces rails directs vers des mineurs qui sont exclusivement motivés financièrement, mais c'est un coût fixe, et je n'ai aucun doute que cela serait fait, puis intégré via API à des services de minting centralisés. Ainsi, le problème serait probablement pire que la situation que nous avons aujourd'hui.