Dear sir, my first and last message directed to you personally.

Don't waste your time reading or answering this, you'll be in my ignore list for quite a long time when your opus'll finally be born.

First of all, as I always mention, You came to my thread, not Me to yours, as you can see I've posted nothing at that garbage hole and never tried to stop your little reverse-engineering project.
It's only you splashing your saliva here, GTFO and make your life not so miserable.

Now containment:


1) I'm not accusing anyone, I've just posted two ways of thinking on the same problem, nothing more. And container is a shit when it comes to mining, doesn't matter how good it is, it will cost nothing without proper kernel. Which you can't say about kernel, give it input, you'll receive output, volia, solution, check it against target, volia, proper solution, not so much code, isn't it?

2) The lie is that you do it for community, you do it only because I've hurted your oversized Ego, and don't think you've hidden your personality under this new account

Are you right about devfee? Partially, man, partially, because dev pool connection is not momental, that value highly differs for every user and that doesn't mean that I gain anything from client connecting to server, only fools think so, for some users full dev time was 38-45 secs, for some it could take more as in your case. Even calculating this, kernel speed gave much more profit for end users, much more, none've pushed Neooscrypt so high before me on Pascal architecture and you're just a parasite in that case, you can write hundreds of reveals and investigations, that will change nothing.
Maybe in your perfect world users follow devs, idea, community, etc., in real world the only thing users follow is money.
In your case users switched for functionality, nothing more, so your crown is made of chocolate, man, be careful, chocolate's melting sometimes.

And let's make it bold!!!! 14528731478% DEVFEE, beware, liar, thief, criminal, freedom, ZOG, HOLD THE DOOR, hold the door, holdthdor, Hotdor, Hodor!!!

3) Destructive code is the one and only thing that can stop your kind from your business, so look carefully when you'll start new freedom-fight campaign against me, or you'll make a lot of trouble to your fanbase and for yourself personally (let's make it a little surprise and see).
Because You'll be a creator of "destructive" binary, not Me, my binary will be as clean as a perfect diamond prism.

And there will be no conclusion to all this shit, it's just some kind of open PM which everyone can read and understand from his/her point of view.

Sayonara, my "friend".

Thank you, I think I will continue with hsrminer developement, devfee in future versions will be 0.5% and container will be fully reworked, design will remain nearly the same as a tribute to Alex.

Everything can be reverse-engineerd, only time matters, but I have some "features" for these attackers to make their assholes burn, I didn't include this in original code for two reasons:

1) I write only kernels, container was not my business.
2) It's some sort of "cyber weapon", so if something'd go wrong with code it would be a disaster, needs very precise testing on my side.

Now I'll start from the beginning, think I'd be able to give (n)er's a fight

Ha-ha-ha, haven't been here for quite a long time.

Reverse engineering is cool, but I see no interest for myself in this anymore, especially when it finally came that alexkap died in road accident month ago, which I found out few days ago, so I've lost a colleague and a friend of mine (we were not so close, but he was a person I could rely on)

Info: I've personally spent 1.5 month in hospital (right after New Year, first it was agressive flu that turned to pneumonia and in hospital I got viral meningitis, thank you, hospital). Thanks for everyone who used MY hsrminer during that time, you've helped me to pay all medical bills and survive this nightmare.
Also, hsrminer helped me to attract not only haters, hackers and other sort of garbage, but also good employer, so now I have much less time to spend on developement.

I have Cryptonite nearly ready, also Lyra2v2 with impressive speed improvement.

I see two ways of future hsrminer developement and haven't decided which one to choose:

1) I rework all mechanics, add more layers of code protection and publish new hsrminer with faster 5-7% speed, but not full speed (currently it's significantly more than 5%+   ). Mr hacker hacks this new hsrminer, I fully rework mechanics again and add 5% more speed, and so on, until mr hacker finds something more interesting for himself rather than jerking off all day long. Also, devfee will be lowered because of situation with alexkap.

2) Community betrayed developer, so I won't move even a finger to do something for this "community" anymore and start selling kernels to factory-grade players (currently I have 2 propositions, but price they offer is too low for one-time deal)

Anyway, wish everyone good luck, and have a nice day!

P.S.: links fixed

spider703 is a legitimate user and has nothing to do with any kind of fraud, helped me personally to accelerate transactions several times, all seems clear, so I believe he has really been hacked.
Give this guy a chance to prove his words and unlock his acc.
If he'd be just a scammer, he'd create another account and won't be trying to unlock previous one.

Will definitely check it, but now it's too late and I think I have to leave conversation or my wife will kill me  

Wish everyone Happy New Year one more time! Hope year 2018 will be more productive!

Looks like this, to figure it out someone needs to setup "lab pool", which he certainly knows won't switch blocks insanely, and trace all network exchange
Are there any neoscrypt pools mining only one coin, without scripting?

That's a good idea to keep working on the previous block when something like this happens, but it's highly possible that every share sent will be rejected because in that particular case bug is on the poolside. But I'll experiment with this.

P.S: altminer is good to check connection drops because every time miner reconnects pool sends welcome message.

Nope, devfee mines VIVO too

Will try my best 


Noticed that too, also pool drops connection from time to time (randomly?), doesn't matter what miner to use, ccminer, sgminer, hsrminer, behaviour is the same.
Good pool, but needs hardware update, they've tried using different ports for different coins, but that didn't help much.

