|
NiceHashSupport
|
 |
July 06, 2015, 06:44:23 PM
Last edit: July 06, 2015, 06:56:53 PM by NiceHashSupport |
|
You clearly do not understand how our system works. If diff is too low, we will drop connection to protect our miners - so they can hash with full speed. Other services don't do this, thus buyers are exploiting miners by either setting too low or too high diffs.
Why is it so hard to append diff parameter to password?
Why is it so hard to understand that I didn't have to use that before, still don't have to use it with other rentals and my own miners (KNC titans), and even now I tried it at the standard pricing and worked FINE. So I'm back to my opinion that some others have PM-ed me about, that is it possible, you guys are deleting fixed price orders if the price goes up, making higher priced fixed orders USELESS?? All of your reported orders were >10% dead. By the rules, fixed orders gets cancelled if they are more than 10% dead. For standard orders, this ratio is 50%. That is why standard orders work fine for you, because you have constant changing state of alive/dead, which falls inside margins for keeping order if being standard. It is all explained in FAQ. If you order is like that:  you cannot expect us just to let it be and consume available fixed hashing power. |
|
|
|
|
|
|
|
|
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, but full nodes are more resource-heavy, and they must do a lengthy initial syncing process. As a result, lightweight clients with somewhat less security are commonly used.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
thedreamer
Legendary
 Offline
