Thanks for all your work! Guys like you and slush keep the dream alive!
naelr
Topic: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers - page 369. (Read 903150 times)
October 20, 2012, 01:15:02 AM
October 19, 2012, 10:09:30 PM
I just wanted to give everybody a small update on what new things will be heading to BTC Guild soon. The Stratum pool is being run in a debugger right now, so the next time it crashes (first one took over a month to happen) the bug that caused it can be swiftly patched.
After the crash bug has been found, I will be working on a special log file that is updated whenever the Stratum pool updates its transactions and sends out new work. The goal of the update is that at any time, a miner will be able to inspect the full list of all transactions that are a part of the block being created. As of this time I don't know if the page will be able to provide full details like you would see on blockchain.info (inputs/outputs) or just the transaction hash + raw transaction data.
After the crash bug has been found, I will be working on a special log file that is updated whenever the Stratum pool updates its transactions and sends out new work. The goal of the update is that at any time, a miner will be able to inspect the full list of all transactions that are a part of the block being created. As of this time I don't know if the page will be able to provide full details like you would see on blockchain.info (inputs/outputs) or just the transaction hash + raw transaction data.
October 19, 2012, 04:31:41 AM
Cool, I figured it had to be something beefy to handle the load. I didn't think you would be running that in Python. 
Not so funny. My current Python implementation is able to handle Bitcoin network hashrate on two CPU cores :-P. And as a bonus, it don't segfault at all
.Python isn't immune to crashing ;p And with 600 concurrent users CPU usage never breaks above 3% of one core at peak. Peak being when it's parsing a getmemorypool output with a large # of transactions, and spitting the work out.
I've been running Stratum for over a month now on the main servers with no crash, and even beta didn't crash after the first week, just restarts to add/speed up features. I'm pretty surprised it happened now, but hopefully it will happen again and I can backtrace the exact cause and implement a fix shortly after.
October 19, 2012, 04:28:51 AM
Cool, I figured it had to be something beefy to handle the load. I didn't think you would be running that in Python.
Not so funny. My current Python implementation is able to handle Bitcoin network hashrate on two CPU cores :-P. And as a bonus, it don't segfault at all
. 
October 18, 2012, 03:26:23 PM
Stratum had its first crash...straight up segfault. Restarted it inside GDB to catch the cause next time it happens (if it does).
Diff was so big it bounced out of the memory.. 
October 18, 2012, 03:13:44 PM
Stratum had its first crash...straight up segfault. Restarted it inside GDB to catch the cause next time it happens (if it does).
Does the Stratum code that runs on your pool get updated like the version we run from github? (Currently 1.1.1)My Stratum pool is not related to the proxy or pool that slush has posted. It's an entirely custom C++ design.
Cool, I figured it had to be something beefy to handle the load. I didn't think you would be running that in Python.
October 18, 2012, 03:11:20 PM
Stratum had its first crash...straight up segfault. Restarted it inside GDB to catch the cause next time it happens (if it does).
Does the Stratum code that runs on your pool get updated like the version we run from github? (Currently 1.1.1)My Stratum pool is not related to the proxy or pool that slush has posted. It's an entirely custom C++ design.
October 18, 2012, 03:10:38 PM
Stratum had its first crash...straight up segfault. Restarted it inside GDB to catch the cause next time it happens (if it does).
Does the Stratum code that runs on your pool get updated like the version we run from github? (Currently 1.1.1) October 18, 2012, 02:46:31 PM
Stratum had its first crash...straight up segfault. Restarted it inside GDB to catch the cause next time it happens (if it does).
October 18, 2012, 02:20:48 PM
I don't know if this is related to the reboots that you mentioned, but my Stratum Mining Proxy died around 11:15am Pacific. It was pointed to "btcguild.com" and it is getting a connection timed out error. I switched to "stratum.btcguild.com" and it's up and running.
October 18, 2012, 11:29:46 AM
The stuck payouts (payments that were made but never confirmed by bitcoind) have been manually added in, and the accounts have been "unfrozen" so they can request payouts again.
I've updated my payout script slightly to fix this faster in the future. Whenever it happens again, the payment will be added to your history (so far there has never been an instance where the payment wasn't made), and your account will be "frozen" again. When it happens, anytime I personally go to the website a very large blinking banner will appear telling me that a payment was not fully completed, so that I can go in and verify the transaction and unfreeze the account. I load the page constantly throughout the day, so the maximum time an account should ever be stuck in frozen status would be maybe 12 hours except in very unusual circumstances.
During "frozen" status, you can always turn on automatic payments. This has always been the preferred method of users handling their payouts since it means I'm not having to move coins in/out of a cold wallet as a result of users leaving coins in their account for long periods of time.
I've updated my payout script slightly to fix this faster in the future. Whenever it happens again, the payment will be added to your history (so far there has never been an instance where the payment wasn't made), and your account will be "frozen" again. When it happens, anytime I personally go to the website a very large blinking banner will appear telling me that a payment was not fully completed, so that I can go in and verify the transaction and unfreeze the account. I load the page constantly throughout the day, so the maximum time an account should ever be stuck in frozen status would be maybe 12 hours except in very unusual circumstances.
During "frozen" status, you can always turn on automatic payments. This has always been the preferred method of users handling their payouts since it means I'm not having to move coins in/out of a cold wallet as a result of users leaving coins in their account for long periods of time.
October 18, 2012, 11:13:15 AM
This tends to happen whenever the bitcoin software fails to respond to the RPC command. It's a pretty rare occurrence, but tends to be the result of the wallet getting heavily fragmented. I'll be fixing the problem over the next hour. I may have to do a restart of the servers and point them at a new wallet address, because it seems to have happened to multiple people over the last 2 days, and normally it only happens once a month at most.
Thank you for looking into this matter.
October 18, 2012, 11:11:13 AM
Hello, I seem to be experiencing an issue with while doing a BTC payout. I get the following message:
A payout request is already being processed for your account (you may have clicked the link twice).
I have been seeing this since yesterday. Does anybody know how I can resolve this? Thanks.
A payout request is already being processed for your account (you may have clicked the link twice).
I have been seeing this since yesterday. Does anybody know how I can resolve this? Thanks.
This tends to happen whenever the bitcoin software fails to respond to the RPC command. It's a pretty rare occurrence, but tends to be the result of the wallet getting heavily fragmented. I'll be fixing the problem over the next hour. I may have to do a restart of the servers and point them at a new wallet address, because it seems to have happened to multiple people over the last 2 days, and normally it only happens once a month at most.
October 18, 2012, 09:31:19 AM
Hello, I seem to be experiencing an issue with while doing a BTC payout. I get the following message:
A payout request is already being processed for your account (you may have clicked the link twice).
I have been seeing this since yesterday. Does anybody know how I can resolve this? Thanks.
A payout request is already being processed for your account (you may have clicked the link twice).
I have been seeing this since yesterday. Does anybody know how I can resolve this? Thanks.
October 16, 2012, 05:08:24 PM
cgminer can currently cope on stratum with 96 bits of the difficulty target since the first 32 bits are zeroes and I'm currently using a 64bit unsigned integer for diff calculation. So that allows a maximum difficulty of 18,446,744,073,709,551,616. So we've still got a while to go... and I can always revise it in the future.
If any of us are even alive at that point. Decades of doubling every 18 months before the _share_ targets would be that high. Even if your starting point is a "1 TH/s" ASIC.
October 16, 2012, 05:00:46 PM
cgminer can currently cope on stratum with 96 bits of the difficulty target since the first 32 bits are zeroes and I'm currently using a 64bit unsigned integer for diff calculation. So that allows a maximum difficulty of 18,446,744,073,709,551,616. So we've still got a while to go... and I can always revise it in the future.
If any of us are even alive at that point. Decades of doubling every 18 months before the _share_ targets would be that high. Even if your starting point is a "1 TH/s" ASIC.
October 16, 2012, 04:50:10 PM
cgminer can currently cope on stratum with 96 bits of the difficulty target since the first 32 bits are zeroes and I'm currently using a 64bit unsigned integer for diff calculation. So that allows a maximum difficulty of 18,446,744,073,709,551,616. So we've still got a while to go... and I can always revise it in the future.
October 16, 2012, 10:05:41 AM
Is there any upper limit? 
Quote
2012-10-15 11:00:46,516 INFO proxy client_service.handle_event # Setting new difficulty: 64
There is no upper limit (why should there be?). It will keep doubling the difficulty until you hit the sweet spot which is 1 share every 4-6 seconds approximately (it doubles when you exceed 1 per 3 seconds after a 5 minute evaluation, or if you're going extremely fast over a 1 minute evaluation).
I think hash result is a positive/unsigned integer, if you keep divide target, depends how target is represented and what sort of inequality you use, diff wont matter anymore or no hash will pas target verification. I would have put a soft limit before that, however, considering ASIC war which will probably happen after preorders, moores law and quantum computing, we may get to the point where vardiff will mean hash result = 0, target = 0 and inequality is equality.
It would depend on how the miner software has implemented the target. The hard limit in bitcoin is a 256-bit target (at which point you can't get any harder unless we move beyond SHA256). That target would be 256 sequential 0-bits. In my pool software, I double the decimal representation of difficulty each time because I'm checking the bits. Difficulty of 1 is 32 sequential 0 bits. Each time difficulty is doubled, it's checking one more sequential bit for 0.
Remember, even with Moore's Law, you're looking at doubling every ~18 months. To even hit 100 out of 256 bits of difficulty (147,573,952,589,676,412,928 if my math is right), we've got a long way to go. Right now we're at 52-53 bits. So somewhere around 60 years. And we'll still have 156 bits left after that. It would be up to mining software to update for any 32/64-bit limitations on share targets conversions.
October 16, 2012, 06:12:14 AM
Is there any upper limit?
Quote
2012-10-15 11:00:46,516 INFO proxy client_service.handle_event # Setting new difficulty: 64
There is no upper limit (why should there be?). It will keep doubling the difficulty until you hit the sweet spot which is 1 share every 4-6 seconds approximately (it doubles when you exceed 1 per 3 seconds after a 5 minute evaluation, or if you're going extremely fast over a 1 minute evaluation).
I think hash result is a positive/unsigned integer, if you keep divide target, depends how target is represented and what sort of inequality you use, diff wont matter anymore or no hash will pas target verification. I would have put a soft limit before that, however, considering ASIC war which will probably happen after preorders, moores law and quantum computing, we may get to the point where vardiff will mean hash result = 0, target = 0 and inequality is equality.
October 15, 2012, 06:28:37 PM
Why no stratum on port80? All the others are working great! Thanks MM!
I will probably setup a port 80 Stratum server when I merge some of the getwork servers together.
Jump to: