I swear I'm not whoring +1's but can someone check if the +1 button at the bottom of the page is working for you?
It's not working for me.
TAKE IT LIKE THE WHORE YOU ARE!!! Erm, yes, the +1 worked fine for me (changed the icon and said "You +1'd this as (namehere)." Weird, maybe it's a browser setting then. Thanks  NP! I'm using FireFox if that matters. Should work on any browser though because it looks like the default setup for the buttons. A good way to try is to run Incognito (FF or Chrome) and then give it a go. That disables things that may otherwise keep it from working if it's related to an addon. I think it's because I'm blocking third party cookies. |
|
|
|
I swear I'm not whoring +1's but can someone check if the +1 button at the bottom of the page is working for you?
It's not working for me.
TAKE IT LIKE THE WHORE YOU ARE!!! Erm, yes, the +1 worked fine for me (changed the icon and said "You +1'd this as (namehere)." Weird, maybe it's a browser setting then. Thanks |
|
|
|
Is there any way to unlock the auto-payment address? I don't see a way to change it to another address. Thanks.
Email me with your username. |
|
|
|
|
I swear I'm not whoring +1's but can someone check if the +1 button at the bottom of the page is working for you?
It's not working for me.
|
|
|
|
Looks nice, but if so, that 1/2 oz silver 10 LiteCoin round is still only worth 1/2 oz silver, about $10 -
If its current rate of 10 LTC =  at least. Not sure where you get $10. Current price of silver is $21.81 oz, So that half oz coin is worth $10.90, it dosent matter what it says on it, you can put anything you want on a silver coin, its easy to do and it dosent make it worth anymore, silver is silver. It would be stupid to pay $20 or $30 for a $10 piece of silver. I'm assuming that these will each be loaded with the private key to 10 LTC - like the Casascius Bitcoins. So $10.90 plus $23.79 plus premium to cover manufacturing costs and some profit for the guy making them. Gotta be looking at around 40 bucks each. Yea but when you go to sell them no one is going to pay that premium you spent, so your losing money on them.. They are strictly souvenir coins. A big enough company puts any design on a coin they want and sell them for pennies above spot... apmex.com - providentmetals.com - I am a gold and silver investor, I never buy anything with a premium, because your just losing money on it, but thats just me... You should shut up now and look at casascius.com. |
|
|
|
I wonder why more people aren't on this pool...
We're getting more popular.. 200 connections on the multiport now Aww yeah! New coins to celebrate  BTB, NVC, LKY, FRK, MEM... so many to choose from! People voted for NVC in the poll, however I'm thinking LKY might be a better choice, it has a better 14-day average profit ratio and much easier blocks (which means less shares = less load on the db) I think average is less useful here, we want the ones that spend some time as #1. If they can do so with just difficulty spikes and a stable price, then it's perfect. If it has a good average, but never spikes up, all it's really doing is providing a safety net. I wouldn't put too much weight into a popularity poll, you know what will work best I think you've got it right, and I also want to avoid Cryptsy-only coins as they seem easily manipulated and generally don't have much volume behind them. So maybe LKY is not that great of a choice. |
|
|
|
I wonder why more people aren't on this pool...
We're getting more popular.. 200 connections on the multiport now Aww yeah! New coins to celebrate BTB, NVC, LKY, FRK, MEM... so many to choose from! People voted for NVC in the poll, however I'm thinking LKY might be a better choice, it has a better 14-day average profit ratio and much easier blocks (which means less shares = less load on the db) |
|
|
|
|
Share diff changed to 32 for LTC.
|
|
|
|
I just enabled vardiff on the DGC pool. Going to see how it goes overnight, and possibly revert in the morning. Right now efficiency is hovering around 90-95% but the number of orphans hasn't increased as far as I can tell.
Calculation for last N will still be based on diff 32, for now.
Does this mean if someone's is set at 64 they are only getting half the shares? If we set higher difficulty, do we get higher payout per share? Yes, share value is based off its difficulty. Take twice as long/difficult to process it = twice as much value. ~~~ My 2x machines using cgminer 3.2.0 had the same disconnect issue as above yesterday, so I switched them back to 3.1.0. No problems for ~12hrs and counting. I wonder why more people aren't on this pool... We're getting more popular.. 200 connections on the multiport now |
|
|
|
I just enabled vardiff on the DGC pool. Going to see how it goes overnight, and possibly revert in the morning. Right now efficiency is hovering around 90-95% but the number of orphans hasn't increased as far as I can tell.
Calculation for last N will still be based on diff 32, for now.
Does this mean if someone's is set at 64 they are only getting half the shares? Yes but the payments code takes difficulty into account. Got it. Based on how you said it, it seemed more like you were counting all as d32 shares, :p. So what you meant is the number of shares COUNTED for n is based on d32? Such as (assuming we did N=5): Before: 32, 32, 32, 32, 32, 32 (the first one would be knocked off now) Now: 32, 64, 64, 64, 32, 32 (the first one would be knocked off) Later: 32, 64, 64, 32 (the first would be knocked off since each 64 = the same as 2x 32's) Is that right? Correct, N is calculated for scrypt coins as block_difficulty * 65536 / share_difficulty. With vardiff, optimally share_difficulty would be the average difficulty we've been handing out, but I haven't implemented that in the code yet, so for now it's just set to 32. Which means more shares than normal will be included in the calculation. (Rather than less) |
|
|
|
I just enabled vardiff on the DGC pool. Going to see how it goes overnight, and possibly revert in the morning. Right now efficiency is hovering around 90-95% but the number of orphans hasn't increased as far as I can tell.
Calculation for last N will still be based on diff 32, for now.
Does this mean if someone's is set at 64 they are only getting half the shares? Yes but the payments code takes difficulty into account. |
|
|
|
From the third line of cgminer README ( https://github.com/ckolivas/cgminer/blob/master/README): "Do not use on multiple block chains at the same time!". This notice was added in version 2.0.6. I've seen complaints of random crashes and shares not being submitted here. The reason could simply be that cgminer is not designed to work this way. We'd need some clarification what specifically that warning is about. Technically this isn't using cgminer on multiple block chains at the same time... I am almost positive what they mean is don't try to run the same CGMiner to mine two chains using separate video cards at once (ex. video card 0 using one chain, video card 1 using another). I've had 0 issues so far with multipool, aside from the random lock-ups that floud has been aware of and has taken care of (that, at least I think, are unrelated to mining at all). Most of the issues the pool has had so far have involved over taxing the DB. I have not personally had any issues with cgminer at all and I haven't heard reports of any (other than a possible issue with 3.1.x that was observed happening across multiple pools.) |
|
|
|
|
I just enabled vardiff on the DGC pool. Going to see how it goes overnight, and possibly revert in the morning. Right now efficiency is hovering around 90-95% but the number of orphans hasn't increased as far as I can tell.
Calculation for last N will still be based on diff 32, for now.
|
|
|
|
|
Estimates and payouts are re-enabled.
|
|
|
|
|
So twitter requires an authentication token to pull publicly available tweets now. Fucking 5 days after I start pulling the site news from Twitter. What the fuck.
|
|
|
|
|
Something's going on on the DGC network, I've been getting these in my pool logs several times today:
2013-06-12 03:14:32,490 ERROR bitcoin_rpc_manager # Check Height -- Pool 0 Down!
2013-06-12 03:14:33,491 ERROR bitcoin_rpc_manager # Problem with Pool 0 -- NO ALTERNATE POOLS!!!
2013-06-12 03:14:37,493 ERROR bitcoin_rpc_manager # Check Height -- Pool 0 Down!
2013-06-12 03:14:38,494 ERROR bitcoin_rpc_manager # Problem with Pool 0 -- NO ALTERNATE POOLS!!!
2013-06-12 03:14:42,499 ERROR bitcoin_rpc_manager # Check Height -- Pool 0 Down!
2013-06-12 03:14:43,501 ERROR bitcoin_rpc_manager # Problem with Pool 0 -- NO ALTERNATE POOLS!!!
2013-06-12 03:14:47,504 ERROR bitcoin_rpc_manager # Check Height -- Pool 0 Down!
2013-06-12 03:14:48,506 ERROR bitcoin_rpc_manager # Problem with Pool 0 -- NO ALTERNATE POOLS!!!
|
|
|
|
|
Payouts are happening right now for the last couple hours worth of blocks.. some of the queries I was running were not so nice on the db so I had to disable a few jobs.
Estimates are currently disabled.
|
|
|
|
multiport has been flaky the last few minutes. It acts like it is switching coins (dropping out for a minute), but no switch is occuring.
2013-06-11 20:05:40: Listener for "multi": [2013-06-11 20:05:39] Stratum connection to pool 0 interrupted
2013-06-11 20:05:40: Listener for "multi": [2013-06-11 20:05:39] Lost 28 shares due to stratum disconnect on pool 0
2013-06-11 20:06:40: Listener for "multi": [2013-06-11 20:06:39] Pool 0 stratum+tcp://multipool.in:7777 not responding!
2013-06-11 20:08:16: Listener for "multi": [2013-06-11 20:08:15] Stratum from pool 0 requested work restart
2013-06-11 20:09:05: Listener for "multi": [2013-06-11 20:09:04] Stratum from pool 0 detected new block
2013-06-11 20:12:21: Listener for "multi": [2013-06-11 20:12:19] Stratum connection to pool 0 interrupted
2013-06-11 20:12:21: Listener for "multi": [2013-06-11 20:12:19] Lost 37 shares due to stratum disconnect on pool 0
2013-06-11 20:13:19: Listener for "multi": [2013-06-11 20:13:19] Pool 0 stratum+tcp://multipool.in:7777 not responding!
It was actually DGC that had issues, for some reason the client stopped responding. I had to restart the client and the pool. |
|
|
|
I figured someone in Russia or one of those Bond villain countries would have been on the ball by now.
cash is key, nobody wants to tie a bank account or anything to be able to buy litecoins, so if you want to buy litecoins with cash you have to buy bitcoins first.
If you cut out the middleman (bitcoin --> litecoin), Litecoin will actually be able to break out of its current ratio to bitcoins
Parse error. People want to buy LTC with cash, but nobody wants to use a bank account? Where can we buy LTC with cash? A dark alley somewhere? |
|
|
|
I have some ideas for speeding up the estimates script. Once those are implemented I should be able to update the user stats much more frequently.
Awesome! I look forward to seeing that, . Thanks for being an active dev; it's something that's seen somewhat seldom as of late. Yeah, I just had an "oh shit" moment while looking at the db.. See if you can see what I found wrong here: | id | time | rem_host | username | our_result | upstream_result | reason | solution | block_num | prev_block_hash | useragent | difficulty | +----------+---------------------+--------------+----------------------+------------+-----------------+--------+----------+-----------+----------------------------------------------+-----------+------------+ | 67587309 | 2013-06-11 22:58:31 | 127.0.0.1 | sens.1 | 1 | 0 | | | 369216 | 9WQaCrsu9CTCspdYVQBnUuiAXBnXZn8KDZxHchmewFrc | | No difficulty? No, difficulty is there, it got cut off when I copy/pasted. Hint: It's a performance-related thing. Looking at it... I have no idea. You've piqued my interest now though, :p. I'm still a newbie to SQL performance -- I can make things work but when it comes to optimizing I lack the knowledge. prev_block hash is about 1/3 to 1/2 the total data that is being saved in EVERY share record inserted into the DB, and it's an absolutely *USELESS* thing to save with the share. It's not used for ANYTHING. (It's used for some internal pool calculations, maybe, but it's never retrieved from the shares table). I'm modifying all of the pools to stop writing this value to the db with the saved shares. That should cut our write disk bandwidth by 30-50% by itself. |
|
|
|
|
Show Posts
