Edit: thats one of the reasons i love Digitalcoin so much, when i came in and bought just a few, i was treated with respect, when i asked what i could do to help, respect, noone ever treated me like they didnt care if i was there or not, The people involved with Digitalcoin understand that treating the people right is everything.
I find this downright anecdotal... What you consider to be someone else insulting you, I consider to be someone else treating you with a level of politeness well above what would be reasonable for the context. I figure I have enough " millions" IRL, and I don't see how that entitles me to be arrogant and obnoxious to anyone else. Thanks for the edit, I finally see what's going on. /done Edit: In case you're wondering, my views are mine and mine alone. You cannot have them, you cannot borrow them, but I can sell them to you cheap (CACHE discount available).  /really done ~ Myagui |
|
|
|
You were the one being an asshole to the guy trying to introduce himself, let you know where he stood on the coin, and eventually turning him away from your coin with disgust in how you treat people that want to get involved.
Manners go a long ways to getting respect from other people. Point out a single instance/sentence where someone was "an asshole" to you. There is not one. Take the chat log and ask any person outside of the crypto world to read it, and ask their opinion on the tone and manners by which you conduct yourself. If you still don't get it, I'm sorry, it appears you're too far gone!  I'll step out from this now. My apologies for feeding this rather pointless discussion. ~ Myagui |
|
|
|
|
Hm ... Being 5% powerful doesn't sound like much to me... Quite easy for the other 95% to absorb it when Rawdawg "single handedly put the price of the coin down so far it wont recover"... Heck, I'm tiny, but will be happy to pickup any more CACHE if I can, so please go right ahead!
I don't know mrpj, but based on that chat log, kudos to you sir. I don't think I would have been able to keep things as polite as you did.
Joining you all for popcorn!
~ Myagui
|
|
|
|
The thread you're pointing too, shows a an example of a pool being abused by fake shares, which is, again, completely irrelevant with regards to network security and block rewards for just everyone (except those on the abused pool). The coin in question eventually forked for reasons again completely unrelated to your claims here. This adds absolutely nothing to what has already been expressed. You continue to not take the time to read the explanations that you're offered, and you have not added any question or argument of value. Sorry, but I'm done here. You are not being ignored, but I will certainly not feed this discussion any further! Cheers, ~ Myagui |
|
|
|
BOTH the pool AND the network are using the same daemon. This means both will be fooled by these exploits because the daemon is accepting the pool's hashrate which was calculated using the bloated sharerate figures. fake hash vulnerability #1938 https://github.com/MPOS/php-mpos/issues/1938With this method, all pools accepts fake hashrate and shares.
Wrong again. The pools are processing shares of various difficulties. In contrast, the "network" only accepts full "blocks" at the proper network difficulty at any given time. There are no fake shares submitted to the network... See, an abuser can submit all the fake shares he wants. The buggy pool will take them - BUT - unless the pool eventually finds a valid block, there is 0 reward. When the buggy pool does find a block, the block reward is perfectly valid, what is messed up (due to the abuse), is the share distribution of that block to the buggy pool miners. The network is completely unaffected. The victims, are the legitimate miners on the buggy pool, which are not getting their share of blocks found by the pool. Please... Stop posting for a while, go take a read, a break, a smoke, then have another think about your claims. You have received well beyond any reasonable explanations to your concerns, and you do not appear to be taking a breath's moment to think about what is being explained. Cheers, ~ Myagui |
|
|
|
Do you have anything that will back up your claims ?
DGW is making its adjustments based on the pool's reported hashpower. Your statement is illogical..
You do not seem to understand how difficulty adjustments are performed. A pool does not "make" any network difficulty adjustments. The issues with "fake shares" and "shares below target", only affect the buggy pool itself and the miners on it, the network could not care less for these bugs. The network, relying on DGW, makes adjustments based on the time that it took to solve previous blocks, and then estimating the nethash so that the new difficulty results in block solving at the desired rate.Multipools hopping on and off are a well known problem. For a coin that has a modest nethash, when a multipool joins, difficulty will be through the roof. When the multipool jumps off, the network will have a hard time solving the next block. This is completely expected. Smart (or rather, ethical?) multipools, only jump on coins that have enough nethash to not be "catastrophically" impacted by the multipool. Does not seem to be the case with "trade my bit", but I honestly don't know of their motivations or if they care. No offense intended really. Hope this helps settle your concerns. Happy mining, ~ Myagui |
|
|
|
here are my settings
cgminer.exe --scrypt-jane --sj-nfmin 4 --sj-nfmax 30 --sj-time 1388949883 -o stratum+tcp://cach.catcoin.cz:3333 -u user -p pass --thread-concurrency 31427 -I 11 -g 1 -w 512 --temp-cutoff 99 --temp-overheat 93 --temp-target 90 --gpu-fan 40-100 --auto-fan --gpu-powertune 20
Nothing wrong that I can see... The only thing I can think of: have you created a worker? Should instead be: -u user.worker -p workerpass You probably have that right though... Anyways, good luck! ~ Myagui |
|
|
|
anyone know a good intensity to set at using r9 290's getting nothing but HW errors or a pool to get on i do want to try and solo it.....
I'd recommend either of these two: P2P: http://q30.qhor.net:8336/MPOS: http://cach.catcoin.czAs for r9 290's settings, no clue here, myself only ever use nvidia. There were some settings posted on the previous page, see if those will help you... Cheers, ~ Myagui |
|
|
|
The new rules are for PoW diff adjustments. The fix for PoS will not impact PoW in any way. The two blocks do not depend on one another. They are set to generate at 15 mins between themselves. i.e. each PoW is to be generated 15 mins apart, and each PoS is to be generated 15 mins apart, so on average, the confirmation time is to be dancing between 7.5 mins and 15 mins  Ah! Clear now, thanks Kalgecin! ~ Myagui |
|
|
|
Ok, the testing branch seems to ok then. I've set the new PoW rules to kick in on Sat, 31 May 2014 09:53:20 GMT
Anyone who thinks there's something wrong with the testing branch or has any comments, please speak now, I'll merge it into master today if nothing comes up
The PoS change takes effect at the same time as the next nfactor bump then, is that right Kalgecin? (I'm assuming you've got a typo and meant PoS and not PoW, otherwise my post makes no sense  ) I'm particularly curious to see how the diff adjustments will work out around that time as I understand that is also getting improved. Edit: Btw, will the increased chance of PoS maybe lead the block generation slightly towards more PoS and less PoW blocks per day? Just wondering if there's any PoW mining impact to be expected along with the PoS change. Cheers, ~ Myagui |
|
|
|
Since we're on a sharing mood, for nvidia GTX 750TI I'm using the following: cudaminer.exe -a scrypt-jane:CACH -o stratum+tcp://cach.catcoin.cz:3333 -u user.worker -p password -i 0 -L 2 -l T5x12 -q Important: use cudaminer version 28-02-2014, other/newer versions suck at scrypt-jane. These settings will reach 25kh/s at the current nfactor, plus some, depending on how adventurous is your overclocking Happy Mining, ~ Myagui |
|
|
|
Just testing the waters. What is a good price per MH/day?
I really don't know either It's tricky since I had not found any rent offers for cache before. The problem is also that 35KH/s is too low of a hash rate to make a worthy rental. I was trying to rent a powerful rig to make the most of a diff dip for no more than a day (doubtful that I'd have enough funds for more than a couple of hours actually  ). By powerful rig I mean something upwards of 500KH/s, preferably upwards of 1MH/s. Meh, I guess I'd be looking for a small farm, not just a rig Anyways, GL with the renting - though - I'd suggest you work your renting offer based on what you'd charge for the same hardware running scrypt. Meaning, the cost for 1h of scrypt renting, should not be too far off from 1h of scrypt-jane renting for the same hardware. Obviously, the rates per MH are quite different due to the different algorithms & more so with current nfactor for CACHE, but we're really talking about hardware utility vs lease profit. Cheers, ~ Myagui |
|
|
|
Is that your rig vertoe? I had been searching all the time for a rent just for cache, but had not found anything. I can't tell what's the hashrate on that advert though... Is it 35Kh/s? (if so, I'd say way too expensive  ) Edit: Nevermind, confirmed the hashrate at 35Kh/s. Cheers, ~ Myagui |
|
|
|
Yes, that will be addressed in the next release
Super. Thanks Kalgecin. ~ Myagui |
|
|
|
(...)
but it just results in those strange noises, or crashes, maybe I really need to try the 2-28 version.
Yes, that you do! Was also something we debated a few times recently! (dunno about the noise though ... make sure you're monitoring gpu temp & fan speeds) ~ Myagui |
|
|
|
I've tested the simulation for 10 million minutes (~19 years)
(...)
Reviving this discussion just to ask if the proposed change will be part of the next release, and also, if the simulations took into account the nethash drops at each nfactor change. My only worry, is that by the time we hit the next nfactor change, the diff adjustment is again "overly slow". It is not just the nethash drop due to the nfactor change that worries me, but also the tendency to have a reasonable number of miners also dropping (even if temporarily) at that time. My opinion, is that those miners that "stick" around through that period (as myself did in the recent nfactor bump), are being strongly penalized with the slow diff adjustments. Food for thought I suppose. Happy mining, ~ Myagui |
|
|
|
hmm...according to Christian it should still work. Maybe someone found a block after the fork? Oh and btw. I get 240MHash with 5x750Ti. Is that ok?
Hm, maybe it works then. Your hashrate seems off (or mine was), as I was getting about 12MH/s per 750TI. Oh wait, I only used the 0.6 version, have not checked 0.6.1 at all. Maybe that's it... I'm off of jackpot though, perhaps someone else can verify if the latest ccminer is still working after the fork. ~ Myagui Note: I see bigjme already replied and has about the same numbers as me. Points to some issue on your end ltcnim. |
|
|
|
As I can see from getpeerinfo, lots of people are still using qt ver. 1.0.0 Im using v1.1.0.0 and got the stuck problem as described... and Im angry. 12h mining with 4 rigs, each 1200Watts per hour. lost. Close wallet, delete peers.dat, run wallet again. Hope this helps. ~ Myagui |
|
|
|
regarding jackpotcoin: I just tried it, and I got 3 x blocks, but it shows the big bad "booo!". Since the hardfork happened a short while ago, I wonder if this just means I found an orphan, or ccminer has a problem after the fork?
From what I understand, the ccminer that has been circulating so far will not generate "valid blocks" for jackpot after block 6000 (assuming up-to-date QT-clients obviously). There's a couple of PoW blocks since the transition at block 6000, but not many. Most blocks are now PoS, as PoW diff has not adjusted fully. Lucky morning for me: woke up and ran on jackpot with 2x750TIs for just about 3 minutes. The network was at block 5996 around the time so I figured it was my last chance before the switch at block 6000. In 1 minute, block found. Hah! But no jackpot for me though Cheers, ~ Myagui |
|
|
|
|
Show Posts
