Na minha opinião, é provável que para muitos "potenciais spammers" o ganho potencial de fazer um grande OP_RETURN fosse menor do que o custo (tempo/esforço) para contornar o filtro padrão amplamente difundido (principalmente porque uma coisa semelhante é alcançada a um custo menor usando o truque da inscrição), daí a frequência relativamente baixa de grandes OP_RETURNs observada até agora, e a queda acentuada no limite do filtro. Com peering preferencial e/ou submissão direta, o custo foi reduzido significativamente. Além disso, com todo o debate e drama (e a inevitável cobertura futura de novos usos de grandes OP_RETURNs), o benefício potencial cresceu. Agora o custo está caindo para 0 (exceto pelo custo do estigma social, que é limitado a um grupo muito pequeno). Também há um enorme valor em suas transações entrarem rapidamente no bloco candidato da vasta maioria dos mineradores, e assim o benefício cresceu ainda mais. Por essas razões, acho que é provável que vejamos um aumento na frequência de grandes OP_RETURNs nos próximos meses, desde que as taxas permaneçam tão (ridiculamente) baixas quanto têm estado nos últimos meses. Dito isso, não acho que isso seja um problema. Um mau OP_RETURN não vai matar o bitcoin, o que é uma boa notícia, porque se isso matasse o bitcoin, então um atacante bem financiado poderia fazer isso hoje minerando um bloco. A coisa mais provável que os grandes OP_RETURNs vão deslocar é uma carga de menores OP_RETURNs cunhando shitcoins (runes) ou txs de inscrição. Isso só é possível na escala com que está acontecendo porque as taxas estão historicamente baixas. Isso é consequência de uma quantidade diminuída de atividade "legítima" onchain - na minha opinião, essa é a "questão" muito mais importante que merece nossa atenção!

Sub 1 sat/vB verão será estudado por gerações futuras

Vendo alguns comentários a perguntar o que pode ser feito sobre este tipo de incorporação de dados (que existe há muito tempo). Isto é um pouco longo, mas espero que seja útil como referência para a questão mais geral de saber se se pode abordar "problemas" a nível de protocolo no nível dos mineradores / políticas. Realisticamente, a não ser que haja um soft fork, há muito pouco que se possa fazer tecnicamente, e mesmo isso teria sérias limitações e consequências (esse é o objetivo deste design de protocolo grosseiro). A primeira reação óbvia é pedir aos mineradores que parem de minerar coisas assim. Existem algumas maneiras, mas uma seria aumentar o seu -dustrelayfee. Por padrão, é 0.00003 BTC/kB (3 sat/vB), resultando num limite de saída de poeira de 330 sats para P2WSH. Para esta transação com 1859 tais saídas, o total bloqueado em saídas não gastáveis é 1859*330 = 613,470 sats ($736 @$120k/BTC). Digamos que você consiga fazer lobby junto da vasta maioria (95%) dos mineradores para aumentar este valor de configuração em 10x, o remetente teria que escolher entre pagar 6.1M sats ($7k) ou enviar como está e esperar até que a pequena proporção de mineradores (5%) use o antigo padrão. Provavelmente, eles fariam o último, porque essa é uma quantidade suficiente de hashrate para encontrar 7 blocos/dia em média, e qual é a pressa? Tendo falhado em parar isso a nível de mineradores, você pode agora ser tentado a fazer lobby junto dos operadores de nós para mudar o seu padrão e/ou mudar o padrão no core v31. Digamos que você teve sucesso, e o core v31 contém um padrão mais alto. O remetente pode simplesmente tentar se conectar preferencialmente para tentar alcançar os mineradores no protocolo. Então você dobra a aposta e finge uma conexão preferencial de modo que não seja suficientemente confiável. O remetente agora não tem escolha a não ser pagar um minerador OOB - se forem fazer isso, podem muito bem fazer com que cada saída seja 0 sats. Isso poderia, na verdade, ser mutuamente benéfico financeiramente para o remetente e o minerador, porque em vez de sats serem queimados como taxas, eles fluiriam para o minerador / seriam economizados pelo remetente. Agora, para ser justo, levaria esforço estabelecer estas vias diretas para mineradores que são exclusivamente motivados financeiramente, mas este é um custo fixo, e não tenho dúvidas de que isso seria feito, e depois integrado via API a serviços de cunhagem centralizados. Assim, o problema acabaria provavelmente por ser pior do que a situação que temos hoje.