rprtr258's bog

Про верификацию ауков.

При крутке аука есть два больших вопроса:
- не нажал ли стример на педальку (педалька)
- не заабузил ли какой-то из зрителей аук (абуз)

Это упирается в верификацию покрута: как проверить, что покрут действительно был случайным и не заафекченым? Тут мои соображения по этому поводу, ни с какими ауками не сотрудничаю, просто мысли.

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

Далее, рассмотрим два сценария:
1. верификация покрута удачи на один лот (+удача)
2. верификация покрута всего колеса

Начнем с верификации удачи. Несколько утверждений верны:
- сиды на разные покруты удачи должны быть независимыми. Т.к. иначе (абуз) следующие покруты удачи можно подгадать, зная предыдущие сиды.
- сид покрута должен отображаться перед самим покрутом. Т.к. иначе нет возможности проверить, что не имела места (педалька), после которой показывается удобный сид.
- в то же время, сид должен показываться после получения доната. Т.к. иначе возможен (абуз)
- сид не должен определяться временем (абуз), текстом доната (абуз), предыдущими донатами/покрутами (абуз)

В итоге, схема, к которой я пришел, примерно такая:
1. Всё происходит на стороне бэкенда, открытый сервер или с открытым исходным кодом или хз. Как верифицировать его валидность за рамками обсуждения.
2. При получении доната, сервер делает следующее:
1. идет на random.org за криптографически случайным сидом. В принципе можно и понабрать раньше и брать из устройства, главное, чтобы соблюдались шаги дальше.
2. Сид показывается на экране аука. Т.к. донат уже пришел, ничто не влияет на результат, в т.ч. (педалька), т.к. донат еще не отображается.
3. Отображаем донат, покрут, результат. Покрут после шагов выше уже определен сидом, не подверженым (педальке) и не может быть (заабужен), т.к. сид криптографически случаен.

Перейдем к сценарию верификации покрута всего колеса. Тут показывать сид заранее нельзя, т.к. возможен (абуз). Но и нельзя показывать после покрута, т.к. возможна (педалька). Нам нужен способ показать сид ПОСЛЕ колеса, чтобы продиводействовать (абузу), но дать возможность верифицировать, что сид был выбран ДО покрута колеса, в начале аука, чтобы запретить (педальку). Этот способ также не должен дать возможность определить сид заранее. Из таких способов я придумал следующий:
- выбираем сид на сервере случайно, по суди как угодно, но в идеале криптографически случайно
- показываем перед началом чего-либо ХЕШ(сида)
- после покрута показываем сид

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

Оба случая упираются в вычислительные мощности и настраиваются сложностью и размером хеш функции, поэтому их можно выбрать такими, что "разворот"(из хеша получить возможные сиды) будет долог и/или нецелесообразен.

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

чедум?

Рассмотрим свиной аук (с вычитаниями). При включенной удаче, добавляется только множитель ROI, в остальном ничего не меняется.
Пусть:
A — сумма моего варианта
B — сумма некого другого варианта, предположительно самый топовый варик, не считая наш
C — сумма всех остальных вариантов
d — донат, который мы можем кинуть сейчас
шанс варианта X = X / (A + B + C)
Вопрос: когда выгоднее задонатить на свой вариант, а когда выгоднее вычесть из другого варианта?
В случае d > B, вычитание обнуляет этот вариант, поэтому будем рассматривать только случай 0 < d A + d
Вычитать из B выгоднее, если:
B + C < A + d

Примеры:
A=10, B=20, C=70, d=15 → добавить к A: 22% > 12%
A=80, B=20, C=10, d=15 → вычесть из B: 76% < 84%
PS. редактор тг это пиздец
PSS. подарите прем, я не могу писать формулы

Как же меня трясет что в треке DEAD BLONDE - Бесприданица строчки
Новенькой подводкой я накрашу себе стрелочки
Самая красивая приду на перестрелочку
а не
Новенькой подводкой я накрашу себе стрелочки
Самая красивая из всех возможных девочек
С отсылкой на трек CRASPORE & Chernoburkv – Аквариум
В её коже бижутерия и ресницы бабочки
Самая красивая из всех возможных самочек

