Sorry I didn't reply sooner... I have opened up port 80 on both the US and EU stratum servers. You can now connect there instead of port 3333 if you wish. It's a vardiff port. Starting diff is 10042. Min diff is 1042. Max diff is 1048576. For those of you with firewall concerns, this should solve your problems  Enjoy! I've updated the OP to include the new port details. |
|
|
|
|
I don't have either 80 or 443 opened on the stratum servers, but changing that won't be a problem. I will take care of it in the morning and post back here when it is done.
|
|
|
|
|
To all who replied to me in this thread - sorry I didn't get back to you earlier. I ended up selling my 18 hosted units. I still have the 2 at my home.
Unfortunately, the offer of $150 - $170 is not something I'd be willing to consider. I wish you the best of luck in acquiring gear!
|
|
|
|
|
Obviously you should send 1000 of them to me at the at the following address: 1EZscamhQzRaB3xhdp2i68zt8zTYqtH1ud
|
|
|
|
|
Mine are not on the way yet. I'm still working with my hosting provider and Canaan to see what kind of a deal we can get. Initially we were told a nice, discounted price on the hardware, but since then I haven't heard a peep about whether or not it would be honored. So, that means I'm on a buying hold until I get final word. For some reason Canaan has stopped communicating with me. We had a number of emails going back and forth, but they haven't responded to me, even after multiple followup reminders that I'm waiting for an answer.
I'm going to contact my hosting provider today to see if they've gotten any news. Hopefully I'll hear back and get the ball rolling on new gear. If not, well... I'll keep my 2 A6 plugging away here at home.
|
|
|
|
I posted this on kano's thread as well. Reposting it here since it seems to be more relevant to this discussion... Reading through the comments, my understanding is that a 0.13.1 node will fill its outgoing connections with other 0.13.1 nodes on priority, and only connect to non-0.13.1 nodes if it cannot find any 0.13.1 nodes to connect to. It will accept inbound connections from any version. Looking at one of my own 0.13.1 daemons, I get the following from calling getpeerinfo (I snipped a lot to only show relevant info): [
{
"id": 6,
"addr": "84.245.27.185:8333",
"addrlocal": "50.2.189.35:42918",
"services": "0000000000000005",
"relaytxes": true,
"lastsend": 1480270212,
"lastrecv": 1480270213,
"bytessent": 224159059,
"bytesrecv": 582881556,
"conntime": 1478943142,
"timeoffset": -6,
"pingtime": 0.120353,
"minping": 0.11485,
"version": 70012,
"subver": "/Satoshi:0.12.0/",
"inbound": false,
"startingheight": 438527,
"banscore": 0,
"synced_headers": 440804,
"synced_blocks": 440804,
"inflight": [
],
...
{
"id": 17,
"addr": "213.251.186.216:8333",
"addrlocal": "50.2.189.35:51776",
"services": "0000000000000005",
"relaytxes": true,
"lastsend": 1480270212,
"lastrecv": 1480270212,
"bytessent": 295398321,
"bytesrecv": 125067139,
"conntime": 1478943165,
"timeoffset": 0,
"pingtime": 0.209322,
"minping": 0.10465,
"version": 70014,
"subver": "/Satoshi:0.13.0/",
"inbound": false,
"startingheight": 438527,
"banscore": 0,
"synced_headers": 440852,
"synced_blocks": 440852,
"inflight": [
],
Based on that, I can clearly see I've got outbound connections to nodes with a version lower than 0.13.1. Here's the call to getinfo (balance removed): {
"version": 130100,
"protocolversion": 70014,
"walletversion": 60000,
"blocks": 440852,
"timeoffset": 0,
"connections": 125,
"proxy": "",
"difficulty": 281800917193.1958,
"testnet": false,
"keypoololdest": 1452577986,
"keypoolsize": 100,
"paytxfee": 0.00000000,
"relayfee": 0.00005000,
"errors": ""
}
So, I'm running a 0.13.1 node that has outbound connections to nodes with a version less than 0.13.1. My initial statement about when a 0.13.1 node might connect to lower-version nodes is likely incorrect. However, I've certainly shown that a 0.13.1 node will indeed fill outgoing connection slots with versions that are not 0.13.1. |
|
|
|
Reading through the comments, my understanding is that a 0.13.1 node will fill its outgoing connections with other 0.13.1 nodes on priority, and only connect to non-0.13.1 nodes if it cannot find any 0.13.1 nodes to connect to. It will accept inbound connections from any version. Looking at one of my own 0.13.1 daemons, I get the following from calling getpeerinfo (I snipped a lot to only show relevant info): [
{
"id": 6,
"addr": "84.245.27.185:8333",
"addrlocal": "50.2.189.35:42918",
"services": "0000000000000005",
"relaytxes": true,
"lastsend": 1480270212,
"lastrecv": 1480270213,
"bytessent": 224159059,
"bytesrecv": 582881556,
"conntime": 1478943142,
"timeoffset": -6,
"pingtime": 0.120353,
"minping": 0.11485,
"version": 70012,
"subver": "/Satoshi:0.12.0/",
"inbound": false,
"startingheight": 438527,
"banscore": 0,
"synced_headers": 440804,
"synced_blocks": 440804,
"inflight": [
],
...
{
"id": 17,
"addr": "213.251.186.216:8333",
"addrlocal": "50.2.189.35:51776",
"services": "0000000000000005",
"relaytxes": true,
"lastsend": 1480270212,
"lastrecv": 1480270212,
"bytessent": 295398321,
"bytesrecv": 125067139,
"conntime": 1478943165,
"timeoffset": 0,
"pingtime": 0.209322,
"minping": 0.10465,
"version": 70014,
"subver": "/Satoshi:0.13.0/",
"inbound": false,
"startingheight": 438527,
"banscore": 0,
"synced_headers": 440852,
"synced_blocks": 440852,
"inflight": [
],
Based on that, I can clearly see I've got outbound connections to nodes with a version lower than 0.13.1. Here's the call to getinfo (balance removed): {
"version": 130100,
"protocolversion": 70014,
"walletversion": 60000,
"blocks": 440852,
"timeoffset": 0,
"connections": 125,
"proxy": "",
"difficulty": 281800917193.1958,
"testnet": false,
"keypoololdest": 1452577986,
"keypoolsize": 100,
"paytxfee": 0.00000000,
"relayfee": 0.00005000,
"errors": ""
}
So, I'm running a 0.13.1 node that has outbound connections to nodes with a version less than 0.13.1. |
|
|
|
I love this thread. While some of the repeated memes are just downright boring, others are hilarious. Add to that some of the exceptionally creative replies and it makes for some fine reading. One that sticks out to me (and actually had me laughing out loud) was, "pop a Midol and spin some Liberace". Keep up the good work |
|
|
|
|
Of course they are. If you look at AntPool... they've solved 26 blocks in the past 24 hours. At 3% fees, that's 9.75BTC they've made that should have gone to miners. If we expand that out to the past month, Ant has solved 794 blocks. 297.75BTC kept by the pool. Take away some of that because of their empty blocks... but still. Not a bad payday ($220,335 for a month's hashing with BTC at $740).
|
|
|
|
Just about 12 hours left... let's solve that block and give someone a nice holiday shopping bonus |
|
|
|
Core typically does a good job estimating fees, but I almost always check against https://bitcoinfees.21.co to see how the network looks. For example, right now Core is giving me an estimate of 0.0007 BTC per kb; however, the website is suggesting 100000 satoshi per kb. If I were to send a transaction now, I'd probably use the higher estimate to fast track it, especially since my last reply there are now more than 64k unconfirmed transactions. |
|
|
|
|
it could very well be a case of transaction fee being too low. There are currently almost 50k unconfirmed transactions out there and you're looking at a fee of at least 80 satoshi per byte to get you confirmed in a reasonable time.
|
|
|
|
|
If you're renting, configure your hash to use port 3334. It has a much higher starting diff.
|
|
|
|
Good luck. I hope you manage to get a good, stable unit. If anyone is wondering, I've sold 18 of my 20 A6 units and am waiting to hear back from both Canaan and my hosting provider on acquiring some 721s. That's why my hash rate is way down. I'm not pointing it somewhere else . Hopefully I'll be back up and running (albeit likely with less hash than I had before) shortly. In the meantime, let's do a Thanksgiving promo. Whoever finds a block between now and the end of the day Thursday (23:59:59 EST on 11/24) will receive a 1 BTC bonus from me. Good luck everyone! |
|
|
|
45 chips model frequency should be 700M not 600m lower the frequency, lower the hash rate I'm pretty sure the question is more about why it is showing 3 blocks found. The only explanation I can even think of giving here is that for the very short time your miner was hashing at NH (not solo) it was mining a very low diff alt coin. It certainly didn't hit a block of BTC. The highest diff is nowhere near what the BTC network difficulty is. it wasnt mining at the multipool thats 100% logs of solo even proof that but who cares build my own node now and will point them their its anyway just for fun not profit Look at your screenshot again. There was a very short time that your miner was pointed to sha256.eu.nicehash.com. That is not the solo pool. It is in the realm of possibility that your miner found 3 low-diff alt-coin blocks during that time. You certainly didn't even come close to a block of Bitcoin. 2 possible since it's only 2 shares The 3rd was most likely just the fact that Bitmain is unable to count and we've seen for a long time their cgminer hack reporting blocks incorrectly. Suppose Bitmain's not the only one who can't count, since I stated 3 blocks. Oops. I'll go back to drinking my bourbon now...  |
|
|
|
45 chips model frequency should be 700M not 600m lower the frequency, lower the hash rate  Can someone pls explain this to me ? how reliable is the antminer backend ? I'm pretty sure the question is more about why it is showing 3 blocks found. The only explanation I can even think of giving here is that for the very short time your miner was hashing at NH (not solo) it was mining a very low diff alt coin. It certainly didn't hit a block of BTC. The highest diff is nowhere near what the BTC network difficulty is. it wasnt mining at the multipool thats 100% logs of solo even proof that but who cares build my own node now and will point them their its anyway just for fun not profit Look at your screenshot again. There was a very short time that your miner was pointed to sha256.eu.nicehash.com. That is not the solo pool. It is in the realm of possibility that your miner found 3 low-diff alt-coin blocks during that time. You certainly didn't even come close to a block of Bitcoin. |
|
|
|
|
100% agree. Antpool produces the most empty-blocks of any entity on the network. Crap coding in their hardware combined with crap coding of their pool. Then they have the audacity to keep the transaction fees to pad their own pockets.
Your vision of the ideal ecosystem is spot on: a number of medium-sized pools spread throughout the world offering low fees and running full nodes that verify blocks. Unfortunately, the reality is a vast majority of the global hashrate is concentrated in Chinese pools, most of which rip off their miners and/or are detrimental to the sanctity of the blockchain.
|
|
|
|
|
You mine on pools that do not support segwit. To enable segwit, a pool has to do a few things, including changing their coinbase transaction to include the segwit commitment. Without doing those things, the pool will not vote for segwit blocks, and segwit will never be activated.
|
|
|
|
Yah it makes no sense. Maybe it's just greed and the fee is too high. Then again some of the other pools have fees as well - with the exception of Antpool. I've used Antpool in the past and I'm firm convinced that Slush's infrastructure and web front end is superior in every way. The graphing and charting on Antpool is crap. I'd notice mysterious drops in hashrate. In fact oddly enough with Antpool S9s were performing worse. I'd see a loss of 4 TH on the daily average, which makes me think that the miners were dropping connection to the pool very frequently or the pool's network has some routing or connectivity issue. After moving them to Slush they've been rock solid and daily average is what the miners' web panel reports.
Anyways, not sure what Slush can do to bring on more miners. Maybe he can give a "fee discount" for miners that have been mining steady for X amount of days on the pool - a kind of loyalty reward. I dunno, just saying that this pool deserves more hashing power, that's all.
Antpool has fees... they're just hidden. They advertise 0% fees, but the fine print states they do not give any transaction fees to miners. That's about a 4% loss of income. |
|
|
|
|
As the good doctor pointed out, working faster does not mean increased luck. It just means you got more accomplished in the same time frame than you did previously.
You can look at a pool's history and determine how that pool has done compared to expectations, and thusly derive a luck value. Better than expectations is good luck, worse is bad.
However, you absolutely cannot predict future luck. You can use statistical models to provide expectations, but those are not indicators of luck. As I wrote in an earlier post, just because a pool has submitted 95% of expected shares this has no bearing whatsoever on whether or not that pool will block in the next 5%. You have no better chance of blocking at 96% than you did at 1%. The pool isn't suddenly more likely to find a block just because some percentage of expected work has been completed.
Both kano and I previously pointed out what DrHaribo just linked to (the law of large numbers). Mining follows a known pattern, and hence we can derive certain expectations from that pattern. However, those expectations do not provide for predictability of luck.
|
|
|
|
|
Show Posts
