|
I'm pretty sure this used to work, though it didn't when I just tried...
|
|
|
|
I want to know how many blocks I have solved for your pool. Here it is, but please note this is irrelevant data, and tells you nothing about who might or might not have found a block solo-mining. mysql> select count(*) as blocks, username from shares where upstream_result='Y' group by username order by blocks, username;
+--------+------------------------------------+
| blocks | username |
+--------+------------------------------------+
| 1 | 12N1zD7RDk9FodVJWGu6mm4JxmoPdwZZFw |
| 1 | 14KNFwF8dVoC2r5yyckFTZdfnHAkU4BSxU |
| 1 | 16u6Z8N5zf3GpUwsTApUvMKGw6HZU7h1qd |
| 1 | 17EE2yvRqRk3so48fvk2dtUdBYcB8yMsF8 |
| 1 | 17gvseN698hbmeRKa4NC6LtsJo45oqpF3p |
| 1 | 17MS6qKSXcHwSYf3DFA3rQpXMu6FRHFK1p |
| 1 | 19c8FiddoGnvX7DFXSqLNPTfKtiZ29w6Te |
| 1 | 1C4hgGujvGM9U32r8bhK6XPEwKKmhTSwUY |
| 1 | 1CiWEKiF5J5Xarxu1MMM7YMuZ51xBMs3Bw |
| 1 | 1Dh225PqFhD8eDFzqPoT8j5uhPF2j815Cb |
| 1 | 1DhV9Xf9wfXmngaW2WbjEti8WoRJzrHCC7 |
| 1 | 1DiDC5jb96GR2d5LVsWuSdSB3q5zbns2Bo |
| 1 | 1DYMBjQqcgbaEQ64jVNRDkKSspfqgDXTpa |
| 1 | 1EyB7VhC911SoviLVNKYkodRXEbQgvP7Pb |
| 1 | 1FCuPNz2xAtFV3xnVnMuW3uC4g6xXUngET |
| 1 | 1HA1fNoiFe9D7Kcb7zpA5wY6bbR3FQVn2A |
| 1 | 1HcbN4NTAcUhcXVfgs2KooVhtK6nwUkaog |
| 1 | 1JoSZ1Foc5sXSbmRdTqghgoAtpj9jGZiYa |
| 1 | 1LftD91GtgA8Jicqzp7CsRgFGKesAo4Lrn |
| 1 | 1MmhDAnCKkeJwCbgExnvrL2fk7n1WGM5De |
| 1 | 1NkdAgbMLrcSQZYhXYamg7VBFaUr4Qfk9m |
| 2 | 13CUe6FDXkX7QFwKYCAHeJePZgiuj293Hj |
| 2 | 15xWuDHSyKzpvp6FacGKXijBeaaaYhKWSi |
| 2 | 1GKZ7YBMSquJTwxEuBmvAiuG5dwq3h1CvA |
| 2 | 1QDs3u4NawCmPBfMxWzZARbwjWwEQdTFTd |
| 3 | 1JNuUZmgJ46nFzgM2JeoZiEt2Rn8KpG8zB |
| 3 | 1KoBYhF3uNS5ZvGTd4RNjWc7VbMqQfDwzy |
| 4 | 14rJYeAPkXGDRVeTcEn7czE9xNaU5aRi64 |
+--------+------------------------------------+
28 rows in set (2.77 sec) Has anyone else been having problems with Eligius lately? I'm getting lots of idle miner warnings and RPC connection errors. Apparently a lot of people can't use port 8337, and pointed their miners at port 80. Port 80 was an Apache providing reverse-proxy to pushpool. It got overwhelmed pretty fast, due to this and another reason. As a temporary measure, I have added another IP to my server and setup iptables to send its port 80 direct to pushpool. After a couple of restarts of Apache, everyone has been migrated to a direct pushpool connection. However, there is one stubborn fellow who refuses to honour the 60 second TTL on my DNS record. Furthermore, this guy is also keeping 3 active connections at a time! I have used iptables to forward his IP (sjs-130-65-215-206.sjsu.edu) to pushpool always. Which means he can't get stats or BitGit or such. Whoever this is, tell me when you have your system fixed and I'll undo it... |
|
|
|
The only thing I want is the ability to track my solved blocks. ;] I don't understand what that means. |
|
|
|
So, how do I see my balance? I tested your pool a few hours with a GPU so I could expect a few bitcents coming my way sometime in the future? Or are those lost until I've racked up over 1BTC? Payouts occur when your balance reaches 1 BTC, or you haven't mined for a week, whichever is sooner. One last question/concern... Eligius doesn't pay until a "balance" goes over 1btc, and then it pays once the block is solved right? So my question/concern is, if my balance keeps going down because I'm not generating as many shares as others, even if the block gets solved faster, I will never get paid? It's been about 5-7 hours now, and i've watched my balance bounce between 0.370 and 0.379, but for every step up, its like two steps down, as im now at 0.365. At this rate, its not even the decrease thats bothering me, so much as the fact that i will never hit 1btc at this rate/as more users with better rigs join because my 78Mh/s just can't generate enough shares to net an increase in balance. If you get 0.50 BTC from the pool twice a day, it adds up to 1 BTC. If you get 0.25 BTC from the pool four times a day, it also adds up to 1 BTC in the same time period. So no matter how your earnings-per-block change, the blocks-per-day should also be changing to make it come out the same in the end. [The balance] will be paid out when it reaches 1 BTC or after 1 week of not mining on the pool. How about changing this to “the balance will be paid out when it reaches 1 BTC or when nothing has been paid for one week, whichever comes first”? For some of us with CPU miners it will take ages to reach 1 BTC, and getting paid at least once per week will be encouraging. As soon as message signing becomes standardized, I hope to allow changing the minimum payout on a per-address basis. So there seem to be two different things: - Amount if Bitcoins that I have earned and will be sent to my Bitcoin adress some day. (This Amount does not change)
- An expected value that will be added to this amount when the next Block is solved.
How can I find these two numbers? includes the first. http://luke.dashjr.org/programs/bitcoin/pool/balances.json is the total combination. However, note that the block json files do not consider manual payouts (such as I had to do because of a bug about a week ago). |
|
|
|
Luke, I'm sorry, but when votes are held (votes written by you on this forum) and they vote specifically to change the protocol to kill unused features in it, that is not bigotry. Have you ever seen a bitcoin: link? If they aren't used yet, changing the spec doesn't break anything. UseFUL features, killed by bigots to make things harder for people who don't happen to have the same PREFERENCES as them. Yes, bitcoin: URIs have been/are used. |
|
|
|
|
All the clients besides the wx one on bitcoin.org support bitcoin: URIs (including Spesmilo, which sets up Windows and KDE to use it). I wrote a patch for the wx client a couple weeks ago, but it seems like due to the developers of that client's bigotry, it will either not be merged, or will be molested to break compatibility (against my express wishes when I released it) before being merged.
|
|
|
|
|
Clients should ideally open a prompt with information on expected "today" (default) fee, minimum fee, and "ASAP" fee, and let the user decide what fee specifically to pay. There should also be a checkbox to override the minimum and allow a lower fee. For example, you can send amounts under 0.01 BTC for only 0.00004096 BTC fee today (approx confirm every 3-4 hours), but the existing clients make it impossible...
|
|
|
|
Listener for "EL 5850": 08/05/2011 09:52:45, Problems communicating with bitcoin RPC
Listener for "EL 5850": 08/05/2011 10:05:41, warning: job finished, miner is idle
Are you now also under ddos luke-jr? Hope not. I saw the "miner is idle" a lot when I had very congested (busy) bandwidth. Then I configured my router to prioritize port 8337. No problems since then... |
|
|
|
Also, are you planning on implementing the threshold signed message thingy? When there's a final standard for it (eg, merged to mainline git), probably. That way you can set your minimum payout by signing a command with your payout address.  In case anyone else noticed and is confused by it, we had an orphan block today.  |
|
|
|
It has only earned 0.60927445 BTC total, so far. Payout is once it reaches a minimum 1 BTC. Also, Ufasoft should work now. Fixed a bug in pushpool related to standard compliance. "The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource." |
|
|
|
what is the current block finding rate for this pool? i see the pool hash rate between 10 and 20 Gh. [09:50:49] <luke-jr> ;;bc,calc [bc,eligius] [09:50:50] <gribble> The average time to generate a block at 16721739.3391 Khps, given current difficulty of 109670.13329248 , is 7 hours, 49 minutes, and 28 seconds We had a nice peak of 31 GH before the debugging and MySQL switch. Spread the word so we can reach 100  |
|
|
|
When an address is "paid" should we expect to see it show in blockexplorer or does it then go in a queue to be paid with the next or possibly subsequent block found by the pool? It should be part of the generation in blockexplorer. |
|
|
|
My balance on 1KmTsdzjvrkZcMxtdoR9WdHwb8Bn5v6fpd decreases a couple of times a day. What's going on? The balance includes rewards for the current block. If you don't maintain your mining yields, or if another miner joins, before the block is found, that amount will decrease. If you get paid, that is not included in the balance anymore. |
|
|
|
|
These addresses and amounts will be deferred until the bugged block matures (100 confirmations):
1HcbN4NTAcUhcXVfgs2KooVhtK6nwUkaog -764408220
16u6Z8N5zf3GpUwsTApUvMKGw6HZU7h1qd -402464413
1KoBYhF3uNS5ZvGTd4RNjWc7VbMqQfDwzy -367798848
1QDs3u4NawCmPBfMxWzZARbwjWwEQdTFTd -278997383
14rJYeAPkXGDRVeTcEn7czE9xNaU5aRi64 -280856126
1DhV9Xf9wfXmngaW2WbjEti8WoRJzrHCC7 -279276194
1CiWEKiF5J5Xarxu1MMM7YMuZ51xBMs3Bw -218262942
173Qmir9hTmvkb3Cmvgj78AV2CjL5azZYS -107295962
1Dh225PqFhD8eDFzqPoT8j5uhPF2j815Cb -190614135
19kQaXvKVWAF6oAsdsyuzWZqxLnttT3eAj -102416760
12mcF29MTcJxpKhe4PiggpneTpFQqux1Ho -104043161
1EFotQdsKSR1dbDRdH4iFbHmtVax1TjNBi -159758994
19uXX5nHK9hYQqvEYUi1tBGieLqYB5aSN4 -117007896
13BNLook5Bf6gUXJjCGu5Hkds3BEj2q1nB -109758797
I felt it would be unfair to delay the payouts of everyone whose balances only just finally added up to over 1 BTC, so there is still about 17 BTC that the pool will continue to fit in across transaction fees and other gaps in the coinbase as soon as it can.
Sorry for any inconvenience.
Also, until the 50 BTC is fully distributed, my own GPU miner will not be receiving any funds.
Edit: 1HcbN4NTAcUhcXVfgs2KooVhtK6nwUkaog has volunteered to wait for a manual send of some older delayed funds, so the pool self-recovery should go a bit faster.
|
|
|
|
|
Migration complete. Hit a few hiccups on the way, but I think I minimized total downtime to under 30 minutes. During that time, miners may have idled, or lost shares. Unfortunately, it seems we found a block during that time too. I expected that in such a case, the rewards would just be off slightly and it would make up the difference in the next block, but apparently it took the whole 50.03 BTC to itself. I'll figure out a way to get that fixed, probably with a sendmany once it's been confirmed (and I write the code to tell the pool I did it). In the meantime, Eligius should be stable again, and much faster with getworks. Until I get that 50 BTC made up, the pool payouts will likely be delayed by one block while it tries to make it up on its own. Will post more when I have an update.
|
|
|
|
|
We're hitting some pretty major I/O bottlenecks with SQLite. I'm going to migrate the db to MySQL to mitigate the problems. During that time, the pool will be down. Hopefully it won't be too long, but the db is currently already 1 GB...
|
|
|
|
I think the pool is having problems Was trying to help debug a memory leak in pushpoold for jgarzik, but it shouldn't have been down for any significant amount of time. Most miners should automatically reconnect. |
|
|
|
|
Wrong forum. Also, TradeBitcoin.com works better IMO.
|
|
|
|
|
Show Posts
