Actually that is fairly high for that card. Try to take it below +50/+80 and see what happens. The issue is definitely overclocking.
its actually pretty weak.
Iād seen 1070 with over 100 core and easly 500/600+ memory (with less power draw).
iāve got a 1070ti i have +200 core and +700 mem.
The 1070 and 1070ti are known for having their sweet spot with such settings
Iāll defer to @johnwisdom on this one for my lack of experience with 1070s. For a 1080 ti that might be too much, depending on the power level, and I have seen that error before after too much overclocking.
1 Like
We are happy to announce that Flypool is now ready for the upcoming Sapling network upgrade. Payouts will be paused shortly before the Sapling block and resumed as soon as the network is in stable again. Mining will be unaffected by the update.
5 Likes
Will you support payouts to Z-addresses?
For performance reasons it is not possible for us to enable payouts to pre-Sapling Z addresses. Sapling fortunately reduces the amount of computation required for payouts to Z addresses and after the upgrade we will re-evaluate if those improvements allow us to support payouts to Sapling Z addresses.
5 Likes
We are happy to announce that all Flypool stratum mining servers are now protected by an enterprise grade DDoS protection supplied by Cloudflare Spectrum. Besides a more secure mining environment this will also improve network latency and reduce stale shares.
Thanks for mining with us!
4 Likes
With block 419200, which was mined by our pool, the Sapling fork has successfully activated. We have re-enabled pool payouts and are closely monitoring the network for any potential issues.
2 Likes
We have started to evaluate the performance of mass payouts for sapling shielded addresses (addresses starting with zsā¦). So far our first results are looking very promising and we should be able to draw a definite conclusion if flypool can support them till latest end of this week.
3 Likes
!!! This would be huge.
Keeping my fingers crossed
We have completed our performance evaluation of the new sapling shielded addresses and concluded that their fast generation time & low resource requirements will allow us to use them for pool payouts. Which means that direct payouts to shielded sapling addresses will be supported by flypool in the future!
Over the coming week we will implement the required changes in our backend and we are confident to have everything finalized in latest 2 weeks time if we do not hit any blocking issues.
Thanks for mining with us.
6 Likes
Awesome news! Keep us posted!
Is there a representative for flypool in this thread?
Why does flypool not follow the stratum protocol when it comes to mining.authorize? Per the protocol, a single connection should allow multiple mining.authorize calls. Flypool does not follow this, and worse, with some finagling, it will provide a valid authorization for more than one wallet, but never pay out, all the while returning ātrueā to the submitted shares. Which leads to my next questionā¦
Why does flypool accept shares for wallets and then never associate the shares with the wallet? The simplest case is one where you mining.authorize walletA but perform all of the mining.submits with walletB.
In that scenario, flypool acknowledges the share acceptance for walletB, but never pays walletB. Where do those shares go? Who is keeping them? Why does flypool respond with an acceptance of the shares?
Iāve been using flypool a while and recommending it strongly, but until I can understand this behavior, I can no longer make that recommendation.
This is how flypool responds to a mining.submit with an address it did not accept as authorized:
{āidā:2001,āresultā:true,āerrorā:null}
This is how a proper pool should respond to a mining.submit with an address not authorized:
{āidā:6,āversionā:ā2.0ā,āresultā:false,āerrorā:[24,āUnauthorized Userā,null],āNotificationā:{āmethodā:āā,āparamsā:null}}
The difference is in the first case, flypool seems to take the share. Are there other conditions where flypool silently takes shares?
While trying to investigate this, I was banned from the flypool API.
Thank you,
Jason
1 Like
@efudd thanks for your feedback. Currently our stratum implementation does not allow more than one worker authorization per connection. If you try to authorize a second worker the server will respond with an Invalid request error. All shares submitted will be attributed to the first authorized worker as all subsequent authorization requests within a single connection with fail.
So far you are the first user requesting such a functionality. If this is something needed for your operation we will be able to add support for it immediately. Please note that in order to avoid the server being flooded with random worker names we will have to introduce a soft cap of max authorized workers for each stratum connection.
1 Like
@peter_zcash - thank you for the quick response. Yes, this would be a useful addition for my operation. I am willing to discuss via PM the justification if necessary.
(api ban has since been liftedā¦ i believe it was the timer/query count based ban).
Thank you,
Jason
We are looking for a volunteer that helps us testing direct pool payouts to Sapling shielded addresses. If you want to help us test the new feature please send me a PM.
Thanks for mining with us!
2 Likes
Awesome @peter_zcash ! Do you mind if I Tweet your request for volunteering, or would you prefer to keep it here on the forum for now?
Thanks for your offer but we are only looking for a hand full of testers which we are confident to find with just that announcement.
Ok, thanks for your efforts! 
1 Like
@Shawn BTW resolving Allow z_sendmany to use multiple transparent inputs from different addresses Ā· Issue #3640 Ā· zcash/zcash Ā· GitHub would greatly simplify adding support for Sapling shielded addresses. It is really essential for any mass payout processor to be able to use multiple transparent outputs as inputs to shielded transactions.
3 Likes