This is a common misunderstanding. Pool hopping usually is automated. So you just leave the pool hopping software alone and let it run 24/7.

Probably not, back when eligius was proportional there was a delay as well.
It's a bad thing to have a lot of small transactions for payout, because when you spend the coins later, you have to pay higher fees and it pollutes the block chain.

Something just came to my mind that could shorten the payout queue, although I'm not sure if it works, and it seems rather dangerous to do. Why doesn't eligius put transactions with a very high fee (input: maybe 50BTC, output: maybe 0.01BTC, fee: 49.99BTC) in its blocks. The fee should be available in the generation transaction instantly and can be used for >50BTC payouts. Just need to make very sure that transaction is not broadcasted to the network for other pools to pick up..
And now that I mention it, of course: it's a bad idea, because the block might be orphaned later and then others can put the transaction into their own block.

Thanks for fixing the bugs really fast! I appreciate it. And get well soon.

I also thought about creating a test suite to check for these kind of problems (could be useful for other custom pools, like AFAIK bitp.it). I have been digging through the Diablominer source some time ago, and I guess it's possible to use it (if the license allows to do so). It will probably get "a little" cluttered..

Wow, that's where I'd probably stop mining at eligius if I had my miner there. WTF.

If they do, then they don't believe in freedom of religion as well. I couldn't care less if they stayed away from bitcoin. They can put their own prayers into the blockchain if they feel like it.

I personally don't have a problem with people believing in god or even putting prayers into places where I won't ever find them, even if I'd help doing so by mining at eligius. It *does* bother me what Luke-Jr said about freedom of religion, but maybe I'm just interpreting that wrong.

It's a fact that Luke-Jr's contributions, innovations and Eligius are a win for the bitcoin community. If I'm getting it right that Luke is against letting people believe in whatever they feel like, however, I'm disappointed.

That's great! And thanks, Luke.



