Topic: [ANN][YAC] yacoin: yet another altcoin. START is now. - page 172. (Read 346717 times)

Obviously it should be called Botcoin  

Try Pool's Miner
.bat command line is:
start /b "path.." minerd.exe --url http://url.com:port --userpass UserName:Pass

under my copyright only

Can anyone provide information how to test SOLO CPU mining (i.e. with litecoin client) with that basic client?
Command line parameters and solo proxy setup (if needed)?

PS. I have only used a cgminer...

This seems like an interesting concept however the name does suck which will overall devalue the coin as a whole.
I wonder how long it'll take before the difficulties to skyrocket when the coin takes off.

Dev/OP don't rush this KK I'd wait for something thought about and fine tuned than pushing another one out.

You are right. I just skipped through the code and i will give this a try.
Perhaps there is more behind it (as it almost always is when something looks easy ) but i don't
have anything to do anyways...

No, you would have to change it in at least 6 places ;-)

https://github.com/ckolivas/cgminer/blob/master/scrypt130302.cl#L762

The best bit is that you are already recompiling the code the first time you run, or whenever you change many of the parameters anyhow. You don't need to recompile your miner; Your miner already compiles the GPU code from OpenCL on demand

that feel when 5 am 

The math is pretty easy. Look at the first post in the Topic and add 24 hours. I believe in you.

Anyone know how much longer until this launches??  

At very least using various scrypt params can give a first mining advantage to cpus while rest are busy recompiling their mining soft

This 

Isn't it almost trivial to just change the Scrypt parameter in the cgminer source and recompile it with that?
If the N parameter doesn't change every 10 minutes or so, one can "track" the N-value manually until you
or someone else figures out something automated (shouldnt be too hard to implement)

My GPU 3GB of memory and a large amount of bandwidth to it; memory access times are on the same order as those of my CPU, so I doubt that it's going to have significantly different bounds in the absolute worst case. It's an interesting challenge trying to make an algorithm used by the network  parallelism resistant while relying on distributed parallelism for part of the network security.

Looking at it from the brute force point of view, the obvious case of a botnet has been already stated, and running 1,000 CPU hours on Amazon is almost insanely cheap. Throwing $20 at AWS would probably be enough to out-mine the entire rest of the network if people were bound per CPU. Once again it degenerates on whoever-has-the-most-cash-to-throw-at-the-problem-wins.

Making stuff hardened against GPUs is going to be pretty hard as they're pretty much computing clusters to start with, without the problem about distance for connection between nodes or power/space overheads. Given you can just write for them in (pretty much) C, and then just pick and choose which parts to parallelize, for repetitive proof-of-works it's almost always going to be possible to find a way that is at least as fast.  It's probably easy to find a way to make something CPU bound in the short term, but no reason it has to stay that way.

Dynamic parameters seems like a good idea to start with, but given optimising compilers can automatically give a not-horrible solution rather quickly, we can either recompile every parameter change, or just have code that isn't fully unrolled for a GPU. The latter is almost certainly what the CPU is doing anyway.  Looking at FPGAs, they are literally designed to be reconfigurable on the fly.  If the parameter change is only once every few days, hours or even minutes then this isn't going to rule those out either.

If you succeed in limiting to only CPUs, it will just be an extra income stream for botnets.

What might stop the situation that we have now (with a never-ending race towards more hashing power, which is actually encouraging entrenchment and centralization of power at the expense of network security) is to somehow have a fixed cap on work, split it into shares, and then have some sort of distribution of those shares across the network.  Encourage geographic network diversity, and encourage nodes rather than just raw brunt.

Proof of work does help to secure against brute force attacks long term by giving fiduciary incentive to be the biggest brute force attack out there first. Those same forces however also drive centralization of mining power and entrenchment of monopoly on those who have been able to re-invest mining profits back into mining. Even the pools consolidate to single points of control, which even if the pool providers have the best of intentions, are single points of attack and single points of failure.

Distribution of work across all node networks over time isn't the hardest problem to solve. Protecting against brute force without an internal arms race against giants is though.  What protects us seems to be also destroying us from within at the same time :-/

CPUcoin

setting my alarm for 4am

wating.....

I like this idea, like the other post https://bitcointalk.org/index.php?topic=194820.20 having a similar idea, only things are give enough notice time before releasing, don't premine, prevent GPUs, and change the name; like others I dont like the name at all

Excellent point by the way.

As this coin is not released yet, how about fixing all the fundamental issues pointed out in this topic before releasing yet another copycat? If OP would fix all the issues and do the launch more properly with pre-annoucement days before the mark, this could get so much better. Maybe change the name too to something more inviting.