This sucks we were on such a good winning streak.  I wonder who you pissed off this time  Nobody pissed someone off. It's summer, it's a bunch of script kiddies home from school and back at their parents' house with nothing to do. I got hit briefly yesterday, and I've been continuing to get threatening emails demanding money (via LibertyReserve, lol) or else BTC Guild will go down again just like Deepbit. Same shit as last year, except this time it's not as bad (last time they were able to take down all the major pools at once). There's nothing any pool op can do but wait it out. I'm hoping by now everybody at least learned to set MULTIPLE backup pools. And hopefully they're not all pointed at the 4 largest pools because a larger threat could easily take down most of the Top 10 at once. EDIT: Looks like I pissed them off with my comment. |
|
|
|
I am getting alot of Get & Send Work connection errors as of late using btcguild.com:8332 as my Primary pool.
In Western Canada, would it be better for me to use either mine2.btcguild.com:8332 ...or... mine3.btcguild.com:8332 for my PRIMARY POOL instead ?
I normally use a setup like this in CGMiner, using BTCGuild mine2 and mine3 as backup pools to regular btcguild.com:8332 as my primary:
PRIMARY: btcguild.com:8332
POOL #2: mine3.btcguild.com:8332
POOL #3: mine3.btcguild.com:8332
POOL #4: Localhost/Solo Mining Server
mine2 and mine3 are ALWAYS recommended over mine1. You go from a server with 2000+ LP connections active to only 500 when you switch to mine2/mine3 because too many people use default settings. Were you just recently getting the errors? The little DDoS'ers sent an email threat roughly the time you posted, so there may have been some packet loss if they even hit at all. |
|
|
|
I received an email trying to extort some money with threat of DDoS this morning. Website is temporarily offline, though the DB server is still running and mining servers aren't getting hit too hard. You may have some packet loss, but shares are still going through fairly well.
More skiddies on summer vacation.  Yeah, that's my guess. The attack this morning was kind of fun compared to what pool operators got used to from last summer's attacks. |
|
|
|
|
I received an email trying to extort some money with threat of DDoS this morning. Website is temporarily offline, though the DB server is still running and mining servers aren't getting hit too hard. You may have some packet loss, but shares are still going through fairly well.
|
|
|
|
I'm guessing you guys are on a VPS then?
Doesn't exactly mean that, they could be on the same network line. I've seen hosts that offer cheaper 1gbit connections because they are shared with other boxes. It isn't only cheap hosts. If you colocate a single server, you're vulnerable to a DDoS if any server in your rack is getting attacked. Even with entire racks, you're going to be sharing an upstream switch at some point with other servers. It all comes down to how quickly the datacenter can isolate the attack and blackhole the affected server, and how far upstream the attack separates from you. |
|
|
|
Both services you listed were hosted on a single dedicated server with no formal DoS mitigation.
The plan we are looking at will stand up to 20gbit bad data and/or a million packets/sec
Wrong, when BTC Guild was DDoS'd it was on a DDoS protected server for the primary server, with 6 other remote servers at different DCs. The primary hosting could absorb 30+ gbit/sec attacks. We've since abandoned the idea of DDoS protected hosting because there really is no such thing (at least within a feasible price range). 1 million packet/sec attacks aren't even close to big enough to protect you from a real DDoS these days. You will never be able to offer true (or even decent) DDoS protection for a VPS company unless your prices are adjusted (more than tripled) to reflect it. |
|
|
|
Does this also explain the weird blip I've just seen in my hash rate graphs over the last 24 hours? At about 1pm, June 11, for an hour or so, all three of my rigs apparently 'doubled' their hash rate! (Incidentally what IS the time that appears on those highcharts.com graphs? I'm in the UK, where it's now nearly 11am, and the last data points on the 24-hour graphs say 05:08)
Yes, that's why you saw the blip on your charts. It's the same thing that happened a few weeks ago when there was a small DB connection problem between the webserver and the DB server. Since the script to calculate your hash rate only executes once per hour (and doesn't have any sort of retry-on-fail), if it misses an hour, the following hour shows twice as many shares as normal. Since the previous hour has -no data-, it doesn't show a drop to 0 followed by a jump to double, it simply shows a steady growth from 2 hours prior. |
|
|
|
Many users use Ozco as their backup pool to GPUMax, so when leasing is available thats where all the hashing goes.
Why is GPUMax so popular? They pay more than a legitimate pool can. But it's happening less and less. More people on GPUMAX = Leased work is finished faster. And with almost all of the proportional pools dead, there is very little incentive for somebody to pay GPUMAX for hash power anymore for hopping. I'm still struggling to see any business model for GPUMAX beyond short term. There's just no reason to pay such a premium for hash power unless you're stress testing a pool server, since pool hopping at those margins requires very precise timing and a large number of hoppable pools. Well, unless you're trying to pull off a double-spend... |
|
|
|
Failed to connect to BTC Guild database. Please try again later. for me now. For 30min at least Sorry about that, some MySQL vulnerabilities were released today and I was doing some testing to make sure BTC Guild was not vulnerable. Allowances were made for the pool servers, so all shares were still being recorded during that time. |
|
|
|
I've noticed Blockchain Wallet freeze up after about 15-20 transactions in 30 minutes.
Bitcoin also has a tendency to lag up after ~400 transactions in 48 hours.
Multibit locks up after ~150 transactions in 24 hours.
Electrum is the one I've been messing with for a while and so far the worst thing is the seconds not showing up for the transaction time. It's frozen up a few times, but a simple switching of the server fixed that.
Sounds like you're running on slow hard drives, or your hard drive is having problems. I was playing with a custom SD Bot using stock bitcoind on my VPS (Raid 10 + 10k drives). Lag didn't start becoming an issue until the wallet hit ~250 megs with 10k+ transactions. Even then it normally wasn't bad. Although now I have it modified to send change back to the original address, which stops the wallet from bloating up so badly in the first place. |
|
|
|
Just posting a friendly reminder to users that are not in the US: We do have a server based in Germany! Simply point your miner to http://de.btcguild.com:8332 to use it! It's not getting used nearly as much as the old EU servers, so I suspect quite a few of you aren't aware it exists  . |
|
|
|
2. This question is asked exactly each 2016 blocks (approx. 2 weeks), but looks like no one ever tried to read a few pages back Luck information is removed automatically each time after the difficulty adjustment until enough stats are collected. To be fair, NOBODY reads anything but the first post and last page on a thread . Expecting otherwise is like expecting somebody to read a EULA. My recommendation: Put up a placeholder/statement when luck isn't being shown, should reduce the question to every 5-6 diff changes instead of each one . |
|
|
|
I've had some issues lately with transactions taking a long time to confirm and not showing in my wallet till they got confirmed, but I could still look them up on the website to see if I won or not. But now I've encountered another issue: I've made a bet and it doesn't show up on the website, even though it does show up on blockchain.info and it's already confirmed: blockchain transactionlink to satoshidice for that transactionSD is going VERY slowly today, there's been quite a few bets that took a couple hours to actually get processed, but so far they all do eventually get processed. |
|
|
|
Someone asked for my comments, so...
1. Block 183478 was found in just 12 seconds, so it was possibly a result from one of the very first getworks from this round. Those getworks contain only the coinbase TX because we had no time to build a complete block.
Block 183482 by other pool was found in 32 minutes, so it has lots of time to collect new TXes and include free or low-fee TXes not mined by Deepbit earlier.
2. Blockchaininfo's information about Deepbit's blocks is wrong sometimes. May be it's because other blocks are frequently received by them from our relaying nodes. Use the Blockorigin site, it takes information directly from Deepbit.
Looks like this time the block is really mine, and that's just our luck. Happens to anyone.
3. Usually Deepbit was including more free TXes than anyone else, but this situation changed recently. I heard from someone that those "1dice" TXes take up to 50% of the total numbers, and they are considered "free" by our fee policy, so we are limiting them in our blocks. There are lots of "1dice" TXes in that 747-TX block.
If this will become a problem, I'll consider rising my free TX limits.
Actually, 1dice TXes actually DO have fees attached, following the standard bitcoind fee assessment of 0.0005 per 1 KB (unless the coins are aged / many coins being sent, but that is not the case with most of dice transactions). As a matter of fact, I'm having trouble finding a single one in that 700 tx block that did not have a fee. |
|
|
|
I don't think its about the blocks found and who finds them. (but then again I could be wrong)
But the lack of transactions within the blocks. Once again I could be wrong and tbh I don't know how pools work (I just mine). Is there a way pools can be lazy and not submit tx work.
I'm sure someone will be along soon with a LOT more brains than me
pools make money from txn fees, be silly not to include them eh? Some pools refuse free txn - deepbit is not one also blockchain.info is notoriously inaccurate with deepbit blocks - they may or may not even be deepbits, look at http://blockorigin.pfoe.be/top.phpfor accurate block stats Blockorigin is over 1k blocks behind  . I missed their charts, it was nice to see a longer window (2016 blocks). I have noticed the same thing lately though [I've been goofing around with SatoshiDice]. Blockchain.info will be showing 1000-1500 unconfirmed txes once in a while, and a Deepbit (it may be a false positive, but I doubt it is wrong EVERY time) block might only have 100-200 tx. A few minutes later, a block from another pool hits with 600-900. It's not a big problem right now, but it could become one later. If a pool is adding a large portion of the overall hash rate, but simply ignoring/not including a large number of transactions in each block, it could be a problem when we're seeing a higher transaction volume. |
|
|
|
|
Latest updates are nice, coins are confirming much faster now. Is the 5 BTC max bet expected to stick around?
|
|
|
|
I cant request any BTC or Namecoin payouts anymore. I get the message:
A payout request is already being processed for your account (you may have clicked the link twice).
I waited a few blocks and still the same. Also the Unpaid Rewards counter did not jump back to zero, after i clicked request payout. Can you take a look at this, please. My username is br0ken
This should be fixed now. Earlier today the hot wallet ran low due to some bad luck last week paired with a large spike in withdrawals due to the price increase. A few automatic payouts were also stuck due to the problem. Those missing automatic payouts should be processed in 20 minutes with the next batch. |
|
|
|
Its been a bit quiet We missed a week Previous post said we wont see any new charts for ~4 weeks. |
|
|
|
So as for my small transactions that are being held up (the ones that DO show on blockchain.info but not my wallet) is this just a matter of time and a different pool picking up the smaller transactions and fees? For example, my oldest transaction is about 2BTC + fees and I've been waiting for at least a few hours now... it's right there on blockchain but it's just stuck as unconfirmed!? Thanks again SatoshiDice seems to be reasonably proactive at resending failed transactions after enough time has elapsed. Unfortunately, there is just no way to guarantee that a payout will arrive in a reasonable time frame, so keep that in mind when betting. Never bet more than you're willing to wait for! |
|
|
|
What's going on with the payments?! I have a bunch of transactions that were "sent" but aren't being picked up by blocks as they are found. I also have a few bets that despite having a payment TX, can not be found on blockchain... I'm also missing about 30BTC worth of bets that haven't shown up at all, I could really use these BTC right now - it'd be nice to sell some while the price is up  It's up to pools to confirm transactions. Very small payments can take a long time to confirm. There are some pools out there that seem to be very misconfigured since there have been times where pools are creating blocks with < 200 transactions in them even with 2,000 waiting for confirmations [WITH FEES!]. However, I've just started playing SatoshiDice for fun with some friends, and there's one thing that has really slowed down being able to play: Sometimes a TX goes from PENDING to UNKNOWN. My assumption is that means the original payout TX was trying to use funds which weren't confirmed, and due to time it eventually became an "orphaned transaction". What's the normal turn around time for SatoshiDice to resend UNKNOWN transactions? |
|
|
|
|
Show Posts
