|
|
|
|
|
NiceHashSupport
|
 |
July 09, 2015, 07:40:04 AM |
|
blockchain.info and even some mining pools (like eligius) are filtering out valid transactions. I replied to eligius claims of 'filtering being good' here: https://bitcointalk.org/index.php?topic=1098263.msg11759025#msg11759025They just ignored this matter. Now if one pool is filtering out good transactions, god knows how many of other pools are doing the same. To the question how to get btc; wait until it is confirmed. |
|
|
|
|
CohibAA
|
|
July 09, 2015, 07:40:34 AM |
|
Blockchain.info is buggy AF. Transaction rejected by our node. Reason: The Maximum number of outputs in a single transaction is 200 This is a limit they set on their mempool. The transaction is being relayed to lots of nodes, but it hasn't been mined, because most normal fee transactions are about 16+ hours behind getting included on the full blockchain, and getting worse due to the spam attack. |
|
|
|
|
Lucko
|
|
July 09, 2015, 07:58:32 AM |
|
Well it probably isn't just BC that rejected this transaction. I have 2 addresses in 2 different wallets and I can't see unconfirmed transaction in them... For a short time I have seen one in mycelium but now it is gone...
|
|
|
|
|
|
NiceHashSupport
|
|
July 09, 2015, 09:10:27 AM |
|
We have just updated BitGo proxy software. It was promised that this should fix the problem and the fees would be higher now.
|
|
|
|
chrysophylax
Legendary
 Offline
