Topic: [ANN][XCN] Cryptonite | 1st mini-blockchain coin | M7 PoW | No Premine - page 146. (Read 578501 times)

Make sure you use --threads 16 or set it to whatever gives you the best result.  Generally, you want to set the threads to be the number of CPU's you have

I don't disagree with any of this in principle. There is just no thorough analysis of exactly how it will end up on GPU. Sure maybe multiplication is 20% on CPU but that means what 60-80% on GPU? we know it will slow down there and a lot of it depends on how things are implemented. XPM has lamo big integer, the things almost always can be fit in registers. These are too large. And i think 2048bit * 32*256 is way too large for local memory. So where CPU is doing some fast 64bit multiplies in registers and has that nice data cache, GPU is executing handful of operations and having to hit global memory to do the same work. Implementing on GPU is quite difficult if you do it the GMP way which is karatsuba i believe.

Keep in mind X11 is not so much faster on GPU. Maybe 3x. Throw a wrench into the works that takes 60% of time and I think that metric will suffer. I can't guarantee it. Maybe not so much, maybe a little. Not even sure it matters. It's just a PoW. People will work it with whatever they have.

The use of Windows Miner, CPU why not working at full speed?

You're underestimating the fraction of time spent in the hashes vs the multiply.  Less than 12% of the current execution time is in gmp bignum functions with your current code, with 88% in hashing (22% of that in one hash function -- easy target for optimization, which I'm sure wolf or someone else has already done).  The one saving grace there is that gmp is avx2 optimized on my platform already, and none of your hashes are yet.  But that leaves things at still < 30% of time in bignum once everything's on an equal optimization footing.  And it's likely that there's some low-hanging optimization possible, given that 6.7% of the time is spent in __gmpz_export and that there's no effort taken to avoid unnecessary allocation and deallocation of the mpzs.  Hint:  there are faster ways to get the data out of gmp if you don't care about portability.

Taking that all together, I'd guess that at most 15-20% of the eventual optimized runtime will be in the multiplication.  The GPUs will win.  You've created a *great* target for Claymore, though, with his pre-built library of bignum routines from writing the XPM miner.

(And to those reading this, no, I don't have an optimized miner - I ran it through a profiler to see what it was, but decided I was bored of miner tweaking this week.)

((p.p.s - no, GPU for hashing and CPU for multiply would be horrible.  You'll just saturate your PCIe bandwidth.))

okay so i'm trying out http://xcn.1gh.com/ with the CPU miner D program

seem to be getting a lot of rejects, is there a list of arguments i can toy with? never done cpu mining before

coinmarketcap.com added XCN

Thanks   I think I have less booo's too now

If you think the launch is bad enough and the developer refuses to relaunch it then you fork it. That is what happens in open source when the developer loses the confidence of the community. I don't know whether that is the case here but it was exactly the case for Bytecoin/Monero.


Yup, I'm betting much lower before (possibly) much higher. And by which I mean I am literally betting that.

I'll change it to 4 hours

It is a lot worse than XMR in that respect.

I think this coin is profoundly overvalued at current prices even if you fully ignore the launch/PoW issues and even if you fully believe in the unique value proposition, both of which I find questionable.

That's nice. But could you change the payout to every hour or at least 3, 4hours. Once per day just taking too long for every miners.

The coin emission here is probably going to crush the coins value for quite a while, like XMR.

Instamined can mean a lot of things to a lot of people but I tend to view it as having an unusual rate total coins mined at the beginning (usually due to bad difficulty adjustment algorithms).

If that happened with bitcoin it would have been most severe in the first two weeks  (before the first adjustment). If we look at block 1, that is January 9, 2009. Block 2016 is January 27, which is 18 days later, or somewhat slower than the 14 day target. Block 4032 was February 12, which is right on target.

This is not instamined, it is just lack of interest to mine. Which is to say that nobody thought the damn thing would be worth anything (you can also see this if you view the generally negative reaction on the cryptography mailing list). They were wrong in hindsight, but they had every opportunity to mine if they wanted to.

There was no instamine or premine on bitcoin, just misjudgment by early miners (and more importantly potential miners) as to its value.

Sorry old moron who can't take a joke, I don't listen to your kind in general but your comment is just pathetic

New Mining Pool  1% Fees!

http://pool.minichain.info pays out once a day proportional to the number of shares (share difficulty = 512)
Also check out the blockexplorer at http://minichain.info It might be down sporadically over the next few days if I'm working on it more

If I get enough interest, I'll release the source code for both

If you run several workers, please try using different wallet addresses to get a lower share difficulty for each. Cryptonite has important block bits updated with every transaction appearing on the network so we have to update miners tasks frequently too.

reorder i got a lot of "Stratum requested work restart". Some miners can't even send jobs after 10 min. Any fix? Thanks.

I agree, this coin isn't a speculator's coin. Not sure why he chose this structure.

Okay I agree midstate will have some benefit here. I don't know how much. It is a long way to go before the multiply becomes a bottleneck.

Thank you for the correction on the multiply output being fully used. That does help.

Cpuminer on xcn.1gh.com updated now, 40%+ speedup.