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

Никогда бы не подумал, что кто-то мог так подумать.  



Да у меня тоже рабочий диск внешний, путь к которому прописан в bitcoin.conf но большинство пользователей полагаются на дефолтные пути.



Спецификации: JSON-RPC 2.0 и JSON-RPC 1.0


Как можно понять во 2-й версии для спецификации протокола добавлено поле jsonrpc ^{(думают о будущем, наверное)} а также структурирован  механизм обработки ошибок


что очевидно  является плюсом.

Ну и ещё кое-что.

Немного неточная формулировка. Можно подумать, что "Мы выпустили клиент с временным ограничением, а потом его снимем".
(По крайней мере я, прочитав, понял так)
Если включить режим занудства, то это надо понимать так: "Увы, все предыдущие версии клиента не будут релеить подобные транзакции. Поэтому пока в сети не будет достаточного количества проапгрейженых до последней версии узлов, шансы на то что транзакция с такими выходами и входами дойдет до майнера и будет подтверждена в блоке малы"
Я может покажусь старым занудой, но ни разу ни в одной программе не полагался на вот эти самые каталоги по умолчанию.
Меня очень напрягает, когда программа пытается своим домашним каталогом назначить какую-то глубоко закопанную на диске C: папку, к которой еще доступ по симлинкам. У меня рабочий диск вовсе не C: и первым делом что я делаю -- настраиваю пути. В частности биткойн запускается только с параметром -datadir= и никак иначе.

А по новой версии меня заинтересовало две вещи:
а) какие изменения в поведении клиента будут у транзакций версии 3?
б) что такое JSON-RPC 2.0 и опять же в чем преимущества/недостатки/отличия?

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


Кроме этого новый релиз принёс  достаточно много изменений, на которые стоит обратить своё внимание. В частности те пользователи, которые используют Windows должны узнать, что с ним data директория изменена с C:\Users\Username\AppData\Roaming\Bitcoin  ^{(было в версиях <  28.0 )} на C:\Users\Username\AppData\Local\Bitcoin . Но при апгрейде, если существует старая директория ^{(C:\Users\Username\AppData\Roaming\Bitcoin )}, Коре продолжит использовать эту старую для того, чтобы обеспечить совместимость

А три последних года было что-то иначе? 
Любых желающих заниматься выходами по 330 сатоши на всей Земле дай бог пять человек за три года набралось.
Я хз.
Там какая-то непонятная мне тема. Вернее, понятная только в самых общих чертах.
При функционировании лайтнинг-канала мы в каждый момент времени с момента создания канала должны помнить, что
а) наш контрагент спит и видит как нас наебать
б) наш контрагент имеет право захотеть закрыть канал в любую секунду
в) наш контрагент имеет право не согласиться на предложение о закрытии канала с каким-то обоюдным распределением комиссии за транзакцию
г) комиссии в сети в моменте времени могут быть достаточно высокие

Короче, весь сыр-бор не про свадьбу, а про развод и сопряженный с ним раздел имущества в канале.
Так что заранее резервируется некая сумма на непредвиденные расходы. Причем таким образом, что другого штатного варианта без резервирования вроде как и нет.

Почитал про этот P2A скрипт. Как я понял потенциально  опасная вещь, так как оставляет выходы не подписанными, отдавая их на откуп  любому желающему.  Будут в основном  использоваться в проблематичных LN  каналах ^{( хотя может быть и не так понял с первого взгляда их предназначение).} Какова ещё цель таких скриптов?

Стоит отметить, что разработчеги озаботились этой проблемой.
Причем примерно в то же самое время, что и я.
В августе. А мой пост был в июле.
Только они канителились три года, а я эту проблему нашел через месяц после того, как включил свой новый компьютер и с нуля переписал (на это как раз месяц и ушёл) анализатор интересностей в блокчейне.
Они вводят новый стандартный тип адреса в клиенте Satoshi:28
Раньше у нас были P2PK, P2PKH, P2SH и так далее. Десяток уже набралось или около того.
Теперь у нас новый тип стандартного скрипта будет: P2A (pay-to-anchor)
Причем под этот новый паттерн попадает... вы удивитесь... барабанная дробь... один адрес!
https://mempool.space/address/bc1pfeessrawgf

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

Мы, наверное, о разных реализациях говорим. Если покажете пример этого самого 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 (которых интересует только его часть, связанная с кошелькои и вовсе не интересует нода, которая действует исключительно  как релейная нода  и у которой эта опция не активирована)?

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