Topic: Замусоривание блокчейна (Read 875 times)

Да, это совсем другая история. У Гринлайта, конечно, такого нет.

Мы, наверное, о разных реализациях говорим. Если покажете пример этого самого Greenlight -- я смогу прокомментировать.
Я говорю о том, что я вижу своими глазами.
а) При закрытии канала создаются два хвостика (бывают исключения, но я сейчас о самом распространенном кейсе)
б) Эти хвостики имеют вполне определенный скрипт для траты
<публичный ключ ноды> OP_CHECKSIG OP_IFDUP OP_NOTIF OP_16 OP_CSV OP_ENDIF
в) особенность этого utxo в том, что его может потратить (то есть отправить транзакцию траты) только владелец этого публичного ключа/ноды сразу же после опубликования транзакции закрытия канала в сети либо любой желающий после 16 подтверждений транзакции закрытия канала
г) за несколько лет в блокчейне накопилось дох#я таких хвостиков, а какой-то перец настроил себе робота и каждый день ~ в 9 утра по московскому времени забирал себе невостребованные хозяевами хвостики за последние сутки (разумеется, никакой гео-привязки я не имею, может он японец и для него это вечер)
д) я прошерстил блокчейн за последние несколько лет, теперь там такой халявы не осталось. А владелец этого утреннего робота-пылесоса на меня обиделся, что я покусился на его каждодневный профит и теперь отправляет все хвостики в OP_RETURN исходя из известного принципа "так не доставайся же ты никому"

Такое может быть при закрытии канала нодой Greenlight.

Greenlight не позволяет стороне канала напрямую распоряжаться выходом транзакции его закрытия. Там нужно отдельной операцией запросить у сервера Greenlight перевод выхода на подконтрольный тебе адрес. Поэтому при недостатке комиссии некому протолкнуть транзакцию. Только сервер Greenlight может это сделать. Но для этого ему придётся волюнтаристски распорядиться чужими деньгами, временно попавшими под его контроль. А тут могут возникнуть юридические проблемы.

В то же самое время есть транзакции закрытия каналов, которые из-за недостатка комиссии никак не могут попасть в блок.
И висят они в мемпуле, как будто владельцы забыли про них. Причем, суммы достаточно ощутимые
https://mempool.space/ru/tx/eb7447df1615a81ba383899e51428556a3e38b43cdd8294893ffe8c8aca1db89 3 недели назад
https://mempool.space/ru/tx/5fbb28f57807b2c3bdb1cafbb507bb0ab0b428974fcdf77b99a3ee3c490625b8 4 месяца назад
https://mempool.space/ru/tx/30d086deb442cd464643f3110b068c7e7ff183a4c7288ea83ee8e3b1d9a7848a 7 месяцев назад
(это не все, я нашел больше)

Закрытие канала
Картинка со страницы https://mempool.space/ru/tx/54ce1cb7d23ba80d058a66cdfe16cbafb9fc55af6d591e975499fb1f7174d3d2
Синим и красным я выделил публичные ключи нод и стрелочками обозначил подписи (обычный мультисиг 2-из-2)


Трата первого "хвостика"
Картинка со страницы https://mempool.space/ru/tx/589e55cb488303fcd03f5dd8ae379f19de0ba6771c347bd54b1d7e3f1ba08234#vin=1


Трата второго "хвостика"
Картинка со страницы https://mempool.space/ru/tx/182c924ab48c61eff1073b94238028d00ed9e2c577601af971606d8640670ada#vin=0

https://www.talkimg.com/

Они принадлежат именно владельцам нод -- там внутри у них (при трате) публичный ключ ноды.
(Если посоветуете мне хостинг картинок -- я вам тогда на картинках смогу показывать, imgur почему-то у меня не работает в связке с bct)
Да, этот вопрос меня самого в тупик ставит -- если одной из сторон канала надо пропихнуть транзакцию -- значит у неё есть баблосы на выходе. А значит из этих баблосов можно организовать CPFP. А если канал закрывается "в одну сторону", то другая сторона (та которая пустая в результате) в закрытии канала и не заинтересована вовсе. Гори оно всё синим пламенем.

