PoW+Dice

[infoman]

Прошу по пинать идейку:

 

1. Майнеры генерируют новый блок (выигрывает, как обычно, самый сложный хэш), где вознаграждение рассчитывается по формуле = ((Текущий размер вознаграждения) / 100) * (Количество монет в обращении) / ((Количество монет в монетной базе ) / 100) + плата. Остальная часть вознаграждения разыгрывается между адресами в сети, на которых есть монеты(стейк холдерами).
2. Адрес на которых есть > MIN_BALANCE имеет право участвовать в розыгрыше оставшейся порции новых монет из монетной базы
3. Розыгрыш происходит путем расчета рейтинга, где на первом месте стоит номер хеша адреса, ближайший к номеру хеша (приведенный к формату адреса) найденного блока
4. Вознаграждение является обязательной транзакцией в следующем блоке после розыгрыша
5. Начальный адрес разработчика - это первый адрес, на который будут переведены первые монеты, поскольку разработчику не имеет смысла играть с собой (деньги, если вы не тратите их на покупки, теряют всякий смысл), все новые и новые игроки войдут в игру например если использовать "кран" разработчика.

 

Какие мои предварительные выводы:

 

Награда из монетной базы за блок майнеру стремится от 0 к 0 в процессе распределения, по окончании которого остаются только комиссионные сборы.

 

ГСЧ:

В розыгрыше есть 2 генератора ГСЧ это будущий хеш блока и хеш адреса победителя. Количество монет, распространяемых в сети, даже если вы распределяете их по одному сатоши на открытый ключ, несопоставимо меньше, чем число возможных вариантов хэша номеров блоков и хэша номеров адресов, следовательно, вероятность того, что человек, имеющий миллион адресов с минимальным количеством монет будет иметь больше шансов на выигрыш чем все остальные ничтожна мала.

По этой причине степень вероятности распределения монет в начале стремится к максимальной.

 

Майнеры будут пытаться не просто найти блок соответствующий таргету, но и наиболее близкий к своим стейк адресам, однако вероятность найти такой блок учитывая ГСЧ будет стремится к нулю и проще будет найти много блоков и насобирать комиссию на ту же сумму.

 

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

 

Сеть либо стартует либо сразу заглохнет от множества атак 51 и неверия публики в светлое будущее.

Ваше мнение? годнота?

[infoman]

Посоветовался с крутым программистом Matt Bell, пришли к выводу что будут попытки сибил атак, которые приведут к скачкообразным волнам сложности, но в целом очень похоже что это таки годнота! Распределение монет будет максимально случайным. В общем и целом майнер в такой системе ограничен не только мощностью оборудования но и стейком в кошельке, это реально синхронный pow+pos...

[infoman]

Как определять победителя:
1) находим полное совпадение хеш блока = хешу адреса (на котором есть монеты определенного количества + определенного возраста) , если такой адрес найден то в следующем блоке награждаем его, если такого адреса нет тогда:
2) находим ближайшие хеши адресов в хешу блока с обеих сторон - и +, если таковых два тогда в следующим блоке награду делим пополам, если один то награждаем одного.

Дополнительные варианты работы пулов:

1) Участники скидываются своими мощностями но не скидываются стейками - такой вариант будет приводить к тому что пул будет награждать того у кого сработает стейк , его и только его, Самому пулу достанутся только копейки от комиссии и копейки от формулы распределения. Этот вариант как мне кажется не окупит пул
 
2) Участники скидываются и мощностями и стейками, тогда пул может распределять награду равномерно, но возникает риск потери стейка в результате СКАМ действий владельца пула. Этот вариант будет неприемлем для пользователей тем больше чем больше СКАМ случаев будет появляться.

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

[Ainz]

1) Конструкция слишком сложна, невозможно реализовать независимую от контекста проверку заголовков.

2) Присутствуют утверждения о том, что не имеет место в реальности.

 

К примеру, вот это:

 

22 часа назад, infoman сказал:

выигрывает, как обычно, самый сложный хэш

 

