|
Доллар централизованый.
Беспокоит ли вас его единая точка отказа?
|
|
|
|
I like poker too  So u made good start! May be u have some statistic? % of bounty that hit hardcap % of bounty that go scum Those numbers may be improve formulas. PS intresnoe, sardnym - not wery english words too. "And now the most intresnoe begins." "From here, you can manipulate sardnym earnings.." |
|
|
|
|
I whsh join to signature program.
I put code to my profile, but what next?
Somebody just please explain, how it work, newer used bounty before.
|
|
|
|
|
Я в курсе что можно зарабатывать сигнатуре форума, мне просто было влом этим заниматься тут, не вникал в нюансы.
А щас уже и рейтинг есть у акка, это выглядит более интересным.
|
|
|
|
|
xDispeLme - держите от меня 1 мерит!
Пару нубских вопросов, в баунти не участвовал никогда.
У меня есть вот этот акк фулмембера на форуме, могу я что то заработать с него участвуя в баунти?
На FB есть акк личный с 79 друзей.
Twitter никогда не пользовался.
|
|
|
|
|
Ну так это и не проект еще, а просто идея достойная изучения
|
|
|
|
|
Смысл денег как раз в том чтобы через них удобно менять совершенно разные категории товаров и услуг.
Если бы какая то страна (корпорация) выпустила деньги обеспечиваемые например 95м бензином.
1 монета = 1 литр бенза.
И всегда отгружала за свои фантики бенз 1:1 вот это были бы стабильные деньги.
Стабильные в бензине ессно.
А потом, если бы мировая экономика перешла на эти деньги, знаете что было бы?
Этих денег мировая экономика бы стала требовать МНОГО.
Ведь за эти деньги бы люди хотели покупать и продавать все другие товары, землю, предметы исскуства, оплачивать услуги итп.
Гораздо больше потребовалось бы денег, чем есть реального бензина у страны их выпускающей.
Больше чем за тысячи лет непрерывной планируемой добычи.
А далее 2 варианта
1. Выпускать не обеспеченные реальным бензином деньги. (Финал как с с отменой золотого стандарта по доллару)
2. Не выпускать. (Финал - дикая дефляция этих фантиков, настолько что как энергоноситель бензин станет использовать совершенно не выгодно)
|
|
|
|
Если стабильность это отсутствие валатильности, то в таком случае 10% перепады курса USD в течении 2017 года врядли свидетельствуют о стабильности.
Я считаю, что стабильность валюты возможно получить обеспечив постоянный товарно-денежный баланс.
И в крипте этотна 100% возможно сделать...
10% перепады относительно к чему? Вы сравниваете с каким то одним другим ресурсом? Относительно btc например доллар можно сказать рухнул в пропасть. А относительно рубля чуток поднялся. Средний "человеко-час" квалифицированного программиста тоже думаю чуток подорожал в долларе, а доллар поручается относительно этого показателя просел. Вообще я считаю что правильно было бы вязать валюту к энергии. Эмитент при этом должен обладать мощьностями и мочь предоставить в обмен на свои фантики мегаваты и тонны нефти. |
|
|
|
Ракет у USA тоже хватает. И беспилотников. И еще много чего  Именно аргументация силой, она первична. А все остальное это старательно созданные иллюзии. Покупательская способность доллара падает, тк его допечатывают быстрее чем ростет мировая экономика. Но падает всего на несколько процентов в год, так что доллар сейчас самая стабильная валюта их существующих. Ну и весь фиат к нему тупо привязан, этож не секрет. В разрезе крипты достаточная стабильность это когда 1 монета = 1 usd Как у USDT Но только чтоб децентрализованно, и не было овнера который может внезапно уйти в закат и обрушить монету в ноль. |
|
|
|
|
Доллар обеспечен военной мощью США.
Не зря же у них одних авианосцев больше чем у ВСЕХ других стран вместе взятых.
Мы охотно принимаем доллар тк знаем что его примут у нас.
А тех кто откажется принимать доллар уничтожит армия США, конечно под благовидным миротворческим предлогом с прикрытием сми и кибервойск.
|
|
|
|
Игрался с рандомом, написал вот такой код: pragma solidity ^0.4.13;
contract Random {
uint max_ticket_number;
uint shift_block;
uint winner_number;
function Random() public {
max_ticket_number = 100;
shift_block = 1;
}
function setMaxTicketNumber(uint new_max_ticket_number) public {
max_ticket_number = new_max_ticket_number;
}
function getWinnerNumber() public {
uint base_random = uint(block.blockhash(block.number - shift_block));
//shift_block++;
winner_number = base_random%max_ticket_number;
}
function printWinnerNumber() public constant returns (uint) {
return winner_number;
}
function getShift() public constant returns (uint) {
return shift_block;
}
function getBlockNumber() public constant returns (uint) {
return block.number;
}
function getBlockhash() public constant returns (uint) {
return uint(block.blockhash(block.number - shift_block));
}
}
Экспериментально выяснил, что когда вызываю функцию изменяющую контракт, то есть объявленную без constant то в блокчейне Remix возникает новый блок. Такие функции Remix отображает красными квадратиками. function getWinnerNumber() вычисляет победителя, но почему то не хочет Remix отобразить результат из нее. Сделал поэтому printWinnerNumber() она чисто отображает результат. Жмем последовательно, видим, что по хешу блока выдаются разные случайные значения в заданном диапазоне. Нет ли у потенциального атакующего возможности узнать хеш блока который мы используем при вычислении победителя до отправки транзакции "покупающей билет"? Этот вопрос надо осознать. Если наш контракт будет вызван после того как транзакция которая запустит механизм вычисления победителя включена в блок, то по идее мы и будем использовать хеш блока в который она включена, и соответственно в момент отправки транзакции этот блок еще не существовал. Это если блоки в эфире делаются строго последовательно, а я что то не уверен в этом.. как то же выполнение этих смарт контрактов распаралеливается, а то бы скорости не было вообще. Надо изучить тут теорию работы эфира значит глубже. |
|
|
|
Пишу читаю, и вдруг я вспомнил про code convetions. Решил что надо глянуть как принято в solidity писать, и писать так, а не как попало. Мда, там многобукв Пока запомню и внедрю самое важное: Функции надо называть разделяя слова заглавными буквами, типа function thisFunctionHasLotsOfArguments() а в переменных использовать подчеркивания long_variable И использовать пробелы а не табы (wtf?!), ну ок, стандарт есть стандарт. |
|
|
|
|
Для розыгрыша нужна функция в которую надо передать полное количество билетов участвующих в розыгрыше и на выходе получить случайный номер билета.
random(max_ticket_number);
Но в solidity нет встроенного random, получается его надо написать.
И заняться этим в первую очередь, все таки случайный выбор архиважная часть лотереи.
Итак мы хотим функцию random куда надо передать max_ticket_number и на выходе целое число получить от 1 до max_ticket_number
Я решил попробовать извлечь случайные данные из block.blockhash текущего блока.
Вот такой код я написал в Remix
Хеш беру не текщего блока а предидущего, тк текущий выдает одни нули, а предидущий дал
0x18676e992055c057538d59b378271bb4eacdb7f6abf9e815fd63255dc11166b6
Выглядит очень случайно!
pragma solidity ^0.4.13;
contract Random {
function get_block_number() public constant returns (uint) {
return block.number;
}
function get_blockhash() public constant returns (bytes32) {
return block.blockhash(block.number);
}
}
Осталось перевести byte32 в uint и произвести деление с остатком.
Ну и протестить на случайность, взяв такой рандом за последние 1000 блоков и посмотреть какие он выдаст цифры от 1 до 10 и посмотреть нет ли отклонений выдаче.
|
|
|
|
|
Контракт думаю сделать постоянно живым, а розыгрыш лотереи примерно раз в сутки.
Те транзакции которые пришли на контракт после розыгрыша пусть автоматически попадают в следующий розыгрышь.
В первой версии у меня не будет ничего кроме контракта на solidity
и я не могу например на сервере по крону запускать скрипт который бы обратился в блокчейн эфириума и вызвал функцию "вычислить победителя и выплатить".
Поэтому думаю в контракте в fallback функцию добавить проверку текущего времени и если с момента прошлого розыгрыша прошло более 24 часов, то производить розыгрыш.
В конструктор контракта добавить первичную инициализацию переменной где сохраняем время последнего розыгрыша = дата запуска лотереи.
|
|
|
|
|
Думал над архитектурой данных своей тестовой лотереи.
Пришел к мысли что надо сделать фиксированную цену "лотерейного билета".
Вопервых, цена билета должна быть значительно выше средней комиссии за транзакцию эфира, ну хотя
бы в 20 раз, чтоб не получилось так что получилась сплошная раздача денег майнерам на микротранзакциях.
Сейчас комиссия менее 0.2$
Если бы не комиссия то я бы делал билеты примерно по 1$
А с учетом комиссии значит надо делать минималку около 5-10$.
Курс эфира сейчас около 400-800$, значит пусть будет цена 1го билета в лотерею = 0.01eth
При поступлении эфира на кошелек контракта вызываем fallback функцию
function() external payable {
тут надо:
1. выяснить на какое количество билетов хватает входящего платежа, и записать за номером кошелька участника номера лотерейных билетов которые он приобрел.
2. сохранить эти данные в контракте до момента розыгрыша.
стуруктура данных напрашивается
mapping (uint => address ) client_tickets;
индексное поле целочисленное без знака uint это номер билета лотереи, а address это кошелек участника которому надо выдать приз если билет выиграет.
Номера билетов присваиваем последовательно, в отдельной переменной контракта сохраняем последний выданный номер билета.
uint ticket_count;
В конструктор контракта вписываем для определенности
ticket_count = 0;
Если участник прислал например 0.05 эфира то выдаем ему 5 билетов, записав подряд 5 записей в наш mapping с данными.
Мне конечно не очень нравится, что я вроде делаю неоптимальные записи, экономнее то записать
кошелек_N:0.05
чем
1:кошелек_N
2:кошелек_N
3:кошелек_N
4:кошелек_N
5:кошелек_N
Если часто участники будут покупать не один билет а сразу десятки или сотни, то неоптимальность значительная.
Если большинство будет брать 1 билет, то все красиво конечно.
Плюс схемы с явным отдельным номером билета - более простое понимание кода и данных читателем контракта. А его хочется сделать максимально понятным, чтоб любой желающий мог понять как работает контракт лотереи, не ломая голову над усложненной логикой.
Что делать с остатком если участник прислал денег на дробное количество билетов?
Вариантов тут 3
1. вернуть сдачу (если она больше чем комиссия)
2. прибавить к призовому фонду
3. забрать организатору
Выберу 2й пункт.
|
|
|
|
|
В комментах на inaword нашел ответ на возникший вопрос:
А как же подключать библиотеки в remix?
Надо добавить в начале кода импорт библиотеки, причем можно напрямую с github!
Пример:
import "github.com/OpenZeppelin/zeppelin-solidity/contracts/token/MintableToken.sol";
Такая запись так же подгружает всё на что MintableToken.sol ссылается внутри.
Задумался о том, как же надо этим правильно пользоваться в продакшине, где уже реальные деньги.
Стоит себе в git наверное форкать все библиотеки, чтоб они там были в определенном "застывшем состоянии" зафиксированы, и регулярно мониторить апдейты и вручную утаскивать к себе тестить.
Чтоб случайно не накатить на продакшен со своим косметическим изменением какие то фундаментальные в библиотеке и потом удивлятся если все сломалось.
|
|
|
|
Возник вопрос, mapping итерируемый или нет? Если нет, то получается в лотерее для хранения поступлений нужно использовать двойной mapping. Первый ключ порядковый номер поступления денег и каждому номеру соответствует пара адресс и сумма. mapping (ticket_number => mapping (address => uint256)) client_tickets; Нумеровать начиная с 0, и еще завести переменную в которой хранить номер последнего билета добавленного в базу. last_ticket_number uint256; Выглядит как изобретение велосипеда, который давно должен существовать. Может mapping итерируемый все же, а мне это пока в доках не встретилось. Пока решил последовательно пройти все уроки с inaword.ruЧитаю, вникаю, все примеры пробую на работоспособность в remix. Разбирать рабочие примеры получается эффективнее чем последовательно читать доки и по ней пытаться сделать сразу. |
|
|
|
|
А кто такие эти дропы?
Что это означает в вашем жаргоне?
Рофлиш я тоже не знал слова, ну тут гугл нормально на 1й странице выдаче все прояснил.
|
|
|
|
|
Конечно я вначале буду писать что то для себя, а там видно будет.
Как минимум, полученный опыт позволит мне более профессионально нанимать программистов, когда это опять потребуется.
|
|
|
|
|
Show Posts
