Открыть список
Как стать автором
Обновить

Комментарии 15

Я правильно понимаю, что речь про азартные игры на деньги (gambling)?

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

У вас какая-то странная RSA-подпись. В нормальной каждый раз должен получаться разный результат для одного и того же подписываемого блока данных.

Вы ошибаетесь.


Сама подпись RSA всегда была и остаётся детерминированной, разница только в схеме padding-а, которая может быть рандомизирована или нет.


Если само сообщение содержит рандомизированную часть, то padding может быть без ущерба для схемы детерминирован.

Так тут и нет никакой рандомизированной части, как я понимаю. Любой злоумышленник, имеющий доступ к "подписывалке", может заранее узнать подпись, а следовательно и то "случайное" число, которое получится в GenerateRandInt. Если бы в реализации подписи фигурировал случайный паддинг, это было бы невозможно.

В нашем случае сервер не может солгать из-за проверки смарт-контрактом. Да, приватный ключ лучше не шарить, но интереса в этом нет, ибо играть против себя тут бессмысленно. Соответственно, сервер может или подписать честно, или не подписать вовсе, но тогда игрок выигрывает по таймауту гарантированно.
Любой злоумышленник, имеющий доступ к "подписывалке", может заранее узнать подпись

Гениально.

Мы придумали обходной путь: использовать схему «коммит-раскрытие».
Кто мы? И честно — это вы придумали?
Оказалось, это неудобно, долго и дорого. На тот момент другого безопасного решения не было.
А разве привидённая схема удобней, короче или дешевле? Количество необходимых транзакций так же 2 — по одной от игрока и казино. Стоимость думаю приблизительно одинакова. Удобство — такое же. Сделал ставку, подождал пока она разрешится.

И на счёт RSA. По-моему можно генерировать разные валидные подписи к тем же данным. Что ведёт к тому, что вы можете легко обыгрывать игрока.

Да, действительно, многое зависит от предварительного кодирования сообщения (в основном есть ли там фиксированный паддинг или нет), но попросили именно детерминированную схему проверки, поэтому получили на уровне блокчейна набор s"${digestPrefix}withRSA", который гарантирует проверку на EMSA-PKCS1-v1_5.

Тоже не понял чем приведенная схема качественно отличается от стандартной commit-reveal, вы должны были уменьшить число транзакций хотя бы, а получили новые проблемы: если ваш привтаник один раз утечет выиграть у вас можно будет в любой момент в будущем. С тем же успехом можно было commits собрать в дерево меркла и reveal делать с меркл-пруфом. В известном всем проекте DICE2WIN помимо commit-reveal еще есть защита от реорга блокчейна.

В предложенной схеме я вижу достаточность 2 транзакций на игру (одна от пользователя и одна от условного казино).


Можете рассказать как в 2 транзакции сделать commit-reveal про который вы говорите?

До этого:


  1. Commit сервером
  2. Ставка юзером
  3. Раскрытие сервером

У вас:


  1. Ставка юзером
  2. Раскрытие сервером

Так?

Не так.


  1. Ставка юзером с комитом.
  2. Раскрытие сервером.

Если придираться, то ваш вариант лучше, да.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
2016
Местоположение
Россия
Сайт
wavesplatform.com
Численность
101–200 человек
Дата регистрации

Блог на Хабре