- неправда.

[Ainz]

5 часов назад, infoman сказал:

Распределение монет будет максимально случайным.

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

 

В общем случае это никак не поменяет существующий порядок вещей, не внесет новых уязвимостей и несравнимо проще в реализации.

[infoman]

50 минут назад, Balthazar сказал:

- неправда.

но близко к правде, и если правда наступит(будет найден самый сильный блок в самый короткий период) то правда станет правдой на 100% 

где я не прав?

 

46 минут назад, Balthazar сказал:

Достаточно просто добавить в генерационную транзакцию обязательный вывод, перечисляющий определенный процент награды на адрес, который выбирается из списка ранее использованных адресов.

- уязвимость получается Бальти, число ранее использованных адресов<>числу адресов со стейком нужной кондиции и нужной величины

48 минут назад, Balthazar сказал:

а по мере набора системой энтропии, достаточной для выбора следующего адреса

- какой источник? что значит достаточной? какие характеристики достаточности? и чем хуже энтропия найденного хеша блока умноженная на энтропию распределения стейков по вектору возможных адресов?

 

1 час назад, Balthazar сказал:

невозможно реализовать независимую от контекста проверку заголовков.

это еще почему? заголовок блока не поменяется

Если ты имеешь в виду проверку только заголовка то заголовок блока как обычно проверяется на соответствие таргету хеша стандартных полей блока

Если ты имеешь ввиду последующую загрузку и проверку полного блока то там так или иначе проверяется контекст всех транзакций и данные об utxo уже висят в памяти узла, разве нет?

И как мне кажется размер массива UTXO куда меньше предложенного тобой списка ранее использованных адресов?

 

Спасибо за критику.

[e46btc]

13 минут назад, infoman сказал:

но близко к правде, и если правда наступит(будет найден самый сильный блок в самый короткий период) то правда станет правдой на 100%  

где я не прав?

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

[infoman]

18 минут назад, e46btc сказал:

И даже в очень редких случаях с орфанами выигрывает не самый "сильный", а самый "быстрый", если такая терминология вам проще.

и где я не прав? или у нас сложность отменили? и можно вообще любой хеш закинуть на верх цепи?

яж сказал "быстрый и сильный" сильный я имел ввиду что он должен соответствовать текущей сложности

если узлу закинуть 2 блока подряд на одной высоте но один из них будет иметь большую сложность то какой из них будет принят главным? при условии что блоки следующей высоты еще не поступили?

[e46btc]

Только что, infoman сказал:

если узлу закинуть 2 блока подряд на одной высоте но один из них будет иметь большую сложность то какой из них будет принят главным? при условии что блоки следующей высоты еще не поступили? 

Любой из них, который вперед получен из сети, независимо от сложности каждого из них.

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

 

[infoman]

@e46btc да? ну круто, это даже лучше чем круто, применительно к данной системе,  добавляет рандомности заставляя выбрасывать свою колоду карт (смайненых блоков) раньше остальных.

или у кого яйца более стальные...

 

Изменено 14 фев 2019, 13:19 пользователем infoman

[infoman]

@Balthazar кстати а что дешевле ? Сравнить utxo c энтропией хеша предидущего блока или перемешать все использованные ранее адреса исходя из хеша предидцщего блока?

Изменено 14 фев 2019, 14:05 пользователем infoman

[infoman]

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

 

Кстати кто нибудь в курсе это уже где нибудь опробовано?  и какой процент по вашему нужно закладывать на награду майнеру?

с одной стороны это привлечет хайперов с другой майнеры могут взбунтоваться?

[infoman]

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

таким образом:

1) распределение становится истинно случайным

2) включение генерационной эмиссионной транзакции в блок становится делом лица заинтересованного в этом (победителя)

3) не требуется проверка заголовка блока в плане контекста

4) снимается нагрузка с майнера  в плане онлайн проверки эмиссионной транзакции

5) возрастает конкуренция за комиссионные сборы среди майнеров сразу на старте запуска монеты а не по окончании периода распределения