PS. Посмотрел размеры, у DEAD BLONDE трехстопный на первый слог, а у CHERNOBURKV какойто пиздец, четырех или хуйпойми какой стопный. Вообще, на второй строчке, слово красивая уже все ломает. По размеру, после трёх слогов Самая с ударением на первый, следующие три должны быть с ударением на первый. В слове красивая четыре слога, т.е. ударение должно быть крАсиваЯ, но в этом слове ударение блять на И, я вахуе.
PSS. А еще у CHERNOBURKV в первой строчке нет ударения на ё, я вахуи.

Почему MCP - это кал.

MCP - это средство, с помощью которого ai harness может вызывать код, передавая ему параметры и получая от него результаты. e.g. MCP curl, который принимает url и возвращает контент по этому урлу (очень упрощенно, на суть не влияет). Что же с ними не так и почему я хейчу MCP?

1. Срет в контекст описаниями. Ещё прежде чем, как вызвать хоть какой нибудь MCP, llm должна знать какие есть и как их вызывать. Для этого ей в системный промпт добавляют все тулзы, их описания и входные схемы. Для примера, chrome-devtools MCP забирает 5k токенов только на свои описания. Возьмите несколько MCP, токенов будет еще больше.
Можно сказать, что под каждую задачу, можно включать отдельный набор MCP, но это никто не будет делать, llm должна сама разбираться, что ей нужно. Вместо того, чтобы дать возможность gradual discovery - хочешь найти тулзу, сначала найди, какие тебе могут помочь, мы вываливаем всегда весь список. И для основного агента и для сабагентов. Да и в разных агентах настройка доступных тулзов выглядит по разному.

2. Срет в контекст инпутами. Чтобы вызвать MCP, llm должна полность, буква за буквой корректно написать входные параметры, хоть они и представляют собой json, модели часто путаются и не попадают в схему, или в допустимые аргументы, или просто в валидный json, из-за чего им приходится писать весь инпут еще раз. Если вы хотите, чтобы llm проверила ссылки через curl MCP, она не может сделать аля bash-pipeline вида
extract links | xargs curl | jq '{url, code}'
Вместо этого, она будет вытаскивать каждую ссылку по очереди, каждую перепечатывать и передавать в MCP. Другой пример, когда llm приходится перепечатывать старый код, который и так есть в файле и в контексте, но edit MCP требует пару old_text/new_text.

3. Срет в контекст аутпутами. В примере с curl MCP выше, модель получит в контекст весь высер страницы: код, хедеры, страницу, хотя ей нужен только код ответа и ничего более. Учитывая, что аутпут MCP полностью попадет в контекст, его нет возможности ни отфильтровать, ни ограничить, его приходится ограничивать на уровне тулзы: не более 5 результатов, пагинация с макс. размером страницы 10 и т.д. Это мало того, что дает неиспользуемый контекст, так еще и заставляет вызывать MCP несколько раз для каждой страницы. А вывод MCP нельзя направить в файл, чтобы пост процессить всякими тулзами типо sed/awk/tail/etc, только полностью читать от и до и платить за это токенами.

4. Следствие из 2 и 3 - MCP не композируемы. Они берут текст на входе, отдают текст на выходе. НО! Этот текст обязан быть порожден llm и скормлен будет также llm. Знаете UNIX тулзы, которые могут брать текст из файла, из других процессов, сохранять в файлы, передавать в другие процессы? Ничего такого для MCP не предполагается. Из-за чего в качестве "решений" предлагаются context-mode/codemode/etc. По сути пересоздавая экосистему для работы с командами/тулзами, только напарываясь на грабли, которые давным давно уже были решены.

5. Вспоминая про UNIX, программы должны работать над одним универсальным протоколом, чтобы взаимодействовать друг с другом. Этот протокол - текст. Отдельный вопрос, насколько этот формат хорош, но для llm вполне годится. Использовать же MCP с классическими тулзами нельзя. Как и классические тулзы с MCP. Никакой мотивации для этого нет, Bash тула достаточно, чтобы вызывать любую CLI и пайпить их как угодно куда угодно.

Вывода не будет, думайте, подписаться.

Я один вахуе, что steampowered.com и steamcommunity.com это два отдельных домена, с отдельной авторизацией?