Storan
Member
Offline
Activity: 112
Merit: 10
|
|
April 22, 2013, 08:35:35 PM |
|
С начальной гипер-инфляцией на ум пока два варианта приходит: а) первые N блоков прибавка +М к награде. (Скажем reward += 100 - block_number/2000 даст в первых 200'000 блоков суммарный довесок в (0+100)/2*200000 = +10кк монет) б) первые N блоков выпускать с абсолютно нормальной наградой, но с удвоенной частотой. За "одинарный" период времени по факту получится двойное накопление средств в системе. Из плюсов - эмоционально приятней соло-майнинг (в 2 раза больше находок). Им минусов - засорение блокчейна ненужными по сути заголовками (ежеминутного вала транзакций первые месяцы после старта системы явно не будет). Тут ещё вопрос технического плана возникает. А возможно ли в форках на основе кода биткоина, организовывать "сборку мусора" в блок-цепи? Поясню что имеется в виду. Берём какую-нибудь красивую большую цифру. Пусть 100'000. Как только цепь достигает №200'000 -> все транзации до блока №100'000 считаются абсолютно истинными, и клиенты "выкидывают" старые блоки от 0 до 100'000 склеивая новый "супер-блок №100'000", в котором запечатлено итоговое состояние жизни системы на блоках 0-100000, с выкидыванием всех промежуточных транзаций (т.е. путь монеты в виде генерация(25)->A1(20)->A2( ->A3 заменяется на генерация( ->A3, ну и естественно все такие атомарные транзакции на один адрес суммируются и в итоге остается лишь одна транзакция на каждый задействованный адрес) , и этот новый блок соотвественно становится стартовым для системы. Все транзакции созданные после 100'000 блока, и ссылающего на блок с меньшим номером - при проверках входов перенаправляются на новый стартовый №. Цепь достигает №300'000 - повторяется всё то же с блоком №200'000 с вырезанием диапазона 100'000-200'000, и т.д. От потеряных кошельков это не спасёт разумеется - эти транзакции на зависнувшие адреса так и будут кочевать с супер-блока в супер-блок, увеличивая размер БД, но хотя бы на заголовках экономия будет всегда. Ну и конечно никто не мешает для безопасности, да и просто параноикам иметь некие server-edition программы кошельков, которые будут всю первозданную цепочку блоков хранить и использовать.
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
April 23, 2013, 01:57:32 PM |
|
Еще момент помните вашу формулу : Reward = K * math.Log(difficulty) + 1.0
Я вот думаю : какую вывести подобную( или др.) формулу, чтобы : 1) при высокой трудности майнеры на Асиках и т. п. оборуд. субсидировали маленьких майнеров. то есть чтобы награда за блок была обратно пропорциональна хэширующей мощности майнера. это была бы еще одна экономическая инициатива НЕ строить FPGA/ASICи 2) а при низкой трудности (скажем меньше 100000) все майнеры получали бы поровну , вне зависимости от своего MH/s От формулы такое думаю получить невозможно. Если слегка модифицировать сам принцип майнинга только. Например. Во всех существующих форках по сути каждый пул - это соломайнер. Для тру можно изначально сам майнинг организовать системно только в составе "обобщенного p2pool" со сложностью шар где-то в 4096 раз меньше чем текущее у сети (в принципе он может функционировать PPS / PPLNS). И этот супер-п2пул уже может делить между всеми майнерами (сиречь обычными пулами, p2pool'ом, соло-майнерами) награду по своему разумению. Половину награды всем поровну "за участие", оставшуюся половину пропорционально супер-шарам; или что-то подобное. Осталось только придумать механизм, запрещающий соло-майнинг в терминах биткоина. То есть все пулы, соломайнеры 2-го порядка, должны принимать в качестве правильных только те блоки, что сформированы в составе этого супер-пула. По гипер-инфляции. Может в формуле награды К побольше задрать? Скажем +10 за удвоение мощности системы. Всё-таки первые года, после начальной приживаемости, мощность будет подниматься как раз при удорожании монет, и соответственно система будет пытаться "сбивать цену" увеличивая эмиссию. Была ещё жуткая идея, комиссии за транзакции не просто передавать майнерам, а ещё скажем удваивать с них доход. А передаёт 1000 Б, на комиссию отдаёт 0.5, С подтверждая транзакцию получает с неё 1. Правда трудно рассчитать, что будет в ситуации когда цены уже стабилизированы и экономическая жизнь кипит - настоящую инфляцию возможно такая "халява" в комиссиях вызовет. P.S. В международной теме каждый второй пост вида премайн -> скам? Печально что саму систему инфляции и платежей не обсуждают
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
April 23, 2013, 05:17:17 PM |
|
100'000 за блок, при сложности 10^9... это эксахэши Eh/s когда пойдут где-то? С логарифмом такого не сделаешь, слишком "горизонтальный" график, при больших значениях х (мощностей). Может заменить функцию на квадратный корень: reward = sqrt(difficulty) ? Получится вместо логарифмического +R за каждый порядок сложности; увеличение награды в ~3 раза, за каждый порядок сложности. Гораздо более сильная обратная связь с реальным курсом монет, и более плавная. (по х миллионы сложности, по у - награда... видно что логарифм стартует как ракета, затем чуть ли не горизонтален, а корень увеличивает награду более плавно) Ну и у извлечения корня конечно отсюда же недостаток проистекает. Если изобретут что-то новое, и сложность системы бешенно взлетит до триллионов-квадриллионов, он с радостью начнёт десятки-сотни миллионов монет начислять за блоки. p.s. На вкус и цвет фломастеры разные. Я полный профан в ономастике, эстетике и т.д., поэтому судить о вариантах, явно не моё
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
April 24, 2013, 08:12:46 AM |
|
Я правильно понимаю, эти итоговые 5% получаются так сказать "суммированием" собственно инфляции, и доп. эмиссии от сложности? Думаю обыватели настороженно относятся к революционерам, и тем более террористам. Хотя именная валюта - это оригинально, и не опостылевшее двузначное именование почти всех форков. (Но повторюсь, моих фантазий хватит лишь на придумать, навроде такого примитива "самое свободно средство расчётов" - ссср ) Как я понимаю в теории, практически для любого алгоритма можно запрограммировать фпга, создать асик; и они будут ad hoc гораздо энергоэффективней . Вопрос в том, сколько будет стоить их проектирование и производство. С двойным ша основная проблема имхо в том, что склепанные кооперативом на коленке, по жуткому большому техпроцессу, в сравнении с CPU|GPU - асики при этом жестоко рвут их в hash/s. Естественно, если такие гиганты как Intel/AMD/Nvidia разработают асики, и начнут их выпекать на своих/арендованных передовых линиях, то они заведомо будут быстрее их же CPU/APU/GPU. Но если такие монстры электроники обратят внимание на валюту, то это де-факто уже состоявшееся признание, и проблема на чём майнят явно отойдёт на третий план.
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
April 24, 2013, 01:00:51 PM |
|
Я все еще верю что и на GPU BMW оч плохо ускоряется. Это кстати можно проверить - в той бумаге (ссылку я давал) есть готовые проги на CUDA для BMW у кого есть такая видяха - может проверить и сравнить c CPU- что быстрее и насколько. на OpenCL BMW реализации я не нашел.
Это где pdf была, работа университетская по вычислениям BMW? Так там где-то сссылки на программы/исходный код присутствуют? У меня конечно не Fermi стоят, а обычна low-end gtx550ti, но проверить можно попытаться. На существующих ша-дважды/скрипт майнерах 40М/70к выдаёт, результаты всё-таки отличные от процессорных.
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
April 24, 2013, 06:11:33 PM Last edit: April 24, 2013, 06:49:48 PM by Storan |
|
Да уж. получить Cuda SDK задача довольно не простая. регистрация, заявки в группах, всё на инглишь. Буду ждать результата. Кстати по тому исследованию, они использовали 9400GT, в которая воддерживала cuda v1.0, нынешние 600-е уже c cuda v3.0 работают. Что там изменилось именно в отношении рассчёта хеш-функций только спецы конечно могут знать, но какое-то ускорение применимое к этой области за 3-4 года могло произойти на аппаратном уровне. =============================================================================================================== А так ли на самом деле важно, у какой абсолютной величины "стабилизируется" М в первые 2-3 года существования? Всё равно ведь, существенно раньше этого (максимум через год после старта) появятся какие-то курсы и обменники true:btc, true:usd и увеличение мощностей от майнеров-фермеров, а следовательно и мощностная эмиссия будет в первую очередь зависеть от возможной прибыльности майна. Ну и период пост-первоначального удорожания при ставновлении валюты никак не убрать. Допустим на определённом этапе жизни системы стабильный неспекулятивный курс достигнет 1true=1usd, ясно же, что в первые месяцы никто в такую стоимость "верить" не будет, и курс будет 1usd = 0,..01true; т.е. какая бы гипер эмиссия не была, как только true приживётся - её монета подорожает. (usd сдесь рассматриваю как самую универсальную меру стоимости в мире в наше время) И с этой точки зрения, самая примитивная стратегия - пускаем всё на самотёк, возможно стабилизирует курс на осмысленных значениях значительно раньше, чем не слишком удачные попытки заранее подогнать агрегат М под нужную величину в ручном режиме (и прогоны в тесте/симуляторе тут мало помогут, будущие точные значения доверия+мощности не просчитаешь, только с потолка значения брать ) ================================================================================================================ В английский драфт добавить бы уточнение к пункту про PoS, что после запуска его награда будет меньше целевой инфляции 2%-3%. PoS включится для стабильности/эффективности системы, а не для начала фазы "а теперь все копят монеты".
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
April 25, 2013, 02:07:43 PM Last edit: April 25, 2013, 03:05:54 PM by Storan |
|
Стремясь очень быстро обуздать инфляцию, можно к несчастью обнаружить что желания сбываются Догадайтесь, какая "инфляционная" формула награды даёт такой +% эмиссии по годам? 1 | 2500,00% | 2 | 100,00% | 3 | 50,00% | 4 | 33,31% | 5 | 12,51% | 6 | 11,12% | 7 | 10,01% | 8 | 9,13% | 9 | 4,17% | 10 | 4,00% | 11 | 3,85% | 12 | 3,67% | ===================================================== с кудой заминка. сволочная нвидиа через небольшое число минут делает устаревшим залогинивание на сайт, и всё отрубает. В итоге я со своим дрянным интернетом не успеваю за этот промежуток выкачать их библотеку. Но голь на выдумки хитра, попробую сейчас с авто-рефрешем вкладки "nvidia developer zone", может получится. ===================================================== правильный ответ к таблице: BTCи значит подобная плавная функция для похожего спадания инфляции будет выглядеть примерно так: k=№_текущего_блока/(N лет * число_блоков_в_году) награда_за_блок = XXХ / e k. Здесь экспонента вместо двойки в степени, ради упрощения расчётов.
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
April 25, 2013, 06:17:05 PM |
|
Ага, а нам надо чтобы награда зависела от времени ( номер блока) и от трудности (ваша идея).
или быстрое получение невысокой инфляции плавно падающей от 10% до 2% (к 55 или 88 году). (это второй вариант оттуда же ) НО не то и другое вместе ((
НО прогресс с этим есть.
-------- А что будет с вашей формулой (с экспонентой) после 12 лет - в году 55 и в 88 ?
Да с экспонентой в знаменателе больше юмора было. Это же чистой воды биткоин, только с максимально возможным сглаженным падением награды за блок (а не нокаутирующими скачками как у оригинала), и натуральным основанием (вместо двойки). w1, _ := math.Lgamma(8.0 * wDiff + 888.0) w2, _ := math.Lgamma(root(float64(block), 2) + 1.0) wReward = math.Abs((w1 * w2) / 100000000.0)
Суперфаворит - выдает до 700% гиперинфляции и затем скромно "худеет" . Прирост в 2-3% здесь не используется, все получается автоматом. В этой схеме есть место для PoS : после гиперинфляции его можно включить начиная с 16% награды и снижая ее плавно до 1% в 55 году. Это скорректирует недостатки фигуры. От логарифма гамма-функции мозги плавятся. Я вот в экселе прикинул - эта жуть Lgamma(x) ассимтотически стремится к величине x * ln(x)... Мы же не физические формулы выводим, может на такой, всё же гораздо более простой вариант заменить? (ну т.е. будет x:= 8.0*wDiff+888.0; w1, _ := math.Log(x) * x; y = root(float64(block),2)+1.0; w2, _ := math.Log(y)*y; По-моему, самое главное к 5-10 годам "разумные" проценты, а годам к 20 "правильные" проценты подогнать. Просто к концу первого года числа совсем уж "гадальные" будут. Например неизвестно, сложность будет всё ещё 100 или уже 100'000. Но в поздние сроки, годам к пяти можно на нынешнюю мощность сети биткоина уверенно ориентироваться, с поправками на менее эффективные cuda,openCL,FPGA,... Мощности можно прикидывать хотя бы потому, что если и за пять лет проект не развился, то его легче похоронить, чем бухгалтерским балансом в процентах. Умоляю, ненадо 16% PoS, зачем средство платежей превращать в средство накопления Пусть лучше фигура с недостатками будет. P.S. с вышенаписанными формулами в лого-гамма-функциях, при сложности 20, и сроке майна 10 дней (7200 блоков) награда за блок будет 0,02 монеты... К итоговой награде надо константу десяточку хотя бы накидывать, а то не пойдёт народ копейку в час майнить (Хотя если убрать премайн, и выкупать монетки по 1$ за десяток... 3$ за двое суток майна всей системы )
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
April 25, 2013, 10:02:54 PM |
|
Я уже прикинул в симуляторе. На поздних годах х*ln(x) отлично заменяет ln(Г(х)) (что естественно). В начальные годы на первый взгляд различия есть, но там из-за рандома и без изменения формулы проценты 2) 180%-250% 3) 80%-120% и т.п. меняются, так что не факт что реальные отличия в процентах будут столь кардинальны. да вот, из экселевской таблички всё можно увидеть x ln(Г(х)) x*ln(x) 1E+00 0 0 1E+01 12,80182748 23,02585093 1E+02 359,1342054 460,5170186 1E+03 5905,220423 6907,755279 1E+04 82099,7175 92103,40372 1E+05 1051287,709 1151292,546 1E+06 12815504,57 13815510,56 1E+07 151180949,4 161180956,5 1E+08 1742068066 1842068074 1E+09 19723265828 20723265837 1E+10 2,20259E+11 2,30259E+11 1E+11 2,43284E+12 2,53284E+12 1E+12 2,6631E+13 2,7631E+13 1E+13 2,89336E+14 2,99336E+14 1E+14 3,12362E+15 3,22362E+15 1E+15 3,35388E+16 3,45388E+16 1E+16 3,58414E+17 3,68414E+17 1E+17 3,81439E+18 3,91439E+18
Отличие в два раза - до аргумента=10... это буквально первые 100 блоков системы. x=100 - это уже лишь четверть разницы; две недели жизни системы. и т.д. Причём отличия-то эти не в аналогичного размера проценты эмиссии переходят в итоге, а просто в денежную массу, генерируемую в первые годы жизни системы. С аргументами 8*wDiff+888, sqrt(block), прогнав по 20 раз первые года на этих почти синонимах получилось усредненная денежная масса по первым годам: ln(Г(x)) : 155k; 480k; 950k; 1530k; 2230k; 3m x*ln(x) : 215k; 700k; 1300k; 2130k; 3m; 3,9m Как и ожидалось, гамма-функция постепенно догоняет х*ln (в абсолютных величинах разрыв растёт, а если смотреть соотношение -всё ближе и ближе друг к другу значения). Принципиально разницы разумеется вообще никакой - один и тот же процесс в эмиссии. Но, по субьективным ощущениям простая функция тут лучше чем сложная. Напоследок, +1 монетой за блок можно всё-таки одаривать. С теми же аргументами 8*wDiff+888, sqrt(block), и +1 к награде: x*ln(x) : 480k; 1220k; 2160k; 3,2m; 4,3m; 5,6m Проценты в последнем случае на 2й, 3й, 4й года получаются при этом ниже - но связано это в первую очередь с эффектом высокой базы, за первый год практически в 2,5 раза больше монет создалось.
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
April 26, 2013, 07:13:27 PM |
|
Может не обращать внимание на процент 2-го года? В принципе он так гуляет только из-за того, что сильно может разнится майнинг в год первый. Может это и правильно? Майнило целый год лишь дясяток cpu - получи мизерную базу денежную и как следствие огромную инфляцию на следующий год, при реальной раскрутки валюты. Если валюта стартанула как ракета, сразу распространившись, было выпущено большое число монет в первый же год - да, возможно на второй год инфляция упадёт даже до двузначной, ну так видимо это будет инфляция уже работающих платежей/торговли. Вдобавок, такой майнинг лишь силами нескольких одиночек вхолостую, почти гарантировано избавляет от "призрака Сатоши" - десятков процентов первоначально намайненых монет, непонятно каким образом зависших, и самое печальное возможно всё-таки хранимых, и лишь у нескольких индивидов.
Моё эволюционировавшее в данном топике восприятие криптоплатежей, теперь полностью склоняется к большой пользе эмиссионых процентов, получаемых опосредовано из мощности; они гораздо адекватней сухих алгоритмических +pi% год, этому алгоритмическому "печатному станку" наплевать, что там в реальности происходит с валютой. А вот "мощностная эмиссия" и её изменение - это самое прямое следствие популярности валюты, и распространенности монет в сделках, и обменного курса.
Смысла отдельно тестировать одни и те же коэффициенты для Ln(Г(х)) и х*ln(x) нет. С учетом "рандомных" мощностей, по прошествии месяца со старта, эти формулы становятся буквально одинаковы (с точки зрения реагирования системы, и начисления в %). Да, в абсолютных значениях x*ln(x) будет всегда чуть больше, потому что оно своеобразная асимптота сверху логогаммы, но на больших значениях оба этих варианта будут неотвратимо сближаться. / x*ln(x) > ln(Г(х)), где х>0; lim x->oo, x*ln(x)/ln(Г(х))=1 /
|
|
|
|
mech
Member
Offline
Activity: 115
Merit: 10
|
|
April 26, 2013, 07:16:16 PM |
|
Тема интересная, где можно получить клиент?
|
PPC? - Should become the first independent altcurrency!
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
April 26, 2013, 09:27:49 PM |
|
Тема интересная, где можно получить клиент?
Пока только концепт вырабатываем. С кодом работает только Ukigo; остальные иногда советы дают, я постоянно языком чешу, ибо балда (Но надо понимать, что такая ситуация вовсе не означает безнадёжности реализации. По сути для старта переписать нужно будет самую малость - только функции майнинга на cpu, и определения награды за майнинг в системе; о них все дебаты в основном и идут)
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
April 27, 2013, 11:30:50 AM |
|
Может "смухлевать"? В первые годы добавить ещё одну функцию к награде. образец идеи: x := wDiff + 1000.0 w1 := math.Log(x) * x + 1.0 y := float64(block) w2 := math.Log(y) * y + 1.0 ycur := float64(block) / float64(year); guile := 20.0 ygui := 3.0; w3 := guile * ycur / ygui; if (ycur > ygui) {w3 = guile * (2.0 - ycur/ygui)} if (ycur > ygui*2) {w3 = 0} wReward = math.Abs((w1 * w2)) / 100000000000.0 + w3; (продемонстрирован совсем черновик. 3 года линейный рост от нуля до 20, следующие 3 года спад с 20 до 0). общие свойства этой функции-добавки: в промежутке [0;X ) - растёт, в промежутке (X;N] - уменьшается, >N == 0 X: это 1-3 в годах; N: 4-7 лет. Основная функция хорошо считает % в будущем, в устоявшейся системе. Новая добавка позволяет сделать красивый график прироста/процентов в первые годы жизни системы, затем исчезает (но следы её присутствия, в виде первоначальной доп. эмиссии, и следственно уменьшенных следующих годовых % будут с десяток лет ощущаться).
|
|
|
|
RoadTrain
Legendary
Offline
Activity: 1386
Merit: 1009
|
|
April 28, 2013, 03:11:43 PM |
|
Можно в двух словах, как награда PoS рассчитывается у вас?
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
April 30, 2013, 04:41:34 PM |
|
... Чет я засомневался : достаточно ли просто вычитать PoS% из poW% , или тут более сложная зависимость ? <-- чтобы вычислить %% реальной (целевой) инфляции" ?
Ну здесь "идеальная" формула проста сама по себе... [%эмиссии_PoW*(число_PoW_блоков)+%эмиссии_PoS*(число_PoS_блоков)]/(общее_число_блоков)=%итоговой_эмиссии. Но тут главнее не переборщить с зажиманием. Вон японцы 20 лет экономили, а счас рубанули сплеча - для роста экономики в ближайшую пятилетку удвоим денежную массу и точка Пора попробовать написать майнер для Skein(BMW())
Понимая, что в практичных вопросах (вроде тупо скачать 1гб библиотек у нвидиа, и скомпилировать cuda-miner) я полный профан; вопрос дилетанта - как насчёт того чтобы этот майнер поддерживал C++ AMP? Как я понял, это некая библиотека/надстройка над С++, где сам компилятор определяет, возможно ли распаралелить функцию на GPU (включая всё новомодные встроенные APU ati|Intel HD) и соответсвено ускорить, где это возможно, скорость простейших хеш-вычислений.
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
April 30, 2013, 06:24:56 PM Last edit: April 30, 2013, 06:37:10 PM by Storan |
|
C++ AMP нам не поможет ( он под Win). А большая часть койно-софта (даже та что работает под Win) собирается на *nix
Я буду издеваться над cpuminer, там как и в моих экспериментах с проверкой скорости хэширования чистый C - надо переписать несколько функций и все ! Но есть маленькие трудности - 1) клиент все еще не форкнут, а там надо будет наверное оборачивать skein/BMW из библиотеки на C в C++ части клиента.
2) после написания майнера надо его проверить, и где брать для него getwork ? Это что еще и пул придется написать ?
Ну если АМР, окажется эффективнее простого cpu-майнера, то любая, даже альтернативная компиляция вытеснит простые майнеры. Идея о полнейшем опен-соурсе юникса конечно хороша, но если в наличии только cpu-майнеры, и под винду с задействованным амр они при этом эффективнее раза в два - то они гарантировано вытеснят на задворки всех юниксоидов, и так будет вплоть до появления gpu-майнинга. Вроде любой пул - для системы выглядит как простой соло-майнер; т.е. код пула нужно будет писать гораздо позднее, когда сеть разрастётся, чтобы много мелких для установившейся сложности майнеров могли стабильно включать свои мощности, а не играть в лотерею. Так что, как я понимаю, для проверки соло-майнинга достаточно реализации -server у кошелька, и наличия консольного майнера обращающегося к нужным локальным портам, и перемалывающего нужные хеши. P.S. У С/С++ различие только в виде вызова функций уже в скомпилированных библиотеках кажись? Или по-другому, неужто в С++ компиляторе нельзя "под себя" скомпилировать си-шные исходники?
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
May 01, 2013, 10:18:57 AM |
|
Совместимость C и C++ это магия ж) http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B В статье написано так : Система C++AMP позволяет переносить вычисления на GPU (видеоускорители) без внесения большого количества изменений в программы. Код, который не может запуститься на GPU, например, из-за своей сложности, будет автоматически запущен на центральном процессоре с применением SIMD (SSE) инструкций. Реализация системы от Microsoft (единственная на настоящий момент) включена в Visual Studio 2012 и включает в себя отладчик и профилировщик. Поддержку других платформ и оборудования могли бы реализовать компания Microsoft или другие в будущем.
То есть BMW не ускорится на GPU (по причине именно своей сложности) В то же время я не верю, что этот AMP будет быстрее работать на CPU, чем cpuminer. Потом у меня все равно нет Win , так что если хотите - можете попробовать написать майнер для AMP (только вам придется найти свою библиотеку для Skein и BMW, ибо моя найденная либа - под Юникс). Тут дело не в опенсорсе или моей Юниксомании (предполагаемой) , а в том что проще кое-что дописать кое-где, чем изобретать велосипед почти с нуля. Попробую разобраться и чего-нить накорябать. Так шальная мысль возникла когда читал про это GPGPU - возможно гибридные майнеры на процессоре с задействованием встроенной графики, будут быстрее чистого cpuminera. Задача явно не первостепенная, но если получится - будет неплохой рывок, почти "халявный" прирост мощностей для cpu-майнинга. P.S. Про совместимость статья занятная... Но если программист на С пишет в xxi веке нечто вида struct template { int new; struct template* class; }; ему надо отрывать руки, а потом яйца.... или наоборот
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
May 02, 2013, 07:37:55 AM |
|
x := wDiff + 100.0 w1 := math.Log(x) * x + 1.0 y := float64(block) w2 := math.Log(y) * y + 1.0 ycur := float64(block) / float64(year) guile := 20.0 ygui := 3.0 w3 := guile * ycur / ygui if ycur > ygui {w3 = guile * (3.0 - ycur/ygui)} if ycur > ygui*2 {w3 = 0.0} wReward = math.Abs((w1 * w2)) / 100000000000.0 + w3
Эта система формул еще лучше Пора попробовать написать майнер для Skein(BMW()) Понимаю, что шаг вперёд - два назад это невесело, и скорости разработки не добавляет. НО... Немножко отвлёкшись и поглядев на 10-ти миллионную сложность битка подумалось: для мощности использовать "усиление" х*ln(x) {ln(Г(х))} - это идеологически неправильно. При быстром росте мощности, даже в устоявшейся системе это даст гигантский рост награды за блок. Нужно осмысленное ограничение, например максимум для w1, должно быть w1 = x; А то уж совсем маразматическая ситуация была. Майнит десяток пулов с 100Mh/sec получает каждый условно по 690, подключается ещё один новенький с такой же мощностью - теперь каждый из одиннадцати получает по 700. Вырастала не только суммарная награда в системе, но и награда каждому майнеру.
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
May 02, 2013, 08:31:31 AM |
|
Да проверок и не надо, вместо x = Z1 * wDiff + Z2; w1 := math.Lgamma(x) или w1 := math.Log(x)*x сокращаем до w1 := x. Цифровой социализм итак останется: как майнил 1 монету в сутки, так и будет продолжать эту же 1 монету майнить своей старой мощностью, несмотря на все изменения суммарной мощности/сложности системы.
Насчёт only-CPU сегодняшние я бы тоже не зарекался так сильно, тенденции последнего десятка лет от процессоростроителей (и амд, и интел) - это многоядерность cpu и всё большее встраивание в него же gpu. Не исключено, что лет через 5-10 "чистые х86-CPU-программы" вообще перестанут существовать. Ещё на уровне компилятора: можно любую функцию быстрее выполнить на gpu-части, которая есть везде - перекидываем её вычисления туда; другой кусок кода просто распараллеливается - аналогично раскидываем на 16 cpu-ядер, и т.д.
Ну и как я уже в другой теме с апологетами майнинга биткона спорил - мощность сети, независимо от типов алгоритмов и устройств на которых они считаются будет возрастать до той поры, пока для среднестатистического майнера затрачиваемое на майнинг электричество стоит дешевле в этой криптовалюте, чем количество валюты майнингом добываемое.
|
|
|
|
Storan
Member
Offline
Activity: 112
Merit: 10
|
|
June 02, 2013, 04:16:21 PM |
|
Ну как экс-трушечки поживают, надежда на воплощение ещё осталась?
|
|
|
|
|