#HACK Помолчал и хватит.

В сентябре стремился повторить salmonela.

Идея в том, что нужно отправить такую "уязвимую транзакцию", что на нее поведется frontrun/backrun бот и не сможет продать токены обратно.
Идеальный пример выглядит так:
- Взять за основу код классического контракта от OpenZeppelin
- Добавить ряд переключателей, чтобы или брать комиссию или отключать свапы
- Создать uniswap v2 пару c некоторой ликвидностью
- Отправить транзакцию обмена со slippage >X$ потерь
- Frontrun бот разместит свои транзакции так, что заработает себе X$ из нашего slippage
- Но несколько позиций в блоке Frontrun бот держит наши токены
- Отключаем возможность продажи через бандл или любым другим способом
- Как итог, Frontrun бот купил наших токенов, но продать не сможет.
- Профит!

Но на практике все очень сложно:
- Если подменять собственную транзакцию свапа со слиппеджем на транзакцию отключения свапов, то боты это видят и даже подменяют свои FR транзы на self-send. Но чаще видят и совсем не реагируют
- Если отправить свап как обычно, а отключение свапов через бандл, то снова никто не ловится, боты это видят.

После тестов в eth/bsc/arbitrum/polygon/avax/base могу с уверенность сказать, что:
- Frontrun и Backrun боты работают исключительно через бандлы, а бандлы есть в eth/bsc
- В любых других блокчейнах без бандлов, есть только снайпер-боты что покупают на копейки свеже-созданный токен
- Благодаря бандлам, боты полностью защищены от подмен и ловушек, риск только в совбстенных ошибках в боте.
- Есть такой тип ботов, что стремится выкупить сапплай токена при резком дампе цены до микро-центов, чтобы мгновенно зарабатывать с любого притока $ в торговую пару.

Касательно бандл-провайдеров, в eth их много, все они форкнулись от flashbots.
В bsc два покемона, первый bnb48.

В этом блоге очень подробно описана работа EVM от noxx

Отдельная проблема была запомнить все эти evm коды, на этом сайте они есть evm.codes. Не нужно читать код geth 😄

Уже есть multicall3. Свои версии были у makerdao(v2) и 1inch(v1).

Когда нужно сделать много операций чтения из блокчейна, например прочитать баланс 100_000 адресов определенного токена. Пути решения такие:
1. Один rpc запрос = одно чтение баланса, супер медленно, даже с потоками
2. Один rpc запрос, но внутри много параллельных eth_call = уже лучше, но будет много контекстов, излишняя нагрузка на открытие/закрытие контекста чтения блокчейна для ноды.
3. Делим задачу на кусочки по 100 адресов, отправляем через multicall3, один запрос один контекст, по накладным ресурсам самое эффективное.

Из плюсов то, что есть в 70+ блокчейнах, не нужно размещать свой код

Существует такой сайт, как haveibeenpwned.com, с его помощью можно проверить, в каких утечках баз данных есть конкретный почтовый адрес, но он для web2 (почты-пароли).

Какая польза от web2 версии?
1. Пользователи часто используют одинаковые пароли на разных сайтах. Риск брутфорса.
2. Для серого маркетинга, если почта "утекла", то мог и телефон, а там подключатся из службы безопасности скам-банка.
3. Через несколько лет haveibeenpwned интегрировали в firefox monitor (ссылка на анонс)

Для web3 такого нет, но у нас есть все, чтобы попытаться сделать.

Идея в том, чтобы собрать скомпроментированные кошельки из eth/bsc и других блокчейнов чтобы сделать интерфейс проверки адреса на наличие в базе.

Почему нужна web3 версия?
1. Если просыпается кошелек и начинает активничать в разных сетях, он может не догадываться, что в bsc уже стоит бот автовывода
2. Централизованные биржи могут снизить риск вывода токенов на скомпроментированный адрес юзерами
3. Web3-кошельки могут показывать при импорте кошелька, что он скомпроментирован, снизить риск потери токенов в попытке вывести их из кошелька.

Почему у нас есть ресурсы это сделать?
1. Понятно как реализовать технически и тянуть хоть 1млрд уникальных строк без 4х значных счетов за аренду.
2. Подписчики из разных сфер деятельности, расчитываю на помощь в сборе, не могу все видеть.
3. Если с web2 верией уже все понятно, это распустившийся цветок, то с web3 еще нет, есть потенциал найти новые полезные направления, где промежуточный этап как раз такой сервис.
4. Почему бы и нет)