We'll try to keep it in English, sorry. I just need to have a rest  


I've tried this already in early versions, only mid- and high-end CPUs handled this, so small portions are more preferrable.

Yes, maybe someone'd claimed the bounty first, hope it was not _sp who stole krnlx's work. But as far as I'm informed nobody gave bounty to the dev who really deserves it.

Regarding second question, no, you need to run simple batfile as everyone's used to.

  Yes, it was just discussion of two developers on the topic of work scheduling methods in CUDA and proper thread abortation. It was quite productive, alarmod is working on neuronets, he's interesting interlocutor, but I just want to rest now and not discuss these themes on New Years eve 

Взаимно, с наступающим Новым Годом!
Безусловно, данная тема имеет место быть, но не перед Новым Годом, согласитесь 
Дайте ж мне отдохнуть хоть пару деньков и не заглядывать в этот чертов монитор 
Все реализую, все сделаю, но отдых мне тоже нужен.

П.С.: надеюсь, не обижаетесь,уважаю ваше дело, нейросети имеют практически бесконечное множество сфер для потенциального применения и способны осуществить революцию по многим направлениям даже в ближайшее десятилетие.

Ну ОК, допустим даже что можно, смысл это делать если данное шаманство убъёт производительность? Если честно, меня уже слегка утомляет данная дискуссии, к чему она вообще в предновогодний выходной день?
В данном случае никого не хочу обидеть, но я вижу Вы и сами в этом деле прекрасно разбираетесь, пишите свои ядра со всеми необходимыми проверками и прерываниями, а я, в свою очередь, с удовольствием буду использовать Ваш софт на своих фермах.

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

Я прекрасно понимаю, но нельзя принудительно завершить уже развернутый на GPU код, как можно то же самое сделать на ЦПУ, он должен либо завершить свою работу, либо вылететь с ошибкой. Первый случай Вы и наблюдаете, второй завершит работу программы в целом, в чем смысл тогда?

Счет не шел зря, Ваша карта занималась хешированием, Вы же получали шары с момента получения новой работки по новому блоку? Как и в любой системе на ГПУ есть стек, приоритеты, по какой причине часть задач опускается ниже плинтуса по приоритету - не могу знать, вопрос к архитектору данных устройств, а я не специалист по проектированию микропроцессоров, и уж тем более такого уровня.
Любое ускорение имеет свою цену, особенно касаясь работы с памятью, на бит сместился - труп.

Про ЦПУ пожалуй соглашусь, надо добавить валидацию того же самого на хосте, в настоящее время валидация на хосте как старая вахтерша в 3 часа ночи, то есть проходит любой

По CUDA можно поспорить, имеем ядро, имеем Grid из стольки-то блоков, каждый из этих блоков запускает определенное количество "нитей" а.к.а. потоков.
Каждый поток в блоке делает одну и ту же работу, со смещением, когда все "нитки" отработали - блок рапортует.
Все блоки завершены - Grid завершен, идем дальше.

Сама логика конкретно алгоритма Neoscrypt подразумевает работу над одними и теми же данными двумя хеш-функциями используя одинаковые начальные данные, из этого логично пускать данные вычисления параллельно, что несет за собой дополнительный уровень синхронизации, уже по потокам.

Итого имеем 2 варианта проверки на ГПУ:

1) Проверка в каждом потоке одного блока на изменение определенной переменной, не подходит, так как забьет и без того нагруженную шину и ядра будут по секундам выполняться, в какой бы памяти данная переменная не хранилась, хоть в разделяемой.
2) Проверка в каждом блоке, аналогично с первым вариантом, тут уже не на секунды счет, а на миллисекунды, но вряд ли получится что-то больше 500-700 кН с 1080 на выходе.

Прикол в том что ГПУ (в данном варианте) вообще не в курсе про существование такого понятия как блок. ГПУ знает только с какого значения надо начинать считать полученный набор (назовем точкой отсчета) и в сколько блоков/потоков данную работу пускать, после этого все передается хосту, а уж хост решает, отправлять данную информацию пулу или нет. Отправлять - добавляет "посчитанное" в "копилку" и распределяет работу дальше с учетом уже посчитанного пространства. Если бракует - шара выкидывается и данная работа снова отправляется на ГПУ.

И как предлагаете убивать потоки в блоках? Ядро может либо завершить свою работу, либо вернуть ошибку. Можно что-то такое надCUDA сделать, но это все отжирает ресурсы и значительно увеличивает время развертки, игра не стоит свеч.

Можно добавить данную проверку на ЦПУ, но это также дополнительный жор ресурсов.

Зависит от общего количества шар, если их накопилось всего 49 и следующая запарывается - будет уже 98%, накопилось 1000 и 20 запоролось - то же значение 98%, смотря в каком масштабе смотреть, это просто среднее арифметическое.


Зависит от времени работы на пуле до переключения на девфи и обратно, тогда отображаемый хешрейт падает, пулом БСОД не пользовался, по их стате сказать ничего не смогу.

По времени - пока никак, у меня такого параметра нет, все забито по-дефолту.

Nope, I won't add this because after that output restart scripts will easily be able to switch devfee off.


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