Побачив кілька коментарів із запитанням, що можна зробити з цим типом вбудовування даних (який існує вже давно). Це трохи довго, але, сподіваюся, воно буде корисним як посилання на більш загальне питання про те, чи можете ви вирішити "проблеми" на рівні протоколу на рівні майнера / політики. Насправді, за винятком софт-форку, дуже мало що можна зробити технічно, і навіть це матиме серйозні обмеження та наслідки (ось і вся суть цього грубого дизайну протоколу). Очевидною першою реакцією є прохання до майнерів припинити майнінг подібних речей. Є кілька способів, але одним з них було б збільшення їх -dustrelayfee За замовчуванням це 0,00003 BTC/kB (3 sat/vB), що призводить до обмеження на вихід пилу 330 сатош для P2WSH. Для цієї транзакції з 1859 такими виходами загальна заблокована кількість невитрачених виходів становить 1859*330 = 613 470 сатош ($736 @$120k/BTC) Скажімо, ви успішно лобіюєте переважну більшість (95%) майнерів до 10-кратного цього значення конфігурації, відправнику доведеться вибирати між оплатою 6,1 млн сатошів ($7 тис.) або відправкою як є і чекає, поки невелика частка майнерів (5%) використовуватиме старе значення за замовчуванням. Вони, мабуть, зробили б останнє, тому що цього хешрейту достатньо, щоб знайти в середньому 7 блоків на день, і який поспіх? Не зумівши зупинити це на рівні майнера, тепер у вас може виникнути спокуса лобіювати бігунів вузлів, щоб вони змінили їх за замовчуванням та/або змінили стандартне в core v31. Скажімо, ви досягли успіху, і core v31 містить вищий показник за замовчуванням. Відправник може просто переважно пірингувати, щоб спробувати зв'язатися з майнерами в протоколі. Таким чином, ви подвоюєте зусилля і підробляєте преференційне пірингування так, що воно недостатньо надійне. Тепер у відправника немає іншого вибору, окрім як заплатити майнеру OOB - якщо він хоче це зробити, то може зробити так, щоб кожен вихід становив 0 сато. Насправді це може бути взаємовигідно фінансово вигідно для відправника та майнера, тому що замість того, щоб спалювати сатоші як комісію, вони надходили б майнеру / зберігалися відправником. Чесно кажучи, потрібно було б докласти зусиль, щоб встановити ці прямі рейки до майнерів, які виключно фінансово мотивовані, але це фіксовані витрати, і я не сумніваюся, що це було б зроблено, а потім інтегровано через API в централізовані служби карбування. Таким чином, проблема, швидше за все, виявиться гіршою, ніж ситуація, яку ми маємо сьогодні.