|
This is ridiculous. You do nothing to stop the endless flow of scammy shitcoins, but people posting USEFUL INFORMATION about what pools are available for a coin is now somehow a problem?
|
|
|
|
|
Multipool updated last night, resynced and was synced to the same block as the explorer. Now we're 400 blocks behind and the client will not sync past that.
Please advise.
|
|
|
|
What is the fee for DRK on multipool.us? Question was raised in another thread https://bitcointalk.org/index.php?topic=688510.0 about 20% masternode fee and multipool was not on list of "20% free" pools. 20% plus on DRK makes no point using X11 multipool. EDIT: Inserted link to mentioned thread The masternode fee does not go to the pool, it goes to the masternodes that do the anonymous transactions. DRK fee is 1.5% just like our other pools We take the masternode fee into account when calculating profitability. If multipool does not make own DRK masternode and free his miners of 20% fee like couple other pools did, I think that 20% better X11 competition will prevail over average 10% multipool advantage from mining single coin. Even if we set up a masternode, we could not direct payments to it. We would get paid randomly, and less than once per day. There are over 750 masternodes now and DRK gets 575 blocks per day (one block per 2.5 minutes). So we'd make less than 1 DRK per day on a masternode, divided amongst all the miners. Also, running a masternode does not exempt a pool from payments, that I'm aware of. If that was the case, there would be no reason to run a masternode as 3-4 pools would be taking 90% of the payments. If that's what you're saying, please cite a source for that assertion. Some pools have not yet updated their stratum/wallets and therefore are not paying out the fee to masternodes. Those pools need to update or their blocks will be rejected by the network when the hardfork comes with the next release. |
|
|
|
I'm interested in mining SHA256 on multipool.us, but have some questions regarding Cryptsy integration. Previously I've mined Scrypt on multipools that automatically handle the exchange. I'm hoping to set up a similar kind of "set and forget" configuration because I don't have the time to manage or optimize the exchange process.
I've gone through the Cryptsy integration instructions, including using my API key to populate the wallet addresses in my multipool account. Not all the addresses got populated, but I think that all the SHA256 ones did (which is what I care about). I've also identified the SHA256 coins from the multipool stats page and enabled auto sell (second highest sell bid) for the corresponding coins in my Cryptsy account.
The question is how should I go about setting the autopay thresholds for the non-BTC SHA256 coins on the multipool side? It seems like if there is fluctuation in profitability, these values might become sub-optimal. Further, I'd be concerned that it would be possible for the pool to send to Cryptsy too often, which could be construed as an attack (according to other posts I've read).
Maybe when the Cryptsy integration level is "Full Auto", it handles the thresholds automatically, or otherwise throttles transfers to the exchange? Honestly I don't know what "Full Auto" does nor can I find information about it in the FAQ on the pool site, but I have it enabled for now.
The last question is regarding new coins. When new SHA256 coins are added (which is probably rare nowadays) I assume that any mined coins just sit in the multipool account until such time that I manually add a Cryptsy address. Does the pool notify me about this situation? It would be nice to get an email rather than have to pull the info about added coins from the news feed.
Thanks in advance for any help or suggestions.
Full auto does set the thresholds automatically, but it won't overwrite addresses or set thresholds for addresses that are already populated. You can set up your addresses and thresholds using full integration by deleting your addresses and saving full integration again. On the help page, it lists the minimum withdraw threshold for each coin. These are in place to avoid overloading of exchanges. You can also set daily pay which will send your coins once per day as long as your balance is over the threshold. |
|
|
|
Is there a problem with the EU based stratum server for SHA256?
It's dead most of the time since sunday for me.
Our upstream Bitcoin pool appears to be having some issues on their EU port over the last couple days. When we can't connect, the pool won't accept your connection. This is intentional, to allow you to fail over to your secondary pool. You should always have a backup pool set (US-East is your most likely bet in Europe) in case of issues. |
|
|
|
What is the fee for DRK on multipool.us? Question was raised in another thread https://bitcointalk.org/index.php?topic=688510.0 about 20% masternode fee and multipool was not on list of "20% free" pools. 20% plus on DRK makes no point using X11 multipool. EDIT: Inserted link to mentioned thread The masternode fee does not go to the pool, it goes to the masternodes that do the anonymous transactions. DRK fee is 1.5% just like our other pools We take the masternode fee into account when calculating profitability. |
|
|
|
|
PoW ends at 20,160 or is that combined PoW/PoS
|
|
|
|
The reason I stopped mining at multipool for a while was because bitcoin mining would randomly go down for hours at a time. My miners would stop mining, and that is just loss of profit. I just checked my mining stats on multipool, and it shows I am mining at 0 Mh/s.
I thought it was a problem with my miners, so I checked on them, and they are still mining. So what is the problem actually?
Are you sure your miner had not failed over to a backup pool? |
|
|
|
I used to mine on multipool and the difference is in the shares received. What happens is that when they mine BTC, they don't have enough hash rate to solve blocks. As a result, they act as a proxy between you and another pool. Originally they mined BTC on P2Pool, but due to variance they have changed. I know they have mined at both eligius and ghash.io too. Now because they are a proxy, they submit your shares as their own. So as a result, the pool they mine BTC on gives them higher difficulty shares, because they submit each server as one worker I believe, than you'd receive if you mined with the pool your being proxied to directly. The low difficulty pool is for those that have a lower hash rate so that they aren't trying to solve high difficulty shares. I hope this helps answer your question.
BTW, I know this information is available at least in their thread, if not their website too. You might just have to look for it.
I actually noticed about a week ago that they were mining on Bitminter. Actually, we didn't change from P2pool because of variance. We were fine with the variance. We changed from p2pool because despite using the fastest processors available, eventually as our hashrate grew, our modified version of p2pool that allowed custom difficulty setting could not keep up with our share volume and our efficiency was suffering. |
|
|
|
No, this is just example I put together to get wanted result. We don't send together, we have several sends. In fact, after each JSON string, we have separate send call for \n. And in real case scenario I observed that first JSON string is sent without \n, then second JSON string has \n pre-appended and one \n at the end. Even though in code, it is being done 2x send+send. This is TCP protocol and you have no control over how data is being split among packets - this means you should never rely on PACKETS in TCP, but read it as a STREAM! If your software reads them as packets, then this is very very wrong.
Your software should not parse JSON line until \n is received. If we follow this logic, then first line is parsed with some result (in this case, diff adjusted + reply + mining notify sent), then it is time to parse next line, which is authorization. Your software does something terribly wrong, because as it seems, it parses both lines at the same time (maybe due to multithreading?) or even worse - it parses line that comes second first. I can't judge that, because I have no idea what kind of software you use.
So in summary, let me see if I understand correctly: ipominer used code that works with existing mining software and called it good. Since it worked with 100% of clients 100% of the time, there was no reason to do further testing, right? From my understanding, there's really only a small handful of different mining software out there. Sure there are many versions of sgminer, but the original neworking code is probably all the same from the first version (no, I didn't check this myself - that's just a guess). It just so happened that (nearly?) all software out there sends the initial subscribe and authorize requests in the same way - probably ending up in two separate packets. nicehashdev used an implementation that was slightly different than most (all?) pre-existing miner applications. Instead of those initial subscribe/authorize requests being sent over the wire in two packets, they were sent in a single packet (as is the case in that C# example). I know nicehashdev said they use separate sends, but it seems whatever they're doing ends up combining messages as in the example. In any case it doesn't really matter, and I'll focus on the example given. nicehashdev is correct that networking communications data must be treated as a stream and not as individual packets. Data could be split/combined in ways you can't control over the internet - there's no guarantee that data will arrive in the same 'chunks' they were sent. There IS a guarantee, however, that the bytes arrive in the same order as they were sent (this was mentioned earlier). I tried out nicehashdev's C# example (both subscribe & authorize sent in a single packet) and sure enough the response received was the low diff, then the high diff (received all in a single packet  ). However, splitting the initial subscribe/authorize Send() into two different sends (no pause in-between) resulted in a response with the high diff, then the low diff. Exactly the same data was sent, but splitting the data into two send events (and therefore packets) resulted in the 'proper' response. I've dealt with this kind of problem before in my own experience with network coding. The issue is always in how I read the data - not how it was sent. I always have to remind myself that the receiving end needs to treat the incoming bytes as a stream - never as a 'packet'. Therefore it is my conclusion that nicehashdev is correct and that ipominer's implementation does not correctly parse the received data. This also explains why other pools don't have this issue with NiceHash. The situation isn't helped by the fact that the stratum protocol documentation is kinda poorly organized. Seems like programmers are sort of forced to test their code by comparing it to how other preexisting implementations handle things, rather than coding according to the documentation (hard to do since it's seemingly spread out in an unorganized fashion). Frankly I'm surprised these sorts of problems don't pop up more often. Python stratum-mining doesn't have an option to decide how it processes packets. It runs under twisted and all of the json code is handled by the stratum package that was written directly by slush himself. If a miner can connect fine, and then nicehash puts something in between the miner and the pool that makes things stop working, it seems to me it's nicehash's problem and responsibility to fix this and if he needs to involve the pool owner he should be respectful and not try to shift blame by calling out the pool in public like he has. To my knowledge there is no contract between nicehash and ipominer and if nicehash does not give the user a choice in pools then they are responsible when things don't work. |
|
|
|
|
This service abstracts the pool it's mining on away from the end user and out of the user's control, correct?
|
|
|
|
HELP PLEASE
What do i alter in my config file to mine Scrypt-N profit switching ?
I put the URL in and have kept ALL settings for my 5 GPU's as normal for mullticript mining.
Just checked and i am mining LTC at 200k when i was mining standard scryot at 3Kh ??
What am i missing guys ?
Thansk
Scrypt-N requires more than just altering a config file. You need to download vertminer or an sph-sgminer version that supports the Scrypt-N algorithm. Assuming you have done that you can mine Scrypt-N by setting your algorithm to Scrypt-N and connecting to port 12222. |
|
|
|
All I will leave here is proof what happen ed when NiceHash connect ed to Ipominer. {"error": null, "id": 0, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f800539c", 4]}
{"params": [0.032768], "id": null, "method": "mining.set_difficulty"}
{"error": null, "id": 1, "result": true}
{"params": [1.572864], "id": null, "method": "mining.set_difficulty"}
{"params": ["9a12", "0ba33752363c1a2ebf6c2304a0a0b9c54397b3db081e297a0013b53e00000000", "0100000027b5c253010000000000000000000000000000000000000000000000000000000000000 000ffffffff1f0245050435b5c25308", "0d2f7374726174756d506f6f6c2f000000000100203d88792d000023210305f73d52e4778d2a584 727c5cad357d544151df9addb44ca41fd668fec9dfe44ac00000000", [], "00000006", "1b23ab19", "53c2b527", true], "id": null, "method": "mining.notify"}
As you can see, Ipominer first sends low diff, then high. Claiming that other software works fine is pointless here. Your stratum should NOT do what it did, under any circumstances. EDIT: Using past tense, because we applied temporary fix to get rid of this case. In fact, this problem can *only* happen if the proxy is reversing the order. Sending low then high would not be a problem for miners. The miners would get some share is above target messages because it would be holding some low difficulty shares in its local queue. Then it would start submitting higher difficulty shares. In this case, the miner thinks the difficulty is set to the high level, but the pool thinks it's set to the low level. This can *only* happen if the proxy is reversing the order. Yes, it would be all okay, if pool considered shares being only over 1.572864. But it turned out, that it considered shares to be over 0.032768. Our proxy sent only shares above 1.572864, and only few of them were sent (due to being high and rare to be discovered) which resulted in low speed on the pool. Yes, and the only way this can happen is if the pool and the miner are confused about which is the current difficulty. And the only way that can happen is if the order of the set_difficulty commands is being changed by the proxy. How could it be? This is what we got from Ipominer - in order as I posted. And you will get same order with the short example program I posted, if you don't believe me (unless they fixed it by now). That obviously isn't the case, since the only way for the situation to happen in the first place is if the order is getting reversed by the proxy. The pool remembers the last difficulty set and credits shares based on that. |
|
|
|
All I will leave here is proof what happen ed when NiceHash connect ed to Ipominer. {"error": null, "id": 0, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f800539c", 4]}
{"params": [0.032768], "id": null, "method": "mining.set_difficulty"}
{"error": null, "id": 1, "result": true}
{"params": [1.572864], "id": null, "method": "mining.set_difficulty"}
{"params": ["9a12", "0ba33752363c1a2ebf6c2304a0a0b9c54397b3db081e297a0013b53e00000000", "0100000027b5c253010000000000000000000000000000000000000000000000000000000000000 000ffffffff1f0245050435b5c25308", "0d2f7374726174756d506f6f6c2f000000000100203d88792d000023210305f73d52e4778d2a584 727c5cad357d544151df9addb44ca41fd668fec9dfe44ac00000000", [], "00000006", "1b23ab19", "53c2b527", true], "id": null, "method": "mining.notify"}
As you can see, Ipominer first sends low diff, then high. Claiming that other software works fine is pointless here. Your stratum should NOT do what it did, under any circumstances. EDIT: Using past tense, because we applied temporary fix to get rid of this case. In fact, this problem can *only* happen if the proxy is reversing the order. Sending low then high would not be a problem for miners. The miners would get some share is above target messages because it would be holding some low difficulty shares in its local queue. Then it would start submitting higher difficulty shares. In this case, the miner thinks the difficulty is set to the high level, but the pool thinks it's set to the low level. This can *only* happen if the proxy is reversing the order. Yes, it would be all okay, if pool considered shares being only over 1.572864. But it turned out, that it considered shares to be over 0.032768. Our proxy sent only shares above 1.572864, and only few of them were sent (due to being high and rare to be discovered) which resulted in low speed on the pool. Yes, and the only way this can happen is if the pool and the miner are confused about which is the current difficulty. And the only way that can happen is if the order of the set_difficulty commands is being changed by the proxy. |
|
|
|
All I will leave here is proof what happen ed when NiceHash connect ed to Ipominer. {"error": null, "id": 0, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f800539c", 4]}
{"params": [0.032768], "id": null, "method": "mining.set_difficulty"}
{"error": null, "id": 1, "result": true}
{"params": [1.572864], "id": null, "method": "mining.set_difficulty"}
{"params": ["9a12", "0ba33752363c1a2ebf6c2304a0a0b9c54397b3db081e297a0013b53e00000000", "0100000027b5c253010000000000000000000000000000000000000000000000000000000000000 000ffffffff1f0245050435b5c25308", "0d2f7374726174756d506f6f6c2f000000000100203d88792d000023210305f73d52e4778d2a584 727c5cad357d544151df9addb44ca41fd668fec9dfe44ac00000000", [], "00000006", "1b23ab19", "53c2b527", true], "id": null, "method": "mining.notify"}
As you can see, Ipominer first sends low diff, then high. Claiming that other software works fine is pointless here. Your stratum should NOT do what it did, under any circumstances. EDIT: Using past tense, because we applied temporary fix to get rid of this case. In fact, this problem can *only* happen if the proxy is reversing the order. Sending low then high would not be a problem for miners. The miners would get some share is above target messages because it would be holding some low difficulty shares in its local queue. Then it would start submitting higher difficulty shares. In this case, the miner thinks the difficulty is set to the high level, but the pool thinks it's set to the low level. This can *only* happen if the proxy is reversing the order. |
|
|
|
What is going on with this pool? seems that the server is not respoding for a long time and that is more down than up lately...
All good here - am merrily hashing away on a number of coins. Our US East provider had network issues for over 24 hours starting on July 3. Everything has been fine since around the early morning on the 5th. |
|
|
|
Master branch was recreated as a copy of 'legacy', 'current' was renamed to 'unstable'.
Update of 0.4.4.6 branch is scheduled tomorrow, it will include recent interface and protocol changes from 0.4.4.7.
Is this related at all to my issue? Sends seem to be working normally again on 0.4.4.6. |
|
|
|
|
I'm still getting the conflicted transactions with v0.4.4.7-nvc-bugfix5-beta afer redownloading the blockchain.
Also, now the entire balance disappears and doesn't come back unless I do a -salvagewallet or a -rescan.
|
|
|
|
|
Multipool's EU node is updated with the stratum changes. If there are no issues over the next couple days with block finding, we will roll out the changes to US-East and US-West.
We did test the changes on testnet, so we do not anticipate any issues.
|
|
|
|
|
I'm getting these errors now with a brand new wallet that has no transactions other than 2 transfers to it.
"account" : "",
"address" : "4PNf73X2L9iUm3cE6tvFq919XrHeiEmPtQ",
"category" : "conflicted",
"amount" : -0.18378200,
"fee" : -0.01000000,
"confirmations" : -1,
"txid" : "6d67a895afe4d077ccf62351c2263295c2fe312ed80e6fdefe259beff64c97e4",
"metahash" : "8ae7e84de3445781bc15194f09813f3c0aae57fb7ee034bf119a1681ae848aa7",
"walletconflicts" : [
"cc5699d0dd84468665d693751646bf497b921b68a78163691947c5bb09d51c36"
],
"time" : 1404720093,
"timereceived" : 1404720093
WTF is going on? am I on a buggy version? What version should I be on?
|
|
|
|
|
Show Posts
