I have 3 Avalon 841 coming in march/April, anyone know of some hosting possibilities
I just sent all my miners to KPM Hosting in Quebec. They're more expensive than some of the other options, but they had capacity, provided the proof they're legit, and have been good to work with. |
|
|
|
|
One other plus for Canaan is the noise is cut a little bit, as there is only one fan vs. two on your S9s.
I know you said your neighbors are sensitive. While it doesn't help a ton, every little db reduction when you have 100+ is an improvement.
|
|
|
|
I think the length of time is dependent on if its having any trouble with any of the strings or individual asics. Sometimes I've seen the log files spin through multiple attempts at different frequencies (maybe depending on temps) to get started, thats when its taken the longest. I just brought it up because its not "instant" which might be what the op was expecting.
Second this - the warm up process for an S9 takes a long time, relatively, before it even tries to start hashing. I've seen it take as long as 20 minutes. Usually when I get a new S9, I configure it and let it do its thing before going to run an errand or grab lunch. |
|
|
|
Block again!! WOHOO!  Unfortunately I don't have my S9 (13.5 THs version January 2018 batch) at home so I can't log in to it to see the hashrate from the miner right now, but can someone explain why CKPool Monitor shows 0.3 THs higher average hashrate than Kano. Or ain't i fully ramped up yet? CKPool monitor uses the Kano API, but it only updates now and then (every minute I think?). Kano's site updates more often. |
|
|
|
|
Loving these daily blocks.
|
|
|
|
There's almost no reason to go for the Ebit miners at all considering most of them are selling for ridiculous prices even used as of right now, and they're just not very good miners in the first place. They're incredibly prone to breaking and Ebit's support is terrible. HagssFIN's post should be enough to keep you away from them.
I agree. I wish I hadn't bought the one eBit I did, and instead bought an Avalon 741 with that money. |
|
|
|
|
Looks like we have another already! Thanks AlexeyDr!
|
|
|
|
|
Thanks DJ Raven, whomever you are. (You should make a new mix called "Block Finder"!)
|
|
|
|
3. Regarding pools, undecided what we'll do regarding default pools. It may reduce support questions if we preconfigure initially. Right now focus is on shipping. Firmware defaults can be tweaked later. Open to suggestions on how to handle this. Miners in warehouse are configured for Slush at the moment.
The way eBit does it is have 3 pools in a drop down and then a custom option. That seems to work pretty well. That way people will understand they're using a "custom" pool and it may not work as well. I do imagine that pools who don't have AB will want to test that it works - for example, I'll point my unit at Kano so he can get it up and running. Having the ability to override the defaults would be needed for that. |
|
|
|
On a related question, IF asic boost is open source...does that mean bitcoin core with seg witness will allow such...or not?
ASICBOOST impacts the way the stratum mining protocol works more than the core software. Right now, core doesn't support stratum out of the box. You'd need another piece of software, like ckpool, or another stratum proxy (slushes, BFG, etc.) to translate the API calls from core into the work format that stratum uses. You wouldn't need to change core, in other words, because that layer stays the same. The middle tier layer that's getting work and coordinating miners in a pool is what needs to be updated. |
|
|
|
The miner exists, that's not the problem here. It's how well it performs on a pool with asicboost enabled vs not.
It will not run without ASICBOOST on the pool. It is hardcoded into the miner driver. You can only run the Dragon miner on pools that support the stratum changes that ASICBOOST needs. You can read the speculation thread - they hacked the driver to force it to hash at a non-AB pool, and it did something like 4 TH. |
|
|
|
No need to send it to me - just to point it somewhere and let me test it properly and see what happens.
Sure - fingers crossed it comes in close to the date they promise  |
|
|
|
Kano- do you think you'd make the stratum changes on this pool to support the new overt ASICBOOST?
Not before getting access to one. I'm not stupid enough to assume any code is just going to work when created by a certain person who loses blocks on his pools and calls that 'misfortune' Testing properly is a way to avoid that  But hackers usually have no idea about such things. Experience tells you otherwise. So if they don't actually exist ... then no they wont be supported  I ordered one - so if I get it, I'd be open to sending it to you to test / integrate (and trust you'd send it back ) |
|
|
|
|
Kano- do you think you'd make the stratum changes on this pool to support the new overt ASICBOOST?
|
|
|
|
[
It requires hardware support, so you can't add it to miners that dont support it in hardware. Also there is a difference between Overt (Dragon) and Covert (bitmain) versions of Asicboost so unless bitmain add overt to their miners it won't help them.
Thing that I'd like some clarity on, ASICboost was only suppost to improve the efficiency of a miner, not its hashing speed, so it did the same but used less power. Overall of course this would lead to either being able to push the miner faster for the same power usage (if the hardware could handle it) or running more individual miners but using the same power. (e.g. if it gave a 25% reduction in power, you could run 5 miners for the power you used to run 4 miners)
Is this new version of overt ASICboost different? There are hints that the Dragonmint miners will only run at 1/4 speed on non-asicboost pools. That sort of doesn't line up with how we all thought ASICboost worked.
https://arxiv.org/pdf/1604.00575.pdf is the whitepaper for this new boost. Sections 3.4.1-3.4.2 talks about how it is different than the Bitmain version. What Bitmain did was prune the merkle tree of transactions to find a collision. This way doesn't state what it does, only that a different way is to "is to calculate many merkle roots at random and filter them based on their last 4 bytes until sufficiently many are found that collide in their last 4 bytes." and also "Another, more efficient way to produce colliding block headers is by using bits inside Chunk 1 but outside the merkle root that are free for the miner to choose. This does not require finding any merkle root collisions. Instead, one merkle root is chosen and fixed. The free bits are then updated in a loop and the respective Mid states are computed from Chunk 1. Each Mid state obtained in this way gives a new colliding work item, so that this method is extremely efficient." |
|
|
|
Alright, so I looked through some of the recent conversations concerning consolidating payouts since I'm getting to the place now where I'm thinking of doing this, but I want a good secure strategy that fits well with my situation--preferably avoiding coinbase too.
I mine everything to a single, offline, paper wallet that's never had its private key exposed to anyone but myself. Yes, I went through the trouble of saving the JavaScript Bitcoin address generator code off to a CD, plugged it into an air-gapped PC, printed it out--even cleared the printer cache afterward...
Anyway, how exactly does everyone who's in a similar situation here transfer (sweep or import?) their mining payouts from cold storage to warm/hot wallets where they can spend the Bitcoins they've earned?
I have looked back through some conversations here and there; however, I'd like to know how you guys recommend doing this in a secure, repeatable manner. Thanks in advance.
I used to go the same route you go, but I've switched to using a hardware wallet. Makes these things much easier. I highly recommend one. |
|
|
|
Yes, but why should pools change their protocol because one mining company says so? Why not make chips that hash at their advertised rates, and then ASICBOOT if your pool supports it to get up to higher rates?
Pools are designed to make money from miners. Do you think pools will refuse to implement it and shut out potential new customers? Will CKPool support it day 1? |
|
|
|
Well I see no reason why BCH pools couldnt also support overt AsicBoost. Hopefully it will become widely adopted by all pools, then there really is no need to worry about AsicBoost, it'll just be a 16TH miner.
Yes, but why should pools change their protocol because one mining company says so? Why not make chips that hash at their advertised rates, and then ASICBOOT if your pool supports it to get up to higher rates? Saying you're selling a SHA-256 miner that runs at 16 TH/s is a misdirection at best and an outright lie at worst if it'll only run at that speed on certain pools. |
|
|
|
|
Wow, thats very disappointing that it'll mine at advertised hashrates on ASICBOOST pools. Talk about false advertising...
|
|
|
|
|
Show Posts