Edit to prevent double post:
There seems to be a (or even two more) different bug(s) related to counting invalid shares as valids. This time, I changed Phoenix to submit every share 10 times with a delay of 1 sec between sends (I'm not sure if the delay works, it might send them instantly..). The first share was counted as "valid" two times, and "invalid" two times as well, so a total of 4 shares were recognized. I'm not sure if phoenix stopped sending the share after the 4th time, or otherwise 6 shares were sent but not registered as valid/invalid.

I assume phoenix then found a second nonce in the same getwork, this time producing 10 valid shares. That bug is probably in WorkProxy.java, line ~186.
When the second share of the same getwork is received, "entry.solutions != null" and "entry.solutions.contains(data) == false", so the second share is accepted (this is correct behaviour). However, unless this happens elsewhere in the code, the second nonce is *not* added to entry.solutions, so it can be sent infinitely often and will award a valid share every time.

Moving "entry.solutions.add(data);" below that if/else if should fix this. There's still the problem with the first nonce in a getwork accepted multiple times, but not infinitely often.


Update:
python does not respect my time.sleep(1), so  all the nonces are sent without delay. The problem with identical shares being accepted multiple times could be a race condition. This is from the phoenix log:
The rejects are not logged in PoolServerJ, so I guess they fail because of connection issues (sending 10 shares at the same moment might cause problems in phoenix).

Yet another update:
My suggestion to move "entry.solutions.add(data);" below the if/else if is wrong, it should probably go pretty far down the validation method, maybe after checking the hash. That should fix the double-accepts.
Are "duplicate" rejects not getting logged on purpose? (Omg, I'm spamming this thread, sorry!)

I sent it, but so far no response.

I'm a little confused as well, because I see the hashing code in WorkProxy.java. But since I'm not so experienced with bitcoin hash targets, BigInter.compareTo and your .getEasyDifficultyTargetAsInteger(), I'm not sure what's wrong!

This is from my properties file, and it's the only line that sets useEasiestDifficulty: (And it is actually a hg clone from yesterday, so I think it was set to false all the time):

Maybe some more details on what I do/get:
 * Start PoolServerJ with empty shares table
 * Start cheating Phoenix (see below)
 * Wait until Phoenix reports "[18/08/2011 15:15:21] Result: b464f013 accepted" (this will appear only once, but phoenix will send 20 getwork-answers)
 * See PoolServerJ log something like this 20 times: "Forced work submission upstream: 00000001a55604a05d5f30c4d1784f38bd1e1389f3[..]" with slightly changed nonce each time
 * Now PoolServerJ logs 20x "work submit success, result: false"
 * A few seconds later, PoolServerJ flushes the shares to MySQL and indeed, 20 valid shares are now in the table

(I'm not sure if this indicates there's another problem somewhere, but a lot of "RETRY" is sometimes mixed into the debug log output)


I'm using a pretty old SVN checkout of phoenix (I prefer poclbm, but I had a phoenix start script for localhost sitting around, so I used it), it's r101 I believe. However the newest git should be fine as well:
https://github.com/jedi95/Phoenix-Miner/
In KernelInterface.py, change foundNonce.

Original code from git:
Cheating code (as always with python, tabs/indents are important, not sure if this was copied correctly):

Edit:
Are you sure Res.getEasyDifficultyTargetAsInteger()=115792089237316195423570985008687907853269984665640564039457584007908834672640 is correct?
I thought it would be 0xffff0000000000000000000000000000000000000000000000000000 for a difficulty-1-share, or 26959535291011309493156476344723991336010898738574164086137773096960 according to wolfram alpha.

Yes, I've seen those libraries. It's very nice of you to open source PoolServerJ! It seems to be a nice piece of software. No need to send me a permission, I simply asked because I was wondering what "no derivative works" means (and why the source code is public then). Now it's all clear, the license has not been updated and it used to be closed source.

I've tested PoolServerJ and so far I'm impressed. The possibility to write your own sharelogger and simply plug it into PoolServerJ with a config file directive is nice. I implemented one that logs invalid shares to their own table (BTW: if "entry.reason == null && entry.ourResult" evaluates to true, is it safe to assume that this share is valid and should be counted for rewards?).

However I'd like to report a bug, or at least I think it is a bug.
I changed phoenix to do this:
So when phoenix finds a share, it takes the nonce and submits it, but then increases the nonce by 1 and submits that "share" as well, and then continues until it has reached nonce+20.

I actually find 20 shares in my table when only one should be valid, and they all have "our_result == 1".
Maybe the problem is with Res.getEasyDifficultyTargetAsInteger()?

This is interesting. I'm wondering, since your license says "no derivative works", what exactly am I allowed to do?

If I wanted to start my own pool and needed to change some parts of PoolServerJ (and let's assume I can't do this with a plugin, so I actually need to change YOUR code), this seems to be a "derivative work". Can I do this? I don't think so. Or maybe it's just forbidden to share my derivate work with others?

So you're saying the stats page is older than the balance shown at my account page.
Since the earnings shown at the stats page sum up to more than my current balance (and no payouts to my wallet happened today), that means the stats page is missing some negative rewards that are delayed and will show up later?

Anyway, thanks for the help, but I don't think this is the problem.

(Also, it's still the same, ~5 hours after I stopped mining)

It can't be the pool fee, because the stats page already takes that into account.

Something doesn't add up correctly for me.

I hadn't used deepbit in a very long time (2 months ), and now submitted a few shares.
From the stats page, I can tell that I should've earned 0.01558598BTC total (I stopped mining more than 1 hour ago). However, my current balance shows as 0.01234512 BTC, even though I had a sub-0.01BTC amount left in there from 2 months ago.

I wonder where the remaining 0.003BTC+ has gone?

Actually, the manual correction is probably not only different for every miner out there based on their location, but also depends on how many other workers are currently connected to the various pools. It's probably a very unreliable method to determine a block finder.

Maybe it's possible to hook into bitcoind and see in which order connected nodes send the new block information. There might be patterns, but I suspect they are not very constant and need to be re-learned often. The learning would probably take a few hours at the begin of every session to recognize patterns of deepbit, BTC guild, and other pools, if there is any difference.

The simplecoin frontend is known for getting block numbers wrong. Ask BurningToad from ArsBitcoin, he uses that frontend (probably heavily modified) as well and tried to fix these problems. Sometimes the simplecoin frontend also misses a found block when two blocks are found within a certain time frame.

Deine Sparkasse hat eine BIC, und dein Konto eine IBAN, die Daten müsstest du z.B. im Onlinebanking finden.

Du hast dann eigentlich keine Adresse.

Allerdings werden alle BTC, die an die Adresse unter "Add Funds" geschickt werden, auf dein MtGox-Konto gutgeschrieben. Die Adresse gehört aber MtGox. Nach jeder Gutschrift auf das Konto ändert sich dann auch die angezeigte Adresse, aber die vorherigen Adressen sollten trotzdem noch funktionieren.

Eine richtige eigene Adresse, über die du 100% verfügen kannst, bekommst du (nerdige Dritt-Tools mal außen vor) nur durch Installation des Bitcoin-Clients. Dann kann auch nicht durch einen Fehler/Hack bei MtGox deine Kohle weg sein, sondern nur, wenn du deine Wallet-Datei verlierst oder ausspionieren lässt.

This.

Ich habe zwar wenig Ahnung von der Materie, bin mir aber recht sicher, dass man Botnets auch vermieten kann, und dann sicherlich zu besseren Preisen als CPU-Mining (oder selbst GPU-Mining).

Ich frage das mal öffentlich, weil es vielleicht auch andere interessiert: Gilt das erstmal auf unbestimmte Zeit, oder müsste man da schon schnell auf dein Angebot eingehen? Ich spiele mit dem Gedanken das zu tun, aber natürlich ist es mit mehr Risiko behaftet als eine MtGox-Auszahlung und deshalb will ich mal abwarten, wie sich das entwickelt.. Und: Müsste ein gewisser Mindestbetrag überschritten werden damit du dir die Mühe machst, oder geht das auch schon zweistellig?