Activity: 1694
Merit: 1002
Go Big or Go Home.....
|
|
July 06, 2015, 07:40:10 PM |
|
How can it be 'dead' if the pool is alive, settings are correct and it's a FIXED order?
I don't understand what decides if an order is dead or not if all that is correct.
|
Go Big or Go Home.
|
|
|
|
NiceHashSupport
|
|
July 06, 2015, 08:04:43 PM |
|
How can it be 'dead' if the pool is alive, settings are correct and it's a FIXED order?
I don't understand what decides if an order is dead or not if all that is correct.
Order is dead when there are no valid stratum connections established with remote pool; reasons for that can be many such as bad link between us and pool, wrong authorization, invalid extranonce sizes... but the most common scenario is when pool switches to low diff, which we do not permit - in such case, we terminate connection thus there is no valid stratum connection established and order is marked as dead. Until reconnect kicks in and if pool provides good diff this time, it stays alive (but only if diff is above 16384). |
|
|
|
thedreamer
Legendary
Offline
Activity: 1694
Merit: 1002
Go Big or Go Home.....
|
|
July 06, 2015, 09:14:15 PM |
|
How can it be 'dead' if the pool is alive, settings are correct and it's a FIXED order?
I don't understand what decides if an order is dead or not if all that is correct.
Order is dead when there are no valid stratum connections established with remote pool; reasons for that can be many such as bad link between us and pool, wrong authorization, invalid extranonce sizes... but the most common scenario is when pool switches to low diff, which we do not permit - in such case, we terminate connection thus there is no valid stratum connection established and order is marked as dead. Until reconnect kicks in and if pool provides good diff this time, it stays alive (but only if diff is above 16384). Yeah that makes sense. I just don't understand why the fixed priced ones got canceled, yet at the same time I had rentals with non-fixed prices when the prices moved above the fixed price ones and those were kept fine. Same pool same settings. Just looks pretty suspicious... |
Go Big or Go Home.
|
|
|
|
NiceHashSupport
|
|
July 07, 2015, 05:30:59 AM |
|
How can it be 'dead' if the pool is alive, settings are correct and it's a FIXED order?
I don't understand what decides if an order is dead or not if all that is correct.
Order is dead when there are no valid stratum connections established with remote pool; reasons for that can be many such as bad link between us and pool, wrong authorization, invalid extranonce sizes... but the most common scenario is when pool switches to low diff, which we do not permit - in such case, we terminate connection thus there is no valid stratum connection established and order is marked as dead. Until reconnect kicks in and if pool provides good diff this time, it stays alive (but only if diff is above 16384). Yeah that makes sense. I just don't understand why the fixed priced ones got canceled, yet at the same time I had rentals with non-fixed prices when the prices moved above the fixed price ones and those were kept fine. Same pool same settings. Just looks pretty suspicious... Because standard orders have higher tolerance for amount of dead time in % as already explained: All of your reported orders were >10% dead. By the rules, fixed orders gets cancelled if they are more than 10% dead. For standard orders, this ratio is 50%. That is why standard orders work fine for you, because you have constant changing state of alive/dead, which falls inside margins for keeping order if being standard. It is all explained in FAQ. |
|
|
|
thedreamer
Legendary
Offline
Activity: 1694
Merit: 1002
Go Big or Go Home.....
|
|
July 07, 2015, 02:35:54 PM |
|
Ok, so I tried 2 fixed orders again with the difficulty set manually to 20,000 which is more than enough, considering even with no difficulty set the pool works 100% from EVERYWHERE else.
My 2 fixed orders were canceled again!
#485018 Fixed
Cancelled - placeholder order
0.4582 0.19824378 0.19824378 0.00% 5.00
#484121 Fixed
Cancelled - placeholder order
0.4775 0.09690300 0.09690300 0.00% 1.50
Either your software is bad since the upgrade or whatever you guys did recently, or you are actively canceling and NOT Honoring your own fixed priced orders as price moves up, which is BAD Business in my book.
I think I'm done trying to have you guys figure it out as you seem biased and blame everything else as I've been told by members of the forum in PM's.
No more renting from you guys. Hope everyone else sees this also as a warning not to waste higher $$ on fixed orders.
|
Go Big or Go Home.
|
|
|
|
NiceHashSupport
|
|
July 07, 2015, 03:36:36 PM |
|
Ok, so I tried 2 fixed orders again with the difficulty set manually to 20,000 which is more than enough, considering even with no difficulty set the pool works 100% from EVERYWHERE else.
My 2 fixed orders were canceled again!
#485018 Fixed
Cancelled - placeholder order
0.4582 0.19824378 0.19824378 0.00% 5.00
#484121 Fixed
Cancelled - placeholder order
0.4775 0.09690300 0.09690300 0.00% 1.50
Either your software is bad since the upgrade or whatever you guys did recently, or you are actively canceling and NOT Honoring your own fixed priced orders as price moves up, which is BAD Business in my book.
I think I'm done trying to have you guys figure it out as you seem biased and blame everything else as I've been told by members of the forum in PM's.
No more renting from you guys. Hope everyone else sees this also as a warning not to waste higher $$ on fixed orders.
If your order is 100% dead, of course, it will be cancelled.  Same goes for your order #484121. Also, after checking your pool password, we immediately saw error: you wrote 1;d=20000 instead of 1,d=20000. Probably pool refused authorization and thus order was dead always. Maybe you should start reading bridge status? Because bridge status clearly reports back what is wrong.... but yet again, you failed to listen us when we told you to check bridge status. |
|
|
|
thedreamer
Legendary
Offline
Activity: 1694
Merit: 1002
Go Big or Go Home.....
|
|
July 08, 2015, 02:05:01 AM |
|
Odd, I always use the pre-set pools from my list which has been '1,d=xxx'.
Not sure why it changed to ';', my bad on that then.
I'll try again with the ',' and we'll see.
Weird..
The bridge status to me is gibberish so it makes no sense to me.
|
Go Big or Go Home.
|
|
|
Raskal
Member
Offline
Activity: 67
Merit: 10
A Fools Paradise Is A Wise Man's Hell
|
|
July 08, 2015, 02:26:29 PM |
|
What causes the Delta % of an order to go into the red. I understand Delta is the difference in measured hashrate between the pool and nicehash, I'm just not sure what causes it? I had a fixed order that was at -100% Delta for a few mins so I was paying for hashrate that wasn't being counted by the pool, it seems strange the nicehash servers can tell the pool isn't getting the hashrate yet it continues to charge for that hashrate. I deleted the worker at the pool and created a new one with the same name which seemed to work, I just want to know what causes a negative delta % and is there anything that can be done on my end to prevent it, also why does the nicehash system allow a -100% delta rental to keep paying for hashrate they aren't showing at the pool?
Thanks
Best Regards
|
|
|
|
|
|
NiceHashSupport
|
|
July 08, 2015, 03:22:36 PM |
|
What causes the Delta % of an order to go into the red. I understand Delta is the difference in measured hashrate between the pool and nicehash, I'm just not sure what causes it? I had a fixed order that was at -100% Delta for a few mins so I was paying for hashrate that wasn't being counted by the pool, it seems strange the nicehash servers can tell the pool isn't getting the hashrate yet it continues to charge for that hashrate. I deleted the worker at the pool and created a new one with the same name which seemed to work, I just want to know what causes a negative delta % and is there anything that can be done on my end to prevent it, also why does the nicehash system allow a -100% delta rental to keep paying for hashrate they aren't showing at the pool?
Thanks
Best Regards
There are probably like 100 possible reasons why there is negative delta; I will just mention few: - Remote pool does not respond to shares being sent (timed-out speed). - Stale shares (remote pool rejects shares as being too late). - Extra rewards being paid on NH for fast job switching (putting high load on miners with fast job switching causes them to not get full mining speed). - Remote pool bans your worker thus rejecting all your shares (this one is very evil one - instead of disconnecting you, remote pool simply rejects all your valid shares - internally, it can use these shares to solve blocks, but does not reward you - we believe all MPOS pools do that and there are several large pools that are doing this nasty trick). - Incorrect remote pool software implementation regarding diff adjustments (some pools do not honour the official stratum specifications that state => diff change affects all next jobs); some pools don't even send starting diff before first job (I think even ckpool does that sometimes). These shares are then rejected by the remote pool as shares above target. - And don't forget about variance. If your pool is working with very high difficulty, miners do not. You will see more steady speed on NH, but fluctuating one on remote pool (because there are not much high shares found, but they count more). As a consequence, delta will fluctuate too. If you set extreme pool diff, you may not find a share for several minutes. In that case, remote pool speed is of course 0. But that does not mean you are not mining. All speeds are calculated out of received shares (and out of received responses from remote pool) and are therefore highly dependent on pool difficulty. |
|
|
|
|
jjjordan
|
|
July 08, 2015, 06:12:26 PM |
|
Any idea why transactions for last 3 payments (14+ hours) are still not confirmed?
|
|
|
|
|
pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
|
July 08, 2015, 06:33:50 PM |
|
Any idea why transactions for last 3 payments (14+ hours) are still not confirmed?
Generalised bitcoin problem. There is a flood of transactions. |
|
|
|
VirosaGITS
Legendary
Offline
Activity: 1302
Merit: 1068
|
|
July 08, 2015, 10:18:18 PM |
|
Any idea why transactions for last 3 payments (14+ hours) are still not confirmed?
Generalised bitcoin problem. There is a flood of transactions. Today's payment report a different error, it says; Transaction rejected by our node. Reason: The Maximum number of outputs in a single transaction is 200 First time i see this. Either its the error it revert to when its getting flooded or the transaction was actually rejected by the network because it has too many outputs. https://blockchain.info/search?search=155db70e686bbae5c7a9f8253a194274af0e4556f5e5a1c024973a6bf71ba296 |
|
|
|
|
NiceHashSupport
|
|
July 08, 2015, 10:21:04 PM |
|
Any idea why transactions for last 3 payments (14+ hours) are still not confirmed?
Generalised bitcoin problem. There is a flood of transactions. Today's payment report a different error, it says; Transaction rejected by our node. Reason: The Maximum number of outputs in a single transaction is 200 First time i see this. Either its the error it revert to when its getting flooded or the transaction was actually rejected by the network because it has too many outputs. https://blockchain.info/search?search=155db70e686bbae5c7a9f8253a194274af0e4556f5e5a1c024973a6bf71ba296That is just blockchain, nothing to do how miners see transactions. It is perfectly valid transaction, created by BitGo. |
|
|
|
anamichii
Sr. Member
Offline
Activity: 287
Merit: 250
Global economic crisis? i hold my bitcoin..
|
|
July 08, 2015, 11:34:30 PM |
|
uh my deposit is always take so looooooooooooooooooooooooong to confirmed, it happen from 2 days ago..
it caused by bitcoin stressed test or what?
|
|
|
|
|
kae1078
Member
Offline
Activity: 78
Merit: 10
Kupla Kudos Coming Ur Way!
|
|
July 09, 2015, 02:59:16 AM
Last edit: July 09, 2015, 03:24:15 AM by kae1078 |
|
Hi there,
Why is it that it's taking too long for confirmation, my payout has been stuck for the last 12 hours? (Stuck in limbo)
Should I be worried or this is just normal?
|
|
|
|
|
|
innerchaos
|
|
July 09, 2015, 04:22:11 AM |
|
obviously something is different.. so why dont you try something different instead of just blaming everyone else..
perhaps you could reduce the number of transactions
or perhaps you could raise the transaction fee ...I mean you are charging your customers 2% transaction fee... why dont you put a little of that on the actual transaction instead of making a 25 cent transaction fee every single time.
at least try something.
Your customers use you and depend on your service.. well its time to service us.. and show us what the term Customer Service Means
|
|
|
|
|
|
|
|
NiceHashSupport
|
|
July 09, 2015, 07:11:18 AM |
|
obviously something is different.. so why dont you try something different instead of just blaming everyone else..
perhaps you could reduce the number of transactions
or perhaps you could raise the transaction fee ...I mean you are charging your customers 2% transaction fee... why dont you put a little of that on the actual transaction instead of making a 25 cent transaction fee every single time.
at least try something.
Your customers use you and depend on your service.. well its time to service us.. and show us what the term Customer Service Means
Unfortunately, transaction fee is not something what we control, but is automatically adjusted by BitGo. We have already contacted them and are looking for a solutions to this problem. Making transactions smaller would not help, they would get even smaller fees, and cause another problem - we may run out of inputs due to 4 times per day payment schedule (already happened when we had smaller transactions). |
|
|
|
|
|
|
