Bitcoin Forum

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

конечно возможно 

а какая примерная комиссия будет за его обработку?

п.с. если кто то может за оплату написать его для меня , пишите в лч

как обычно стандартный газ как и за любую другую вещь на сети эфира.. вроде так.

не нашел такую возможность в смарт контрактах вот документация на сайте https://solidity.readthedocs.io/en/develop/units-and-global-variables.html


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

Вы нашли другой способ? )

хм поправили доку?

раньше там было написано так

block.blockhash (function(uint) returns (bytes32)): hash of the given block - only works for 256 most recent blocks

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

К сожалению так тоже не работает. Контракт пассивен он сам себя вызвать не может по таймеры вызвать тоже не может; Его можно вызвать когда кто то запускается функцию контракта.

Тут нужно использовать случайное число, вот другой вопрос где его взять?

Я так прикинул что можно взять sha256 от таких параметров как block.coinbase + block.timestamp

Годная мысль. Что касается невозможности, то можно сделать так: пока строится текущий блок, собираются заявки в какую-нибудь мапу, по которой можно пробежаться. Прежде чем добавлять в эту мапу, сверяется block.timestamp с последним достроенным блоком. Это делается каждый раз при вызове функции "сделать ставку". Если timestamp, хранимый на данный момент в контракте и timestamp последнего блока не совпадают, значит достроился новый блок и надо "отправить выйгрыши" и начать новую мапу. Пробегаемся по старой, отправляем выйгрыши, и обнуляем ее. Профит. Если функция "сделать ставку" вызывается достаточно часто, то и выйгрыши будут приходить регулярно.

Опять же, можно сделать функцию, которую может вызвать любой юзверь - "разослать выйгрыши".
Которая проверяет несовпадение таймстэмпа последнего достроенного блока, и если он отличается от хранимого, пробегается по мапе, отправляет выйгрыши и обнуляет ее. Эту функцию владелец обязуется вызывать раз в неделю.
Тут есть другая проблема, что если "ставок" будет много, то выполнение может потребовать прилично газа, так как придется бегать по "длинной мапе". Можно заставить, как это делается повсеместно, пользователя делать транзакцию на запрос "выйгрыша". Тогда владельцу контракта это ничего не будет стоить. Просто проверяется - есть ли у запросившего адреса выйгрыш. Если да - отправить его и обнулить.

Если смысл в мгновенной лотерее, то можно сделать лотерею не мгновенной и прекращать прием ставок за пару блоков или даже за один блок до розыгрыша. Время генерации блока 17 сек. Т.е. розыгрыш каждые 17 или 34 секунды. Предугадать или рассчитать первый(любой) символ хэша невозможно(но это не точно:). Можно вручную запускать контракт, который подождет выпуск нового блока, посмотрит там первый символ и наградит/не наградит