CAPs needs to stop forking so we can get our AUTO BTC EXCHANGE OPTION!!!! Yeah CAP and TRC kept me from adding Cosmoscoin last night, well those and a few games of LoL..
|
|
|
For higher difficulty coins such as novacoin, or more specifically, litecoin, do you think this pool has enough hash power present to actually find a block within the given timeframe before another switch? At current difficulty and an estimated hashrate of 750Mh we have a 51.5% chance to find a litecoin block within 1 hour. I dont know how feesable it would be to foward our hashrate to a litecoin pool large enough to find blocks (or pay regardless) within the timeframe we are mining ltc. Just a thought, maybe you already do this, I dont know. Awesome work on the pool in general and I look forward to seeing it continue to improve!
750 MH is without question enough hashrate to mine litecoin.
|
|
|
CAP is re-enabled on the website but pools are still down until the updated client comes out.
|
|
|
ok, I redownloaded the blockchain several times and now according to the Caps dev we're on the "right" one and our balance is back. But I'm not going to re-enable the pool until the client update that should be sometime tonight or tomorrow.
|
|
|
199.180.115.100
50.137.233.14
Still on the right chain looking into it more now
Well I'm not getting the chain I was on earlier in the day, I had confirmed transactions to cryptsy up till 2 hours ago, the new chain I downloaded is all orphans back to 2.5 days ago. What is the block height of the chain you are on? If it does not match the explorer here http://bottlecaps.kicks-ass.net/block_crawler.phpYou are not on the right chain. When I checked last night multipool was on the correct chain. Unless there is a new fork that just occured 2.5 days ago that you just switched over too, when you get on the correct chain the tx's from the last 2.5 days should be valid Ill be working on 1.4.1 and wont stop until it is finished It looks right now.. My balance is back.
|
|
|
199.180.115.100
50.137.233.14
Still on the right chain looking into it more now
Well I'm not getting the chain I was on earlier in the day, I had confirmed transactions to cryptsy up till 2 hours ago, the new chain I downloaded is all orphans back to 2.5 days ago.
|
|
|
Why do I no longer have an option to withdrawl CAP? (Bottlecaps) It was there earlier today, now it is missing
Thanks
see news
|
|
|
Looks like CAPs is forked again. Removed from multiport and all CAP pools are down until this is sorted.
So what happens to our coins if we still had a balance on the Multipool? I have 6000 coins in the cold wallet, we'll have to wait and see which chain is picked again, wait for the client to be updated, and then see how many coins are in the hot wallet. Right now, the pool owes approximately 10,000 CAPs to miners, so there's a deficit of about 4,000 from the blocks from the past 3 days that are currently showing as orphaned. However, I believe we were on the same chain as cryptsy again because I have confirmed CAP transactions to Cryptsy as late as 3pm today (2 hours ago). Best case, if the chain we were mining on becomes the "official" chain again, the pool loses nothing. Worst case, everyone gets paid 60% of their balance.
|
|
|
Still no issues with mine
Block 65866 matching the block explorers using: connect=199.180.115.100 addnode=199.180.115.100 addnode=199.180.115.125 addnode=50.137.233.14
I heard one of the trusted nodes is running the wrong client I'm guessing its not the one I am connected to or the 50.137.233.14. I am also told 1.4.1 will address this as well as add UPNP and should be out tomorrow. Maybe more cap lovers could offer up some good trusted nodes would help the folks with issues.
I can't connect to 199.180.115.100 at all, I just get the following over and over again in my log: send version message: version 60008, blocks=0, us=0.0.0.0:0, them=199.180.115.100:7685, peer=199.180.115.100:7685 socket closed disconnecting node 199.180.115.100 trying connection 199.180.115.100 lastseen=0.0hrs connected 199.180.115.100 send version message: version 60008, blocks=0, us=0.0.0.0:0, them=199.180.115.100:7685, peer=199.180.115.100:7685 socket closed disconnecting node 199.180.115.100 trying connection 199.180.115.100 lastseen=0.0hrs connected 199.180.115.100 send version message: version 60008, blocks=0, us=0.0.0.0:0, them=199.180.115.100:7685, peer=199.180.115.100:7685 socket closed disconnecting node 199.180.115.100 trying connection 199.180.115.100 lastseen=0.0hrs connected 199.180.115.100 send version message: version 60008, blocks=0, us=0.0.0.0:0, them=199.180.115.100:7685, peer=199.180.115.100:7685 socket closed disconnecting node 199.180.115.100 trying connection 199.180.115.100 lastseen=0.0hrs connected 199.180.115.100 send version message: version 60008, blocks=0, us=0.0.0.0:0, them=199.180.115.100:7685, peer=199.180.115.100:7685 socket closed disconnecting node 199.180.115.100 trying connection 199.180.115.100 lastseen=0.0hrs connected 199.180.115.100 send version message: version 60008, blocks=0, us=0.0.0.0:0, them=199.180.115.100:7685, peer=199.180.115.100:7685
Also, won't the connect line prevent addnodes from being used? My understanding was if you have a connect= line, the daemon will ONLY try to connect to that server and not connect to any other nodes.
|
|
|
Looks like CAPs is forked again. Removed from multiport and all CAP pools are down until this is sorted.
|
|
|
So, the blockchain I downloaded now was split at block 62731 (at least, that's the last block we found, after that all are orphans). That block is from 8/6 at 18:59 GMT...
|
|
|
Looks like your connect= node isn't responding anymore.. That might be the reason the network split again.
|
|
|
redownloaded block chain, now my wallet is showing 2.x, coinchoose still showing 1.x, and all our blocks for the past day are orphaned.
|
|
|
Something wrong with CAPS again. Big Verns pool diff is 1.xxx, and Erundook pool is 0.xxx?
My pool is showing 0.71.. Coinchoose 1.145
|
|
|
verify
|
|
|
Hi,
I have started mining TRC, bfgminer is saying that shares are accepted and everything seems fine, however "your detailed stats" showing zeros, more than hour past already
All I can see is below: Coin Speed Shares Confirmed Unconfirmed Estimate TRC 502 MH/s 388 0.1303 0.0000 0.2083
my nick is "oranglain"
above statistic issue resolved, another question is why confirmed and unconfirmed balances not changing please advice
On PPLNS you get paid when we find a block. check https://www.multipool.us/help.php
|
|
|
I found a bug in the Add worker feature on the site.
I was trying to add a worker with name 6870_777 (for my rig that has 6870 & 7770 cards in it). The Add worker button complained that I should try a different name.
I was able to add that worker when I removed the _ character from the name. However, after that I was able to rename the worker to use the name 6870_777 with the Update worker button.
So, either both of those features should allow underscores or neither one..
- Bitmong
Fixed, thank you.
|
|
|
PhenixCoin at that point, but I think it happened also with Feathercoin.
I'll keep monitoring for this issue and report on what coins it happens with.
- Bitmong
This was an issue on PXC and CAP, I have updated the pool config and this should not happen again.
|
|
|
I just started mining on the pool1.eu.multipool.us (I am in Finland), and my hashrate shown on the website is 50-70% of the hashrate CGMiner shows me.
I also get lots of rejects:
GPU 0: 81.0C 3383RPM | 386.7K/378.3Kh/s | A:114 R:89 HW: 6 U:2.55/m I:18 GPU 1: 73.0C 3624RPM | 319.6K/303.1Kh/s | A: 79 R:63 HW:32 U:1.77/m I:18
Rejects show this message:
[2013-08-08 20:57:43] Rejected a615ddd1 Diff 9.86K/64 GPU 0 pool 0 (DBInterface instance has no
Is that some error on the pool software? Unfortunately I cannot see the complete error message from my CGMiner output.
- Bitmong
Look at your hardware errors - compare # of submitted shares to the # of shares shown inside the pool stats - they will much, but you must fix your HW errors before you can expect your hash rate to match to your hashrate at the pool's stats. Edit: what GPUs are you using, please consider increasing thread-concurrency to a higher # At intensity 18 you are going to get hardware errors pretty much no matter what, I suggest max of 13 for scrypt mining.
|
|
|
|