Жду вашей реакции, скоро опишу процедуру как скидывать файлы, чтобы все по красоте было)

Октябрь, пятница, тринадцатое.

Подобная идея сервиса созревает больше пяти месяцев, самое сложное было разобраться внутри себя, а хватит ли сил не смышиться.

Репутация важнее и я верю, что намного приятнее и стабильнее будет делать бизнес, чем разовая нажива на двуличности.

В крайнем случае лучше удалю эти файлы, чем предам себя)

Если готовы поделиться списком скомпроментированных кошельков, вот общая информация:

Поддерживаемые форматы строк:
- address, возьму случайные адреса и попрошу скинуть к ним данные для создания идентичного адреса, это поможет снизить шанс добавления ложно-скомпроментированных адресов, наименее предпочтительный вариант.
- seed - генериую адреса на 0м пути, как metamask или ethers делают.
- privateKey - генерирую адреса
- любое сочетание address/privateKey/seed с понятным разделителем
- количество строк и файлов любое

Опциональные меры сохранения анонимности:
- Загружать zip-архив на облачное хранилище с ограниченным временем действия ссылки на скачивание
- Ссылку на скачивание прятать за privnote
- Использовать telegram secret chat (обычно доступен из мобильного приложения), писать @zerofuz.

Скам-детектор: добавить один адрес с 1-10$ и если он проявит активность после добавления в базу, значит админ заскамился :D

По наводке из комментариев к прошлому посту, открылся непокрытый сегмент в виде тестовых кошельков для разработки solidity контрактов.

Известно о таких:
hardhat - js/ts/sol
truffle - js/ts/sol
anvil - rust/sol
embark - js/ts/sol, тот случай, когда гуглится сначала ветклиника, а потом фреймворк 😄

Какие еще сайты проверить на наличие кошельков?

Барабанная дробь

Опубликован интерфейс для взаимодействия с базой скомпроментированных адресов haveibeenrected.

Критика и пожелания приветствуются

Приятно знать, что у кого-то получилось сделать рабочую версию ретродроп фармилки с микросервисами. Great minds think alike…

А вот что мы делаем с ретродропами:
- у нас написан свой софт для того, чтобы делать транзакции и анализировать статистику
- ничего стороннего не используем и не продаём софт/доступ

Архитектура у нас такая:
- база данных и бэкенд: храним все кошельки, зашифрованные приватники, балансы (регулярно индексируем)
- апи бэкенда и фронтенд: можно добавлять, генерировать кошельки, разделять их на группы и пользователей, создавать задачи, смотреть и создавать "события", базовую статистику
- скрипты-задачи. Сами транзакции у нас делает не бэкенд, а отдельные скрипты, написанные по шаблону и отдельно запущенные на сервере. Они получают всё нужное по защищенному апи от бэка и точно так же по апи могут создавать события, чтобы бэк, другие скрипты и сам скрипт-задача при перезапуске были в курсе о состоянии того или иного кошелька, таска и так далее
- wizard. Это штука для ручного проведения различных действий типа докинуть с биржи на конкретный акк или сделать csv с балансами определенной сети и токенов

Всё это пишем уже более полугода, и сначала казалось, что такая архитектура это слишком, ведь проще всего просто один скрипт написать, и в нём всё гонять. Но сейчас она уже оправдывает себя. Рассказать подробнее?

Как устроена работа изнутри у haveibeenrected:
1. База хранится в leveldb (key-value хранилище в файлах), чтобы минимум зависимостей, влезут миллиарды строк, ТБ данных, но есть один недостаток: только одно соединение за раз
2. Вебсервер это expressjs, который отдает html и обрабатывает api запросы от пользователей к leveldb. Ограничение в 250 запросов в секунду
3. Домен - cloudflare - nginx - сервер, ssl с обеих сторон к cloudflare.
4. Обработка файлов происходит через bash-команды, такие как cat|cut|split|uniq|comm
5. Отдельный скрипт для расширения leveldb базы.

Если нагрузка повысится, нужно перенести код вебсервера на golang, чтобы одним процессом занимать всю доступную процессорную мощность, а не как в nodejs: 1 процесс = 1 ядро.

