Mincoin client update... (It is not the one on the front page... you have to get it from one of the pool-operators who created it.)
It says 6.0.3 (oddly enough, but it is actually v0.6.4.0-g9498fec-beta For the QT client GUI) the one on the front page was 6.3.0 which does not seem to actually work. Who knows what is going on there? Another "copy-paste" coin that dies, because no-one actually knows how to program it, that created it from a previously flawed system.
Seems a lot is failing in the any-coin world...
I am solo-mining, difficulty 0.363099 (23.8K)... on CGminer 3.2.0 & 3.2.1 (3.1.0 didn't work)
Link? |
|
|
|
The fork appears to have resolved, but the pool lost 600 FTC that was already paid out.
I am going to have to manually roll back those payments before I even think about re-enabling FTC on the mutliport.
Glad I spotted it sooner than later and reported via email.  Hope te bug reporting is helping you guys out and yikes at 400FTC loss be sure to send me 499.99999 of it jokes but sad to see a losss tho. I guesss not too much bust still its a loss. However not too big court in time and reported soon as I seen the spot on it. The pool didn't really lose all 600 because the wallet balance was only around 315 after the block we found this morning. Now it's 0. So we're actually at -594 right now, after I roll back the orphans we should be ok. But the miners who spent time mining those blocks will lose the whole 600 which is unfortunate. |
|
|
|
|
The fork appears to have resolved, but the pool lost 600 FTC that was already paid out.
I am going to have to manually roll back those payments before I even think about re-enabling FTC on the mutliport.
|
|
|
|
Something is wrong with FTC: 4 orphans in a raw. Can you cripple it with 20% setback at multipool?
Looks like a possible fork. I just disabled it off the multiport altogether. You must have missed this: May 15th Update: Mandatory update version 0.6.4 released with 504 block retarget and difficulty adjust on block 33,000. There was a hard fork. All the orphans were trying to mine for the same block as well. Once you get FTC updated we should be good to go! I updated to that version long ago, the trouble started when we were on block 33562. Edit: actually, that's some kind of bug, because the raw share data indicates that the following blocks were orphaned. mysql> select username,block_num from shares_found limit 4; +--------------+-----------+ | username | block_num | +--------------+-----------+ | multifever.3 | 33599 | | laserlives.2 | 33608 | | Swimmer63.2 | 33613 | | multifever.5 | 33614 | +--------------+-----------+ 4 rows in set (0.00 sec) |
|
|
|
I was watching the FTC price from the start of the rise and saw something interesting. When the price reached a certain level, FTC jumped up the mining profitability charts and instantly the automated pool at http://www.multipool.in flicked over to mining FTC, that added about 85MH/s when the rate was only 170MH/s which was a 50% hike that made me smile. The sustained price increase for several hours has started getting other miners to switch their rigs to FTC and the current block rate for the last 20 block is down to around 15min. Meaning the next diff change will come a couple of days earlier. The blockchain is currently, or was, forked. I have disabled FTC on my multiport until this situation is resolved. The pool has lost 600 FTC from three blocks that were fully confirmed and then orphaned. |
|
|
|
Something is wrong with FTC: 4 orphans in a raw. Can you cripple it with 20% setback at multipool?
Looks like a possible fork. I just disabled it off the multiport altogether. |
|
|
|
It's true PPLNS prevents pool hopping, but it doesn't stop coin hopping. Nothing can do that. And it just makes sense to mine the most profitable coin, if profits are the goal. But what assumptions go into the profitability calculations? Specifically, is there an assumption that you "cash" the newly mined coin in to realize the profit being calculated since the value of a coin can fluctuate? Or is there a form of "dollar cost averaging" going on here (though DCA only has one independent variable and profitability has 2 or more)? The assumption is that you immediately convert your coins to the more desirable coin (In this case BTC). I realize that prices fluctuate, but that is a problem if you're manually switching your miners as well. I am simply automating the process. |
|
|
|
I have another request for the multi-port settings...
You have it mine LTC, however, it takes HOURS and HOURS of mining, with the current available hashing-power. Sure, you COULD hit a block once you switch everyone over... but you "switch" too fast, to another pool, and leave the actual "mining" to the few who are dedicated miners in that pool. (Eg, you are pool-hopping in a bad way, on your own server.
It's not really the same as pool hopping. Pool hopping is when you mine right after the beginning of a new block, on a proportional reward system, then hop off to another pool that just found a block, always hoping for a quick block. If a quick block is found, you get a larger than average reward, and if not, you are still paid for the shares. PPLNS avoids this issue by dropping pool hoppers' shares, but only when the pool takes longer than N to find a block. If the pool finds a block in less than N shares, the pool hopper still gets paid for their shares. On multipool, we do not generally have this situation. The multiport miners come in and out and submit shares over the course of the whole block. Once a block is found, all miners are paid based on the shares they submitted over the round. It's certainly possible for multiport shares to be dropped, if LTC winds up being profitable only during the first couple hours of a new block and the block turns out to be a long block, but this is not going to be the situation the majority of the time. I would suggest...
1: Do not hop into a pool where you can not find at-least ONE block in 30 minutes. Based off your hashing-power/difficulty of your traveling pool-members + steadfast pool-members. (Eg, if you estimate that your total hashing-power would result in NOTHING found in 4 hours, mining there... then ignore that pool from the hop.)
On the other hand, we wouldn't have found those two extra LTC blocks yesterday without the multiport miners. It's a double-egded sword -- the single port miners might not like sharing their rewards with the multiport miners, but if more blocks are found due to the increased hash rate, the rewards should even out. 2: Re-calculate only after 10 minutes, and only AFTER at-least ONE block has been found in the pool you are in now, before hopping to a new pool. Thus, your pool-hoppers will have actually "earned" that collected share value. (As opposed to staying in a pool for 10 min, not having found anything, switching, and HOPE that someone still there mining, does find a coin, and now has to split it with the swarm that just sucked-up his/her efforts.)
Most pools other than LTC find multiple blocks in 10 minutes. 3: Offer us an "auto-convert", for those coins we don't actually want, into a coin we do want... (LTC/BTC, etc...) You could do that internally, though a little complex, it saves us from having to collect coins we don't wish to support. Plus, gives us the "immediate" reward for the "mining value" which we were mining for.
No, I'm not going to do this. I have no interest in being an exchange. See if you can get an exchange operator to implement auto-sell. Then you can set a low threshold and send all your mined coins direct to the exchange to be sold. Or you can just write a bot to do it. 4: Don't move both pools at once, stratum and getwork. Move getwork first, since there is that delay... then move stratum, or create another pool to split the larger stratum, and delay each entry/exit from pool to pool. Makes less of a "shock" to the system and traffic-collisions/routing.
I'm not sure what problem this is trying to solve. Can you elaborate? 5: Since "you" are moving us... you should get that PPS&PPLNS with a 50/50 setup done, ASAP. Since PPLNS is intended to STOP pool-hopping. (I would not do PPS 100% until another 100-200MHs are added to the pools. They are coming soon! You just have to creatively show them the value over BTC and LTC mining... In your signature perhaps... Simply show/say... 3200KHs = $550 USD a month, mining scrypt-coins at MultiPool.)
Thanks for the suggestions, I appreciate the constructive feedback. |
|
|
|
is there any way to show my payouts?
Or just the last one..
Not at the moment, but it's something that I'm going to be implementing soon. |
|
|
|
I've started mining with multipool.in:7777. It appears to be working and communicating well. It has been 2 hours and I'm not seeing any updates in My Stats.
Did I do something wrong?
What's your username? |
|
|
|
I've been mining on 7777 for just a few hours now and I noticed that it switches coins a lot more than I would have expected. It would seem some kind of smoothing algorithm could help that. But the real question is - what does this do to the PPLNS calculations of the coin pools, since that is designed to discourage hopping.
Don't get me wrong - I love the idea of having an automatic way of switching to a more favorable coin (though there may be other criteria than instantaneous profitability to use to base the switch on). I'm just wondering what other considerations we might need to make beyond PPLNS (like expected time to next block) in deciding when to switch (or when not to).
This could be an interesting community discussion!
Right now there isn't any smoothing at all. It's definitely something that I can look at in the future. The last N for most of the coins is so low that the PPLNS hardly matters. But for LTC, you are talking about an average of around 2.5 million shares per block, so your shares aren't going to fall out of the last N that often. If that does happen, it means that the LTC pool is having an extremely long round, which means you were probably better off mining a different coin anyway. |
|
|
|
Any chance of NovaCoin (123% profitability) or BBQCoin (147%) to be added to the pool?
Seems like SXC is going away, so there is one slot to replace it with something.
NovaCoin is even traded on Btc-E
I've been thinking about adding NVC for a while. BQC we had for a while and never found a block. I wasn't able to find out whether it was a problem with the client, the pool software or what. |
|
|
|
I changed my donation percent on the details page, but it does not appear to stick. Unless it's in the background.
It would be helpful to actually see a transaction page that shows our donations.
If the 7777 thing works out I would donate something for the server. I want to see if I actually make more per day with this than with picking a coin in the AM and again in the PM like I had been.
It was changing in the DB but wasn't immediately displayed correctly upon refresh. This should be fixed now. |
|
|
|
The reason you have a loyal TRC following is the only other pool I know of is Coinotron, except for BTC, SHA256 coins are woefully serviced.
Why not make a SHA256 and a scrypt version of the pool?
I would like to see TRC in rotation with PPC and BTC. That should attract a fair few from the new crop of smaller ASIC owners.
Yes that is the eventual plan. PPC needs some changes to both the mining software and the frontend, I believe. We don't have a snowball's chance in hell of finding a BTC block in any reasonable amount of time until we have around 500GH on SHA256 though. Quite true, BTC can take days, NMC is another SHA256 candidate, I don't mean merge minied, just mined by itself. I think that could be popular too. [/quote] I don't see why anyone would mine NMC directly when its profitability is only 6% of Bitcoin's. |
|
|
|
Quite true, BTC can take days, NMC is another SHA256 candidate, I don't mean merge minied, just mined by itself. I think that could be popular too.
Wouldn't it be more profitable to merge mine NMC though? You would still have to find BTC block wouldn't you? - Ernie. I think this is true. |
|
|
|
I have considered going all-scrypt, but we have some very dedicated TRC miners on the pool (it was one of the first coins I offered) and I do want to eventually include BTC once we have enough SHA256 hashrate. As far as your db suggestions, I agree that there could be much improvement on the DB side. But even then, $150 a month is a bit too much for me to keep spending on something I'm not making any money from I may try to cobble together something from the equipment I have available if I don't see much in the way of donations. The reason you have a loyal TRC following is the only other pool I know of is Coinotron, except for BTC, SHA256 coins are woefully serviced. Why not make a SHA256 and a scrypt version of the pool? I would like to see TRC in rotation with PPC and BTC. That should attract a fair few from the new crop of smaller ASIC owners. Yes that is the eventual plan. PPC needs some changes to both the mining software and the frontend, I believe. We don't have a snowball's chance in hell of finding a BTC block in any reasonable amount of time until we have around 500GH on SHA256 though. |
|
|
|
FYI: You can buffer and compound multiple DB updates to the same table, if you use temp-tables to "hoard" the micro-updates. (Talking about shares that are slightly smaller and more realistic to less-loss.)
BTW if you have python code to do this I'd be interested in seeing it. The current pool software already writes shares in blocks (I've upped the minimums on this recently which should help with performance) |
|
|
|
How the heck do we setup multiport for scrypt and sha-256 at the same time. (Terracoins are sha-256 and run like crap with sha-256 settings... not to mention, cgminer is setup for scrypt for the login...)
This is impossible. You can only configure a miner instance to mine SHA256 or scrypt coins. It can't switch between them. Just curious, because that would result in possibly valid scrypt-hash-shares being returned if you check them for scrypt-validity, but would never result in a valid sha-256 block ever being found.
Or am I missing something, like a special tool that connects and auto-switches video-card profiles/settings and miner-types from scrypt to sha-256?
Personally, I would drop terracoins, because they are sha-256, and will soon be invaded by someone with an ambitious THs army, to pump-n-dump BTC that is failing them in the future. Thus, degrading any holdings and earnings for us GPU and CPU scrypt-miners.
You have a theme, stick with it. "Scrypt-Mining" Get every scrypt-mined coin that exists, to be included in your pool. (Once you get that new server setup.)
FYI: You can buffer and compound multiple DB updates to the same table, if you use temp-tables to "hoard" the micro-updates. (Talking about shares that are slightly smaller and more realistic to less-loss.)
Another trick is to use PHP's built-in MySQLite as the unhindered multi-table. Every Nth or EndRound, you make one update to the real database, which could be a remote DB sent just the table-update info. Since it is just WRITE/APPEND and not REPLACE/UPDATE, for share counting.
I have considered going all-scrypt, but we have some very dedicated TRC miners on the pool (it was one of the first coins I offered) and I do want to eventually include BTC once we have enough SHA256 hashrate. As far as your db suggestions, I agree that there could be much improvement on the DB side. But even then, $150 a month is a bit too much for me to keep spending on something I'm not making any money from I may try to cobble together something from the equipment I have available if I don't see much in the way of donations. |
|
|
|
|
Well I just got the Amazon bill for last month. $152.. And the instance we have is practically at its limits.
So, I'm soliciting donations now for a new server. Looking at 8x2.5GHz, 32GB memory, and SSD for storage. I figure we need about $2k to get something that will last 3 years or so and will allow me to add as many different coins as you guys want.
I'm planning to create a 'donor status' on the site and put a special icon next to people who have donated. In the future, there will be additional benefits for donors.
|
|
|
|
|
Show Posts