Я еще покурю сорцы и почитаю обсуждения, потом может вернусь к теме. Моего знания английского недостаточно, чтобы в простынях текста найти здравое зерно.

Может там логика "если сторона А попытается на#бать сторону Б, то сторона Б (используя все имеющиеся у нее возможности, в том числе хвостик) сможет наказать сторону А рублем по самые гланды"

Почему? Расходы уменьшаются, место в блокчейне экономится. Если, конечно, лайтнинг-канал открывается не ради одного-двух платежей.
Мне не очень понятно, зачем эти дополнительные utxo, особенно два. Если они принадлежат пользователям канала, то почему бы пользователю в случае зависона просто не сделать cpfp своего основного выхода? А если принадлежат посреднику, то хватило бы и одного дополнительного. Может, там какая-то другая задумка?

Не, ну разработчики лайтнинга -- странные люди.
Вроде бы лайтнинг был создан для того, чтобы уменьшить расходы и освободить другим место для транзакций в блокчейне.
На деле же херня творится. Могу вам рассказать с примерами и пояснениями.

Итак.
Возьмем транзакцию https://mempool.space/ru/tx/54ce1cb7d23ba80d058a66cdfe16cbafb9fc55af6d591e975499fb1f7174d3d2
Это закрытие канала между (ну, короче сами посмотрите, там все написано)
После закрытия канала часть бабла ушла одному концу канала, часть другому. Тут всё понятно
И ещё эта транзакция закрытия канала создала два выхода по 330 сатоши. Для чего, спросите вы?
А для того, чтобы, если эта транзакция закрытия каналов зависла бы из-за недостатка комиссии в момент загруженности сети, то каждый из "концов" этого канала смог бы, используя эти "довески" её попытаться пропихнуть.
Но! Что мы видим? Всё и так прошло штатно (на момент написания мною этого текста транзакция имеет 3 подтверждения, а в блок она попала всего-навсего ожидая 13 минут -- это нормально)
Довески не понадобились, а использовать их сперва могут только "стороны этого канала".
И что? Кто-то будет париться из-за одинокого utxo в 330 сатоши? Человек точно не будет. Однако, и та, и другая сторона решили утилизировать эти "хвостики", соответственно в транзакциях
https://mempool.space/ru/tx/589e55cb488303fcd03f5dd8ae379f19de0ba6771c347bd54b1d7e3f1ba08234
https://mempool.space/ru/tx/182c924ab48c61eff1073b94238028d00ed9e2c577601af971606d8640670ada
Повторюсь, эти две транзакции появились в сети после того, как транзакция закрытия канала была помещена в блок.

А смысл? Первый заплатил 1785 сатоши за 330 сатоши, второй ещё круче -- заплатил 4529 сатоши за 330 сатоши
Плюс две лишние транзакции в блокчейне.

Я не верю, что это делалось руками, скорее всего лайтнинг-клиент сам решает "а давай-ка я сделаю CPFP для транзакции, несмотря на то, что она уже подтверждена в блоке, мне похуй на хозяйские деньги"

Update: единственное разумное объяснение, это то что канал был в некотором роде "тестовый" (он действительно просуществовал недолго) и стороны не парились особо над расходами и комиссиями. Но об этом должны париться разработчики клиента!

Класс . Да, уже пошло дальше на несколько поколений ).
Не, ну то, что он там что-то для себя важное в op_return пихает - это понятно и банально. Но зачем сотни раз отправлять  в космос в общем-то немалую сумму (причем все время одинаковую), да еще по два раза на транзакцию - это никак объяснить не могу.