Отдельная история с фронтендом: имея референсы https://www.ipify.org/ и https://www.useweb3.xyz/ просил chatgpt создать html+js код, потому что лень писать самому) В том числе кнопки копирования curl в буфер обмена.

Предоставление ликвидности в uniswap v2 сравнительно простое занятие, есть ликвидность пары, токены в пропорции 50-50, комиссии фармятся сразу всеми провайдерами ликвидности в паре.

В uniswap v3 это сложнее, пример для eth/usdt:
1. eth=2000$, предоставляем ликвидность в диапазоне 1900$-2100$, добавляем eth и usdt не в пропорции 50-50, а плавающая, например 41-59
2. eth=2090$, позиция в диапазоне, но 90%+ позиции уже в usdt
3. eth=2150$, позиция вне диапазона, 100% позиции в usdt, комиссии не фармятся
4. eth=2050$, позиция снова в диапазоне, комиссии фармятся, доля eth в позиции повысилась.
На третьем шаге вероятно понадобится переоткрыть позицию (вывести usdt, выбрать новый диапазон, свапнуть в eth в нужной пропорции, добавить ликвидность в пул), это расходы на транзакции с пулом и свапами.

Чем уже ценовой диапазон позиции, тем выше APR.
Задача успешного предоставления ликвидности в том, чтобы:
- Уже диапазон, выше APR, основная фишка v3
- APR позволяет покрывать инфляцию и наращивать капитал.
- APR покрывает расходы на свап, обновление диапазона и claim позиции
- Награда(комиссии) от предоставления ликвидности не капитализируются, а лежат отдельно, регулярно добавлять их к позиции вручную через claim
- Размер позиции позволяет получать достаточно комиссий на расходы и прирост капитала

Трекать позиции, помимо app.uniswap.org:
288611$ debank
287673$ revert.finance
Калькуляция различается, хочется верить, что там, где выше число, там правильнее 😄

Посмотреть на APR пулов:
https://revert.finance/
https://unispark.metacrypt.org/

Агенты и агентессы, обновите свои веса нейросетей ⚖️

Не все solidity контракты строго соблюдают erc20 стандарт.
Есть исключение, которое не видно на уровне взаимодействия с abi.
Это исключение становится видно тогда, когда смарт-контракт размещен в блокчейне, а вывести токены нельзя.
Имя этому токену usdt. Прелесть в том, что erc20.transfer должен вернуть bool, но usdt думает иначе, поэтому типичный erc20.transfer будет тихо фейлиться без объяснения причин. В tenderly выглядит как REVERT .0x()

usdt 0xa9059cbb
function transfer(address _to, uint _value) public whenNotPaused {

usdc 0xa9059cbb
function transfer(address to, uint256 value) external returns (bool) {

Чтобы такое не повторялось, используется safetransfer библиотека для solidity, чтобы такие случаи не хоронили нестандартные токены на контракте.

Реализации safetransfer:
- openzeppelin SafeERC20
- Uniswap V3 TransferHelper (docs)
- Uniswap V3 (solidity)

Зачем изучать ai/ml/llm/web3, когда есть btc циклы?

Обновление по графику от 13 июня 2022

ATH может оказаться 258000$ в этом цикле. Примерно в 2025-2026 году (симметричная ширина синих прямоугольников)

Все волшебство графика в:
- логарифмическая шкала
- fib retracement с дефолтными уровнями
- первый цикл проводим от лоя, до хая
- следующий цикл от уровня 0.786 будет началом следующего цикла, у которого на этой высоте уровень 1

Серые прямоугольники связаны между собой

Увидимся в 2026 :D

Про TornadoCash.

Хорошо написано обновление ситуации тут

Комментарий:

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

Не уверен на счет хороших сравнений, но вижу такие:
- В фиате больше грязных денег, чем в крипте и это не проблема, фиат не банят.
- Разве создатели языка программирования виноваты, что на их языке пишут вирусы?
- Криптографические алгоритмы придумали для защиты нац безопасности и уже потом https/rsa/ssh. Но есть винлокеры, забанить ученых-создателей криптоалгоритмов?

В комментах можно посоревноваться в остроумных сравнениях, где еще такая интерпретация суда неприменилась.

Случилась транзакция от jared, где он перевел майнеру 49eth в качестве комиссий за транзакцию. Разобрал что случилось подробнее https://telegra.ph/O-tom-kto-poznal-dzen-i-uniswap-v3-06-28