|
By the way, the MEC transfer is still confirming (it has 1 confirmation so far). Hopefully the difficulty will adjust downward soon so more blocks can be found, and the transfers will speed up.
If it hasn't confirmed within a few hours I will start doing manual withdrawals from the cold wallet for anyone who needs their MEC right away. (Or to at least see the unconfirmed transaction right away)
|
|
|
|
|
The TRC pool should be accepting connections again now. I'm not sure why the TRC pool hashrate isn't updating properly and I don't have time to look into it right now, but shares are definitely being recorded in the DB and user hashrates are updating correctly so you should consider this a display bug.
|
|
|
|
Correct but not so correct, coz first check what suck exchanger you can use and than check how much fee it will take from you... For example I had 2 coins that both was less from this fee... It's rediculous!
And all day I try to cashout, Finaly it's done. MEC was last before few mins... (the banking is faster...) and now how much time I will wait for confirm deposit to exchanger, no one know...
P.S. My best profit coin can't be cashout, coz less from 1 so I will go to make it ~1 and than I will out from this pool ! I can back if they add easy for use integrated exchanger or if use only coins from 1 exchanger... I can't pay 0.005 BTC when have profit 0.0045 BTC... I can't pay 5 times fee for 8 coins and than they said me we have no fee...
What fee are you talking about? We have no fees and one of the lowest withdrawal thresholds of any pool that I know of. I'm sorry you had a bad experience, if you like I can send your balances manually to you. |
|
|
|
does profitability 2.1, for instance, mean 210% of btc?
Yes that's correct. |
|
|
|
|
DGC should have plenty of coins in the hot wallet now.
I'm sending over another 5000 mec, but please be aware that the MEC blockchain is running very slowly now because nobody is mining it after the reward halving. Hopefully the coins will show up soon.
|
|
|
|
the Caps arrived at their destination .
thank you for your support in this matter.
hopefully with a new client and some work these things could be resolved in the future .
Good. I'm glad.  I'm not a dev of CAP but I honestly believe an attack on any coin is an attack on altcoins as a whole. And I don't want to see people lose money because of the actions of these tech bullies. -Merc This is the first I'm hearing of an attack on the CAP network. Could you please post the link? No one knows what happened or how it happened. And there was talk that maybe there was an attempted attack while multipool switched to CAP (because the big jump in network hashrate would camouflage an attacker). But pure speculation and nothing more. So when this guy said his coins went through, I was glad that an 'attack' or whatever it was didn't cause him to lose his coins. I should have quoted the word 'attack'. Good news is that PoS blocks should be kicking in and security of the network will be increasing by each minute. Cheers! Not very likely, we have been on CAP for 3 or 4 days now at least hourly. |
|
|
|
I suspect there's a bug in the Profit Snapshot. I used Burnside's LTC Profitability Calculator and enter my donation as the fee and zero for electricity and my average scrypt hashrate to get a daily value and converted to BTC. The Profit Snapshot is 2.5x higher.
A few days ago it was pretty reasonable so I think the bug is recent.
Mine has actually seemed low recently, but I have spent a bit of time playing LoL on my main PC so that might be why. That said, mine does not seem totally out of whack. PM me your numbers and I'll take a look. |
|
|
|
Hi Team
For some reason my stats are off by approx 1500kh/s, my cgmiers for 10 PC's total 8700kh/s but multipool is reporting only 7200kh/s, is there anything I can do to optimise it or do I need to jump onto the 2nd pool and setup custom diff for each PC?
Stats may be off right now as some of the jobs just started running on the new server. Give it about 20 minutes. |
|
|
|
i can remember a while back i saw a block confirmed on silverwolfs pool. and 5 mins later the same block confirmed on bottlecaps pool! I expected to see it become an orphan but it didn't! I didn't know enough about how mmcfe worked so i didn't question it. the block if i remember correctly was 21090..
what really made me suspicious was that the block was mined by user torispelling.
That bitch... |
|
|
|
If you want the price of a coin to go UP, you need to give people something to do with the coin other than dump it for BTC.
True, but I think the discussion here is to protect the coin against issue (e.g. bearish pressure) coming from its own mining process. Finding ways to make the coin go UP on the market is a whole other subject. Ensuring profits for speculators is not a miner or pool operator's priority and really should not enter into our concerns in any way.
Who will keep buying a given coin in large quantity if speculators have no room left to operate? Please don't kill the goose  I understand most are not to be concern about this on short term. I just hope a coin developer is observing and willing to try to experiment about this. It might make a difference on long term. We only mine coins that people are willing to buy. If people stop wanting to buy a coin its value and profitability will go down and we won't mine it anymore. See PXC. Right now there are many competing coins and many speculators who want to diversify into them. The cream will rise to the top, the dregs will fall to the bottom, just like any free market system. |
|
|
|
What I proposed a an error handler for a sudden increase in hash rate in the DGC thread was: My solution to the hash rate burst problem is simple, reject blocks that try to be added to the chain faster than a predetermined rate. So you are introducing a minimum gap between blocks.
Say a DGC miner finds a new block and want's to submit it to the block chain, the digitalcoind would check the current time against the timestamp on the newest block of the chain and if less than 15sec had elapsed, it would not submit the block. Also the copies of digitalcoind peering, would not accept any blocks to be added to the chain unless their timestamp was at least 15 higher than the highest timestamp in their copy of the block chain, but not higher than the current time. (to avoid cheats) For ARG you would probably make it a 25 sec minimum gap between blocks.
You would need to calculated difficulty slightly differently, it would be based on the ratio of blocks that were submitted exactly at the 15sec mark rather than the 20sec target. Some testing and tuning would be requited. 15secmin between blocks might be too long for a good difficulty calculation, perhaps 10sec. So you would multiply the times by 3 to suit CAP since DGC is 20sec block target and CAP is 60sec. This would not be easy to implement since you can't guarantee that all nodes are going to be within 15/25/whatever seconds of each other. |
|
|
|
|
If Multipool ends up being on the chain that is kept, we will donate some CAP to the miners that were other chain to help make those miners whole. I don't like seeing other pools' miners lose money any more than my own.
|
|
|
|
Last night when I checked Cryptsy wallets verns pool and Multipool all appeared to be on the same chain. The biggest pool to be on the shorter chain was Epools
Epools and Silverwolf combined had more hashing power than the BigVern pool, but the difficulty was higher at the BigVern chain indicating there was some other hashing power on that chain, most likely Multipool. Yes i could verify this by the gaps in blocks found on verns pool. When multipool switched they would push the chain further ahead of the other. When the difficulty rose it would switch off and it lowered they returned. Have the other pools checked their addnodes? Are the addnodes in post #1 still valid? I can only seem to connect to 2 of them. |
|
|
|
Last night when I checked Cryptsy wallets verns pool and Multipool all appeared to be on the same chain. The biggest pool to be on the shorter chain was Epools
My transfers and my miners' transfers are not showing up on Cryptsy, has he disabled deposits? |
|
|
|
The coin will die if he kills cryptsy chain..
It deserves to die then. Release Bottlecaps 2.0 with a longer block confirm. |
|
|
|
I'd say the truth is the dev doesn't know what caused the fork.
Interesting how the finger pointing started before any investigation was done.
We do not know if it was caused directly by multipool. The timing just seemed to perfect for it not to be. It is not any easy decision choosing the chain to be considered valid. Since the only exchanges to currently trade the coin are on the same chain as you we are going with the longer chain. Multipool and Cryptsy are not on the same chain. If you are keeping Cryptsy's chain you are orphaning all of my miners' blocks. The chain that had the most nodes should be the one considered valid, not just the one that the exchanges happened to be using. I predict your coin will suffer serious credibility issues if you keep the smaller chain as you will be screwing over a far greater number of miners. |
|
|
|
...
Do you think there is any problem in a big pool (or a big mining rig) targeting a new coin, take profit and leave when it's not profitable?
Personally, I am concern about automating the mining/dumping part... with some synchronization at a large scale. I have observe the effect of this on CAP for days. The sell orders are constantly filled, so both price and difficulty get into a cycle of reduction. It remains profitable from a miner standpoint, but it stink from an investor/speculator perspective. On long term, that can't be good for everyone. I am not as much concern about the size of a given pool (and the fork thing which might be another matter). More automated service will be created and it is now becoming easier to collectively target the same coin. Coinchoose was just the tip of the iceberg. Solution? ====== Making newly minted coin "special" may address the issue fairly. It will not matter if being produced from a large automated pool or not... it is all about making it harder to profit from mining/dumping systematically. If you want the price of a coin to go UP, you need to give people something to do with the coin other than dump it for BTC. Ensuring profits for speculators is not a miner or pool operator's priority and really should not enter into our concerns in any way. |
|
|
|
Can't seem to cashout MEC. Other coins seem fine. Doesn't give any message like "Please try again later". Doesn't say anything.
Auto payout not working either.
I sent 3000 more coins to the MEC wallet this morning, unfortunately it seems as though the blockchain is stalled, as the transaction only has 4 confirmations. Hopefully the transaction will be confirmed soon so you can withdraw. |
|
|
|
I'd say the truth is the dev doesn't know what caused the fork.
Interesting how the finger pointing started before any investigation was done.
We do not know if it was caused directly by multipool. The timing just seemed to perfect for it not to be. It is not any easy decision choosing the chain to be considered valid. Since the only exchanges to currently trade the coin are on the same chain as you we are going with the longer chain. A pool mining a coin cannot cause a hardfork. The fact that you are even considering a pool as a possible reason for the hardfork, as someone else said, is incredibly irresponsible and suggests incompetence as a dev. Especially when the pool in question had all of your recommended addnodes in the config since day 1. A hardfork is caused by a segmented network where blocks on both chains become fully confirmed. This means that whatever pools were on the other chain were disconnected from the main network long enough to mine and fully confirm blocks. What I suspect happened is that Vern's pool or another pool did not have the right addnodes, but was operating fine for a while because it was well connected. Most likely, their coin daemon was restarted at some point last night, and did not fully reconnect to all the nodes or connected to a different set of nodes that was already forked. Then they continued to mine and fully confirm at least 1 block (which requires 25 confirms) before the two networks reconnected to each other. Multipool and the other pools/solo miners on the main chain had also mined 25 or more blocks. |
|
|
|
Can we defend some little coin if attacker has 3+GHs of power to attack it? Can we defend FTC? No we cant, someone is mining a hell out of it every time he wants to. Only acceptance of coin by many independent miners like LTC has can defend scrypt coin. So when and only when scrypt coin has over than 10GHs it can be resistant. Sorry for CAP being forked, but us small miners wont defend it by not mining on autopilot pools, when someone has the power to fork any time he wants to.
Awesome point. Its free choice if you don't like it don't use it. To the OP: Please quit spreading FUD about high hash rates causing forks. No one and more so the dev of caps has no clue what caused the fork. If you could OP please answer my question since you "know" according to the OP that the increase in hash rate caused the fork, explain how that actually happened? Actually it should be pretty obvious what caused the fork, since there is really only one way to have a hard fork: the network was split into two, most likely because one side didn't have it's addnodes set up properly. I don't blame the dev for not wanting to orphan BigVern's blocks, since if he did that Vern might remove C AP from cryptsy. |
|
|
|
|
Show Posts