Впрочем, замусоривание замусориванию -- рознь.
Или как говорит одна моя подружка: "У богатых свои причуды"
Вот возьмем транзакцию https://mempool.space/ru/tx/367cd6257323990320b66507da0719f956d8aa0d388caeeed2ef370ab44f6266
На момент, когда я это пишу, она ещё не подтверждена, так что можете посмотреть только "историю назад"
Возможно, когда вы будете читать это -- то у неё будет еще "история вперёд".
Можно просто смотреть историю адреса https://mempool.space/ru/address/bc1qgdq67upw5909ctmm3t54zpk4xcz8ncm5ggafcr

А в чем атака-то? Засрать пропускную мощность сети, заставив обрабатываться транзакции, которые вряд ли будут намайнены? Ну так для этого не надо много ума. А трафик у нод как правило безлимитный. Получить какой-то профит? Тоже не пахнет. Транзакции без подтверждений только ССЗБ принимают.
Пост-фактум по истории транзакций в блокчейне понять "а не было ли тут подобного действия?" практически невозможно.
А делать реал-тайм следилку? Ну, если объясните мне, как из этого можно извлечь выгоду -- я могу подумать.

Я вот что сегодня придумал к будущим экспериментам. Допустим, для вас стоит проблема консолидации выходов. (Для меня лично не стоит, мне наоборот моих 11 мало, хорошо бы штук 50 иметь, но и большему числу порадуюсь, подайте бывшему депутату государственной думы). Так вот. Тратиться на комиссию при консолидации не хочется, если есть возможность подождать и хочется сэкономить. Допускаю, что в сегодняшний век автоматизации существуют роботы на крупных биржах или ещё в каких-то сервисах, которые автоматом консолидируют свои выходы. Что если коряво написанный такой бот возьмется консолидировать и "как-бы случайно" сделает моей транзакции CPFP? Я готов отправить 546 сатоши. Ну а не выйдет, так и бог с ним, я ничего не потеряю. Найти такого бота (если, конечно, такие есть) мне вполне по силам, понаблюдав за транзакциями (разумеется, не глазами, а программой) в течение недельки-двух

Если хотите -- вот вам логическая задачка:
Как даблспенднуть транзакцию, не поднимая значение комиссии вообще в принципе!
Думаете это невозможно? Ловите, и не говорите, что не видели:
https://mempool.space/ru/tx/03d34248926b742e43c18fbe90bc9922fc2f0933fc4fe9ea256c5d13b9594093

А не тестирует ли тут кто-то  free-relay атаки  ( а может быть и реально их и проводит), возможность которых была недавнно раскрыта для сообщества разработчиков Питером Тоддом за счёт различия в RBF полиси майнеров ( большинство которых активировали full-RBF ) и нодами обычных пользователей Bitcoin Core (которых интересует только его часть, связанная с кошелькои и вовсе не интересует нода, которая действует исключительно  как релейная нода  и у которой эта опция не активирована)?

Это более логично, чем все пляски с бубном. Нода имеет право сказать "а я не видела первую транзакцию, поэтому вполне себе акцептила вторую и меня ниипёт, что у вы считаете это наглым даблспендом"

Да, это так выглядит со   стороны нод, которые приняли  Full-RBF полиси, т.е. для таких нод любая транзакция ( в не зависимости от того, просигнализировала ли она или не  не просигнализировала о своей готовности быть замененной на другую согласно BIP 125) имеет право быть замещена  с более высокой оплатой.

Достаточно любопытно.
В глобальном мемпуле (я все-таки настроил себе скачивание всего и вся с mempool.space) достаточно много "неприоритетных цепочек"
Что такое "неприоритетная цепочка"? Это я только что сам такой термин придумал.
Вот транзакция:
https://mempool.space/ru/tx/a6443bd2580018d7e5293bbb3e7551cb6577cad6e98765406fb6bd5c7389b616
она же есть тут:
https://www.blockchain.com/explorer/transactions/btc/a6443bd2580018d7e5293bbb3e7551cb6577cad6e98765406fb6bd5c7389b616
Замечена две недели назад (хотя если она ребродкастилась -- то может быть она и полгода назад создана, а сайты имеют срок протухания две недели)