Activity: 2828
Merit: 1091
--- ChainWorks Industries ---
|
|
July 09, 2015, 09:59:02 AM |
|
blockchain.info and even some mining pools (like eligius) are filtering out valid transactions. I replied to eligius claims of 'filtering being good' here: https://bitcointalk.org/index.php?topic=1098263.msg11759025#msg11759025They just ignored this matter. Now if one pool is filtering out good transactions, god knows how many of other pools are doing the same. To the question how to get btc; wait until it is confirmed. good call ... though i would think the confirmation will take a while ... but it WILL come through ... #crysx |
|
|
|
|
|
anamichii
Sr. Member
Offline
Activity: 287
Merit: 250
Global economic crisis? i hold my bitcoin..
|
|
July 09, 2015, 01:46:52 PM |
|
|
|
|
|
|
|
NiceHashSupport
|
|
July 09, 2015, 02:19:11 PM |
|
Unfortunately, nothing we can do about it. As discussed before already, confirmations are miners discretion. |
|
|
|
thedreamer
Legendary
Offline
Activity: 1694
Merit: 1002
Go Big or Go Home.....
|
|
July 09, 2015, 07:32:39 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?
My deposits are quick, but I always send with a 6block speed. Not the fee-less that times out always. On another note, the issue I've had with my fixed orders seems to be all set now. Thanks nicehash support on here for helping out. I seemed irate, but I've never had issues with using the pools with no difficulty set before, and all of the sudden my fixed orders were getting canceled. Seemed suspect. Seems ok now though if I specify correctly difficulty manually now. Thanks. |
Go Big or Go Home.
|
|
|
|
NiceHashSupport
|
|
July 13, 2015, 02:14:53 PM |
|
this system kills all of my fixed scrypt orders sooner or later,
actually i can't rent anymore, 12 different pools - no luck.
how that happened, what's changed ?
Give us order # and we will take a look into it. In most cases, problem is too low difficulty. Just make sure you use high difficulty and everything will be fine. |
|
|
|
|
Automatic Monkey
|
|
July 13, 2015, 02:24:13 PM |
|
NiceHash on P2Pool.
I'm new to P2Pool. What's the best way to do this? I know latency time to the pool node is imperative, but when using Nice/West is that the time from the Nice/West servers or from the miners themselves? How does one determine what is the best node to use?
|
Try ShadowCash, the first coin with instant and decentralized private transactions!
SDC address: SUPERMAN8eDvcPL6RWYMVwtPzUtqWi2zCr
Wallet Private Key: 7S6fJBEzXqJuuGCvEPcgBSbd5wmjVTvDj7591gNKcTmS7X47e98
|
|
|
|
NiceHashSupport
|
|
July 13, 2015, 03:32:11 PM |
|
this system kills all of my fixed scrypt orders sooner or later,
actually i can't rent anymore, 12 different pools - no luck.
how that happened, what's changed ?
Give us order # and we will take a look into it. In most cases, problem is too low difficulty. Just make sure you use high difficulty and everything will be fine. my last attempts that were killed #495299, #495264. the rest of them simply couldn't start... I ran your pool through pool verificator and got following result:  Your pool isn't using high enough difficulty. NiceHash on P2Pool.
I'm new to P2Pool. What's the best way to do this? I know latency time to the pool node is imperative, but when using Nice/West is that the time from the Nice/West servers or from the miners themselves? How does one determine what is the best node to use?
Use node that is closest to Amsterdam if you plan to use NiceHash or closest to San Jose (CA) if you plan to use WestHash. |
|
|
|
|
Automatic Monkey
|
|
July 13, 2015, 04:21:43 PM |
|
NiceHash on P2Pool.
I'm new to P2Pool. What's the best way to do this? I know latency time to the pool node is imperative, but when using Nice/West is that the time from the Nice/West servers or from the miners themselves? How does one determine what is the best node to use?
Use node that is closest to Amsterdam if you plan to use NiceHash or closest to San Jose (CA) if you plan to use WestHash. Thanks for the info. Maybe someday you can set up P2Pool nodes right in your facilities in Amsterdam and San Jose, for maximum efficiency. That way we will always know exactly what node to connect to. I would happily pay a small fee for that much efficiency. |
Try ShadowCash, the first coin with instant and decentralized private transactions!
SDC address: SUPERMAN8eDvcPL6RWYMVwtPzUtqWi2zCr
Wallet Private Key: 7S6fJBEzXqJuuGCvEPcgBSbd5wmjVTvDj7591gNKcTmS7X47e98
|
|
|
|
NiceHashSupport
|
|
July 13, 2015, 04:44:15 PM |
|
NiceHash on P2Pool.
I'm new to P2Pool. What's the best way to do this? I know latency time to the pool node is imperative, but when using Nice/West is that the time from the Nice/West servers or from the miners themselves? How does one determine what is the best node to use?
Use node that is closest to Amsterdam if you plan to use NiceHash or closest to San Jose (CA) if you plan to use WestHash. Thanks for the info. Maybe someday you can set up P2Pool nodes right in your facilities in Amsterdam and San Jose, for maximum efficiency. That way we will always know exactly what node to connect to. I would happily pay a small fee for that much efficiency. Any professionally hosted node in Amsterdam or San Jose will have <3 ms latency to us. We do not have plans to make such nodes on our own. |
|
|
|
|
NiceHashSupport
|
|
July 13, 2015, 07:54:50 PM |
|
Your pool isn't using high enough difficulty.
this only means nicehash is incompatible with its vardiff behaviour these days, becoz when i started, the diff was insane 90k not 4k. coinmine.pw, coinotron, ipominer, and even 3-4 pools on suprnova, the same shit. all of them were ok a month ago, that's why i asked what changed ... i just noticed the fixed rent gets killed every time when price jumps Most of pools offer you ability to choose difficulty (via password for example) or they have high diff ports. Most of Scrypt pools are still stuck with old diff configs, when Scrypt was mined with GPUs. Diffs below 1024 were normal that time, but todays ASICs are 100-500x times faster thus they need 100-500x higher diff. As explained already 2 pages back to another person who had the same problem, fixed orders have very small tolerance for dead time They get cancelled if being dead for more than 10% of the time. |
|
|
|
|
NiceHashSupport
|
|
July 13, 2015, 08:16:30 PM |
|
Your pool isn't using high enough difficulty.
this only means nicehash is incompatible with its vardiff behaviour these days, becoz when i started, the diff was insane 90k not 4k. coinmine.pw, coinotron, ipominer, and even 3-4 pools on suprnova, the same shit. all of them were ok a month ago, that's why i asked what changed ... i just noticed the fixed rent gets killed every time when price jumps Most of pools offer you ability to choose difficulty (via password for example) or they have high diff ports. Most of Scrypt pools are still stuck with old diff configs, when Scrypt was mined with GPUs. Diffs below 1024 were normal that time, but todays ASICs are 100-500x times faster thus they need 100-500x higher diff. As explained already 2 pages back to another person who had the same problem, fixed orders have very small tolerance for dead time They get cancelled if being dead for more than 10% of the time. well, that's it, 10%, and seems i've no use of fixed orders then. as per theory, 6**** ports of cryptopia are just those high diff ones, but that doesn't help, and suprnova "nicehash" ports don't help either, those 10% deadtime happen to occur no matter, or at least nicehash engine counts like that. thanks anyway..... Contact the pool you mine at and ask them for a diff raise. Using a diff 16384 is nothing unusual today and this is still very low diff for fast modern ASICs. It is just a matter of setting value in pool's config. |
|
|
|
|
NiceHashSupport
|
|
July 13, 2015, 08:31:41 PM |
|
Your pool isn't using high enough difficulty.
this only means nicehash is incompatible with its vardiff behaviour these days, becoz when i started, the diff was insane 90k not 4k. coinmine.pw, coinotron, ipominer, and even 3-4 pools on suprnova, the same shit. all of them were ok a month ago, that's why i asked what changed ... i just noticed the fixed rent gets killed every time when price jumps Most of pools offer you ability to choose difficulty (via password for example) or they have high diff ports. Most of Scrypt pools are still stuck with old diff configs, when Scrypt was mined with GPUs. Diffs below 1024 were normal that time, but todays ASICs are 100-500x times faster thus they need 100-500x higher diff. As explained already 2 pages back to another person who had the same problem, fixed orders have very small tolerance for dead time They get cancelled if being dead for more than 10% of the time. well, that's it, 10%, and seems i've no use of fixed orders then. as per theory, 6**** ports of cryptopia are just those high diff ones, but that doesn't help, and suprnova "nicehash" ports don't help either, those 10% deadtime happen to occur no matter, or at least nicehash engine counts like that. thanks anyway..... Contact the pool you mine at and ask them for a diff raise. Using a diff 16384 is nothing unusual today and this is still very low diff for fast modern ASICs. It is just a matter of setting value in pool's config. i used high diff ports wherever possible, or manually set as on ipominer for example. but that doesn't help, fixed jobs die in 30 min maximum What was the diff on these ports? If it was 4096 like in that order # you provided - that is not high diff port, that is low diff port. It would have been high diff port 1 year ago, but not today with 400MHs titans running around. |
|
|
|
|
NiceHashSupport
|
|
July 13, 2015, 08:53:10 PM |
|
Your pool isn't using high enough difficulty.
this only means nicehash is incompatible with its vardiff behaviour these days, becoz when i started, the diff was insane 90k not 4k. coinmine.pw, coinotron, ipominer, and even 3-4 pools on suprnova, the same shit. all of them were ok a month ago, that's why i asked what changed ... i just noticed the fixed rent gets killed every time when price jumps Most of pools offer you ability to choose difficulty (via password for example) or they have high diff ports. Most of Scrypt pools are still stuck with old diff configs, when Scrypt was mined with GPUs. Diffs below 1024 were normal that time, but todays ASICs are 100-500x times faster thus they need 100-500x higher diff. As explained already 2 pages back to another person who had the same problem, fixed orders have very small tolerance for dead time They get cancelled if being dead for more than 10% of the time. well, that's it, 10%, and seems i've no use of fixed orders then. as per theory, 6**** ports of cryptopia are just those high diff ones, but that doesn't help, and suprnova "nicehash" ports don't help either, those 10% deadtime happen to occur no matter, or at least nicehash engine counts like that. thanks anyway..... Contact the pool you mine at and ask them for a diff raise. Using a diff 16384 is nothing unusual today and this is still very low diff for fast modern ASICs. It is just a matter of setting value in pool's config. i used high diff ports wherever possible, or manually set as on ipominer for example. but that doesn't help, fixed jobs die in 30 min maximum What was the diff on these ports? If it was 4096 like in that order # you provided - that is not high diff port, that is low diff port. It would have been high diff port 1 year ago, but not today with 400MHs titans running around. the diff on cryptopia was 90k soon afetr the start, that diff is NOT appropriate for 80MH/s, after it reached that value pool dropped, so your engine started counting deadtime, then it revives again from 1024-2048 and goes higher until next drop, that's how it works, and not only for cryptopia, probably that's why those 10% are being accumulated very soon and order gets killed. When you closely monitor order before it goes into dead, you can see bridge status. What kind of status is reported once order gets dead? |
|
|
|
|
