Jump to content

New MNC Algo


Jusdem
 Share

Recommended Posts

I've been really looking forward to a change to this algo recently.  I am really tiring of the list of all the coins blending together into a mess and I'm on board with the notion that an algo change will keep MNC on the top of lists of innovative coins.

 

I also am fairly sure that Reaper is just flat-out more efficient than other software.  I know temperatures are noticeably lower and it seems that the speeds are solid compared to other software.  Reaper v13 is pretty spiffy and hopefully a v14+ with even more tweaks could come out with all this. It would be cool to have more options for tweaking, but overall, it's a working app that is pretty straight-forward to configure.

 

There are plenty of GPU miners out there who will love to have a good coin to keep mining.

 

What algo do you suggest? I would be comfortable if we decided on one and then made a GUI, guide, one-click type launch for it all. We cannot expect people to migrate over randomly.

 

EDIT: I would also suggest making the new algo have a purpose, like XPM's does. Rendering videos, audio, global warming models- something other than arbitrarily hard algos that weren't meant to have hundreds of people mining them ;)

Link to comment
Share on other sites

  • 2 weeks later...

I will just have to write an FPGA for whatever algorithm we choose then :)

 

But what is the point of changing it? do we just change the algorithm once we decide there are too many people mining it?

 

The point is to avoid multi-pool mining that just switch in and out creating a high difficulties for loyal miners and cutting away the profits from the loyal miners when the difficulties drops.

 

 

I am actually more supportive of CPU mining than GPU or even FPGA mining, as CPU mining would means every single person in the world will be able to mine it.

 

Not everyone has a GPU and not everyone can afford a $8K-$10K FPGA just to mine some coins for a beer gathering or for fun or support.

Link to comment
Share on other sites

The point is to avoid multi-pool mining that just switch in and out creating a high difficulties for loyal miners and cutting away the profits from the loyal miners when the difficulties drops.

I agree this could be a major ongoing issue for mincoin as well as most other altcoins.

 

I am actually more supportive of CPU mining than GPU or even FPGA mining, as CPU mining would means every single person in the world will be able to mine it.

 

Not everyone has a GPU and not everyone can afford a $8K-$10K FPGA just to mine some coins for a beer gathering or for fun or support.

Hmm, is it even theoretically possible to have an algorithm that would be optimized for CPU mining, but resistant to GPU, FPGA and ASIC mining? My guess is no. That is, for any computable algorithm, I expect that CPUs will underperform against specialized hardware that is developed to be optimized for nothing else but processing that algorithm.

Link to comment
Share on other sites

Well, yea.  Nothing will perform better than an ASIC...because it's application specific.  But it is entirely possible to write an algorithm that is optimized for CPU; that is, you could easily write an algorithm with which a $300 CPU would drastically out-perform a $1,000 GPU.  It depends entirely on the math behind the algorithm.  Processors all do the same things essentially, so why do CPUs and GPUs perform differently for different tasks?  It's because of their design.  CPUs are designed to perform maths, which is what allows software to run on computers.  GPUs perform maths as well, but with a focus on graphics aka vectors and rendering.

 

 

I would be interested, however, to learn more about this "proposed" algorithm.

Link to comment
Share on other sites

  • 3 years later...

Hello,

 

    Since the Mincoin distribution curve is flat and there are as many rewards per minute now as there were in the beginning and will be near the end, there are benefits for non-early adopters who want to start mining and still obtain a decent amount of MNC.  (ignoring the first 4,320 blocks for argument's sake)

 

    I don't necessarily have a particular favorite to propose in regards to a CPU algorithm with characteristics to make it GPU / ASIC resistant but I am inclined to think there must be some particular hardware extensions on the various newer AMD / Intel chips which could be featured in a proof-of-work algorithm where plain chips see a hash rate of x +/- 35% (due to clock frequency) and the good chips see a hash rate of somewhere in the ballpark of 3x.

 

    For comparison, think processors from the late 90s encoding an MP3 before MMX extensions (with integer math optimizations) or video encoding before the various floating-point SSE extensions improved the throughput dramatically.

 

    Since I haven't looked too deeply at potential candidate algorithms, I am open to discussion and listening to the thoughts from others about algorithm change related suggestions.

    More than likely a "good" candidate will already be included in pooler's or tpruvot's cpuminer and have seen some action in prime time on a relatively secure chain.

 

    At the same time -- people have their Scrypt ASICs from 2014 and might want to have a chance to find profitability with them in the not so distant future on the Mincoin chain.

 

    Is the impetus to change the proof-of-work algorithm to secure the network or to level the playing field with one cpu one vote?

    Or for the sake of argument, does one cpu one vote actually achieve the goal of better securing the network? (I think it does very much.)

 

Best Regards,

-Chicago

Link to comment
Share on other sites

  • 1 month later...
  • 2 weeks later...

Hello Mr. Mincoin,

 

    Thanks!

 

    Yes, new release candidates have been posted in the Mincoin Development Forum for testing to ensure the compatibility across platforms as well as to ensure all the things work quite well.

    It is simply a transitional update, with new libraries linked into it, to secure OpenSSL and such.

 

    I took the opportunity to rebase against Litecoin when doing the work in order to eliminate cruft from the 0.6.x SandyCohen release and the earlier 0.8.7 Vipah release.

    The Alert system has been restored and a testnet has been erected.  All of which we can validate as the testing stakeholders bring their nodes online.

 

    The new client will only communicate with peers using the new client as there is a protocol version upgrade to 70002 and a minimum protocol version requirement of 70002.

    As a stop-gap until we bring everyone on the same new code; a  bridge node is operating to keep the current v60002 peers and the new v70002 peers on the same Best Chain.

 

    Largely, it will be a maintenance release we hope for everyone to adopt.

    Then, we'll be able to evaluate who is getting our message, by upgrading and who might be left behind when we do the next Network Upgrade to the v0.10.2.2 Litecoin code which will bring us the BIP66 improvements and then afterwards, v0.10.4.0 which will bring us a BIP65 lock-in too.

 

    After those steps, we can jump ahead to the fun stuff where the inherited build system on the modern Bitcoin/Litecoin code will give us releases for Raspberry Pi.

 

Best Regards,

-Chicago

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.