 Show Posts
|
|
Pages: [1] 2 3 4 »
|
|
Just got them from Bitmain. Haven't even opened the shipping box. Want $1800 a piece (or equiv BTC at time of trade). I live in Monroe, Michigan, and would prefer to trade in person to avoid Escrow fees. I have PSU's for both available as well, $150 a piece or equiv BTC ofc.
Email me, dunno if I'll remember to check the forum.
|
|
|
|
Correct. Everything seems to work, nothing happens weird on any software, be it the electrum wallet or coinomi. Only, no BCH shows up anywhere.
I think I'll just take the electron cash route soon. Moving coins to a safe wallet, then importing the electrum seed to electron cash. Seems to be the most reliable way, even though I wanted to stay away from Electron cash if possible.
As a follow up to all my previous posts, it seems as though Coinomi pushed an update on the Play Store (today? last week?), and everything works as it should now. I once again attempted to split my coins using the OP's method, and after the update, it has worked with no problems. The BCH are split successfully in to my Android Coinomi wallet, and the Bitcoin in my Electrum wallet is still there. Yes, I imported my keys without moving them first. Here to report that everything is fine now. It seems there was a bug causing things to not be imported properly, until today, I suppose. I tried again right after Coinomi updated, and everything worked as explained. |
|
|
|
you did the BCH sweep wallet using your still visible and current BTC pre-fork addresses, it appeared to work, and yet you can't see any BCH in your Coinomi wallet. Right?
Correct. Everything seems to work, nothing happens weird on any software, be it the electrum wallet or coinomi. Only, no BCH shows up anywhere. I think I'll just take the electron cash route soon. Moving coins to a safe wallet, then importing the electrum seed to electron cash. Seems to be the most reliable way, even though I wanted to stay away from Electron cash if possible. |
|
|
|
Did you still have your BTC in your Windows Electrum when you tried this?
Yes. Everything seemed to work as expected, no errors, no weird things from the source wallet, nothing. Only, I don't have my BCH in Coinomi either. Not sure what to think at this point. |
|
|
|
|
So I as well attempted to sweep my private key from Electrum(Windows) into Coinomi(Android) to get my BCH.
Followed the instructions, and it seemed to go through just fine. I had some coins under Receiving, and under a Change address. I sweeped both of those, and Coinomi didnt throw any errors, nor did it say it was empty or anything like that. It loaded, said it was creating a transaction, and seemed to finish, taking me back to the main screen of the BCH wallet. But no transaction was created, nor do I have any more BCH. Some people here said to try expanding the Used addresses section, and sweeping that. Electrum said it was empty, with 2 Tx, but I tried anyway. Coinomi then said it was empty as well, with an error. Seems to make sense.
But I still have nothing. Of course, I just did it. Maybe it takes time? I will post again later if anything happens.
|
|
|
|
|
rJByjnYD5oEScYNLiV1w9d4zmpLXDJnMXz
|
|
|
|
Right, this seems pretty dead on. Try turning off your bitcoind (if you're on 0.8.1 anyway, which by your post I'm assuming that's your problem) when the lag seems pretty bad to see if it goes away like we did. We also realized that this started happening about the same time we upgraded to 0.8.1. Only thing is that your lag stops when you stop mining? Well, turns out that mining had nothing to do with it...Just a coincidence that led me to believe so. Closing the 0.8.0 client makes my high latency go away almost instantly. Thanks so much to Doc and farfie for bringing up this topic. The high latency was driving me nuts when gaming! No problem. If what was said in an earlier post was true, hopefully they'll add a way to cap the upload/download on bitcoin-qt in the settings or something. Could QoS or use other software to do it, but I'd still rather just see the feature implemented. Sorry for OT discussion. |
|
|
|
Sorry for downtime. We are back up.
bitcoind 0.8.1 seems to have a memory leak, it sometimes expands to several gigabytes of memory usage.
I'll see what I can do to prevent this in the future.
And yeah, backup pool support is at the top of the list, right after ASIC support for the miner.
This isn't really related to the pool, but since you mentioned bugs, my friend and I have noticed another bug about 0.8.1 (or perhaps an extension of the one you already mentioned) that it also causes massive lag when running. It introduces jitter and cuts my speeds down by about 50% give or take it seems, and we verified it many times by letting it run, and turning it off to instantly watch our internet become 100% better instantly. We were wondering if anyone else has noticed this, or could try it and see? It actually took awhile for us to notice what was causing it, but we were pretty sure something was up (before we knew it was the bitcoin client). The problem was that it's not really a stable lag, and looking back I have no idea how often it would be. Definitely enough to make us angry very often. We both run Windows 7. Thanks for any input. Farfie I don't know if this is related to what you're talking about, but figured I'd chime in. For a few weeks now, my Internet connection has had horrible latency (up to 500ms) on and off when mining with two mini-rigs. This does not occur if I stop mining. I restart my network equipment and it's fixed for a while, but the issue comes back in short order. Right, this seems pretty dead on. Try turning off your bitcoind (if you're on 0.8.1 anyway, which by your post I'm assuming that's your problem) when the lag seems pretty bad to see if it goes away like we did. We also realized that this started happening about the same time we upgraded to 0.8.1. Only thing is that your lag stops when you stop mining? I also have two mini-rigs, but my lag goes away if I simply turn off bitcoind. My buddy also only has a few singles, and had lag just as bad as mine, which was fixed by also turning his bitcoind off. Try it out. |
|
|
|
Sorry for downtime. We are back up.
bitcoind 0.8.1 seems to have a memory leak, it sometimes expands to several gigabytes of memory usage.
I'll see what I can do to prevent this in the future.
And yeah, backup pool support is at the top of the list, right after ASIC support for the miner.
This isn't really related to the pool, but since you mentioned bugs, my friend and I have noticed another bug about 0.8.1 (or perhaps an extension of the one you already mentioned) that it also causes massive lag when running. It introduces jitter and cuts my speeds down by about 50% give or take it seems, and we verified it many times by letting it run, and turning it off to instantly watch our internet become 100% better instantly. We were wondering if anyone else has noticed this, or could try it and see? It actually took awhile for us to notice what was causing it, but we were pretty sure something was up (before we knew it was the bitcoin client). The problem was that it's not really a stable lag, and looking back I have no idea how often it would be. Definitely enough to make us angry very often. We both run Windows 7. Thanks for any input. Farfie |
|
|
|
|
Hey ck,
Could we get a link to the WinUSB drivers in the OP? Sorry if this was asked already before and rejected,
but it feels weird not being able to find it there, even if it is in the FPGA readme.
Thanks,
Bryce
|
|
|
|
I'd argue that you'd still have to install 7z or some program that can deal properly with zip files. While I haven't tried Vista's and 7's implementation, at least XP's was pretty broken. (Stuff like random error messages for proper zip files or files in an archive being silently ignored.) I have a friend who stopped supporting people who used windows' zip to extract his program because he knew that'd fail. So, please, if you want to continue using that POS, go ahead, but do stop spamming this thread about it...  Pretty much everyone's needs something that supports zip and rar files. Not sure why you assume I use winzip, but I don't. I do think its better to use a compression everyone already needs support for, unless there is a reason to do otherwise. Off-topic, but like ck was saying, I can't believe someone that's so ahead of the curve technology wise (by even USING bitcoin) would be so against this. And then he goes on saying how there's "no point to using 7z". But there is a point, it's a better program, and the files it generates are better in every way, not to mention how lightweight 7z is in the first place. Do you still use XP? A dumbphone? CRT television? Even if you do, it doesn't make you right, and doesn't mean you're making the right choice. Technology won't stagnate just because you're unwilling to move forward with the rest of us. That's the whole point of technology in the first place, since it seems you have forgotten. But then you also had the gall to come in here with your ignorance, complain about 7z while arguing with multiple people as if you knew it wasn't a good program. Does it ever end? Hey guys, I can't seem to run CGMiner with the --scrypt option. I always run into the following error, followed by CGMiner disabling all GPUs and the crashing (dialog of the program is not responding comes up). Anyone know why? I have 3 5970s.  Sorry if this is obvious, but first, try using the latest cgminer. Also, that little echo script thing you have goin on is mega cute bro. Mad props. |
|
|
|
What are you guys using when there is more then one COM in the double digits? This was my best idea and it's not working
-S COM8 -S COM9 -S \\.\COM10 -S \\.\COM11
cgminer should automatically see BFL devices by itself now, unless you're using something else. Also, I think 2.6.5 is in the spot for 2.6.6 @ "cgminer-2.6.6-x86_64-built.tar.bz2". |
|
|
|
Hard lock. Where the thing just locks at whatever it was doing and stops accepting input. Monitor continues to output video, but nothing is animated of course. It's a video card freeze. Are your video cards overclocked or undervolted? If it happens again, try to ssh from another box if you can. Have to hold down the power button to reset. Didn't you try the magic sysrq keys (in Linux, of course)? Sync first (S), then remount ro (U), then reboot (B). http://en.wikipedia.org/wiki/Magic_SysRq_key-- Bye I guess your post does reveal my vagueness. First off I don't GPU mine, and while I definitely expect Linux's GPU drivers to be flaky, I've never had a problem on my Windows machine... ever. And even with knowing that Linux has crap for GPU drivers, I've never had a problem on that machine before either. But then both freeze soon after 2.7.4? Either way, both cards are on stock settings and are not being used to mine either. I have only BFL devices. Again, not trying to point fingers but it does seem pretty coincidental. About your magic keys, no I didn't do that. I know nothing about Linux, and maybe a little more about coding. Took C, C++, Java, VB back in college, never went anywhere with it. But I do know that code gets extremely complex, and when you have someone (like ck here) that loves to hack at his code, I try to bring any possibility of problem along in here because it's a rare opportunity to have such a close, ongoing communication between the main developer of -any- widely used software. This is because that even if your problem doesn't bring any bug kill to fruition, you never quite know how you're poking his brain with your words  ..not that I don't think you know all of this. But some here might find this useful. I will wait for both machines to freeze in a similar manner, and if it happens go back to 2.6.6 and wait for another freeze. |
|
|
|
|
Not trying to say cgminer caused this, but I had my Ubuntu machine freeze on me yesterday and that has literally never happened before... thought nothing of it at first, but now just tonight my Windows 7 machine just froze as well... that also hasn't happened, in probably a few YEARS. And they both just happen to be running 2.7.4 now.
Coincidence? Maybe..
Hard lock. Where the thing just locks at whatever it was doing and stops accepting input. Monitor continues to output video, but nothing is animated of course. Have to hold down the power button to reset. Both computers froze in the same fashion.
Again, no clue if cgminer is even capable of freezing a computer but this just seems way too coincidental to not mention.
The other thing is that they're both operating in very different environments. Both on their own electric circuit, one has an AMD card while the other nVidia, and on the Ubuntu machine cgminer is literally the only process running. I mean cgminer is the only common denominator, literally, outside of both pc's having an intel processor.
But you would think something like this would be reported already. I don't know, I'll keep an eye out.
Other than that, only other thing that's off is that when I start 2.7.4 on the 60GH machine, I get a massive log full of "pool not providing work fast enough" right at the beginning. Like 16 lines, heh. Just an aesthetic thing if anything.
|
|
|
|
My bonuspool account went apeshit exactly like that for a little while a few hours ago. I switched a couple parts around in my rigs so I wasn't sure if it was a hardware issue, but it seems to have gone away.
I don't think it's bonuspool. The common element was that we both had a pool go down. I use Eclipse and mtred, and when Eclipse went down this morning, I manually added mtred because it wasn't in the config at the time. Later on, I realized Eclipse had come up and was up for awhile, but the miner was doing -exactly- what Morblias was saying: except that I switched it myself, and it was failing to switch back. Actually, I didn't even switch it - I just added mtred manually while it was running, and it went over to mtred on it's own. Of course at first I expected the errors it was giving... because the pool was down. I even checked using ping.eu's port checker function and 8337 on eclipse was closed for all Eclipse servers. Later on when I knew the pool was up, the miner was doing exactly the same thing. Sitting on mtred, and saying Eclipse was down. I even checked again with ping.eu to make sure, and indeed Eclipse was up. So I just closed the miner, repoened it, and voila, connection to Eclipse. I think this is pretty solid evidence |
|
|
|
When I went to 2.7.1, at some point one of my cgminers switched pools, and then would not switch back:  Bonuspool is definitely up and the cgminer on the right is connected to it, but on the left, it keeps saying it is online, won't switch to it, stays on pool 1, then says pool 0 is not responding (even though it isn't offline). I can confirm this. At first I thought it was because I manually added a pool while cgminer was running and that messed it up, but now he's posting a similar issue. Did you add a pool like me or did it switch and fail to switch back on its own Morblias? |
|
|
|
On second thought, there may be a bug here... will investigate tomorrow.
I suppose I'll start integrity checking some of my equipment. The route from this single to my bitcoind is windows client -> router -> switch -> windows host. I am thinking the switch is perhaps seeing the end of its days if it does not result as a bug. But I never really noticed any performance problems with anything... I could perhaps try downloading something that would max my bandwidth on the bitcoind machine, or comparing speedtest results between it and my machine that's not behind the switch. Sorry, not related to cgminer, but my fingers are moving on their own... |
|
|
|
It's not the default, it's just that a local bitcoind is actually really quite slow compared to a pool. You probably want to enable --failover-only to cope.
I see... But, and I hate to pester, that raises so many questions in my head. Wouldn't doing that mean my machines are definitely not working anywhere near what they're supposed to be? And then, if bitcoind is really THAT slow, I don't see how solo mining was ever worth it.. here's a picture of solo mining with one bfl single for ~30 minutes. This was the only device solo mining on the network at the time:  More than half of the work is going toward pool 2 (pool 1 is down, probably a coincidence). I mean, is it only not complaining that pool 0 is too slow because it can grab work from pool 2? Or is it designed to not put those kinds of errors when soloing? Pretty sure I've seen them before when solo, on an NB or something.. Here we have soloing now with --failover-only, ~45 minutes, everything else the same (even pool 1 is still down  ) :  Sorry about the disparity in uptime, but the last prompt makes me believe that bitcoind is only fast enough to provide half of what the single can handle. Temps are also the same, so it's safe to assume the single is being worked pretty closely to the last prompt as well. Everything is the same.. not sure if that matters but it seems to matter. But if I'm misunderstanding all of this, which is fine; what is the "limit" of bitcoind in GH/s? Will solo'ing on one of those new ASIC mini-rigs basically be a no-go? I appreciate learning about this as it interests me greatly. |
|
|
|
I must be misunderstanding something, or perhaps the default is different and I don't know it? But when I'm solo mining, tons of shares are going to other pools. But it doesn't happen when I'm not solo.. is there some kind of flag I need to use? It's acting like --balance when it's not enabled, only when I'm solo mining though. I would take from this that --balance is the new default, but it's not like it does that if I simply change to work for a pool instead of going solo. I am so confused, haha.  |
|
|
|
The nonce size in bitcoin is too small - it is 32bits (sorta like MS-DOS saying 640K will always be big enough) Each piece of work you get from a pool allows you to attempt 2^32 (~4 billion) hashes - i.e. one for each nonce value. For a single MiniRig, this means that you need to get over 350 pieces of work from the pool per minute. The hack solution to this, that someone come up with in the past, was to instead edit the time field (roll it forward) Thus if you add 1 second to the time field, you can then do another 4 billion hashes on the same piece of work you got from the pool (without having to ask for and wait for more work from the pool) since you are now hashing something different. Thus most pools now support this. If they don't - get a new pool. It means you get less work from the pool to do the same amount of hashing. The E: % value will tell you how much less. e.g. if you have an E: of 200% that means you are rolling each piece of work you get, on average, once Thus you are getting half as much work from the pool to do the same amount of hashing. If a pool doesn't support roll-n-time then perfect "no rolling" E: is 100% It doesn't reduce the number of shares you have to send back to the pool however. The pool would have to support high difficulty shares to reduce that also. But it does reduce the amount of work you request from the pool. You can add up to 7200 seconds to the time field and bitcoind will still accept it as a valid block solution if you find a block ... thus why the timestamps in the bitcoin blockchain are not to be taken too seriously. A larger nonce range in bitcoin would solve this correctly, rather than a time hack, however that would require a hard fork, and the bitcoin devs are scared of hard forks coz they do soft forks so badly. https://bitcointalk.org/index.php?topic=89278.0Edit: The other solution (that no doubt, one of which will be used) that are being bandied about are to move the pools work to the miner. Thus pretty much all the pool will be doing is counting shares. The miner (or some other program run by the miner) will be doing the work of dealing with longpolls, transaction selection and everything related to that. If this were to take place, then I would suggest anyone who implements such a solution, also put a fee in the coinbase to cover the work you are doing for the pool ......... Sort of related, I had a different question - is it possible for you guys to do the opposite of how you will grab long poll from a different pool that you have set up if the primary pool does not support it, so that you could add a local bitcoin client to check for blocks that could possibly find a new one before long poll does? There's no way I'd be the first to think of this, so I just assumed it's not doable, or perhaps not worth doing? Just curious I guess. edit: typo |
|
|
|
|