Это пример, там такого говнища полно. Посылаем транзакцию с комиссией 1 сатоши за вбайт. Сдачу отправляем второй транзакцией с комиссией 1 сатоши за вбайт. И так пока клиент не взвоет от длины цепочки. Пусть вас не смущает, что в транзакциях присутствуют какие-то данные в OP_RETURN -- скорее всего это просто мусор, потому что трудно представить, что одно и то же значение (а оно одно и то же во всей цепочке) несёт смысл.

Даблспенднуть такую "цепочку" довольно легко (для её создателя, разумеется) - даблспендим её "голову", хвост сам отвалится.
Вот только зачем это было сделано? Две недели назад нормальный человек не стал бы отправлять с минимальной комиссией. Не стал бы и полгода назад. Зачем нам этот "навес", или можно сказать "андеррайдинг"?

Update:
Видимо, никто не чистит мемпул раз в две недели, как мне показалось
https://mempool.space/ru/tx/a4e1db454435e4e662aac6792184323e99ca902ccd1daf78d15832bb3ccc5318
Честно говорит -- семь месяцев назад
Эта же транзакция на другом сайте
https://www.blockchain.com/ru/explorer/transactions/btc/a4e1db454435e4e662aac6792184323e99ca902ccd1daf78d15832bb3ccc5318

В таком случае у давно запущенных нод мемпул должен на 99% совпадать
Но https://jochen-hoenicke.de/queue/#BTC,24h,count показывает 200к транзакций в мемпуле
А https://mempool.space/ru/docs/api/rest#get-mempool 220к (разница небольшая, но есть)
У меня локальный клиент, который я перезапускал вчера (и, кажется, при этом грохнул мемпул) сейчас показывает 71к транзакций
Ну что же... Придется терпеть пока не сравняюсь. Но я за NAT-ом сижу, я же обычный юзер, а не сервер с открытым портом. Долго буду ждать...

Раньше как раз три дня и было, блок-эксплорер blockchain.com, возможно, и до сих пор на три дня настроен (год-два назад такое замечал). А сейчас (последних лет 7-8, наверное) этот срок по умолчанию составляет две недели. Сейчас уже не редкость - транзакция хоть и вылетает через две недели из большинства мемпулов, но вскоре кем-нибудь ребродкастится, и так по кругу, в этой фиче уже по сути и смысла нет.

Здесь еще вот что может быть: раньше, по-моему, у транзакций в мемпуле был срок годности. (Сейчас не знаю, есть ли. Может тоже есть. Но, допустим, другой.)
То есть проходит месяц-два-три... да фиг с ним, три дня транзакция не подтвердилась - нода её выкидывает из мемпула как мусор. (В те времена еще без комиссий вообще можно было посылать при определенных условиях). И готова получить RBF. Возможно, были ноды которые изредка перепосылали свой мемпул соседям, но это была редкость скорее (если была). То есть через какое-то время про транзакцию помнил только кошелек-отправитель и там еще осталась в клиенте опция -walletbroadcast при запуске.

Сегодня просто так чистить свой мемпул пулам (каламбур, однако) не выгодно. Ну то есть разница копеечная, но кому это надо? Я тут решил покопаться в старых транзакциях, которые месяцами лежат в мемпуле неподтвержденными. У сайта mempool.space даже есть апи для скачивания мемпула по одной транзакции. Блин, сделали бы они запрос "дай мемпул целиком или хотя бы жирный его кусок", потому что 200 тысяч запросов к rest-api напрягут любой анти-ддос фильтр. Меня сегодня mempool.space уже два раза зобанил на час. А у всех обычных нод команда протокола "mempool" задизейблена по дефолту.

Как я понимаю, full-rbf позволяет заменять транзакцию независимо от установки rbf-флага, то есть отменяет "финализирование" транзакции. А тот opt-in rbf, с которым мы жили много лет, тоже позволял заменить всё, вплоть до набора utxo. Я даже когда-то здесь тему делал, как заменить транзакцию в Электруме (позже она стала неактуальной).