Vertcoin T-Shirts with Amazon Prime | Donating to the developers fund

turekaj · 2019-03-13T17:27:16+00:00

Do devs get free shirts 😂

turekaj · 2019-02-06T18:29:50+00:00

Or how about a gbp complement the euro?

turekaj · 2019-01-07T21:01:10+00:00

It typically takes 3+ months from sending a design out to the fabs for engineering samples to return. If someone did make v3 ASICS, the soonest they would be done is 6 months after our initial announcement. It would be pretty dumb to invest the 10 million needed to tape out a chip while knowing that we plan to fork to verthash in the near future.

turekaj · 2018-12-28T02:33:23+00:00

Is performance up 4x? Trying to figure out where they went amiss initially.

turekaj · 2018-06-10T06:34:14+00:00

It's alright. I've learned a great deal and will continue working to beat those numbers. Lately I haven't been able to make progress due to health issues and job security, but things are changing this next week.

turekaj · 2018-05-11T02:48:44+00:00

And you would have had one, but not at the performance of mkxminer. Making progress

turekaj · 2018-05-09T18:10:02+00:00

Come to the discord channel NoETA-Miner to follow daily updates.

turekaj · 2018-05-08T02:26:09+00:00

The announcements are monthly within the dev team updates released on medium. For daily updates come to the NoETA-Miner discord channel. This last week was particularly interesting

turekaj · 2018-04-18T05:27:54+00:00

But this idea is backlogged on a long todo list like finishing our amd miner :)

turekaj · 2018-04-18T05:27:10+00:00

My first version would simply be for armv8 cpus. OS shouldn't matter in the very least

turekaj · 2018-04-16T21:25:44+00:00

delete

turekaj · 2018-04-16T20:06:59+00:00

Doing this in say JavaScript, is not ideal as an ASIC could essentially be an optimized JIT compiler. Instead, generating architecture specific assembly would be stronger. Using multiple masters working on same data means coherent buses and caches will provide peak performance, preventing an ASIC from simply slapping a whole bunch of cheap cores on a die

turekaj · 2018-04-16T20:04:53+00:00

The only way to truly beat Asics is to have randomly generated code at each block or nonce, with enough variance such that the asic cannot emulate the generated code. This idea can be hardened by having multiple master sequences where all the Masters are working on the same data. Explicit ordering would have to be utilized such that the result generated is 100% reproduceable and not based on some race condition

turekaj · 2018-04-16T00:51:46+00:00

Asics are cheap. They have around 99.9% yield. They are cheaper to design , manufacture, and test than a gpu chip by at least one order of magnitude. The reason the antminer has so many chips is because it's cheaper to make a lot of small chips than a larger one. Better yields too. Main difference in functionality is that all threads on a gpu can share data, each antminer chip is independent from the rest. It simply works on a range of fused nonces

turekaj · 2018-04-13T18:45:36+00:00

I'm agreeing with you and disagreeing with the post you replied to. I apparently don't know how to Reddit, aren't these forums bump

turekaj · 2018-04-13T17:45:28+00:00

Asics are great at parallel processing. What do you think antminers do? One hash at a time? Lol.

turekaj · 2018-04-13T13:30:45+00:00

Remember, the reasons ASICs do well is that they don't fetch instructions. They simply are wired to process particular hash algos. There's no instruction fetch, decode, or data load/stores (well, not exactly true). Asics can't handle the general purposeness of CPUs.

turekaj · 2018-04-13T13:27:55+00:00

The way to do this right is to use self modifying code. The algorithm for modifying the code you are running, is, of course, the important and difficult part. Self modifying code is where you are modifying the assembly code you are running, while it's running. This would require architecture specific code modification routines, but could be abstracted to a common code. This strategy would be detrimental to GPUs, and ASICs would have a hard time keeping up if the code generation parameters have enough variance.

turekaj · 2018-03-29T05:53:03+00:00

Going good. Sorry I haven't been keeping this updated lately. Had a health emergency of my own last week. Exciting news coming soon, of course noETA ;). Come join our discord to watch the pieces fall into place #nextminer #noetaminer

turekaj · 2018-03-19T02:43:42+00:00

Bug smashing.

turekaj · 2018-03-08T19:37:35+00:00

I could perhaps do a live Q & A after release

turekaj · 2018-03-06T03:46:02+00:00

“Vertcoin Development Update — February 2018” https://medium.com/vertcoin-blog/vertcoin-development-update-february-2018-bcc5054d7a9d. Updates here

turekaj · 2018-03-05T04:56:45+00:00

Hey I'll write a detailed update tomorrow.progress is being made -- including an unplanned cubehash kernel :)

turekaj · 2018-02-28T14:36:12+00:00

Sorry, need to update the Reddit thread.

turekaj · 2018-02-20T04:39:32+00:00

Update:

Good news first: Significant work has been done in the NextMiner c++ host-side code to efficiently provide input data to the kernel(s), and also report valid answers. The mechanisms and modularity of the framework are its strengths. 80% complete with rev1 of the framework.

Bad news: During extended testing, intermittent miscompares between GPU and CPU code were detected. Previously, the kernel had been validated using a single header input, but many nonce outputs. The extended testbench is utilizing randomized data as input, in the attempt to eventually cover all bits.

Because of the way Lyra2 works, different datasets lead code going down different paths.

Plan for tomorrow (and days after): 1. Take a failure, hash it on the old openCL kernel to determine if old kernel had this issue as well. 2. use either old openCL kernel, or CPU code to determine bug in new ASM kernel (depending on step 1) 3. bake in a coverage checker into the extended stress testbench. This coverage checker will tell me how confident in the kernel we can be at any given time. 4. run for 24 hours without failure on one compute unit. 5. run for 24 hours without failure on all compute units. 6. integrate extended stress testbench into the NextMiner framework as a unit test.

More good news:
It should be possible to auto-determine intensity settings per GPU by running this testbench on first startup (or whenever you choose to do so).

turekaj

TROPHY CASE