Pull to refresh

Comments 23

вместо S-code указываем предыдущее полученное число.
хмм… а нет ли тут скрытого предпочтения? Т.е. вероятность, что вы выиграли 1ым — «размазана равномерно», а вот 2й выигрыш и далее — чаще выпадает на начало очереди и нечетные номера?
нечетные номера в какой момент? очередь уменьшается и индексируется заново при каждой итерации. Т.е. если изначально билет 145 был в очереди четным, то после определения первого победителя, он станет нечетным (не по номеру билета, а по порядку в очереди).
А почему на начало будет большее предпочтение?

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

т.е. не предыдущее число, а sha256 от предыдущего числа?
да, если быть точным, то sha256 от предыдущего числа

Не очень понимаю смысл перевода байт в hex- или base64-представление, кодирования в ascii и последующее хеширования.


Не проще ли напрямую хешировать массив байт?

Буду благодарен, если подскажете как в PHP из daf5802953dcb27f89972e38e8900b898733f6a613e6e1c6c5491362c1832596 получить число 1 без промежуточных преобразований

Не вижу связи между daf5802953dcb27f89972e38e8900b898733f6a613e6e1c6c5491362c1832596 и числом 1.


А если вы хотели загрузить набор байт в gmp — то вам нужна функция gmp_import

В таком виде мы получаем данные от оракула и нам надо превратить их в порядковый номер очереди

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


Дальше с этой строкой можно делать всё что вам нужно по алгоритму — импортировать в gmp и делить на число участников.

Вы перечислили именно то, что делается и описано в статье.

Нет. Вы вместо бинарной строки используете её hex-представление. Которое мало того что в два раза больше — так ещё и неоднозначно.


Если кто-то решит повторить ваш алгоритм на другом языке программирования — ему придется бороться со следующими проблемами:


  1. hex-представление может использовать прописные буквы вместо строчных, что изменит его хеш;
  2. hex-представление может содержать пробелы, что изменит его хеш;
  3. hex-представление может начинаться с префикса "0x" или заканчиваться суффиксом "h", что изменит его хеш;
  4. сам факт, что нужно считать хеш не от набора байт, а от его hex-представления, неочевиден.
Я поэтому и спросил, знаете ли вы возможность более простого преобразования bin to int посредством PHP? Минуя hex.
Возможно это упростило бы код и позволило бы избежать лишних операций.
В статье приведен пример конкретной реализации на PHP, на других языках никакой борьбы не будет, получаете bin и доступными средствами преобразовываете его в int, если есть возможность, то без hex
А в данном примере hex представление является однозначным, т.к. мы получаем его самостоятельно, а не из сторонних источников и формат нам известен.
Другими словами: было удобно сделать именно так. Если можно проще — с удовольствием исправлю.
Я поэтому и спросил, знаете ли вы возможность более простого преобразования bin to int посредством PHP? Минуя hex.

Так я и ответил же: gmp_import, а дальше всё по вашему алгоритму.


В статье приведен пример конкретной реализации на PHP, на других языках никакой борьбы не будет, получаете bin и доступными средствами преобразовываете его в int, если есть возможность, то без hex

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

Я понял о чем вы!
Спасибо, подумаю над решением этого вопроса.
Хотя нет…
По большому счету суть не поменяется, результат останется прежним.

Как он останется прежним, когда sha256("1234") не равно sha256("\x12\x34")?

Пробуем валидацию на сторонних ресурсах?
На сайте gchq.github.io/CyberChef/#recipe=SHA2('256') в INPUT даем наш S-code, в приведенном примере это:
Ri89jHB4UXZDXY6gT1m4LBDXGMTaYzHozMk4nxiuqVXdC
На выходе получаем:
daf5802953dcb27f89972e38e8900b898733f6a613e6e1c6c5491362c1832596
Дополняем 0x и отправляем на сайт defuse.ca/big-number-calculator.htm в виде:
(0xdaf5802953dcb27f89972e38e8900b898733f6a613e6e1c6c5491362c1832596 % 7 ) + 1
Получаем: 4
Как и в приведенном примере.

Это вы хеш hex-представления посчитали. А теперь добавляем перед sha256 шаг fromhex (он нужен потому что сайт не позволяет удобно ввести бинарную строку) — и получаем вместо вашего daf5802953dcb27f89972e38e8900b898733f6a613e6e1c6c5491362c1832596 какой-то 98f358536272a4550fdea5dbb1020a305b8ac5e38b1ec5af920f250d8a38f064.

Подождите…
Что и из чего вы получаете с помощью fromhex?
Приведите пожалуйста последовательность действий и результаты каждого действия начиная с:
Ri89jHB4UXZDXY6gT1m4LBDXGMTaYzHozMk4nxiuqVXdC
всё равно не могу понять, зачем fromhex?
какую строку сайт не дает удобно ввести?
У нас есть Ri89jHB4UXZDXY6gT1m4LBDXGMTaYzHozMk4nxiuqVXdC — ее мы и вставляем на сайте.
Only those users with full accounts are able to leave comments. Log in, please.