На мой взгляд, вероятно, что для многих "потенциальных спамеров" возможная выгода от создания большого OP_RETURN была меньше затрат (времени/усилий) на обход широко распространенного фильтра по умолчанию (в основном потому, что аналогичный результат достигается с меньшими затратами с помощью трюка с inscription), поэтому относительно низкая частота больших OP_RETURN, наблюдаемая до сих пор, и резкое снижение на пороге фильтра. С предпочтительным пирингом и/или прямой подачей затраты значительно снизились. Кроме того, с учетом всех дебатов и драмы (и неизбежного будущего освещения новых способов использования больших OP_RETURN) потенциальная выгода возросла. Теперь затраты снижаются до 0 (за исключением социальной стигмы, которая ограничена очень небольшой группой). Также есть огромная ценность в том, чтобы ваши транзакции быстро попадали в кандидатный блок подавляющего большинства майнеров, и, таким образом, выгода еще больше возросла. По этим причинам я думаю, что мы увидим увеличение частоты больших OP_RETURN в ближайшие месяцы, если сборы останутся такими (нелепо) низкими, как они были в последние месяцы. Тем не менее, я не думаю, что это проблема. Плохой OP_RETURN не убьет биткойн, что является хорошей новостью, потому что если бы он убивал биткойн, то хорошо финансируемый атакующий мог бы сделать это сегодня, добыв блок. Наиболее вероятное, что большие OP_RETURN заменят, это множество меньших OP_RETURN, создающих shitcoins (руны) или транзакции с inscription. Это возможно только в том масштабе, в котором это происходит, потому что сборы исторически низкие. Это следствие уменьшенного количества "легитимной" активности в сети - на мой взгляд, это гораздо более важная "проблема", которая заслуживает нашего внимания!

Суб 1 сат/вБ лета будет изучаться поколениями вперед.

Я вижу несколько комментариев с вопросами о том, что можно сделать с таким типом встраивания данных (который существует уже давно). Это немного длинно, но, надеюсь, это будет полезно в качестве справки по более общему вопросу о том, можно ли решить «проблемы» на уровне протокола на уровне майнеров / политики. Реалистично, кроме мягкого форка, технически очень мало что можно сделать, и даже это будет иметь серьезные ограничения и последствия (в этом и заключается вся суть этого ужасного проектирования протокола). Очевидная первая реакция — попросить майнеров прекратить майнить такие вещи. Есть несколько способов, но один из них — увеличить их -dustrelayfee. По умолчанию это 0.00003 BTC/kB (3 sat/vB), что приводит к лимиту на выход пыли в 330 сат для P2WSH. Для этой транзакции с 1859 такими выходами общая сумма заблокированных непотраченных выходов составляет 1859*330 = 613,470 сат ($736 @$120k/BTC). Допустим, вам удастся убедить подавляющее большинство (95%) майнеров увеличить это значение конфигурации в 10 раз, отправитель будет вынужден выбирать между оплатой 6.1M сат ($7k) или отправкой как есть и ожиданием, пока небольшая доля майнеров (5%) будет использовать старый стандарт. Они, вероятно, выберут последнее, потому что этого хешрейта достаточно, чтобы находить 7 блоков в день в среднем, и в чем спешка? Не сумев остановить это на уровне майнеров, вы можете быть соблазнены убедить операторов узлов изменить свои настройки по умолчанию и/или изменить настройки по умолчанию в core v31. Допустим, вам это удалось, и core v31 содержит более высокий стандарт. Отправитель может просто предпочесть пировку, чтобы попытаться достичь майнеров в протоколе. Итак, вы удваиваете свои усилия и подделываете предпочтительную пировку так, чтобы она была недостаточно надежной. Теперь у отправителя нет выбора, кроме как заплатить майнеру OOB — если они собираются это сделать, им лучше сделать каждый выход 0 сат. Это может быть взаимовыгодно как для отправителя, так и для майнера, потому что вместо того, чтобы сатоши сжигались в качестве сборов, они будут поступать к майнеру / сохраняться отправителем. Теперь, чтобы быть честным, потребуется усилие, чтобы установить эти прямые связи с майнерами, которые исключительно финансово мотивированы, но это фиксированная стоимость, и я не сомневаюсь, что это будет сделано, а затем интегрировано через API в централизованные услуги чеканки. Таким образом, проблема, вероятно, окажется хуже, чем ситуация, которую мы имеем сегодня.