|
The C# getwork/LP backend is now feature-complete and is being tested. If there are no major issues, expect a release of it before Tuesday.
|
|
|
|
Just for the record, I was unable to recover any more BTC. The following addresses of mine hold the secured BTC:
...
18a1RoNu3WRneMimHEUYAB9FTmnhymagW1
The coins that are now at this address belonged to a guy who used his email address as the label for his primary receiving address. I've contacted him and he is in full panicmode (not a native English speaker, so I don't think the "I have your coins, they are safe" part got through completely). So these coins at least are accounted for. This guy has his coins back now. The bulk of the remaining coins came from these two addresses in the same wallet: 18AUW2KuwqiCJVWDTBmBtDj5GPYM2znnWv 1FLSA6bs2iAeZXJ85jBV3bUCq8J7G7XVyk If they are yours, please contact me with some evidence (a copy of your wallet.dat to start and we can work from there) and we'll see what can be worked out. If nobody claims them, I would like the community to decide what should be done with them. I don't want to be a part of that discussion since, by controlling the funds, I have a conflict of interest. |
|
|
|
Been lurking in this thread for awhile now. Most of the issues I've encountered have already been reported by other users and patched, but I have two things I can't figure out:
1) I have a very disparate number of getworks to shares in the pool summary (251 to 26).
The getwork code performs failover after 3 seconds if a pool doesn't respond. This means that a little lag in, say, the DNS lookup can trigger a failover. This will not be a problem with the C# backend since it will keep a queue of a few pieces of work per pool, populated on a background thread. Getworks from a worker will pull off of the queue and trigger the background thread to refill it. 2) I noticed on one of my any of my clients running poclbm that every 60 seconds after starting I get an RPC error before it continues. I haven't seen this on phoenix or Ufasoft's miners...
That's odd. poclbm is all I use and I haven't noticed too many problems with it. I do note that it tends to abort a getwork request after about 5 seconds and try again immediately. This means that poclbm and the PHP failover code are often at odds, since by the time that the proxy fails over to the second pool, poclbm has aborted the request and is trying again. I had noticed for the last two weeks I had an abnormally high number of apache2 processes running (150+) for about 20 active miners. I'd eventually have to restart after apache stopped responding. This seems to have cleared with the changes committed in the last 3 days. Again, also not sure if related.
Hmm, I'm not sure what I could have changed that would fix this. The frequency of requests might be causing Apache to try to keep more HTTP worker processes running to serve them. And if your miners recognize the X-Roll-NTime header (which I just added), that means they will usually only do a handful of getworks per round, and so the number of requests to Apache will drop dramatically. Excellent project by the way. I just wish I hadn't been tainted by coding microsoft.net all these years so I could contribute some code.
I don't think you'd be prevented from contributing to the PHP side of the project.  And since I'm not building a compatible framework (like Mono is), I don't think I really need to exclude MS.NET developers from the C# side of the project either. |
|
|
|
I also just added the new s3.mining.eligius.st pool. For some weird reason, I'm getting a lot of invalid shares :
Submitted duplicate shares 17 4
Submitted stale shares 35 0
Which I don't get if I access directly. Anyone else noticed this behavior? The only thing I can see is that worker use the same login on the pool.
If you ignore the duplicate/stale stats and focus only on the accepted shares, are the numbers very different over time from what you see mining without the proxy? I am wondering if the proxy code that retries share submissions on errors is successfully submitting it the first time, but thinks that there was some connection issue and tries again, thereby giving you a duplicate or stale share but also correctly giving you the one accepted share. |
|
|
|
Just for the record, I was unable to recover any more BTC. The following addresses of mine hold the secured BTC:
...
18a1RoNu3WRneMimHEUYAB9FTmnhymagW1
The coins that are now at this address belonged to a guy who used his email address as the label for his primary receiving address. I've contacted him and he is in full panicmode (not a native English speaker, so I don't think the "I have your coins, they are safe" part got through completely). So these coins at least are accounted for. Just for the record, I would like to give you props for your efforts. You are awesome.
I'm just doing what I would want someone else to do if my wallet were stolen. |
|
|
|
try to update to latest version now Current database version is 2. Attempting migration to version 3.
Migrating 2 -> 3 ...
The work_data.data column cannot be shrunk because that would result in duplicate primary key values. Please truncate the work_data table and try migrating again.
Final database version: 2.
Database migration did not fully complete. Correct the errors displayed above and try again.
: I fixed it by deleting the whole database and import a fresh database and load backup to my worker/worker_pool/pool You could have just done what it suggested: TRUNCATE TABLE work_data;EDIT: I have a workable solution. I was able to successfully submit work with the proxy to MultiPool.
I will discuss the fix further with cdhowie in the morning and see how he wants to go about implementing it.
Did you get anywhere with this? Multipool is currently down, so I haven't been able to review the problem and proposed fix. So no problems with getworks and the like? One card solves something and the others some how knows to getwork again?
I'm not sure what you mean. The mining software is responsible for determining how to allocate work to the various devices it supports. My proxy doesn't know or care how many GPUs you have. |
|
|
|
|
Just for the record, I was unable to recover any more BTC. The following addresses of mine hold the secured BTC:
1BNY74WiVn66PQuQTXkzvRaHXnLMbQz9ww
1EeKfHRc6GTcc4Tv5tVGzWNHv4ERirsSk8
1Pw9CkBC6qSxwDgsPqx3kMmofWj8jLwLXH
18a1RoNu3WRneMimHEUYAB9FTmnhymagW1
I do not have time to work more on this tonight. I'll post tomorrow when I figure out a good claim procedure.
|
|
|
|
|
I currently have 41.91003938 secured. One of the wallets I checked had an email address as the label for a receiving address, so at least I have a lead on who owns them.
Time to commute home, it's 8:30 PM already. I'll try to work through a lot more of these tonight.
|
|
|
|
When refreshing the FTP directory periodically, three .dat files appeared. I have downloaded them and removed them from the FTP server. After starting up bitcoind with them I will report on any addresses they contain that have been seen in the block chain. If they turn out to be your addresses, create a new wallet on a secure machine and spend all of your coins to one of its addresses ASAP.
EDIT: More keep popping up every so often. I am downloading and deleting all that I find.
You might want to also set up something that periodically checks to see if the mal-executable changes. The author may change the destination details. Yup, already doing that too. |
|
|
|
|
Sorry for the slow progress, working as fast as I can.
EDIT: At the request of several people, I am spending all of the coins in each address I come across to a secure wallet on my machine. I will publish a complete list of compromised addresses and where the coins they held are after I finish processing the (growing) collection of wallets that I have. We can iron out claim details later. I have a process fetching and deleting new wallets automatically now, so hopefully he won't get his hands on any more.
Compromised addresses:
Wallet d19dc707da850975d64ebf829286839b615e297f2ba14bb28ad49c48180c0b6b
1CsmP7kZzscr5rofaA7S71NQzkYNABrtEa
1PSDJhCicApNvwMqNgTQ7qJNRPey5ZxZT1
16Ph8yB6wDUbRhQLaF4Vwt2scvE4vr8Fz7
1DTNH4iwfRSY8Hjk7c9WufnsV5p5K653xJ
1DrHGf3iiaXRdi3ZXEDY92JzdYXXamaiJP
1NvMmRzYdSjz5bHRkGbKqBT5W1EeorRkft
Wallet 61f474c86963c05695a5c3edbba67b97faea72c05d79ffd80190b7cc125ee5fe
1BNYWKRvyL6BEyRjN3pzf59a6bJNDykmBc
1CA7ZcXvRL9dC7K4rreb5i5aLqS5qz8zP4
1Cwve9n6PWQhErN7nS56SYGYQEWJAHqqFM
More to come; will update this post as I find more.
|
|
|
|
|
When refreshing the FTP directory periodically, three .dat files appeared. I have downloaded them and removed them from the FTP server. After starting up bitcoind with them I will report on any addresses they contain that have been seen in the block chain. If they turn out to be your addresses, create a new wallet on a secure machine and spend all of your coins to one of its addresses ASAP.
EDIT: More keep popping up every so often. I am downloading and deleting all that I find.
|
|
|
|
Has anybody actually downloaded/scanned their software? I'm not going to be the test case for that!
Yes, two of us on -otc have been tinkering with it. It apparently connects to some FTP site (74.208.186.97) and attempts to download a file... using PORT... so it won't actually accomplish anything on hosts behind NAT. (Not that I can tell.) We have FTP access to that site currently and are monitoring things. Will report more as we learn more. |
|
|
|
diablo doesnt work at all, after a while it the proxy stops accepting shares. Rejected doesnt even show up.
The proxy's lack of support for X-Roll-NTime may have been to blame for this. Pull down the latest code; I just added X-Roll-NTime support about 45 minutes ago. |
|
|
|
What happens if i have a single account on a pool and i create 3 miners on the proxy and point them to that one pool using the same account?
Then the proxy will use the same credentials for all three workers. If pointing all three miners at the same pool using the same account works fine, then pointing them at the same pool using the same account via the proxy will also work. @cdhowie, this app is amazing, but need some work of sql optimization and hash-rate calculator
How so? The hash-rate calculation queries perform very quickly on my install, and EXPLAIN shows that the indexes are used appropriately. Which commit are you running from? |
|
|
|
DiabloMiner does it's time increment thing with or without the X-Roll-NTime header in any circumstance where it would otherwise have to be idle (getworks not returning fast enough, getworks erroring out, etc). So DiabloMiner is going to submit data that won't be found with or without that header at least some of the time.
I can't even find a reference to X-Roll-NTime in the DiabloMiner sources. As long as it only does this when otherwise idle, it's as though the pool didn't support the feature anyway. So the effect will be the same as if DiabloMiner didn't do this at all, since all of those shares will be rejected. Therefore this is effectively a feature request against the proxy and not a bug. |
|
|
|
So I sent a claim in as soon as they brought the page up, I submitted 2 tickets over 72 hours ago and haven't heard a single thing nor received a response from them yet.. It sucks because I had a decent amount of USD in there I wanted to trade with and now I can't do squat, and I don't even know if my money is still on the account of what.
If I don't hear anything soon I guess I have to assume its stolen and go through legal action since it's USD stolen and not BTC?
Have you tried PMing MagicalTux on the forum, emailing him, or chatting with him on IRC? |
|
|
|
|
30-day codes are going for 0.95 BTC right now; PM or contact me on IRC if interested.
|
|
|
|
Hey, guys. I am not sure if bitcoin mining proxy has support yet for X-Roll-NTime and for clients that increment the time header (DiabloMiner), but I added it to my ASP.NET implementation of the proxy last night and wanted to share what I had to do to make it work so that you guys to add it to the original PHP implementation if you like.
I'll add support for this at some point. Right now I'm trying to get the new C# getwork backend finished up. Note that as long as X-Roll-NTime is sent as an HTTP header, the proxy should still work with DiabloMiner; since the proxy will not forward this HTTP header on to the miner, it should think that the pool doesn't support it. If DiabloMiner is assuming that the pool supports it (I can't find a reference to X-Roll-NTime in the DiabloMiner sources) then, well, that's a DiabloMiner bug. |
|
|
|
I'll reply to the rest of the post shortly, but wanted to answer this question before I leave for work: EDIT: Still getting quite fast load on dashboard with this dataset. Infact most of the time in the ms range. At slowest nearly a second. What is the point where people are starting to experience serious performance degradation, all the time?
If you've fetched the latest code and applied the database migration script, then you shouldn't be seeing any degradation anymore. If you didn't, then you would certainly see horrible dashboard performance after a while, as there were some missing indexes that would cause table scans against submitted_work during the dashboard query. (As submitted_work tends to grow slower than work_data -- but proportionally to it -- you'll need a fast miner, or a bunch of slow ones, to start seeing the performance issues quicker.) |
|
|
|
.
Just wanted to point out that this was an empty reply Yes, I wrote a reply and then realized that my reply was incorrect. And since I can't delete my own posts, I just edited it to be empty. |
|
|
|
|
Show Posts
