Yeah, please add support for Aeon's CryptoNight-Lite algo. Smooth breathed new life into it.
|
|
|
OK same shit diffrent RIG... On my RIG whit 5 280X, the Miner Do not Start Driver Catalyst 14.4 Win 8.1 BUG: WTF MUTEX ERROR ON LOCK! errno-0 in adl.c lock adl in the Miner cmd field... Someone please post Tahiti kernel bin.
|
|
|
What algo on testnet right now? Or maybe there is a test pool with new algo already available for setup testing? On what drivers new sgminer works?
|
|
|
Well, guys, night is over and I finally synced Aeon blockchain on OS X from scratch. I uploaded it to Mega, so everyone can download blockchain.bin for OS X and move it to ~/.aeon directory for instant sync-up. Would be cool if someone can mirror it.
|
|
|
Mining Aeon while testing my brand new highly concurrent CryptoNote stratum implementation What does this mean, care to explain? Does it mine AEON and cook breakfast at the same time? On another Note (hehe) -- folks, you can still solo mine this coin with aerond daemon. I'm getting 2-3 blocks a day on a 4-core system. Yup, the seed node is doing the same. Good for the network too. Is there any node with open rpc port available?
|
|
|
Mining Aeon while testing my brand new highly concurrent CryptoNote stratum implementation
|
|
|
hey guys, short question: what's the recommended minimum number of confirmations a site should use before crediting deposits? I know that poloniex takes ~16(?) confirmations, but that always feels like a little bit too much. reason I'm asking: https://i.imgur.com/e3BcgAU.jpg15 confirmations is ok for me. It feels too much because I am sure they are refreshing not every millisecond and we don't know how they crediting system behave. There are also network variance can take it's place so 15 confirmations = 15 minutes can turn into 20 or even more just like it can take 5 minutes.
|
|
|
I noticed in this thread some links to optimized miner by author of "kachur" CryptoNight miner. This kachur shit was a malware/scamware miner exploiting plain stupid duplicate share vulnerability in node-cryptonote-pool. You warned, stay away from all blobs by this "dev". https://bitcointalk.org/index.php?topic=583449.msg9262887#msg9262887
|
|
|
Well the pool operator could do that (and could have done it all along). How would anyone else know which payments are his or even which payments are going to the exchange?
Take exchange address, input it in field on pool and you will see all stats & payouts.
|
|
|
I made a HUGE mistake! Was wondering if there is anyway I can recover from this.
Basically I have been mining XMR from time to time for the last 6 months. I used the dwarfpool only because it let me mine directly into my Bittrex address.
Today when configuring my miners, I see that it had backup pools, I never configured any of these pools just used dwarfpool. Out of curiosity today decided to log into those pools with my address and low and behold there are many coins there. But I never received those coins in my Bittrex account.
Is there anyway I can still recover these coins somehow? I now understand why my daily performance was always so low.
My address is basically
address.payoutID
Since I was mining into Bittrex I had to include the entire address but when I checked my stats they only went into my "address" address not the "payoutid" which is the payoutId address for bittrex
Not all pool support payment ID. You should pull your payout records from the pool(s) and then contact bittrex support with your issue but I can't guarantee they will be able to help you particular on old payments going back six months. But give it a shot. And now everyone can contact bittrex and impersonate, because all exchange wallets are public.
|
|
|
I found and prevented another malformed nonce attack vector. All fixed now. Finally. No profits affected. Previous published fix was not strict due to premature optimisation. All CN pools ops should use this update https://github.com/sammy007/node-cryptonote-pool
|
|
|
Do you know why the calculators on the pools show as estimated double than in reality mined. They always tell me that i have to earn about 6-8 XMR pro day but I always earn only the half.
Some pools using incorrect block reward for estimation and must switch to last reward. Also, difficulty fluctuate very hard during 24h, better get average difficulty and calculate yourself. And if your pool is tiny, variance can be significant so use maybe 1 week period for estimation or even more.
|
|
|
I have a few low to mid-range CPUs and am going to set up a private pool tonight for these using this: https://github.com/zone117x/node-cryptonote-pool Can the computer that is hosting the private pool also use some of its cores to mine to its own XMR address? If so, how? This is very bad idea to hash on pool server. Ok - thanks! I'll put the pool on a PC with less CPU power and save the strong CPUs for mining. For solo you can enable share trust to save cpu time on validation too.
|
|
|
I have a few low to mid-range CPUs and am going to set up a private pool tonight for these using this: https://github.com/zone117x/node-cryptonote-pool Can the computer that is hosting the private pool also use some of its cores to mine to its own XMR address? If so, how? This is very bad idea to hash on pool server.
|
|
|
All known duplicate share vulnerabilities fixed on my pool.
Issue was similar to exposed by me several months ago. Someone submitted duplicate shares using nonce validation vulnerability, thanks to onishin for bug report. Stats of spotted attacker were immediately flushed to prevent round payouts to his addresses. Sorry for any inconvenience.
Have a good time.
No one can stop xmr community on our way to the moon.
|
|
|
If I understood correctly, the pool exploit that was just uncovered, only affects the honest miners that are on the same pool as a dishonest one. As the dishonest miner is exploiting the pool by boosting his share count, he is getting an unfair percentage of the overall reward distribution whenever a block is found on that pool.
The underlying point is that overall nethash should not be impacted at all, and neither is the total hashrate for any pool that was being exploited. It is only the internal distribution of shares within each pool that would be crooked, and penalizing the honest miners.
Can one of the pool ops confirm if my understanding is correct? Thanks!
It was small fake hashrate because otherwise it would have been disclosed earlier. It's 2nd duplicate shares issue disclosed, first was found months ago. 2nd address is: 47mQnyN3euDeoZABfAScfh5bHFSTouWMDd6wG5j7V1cjWJg6Nm5D2CN9m6JdK3yuM2Y6pHPHSDiFzds 5bs6bwwhBJv8T56g nonce: "3600c0 kh"
|
|
|
Very nice results with 290(X), any chance for 280x gain?
|
|
|
I'm back.
Average wet dream in this thread.
|
|
|
2 questions:
- Any testnet nodes? - Any testnet nodes?
|
|
|
|