First of all thanks to salfter for all the hard work to code PyCrypsty -- bitcoins coming your way.
PyCrypsty was working great until an error occurred around line 222 in Cryptoswithcer caused by line 80 in PyCrypsty. Error "Unbound Local Error: local variable 'mkt_id' referenced before assignment.
This error causes a fatal error in Cryptoswitcher. After this fatal error occurs when you try to run Cryptoswitcher again, BTC-E Api returns "invalid noonce parameter". I think the error caused by PyCrypsty causes the Cryptoswitcher to exit without saving the incremented noonce value to the BTC-E key file.
mkt_id comes back null (or "None," as Python calls it) if a currency trading pair can't be found on Cryptsy (whether due to a communication error or because that pair isn't traded). PyCryptsy now catches this condition in its helper methods and should respond in a less-crashy manner. |
|
|
|
First of all thanks to salfter for all the hard work to code PyCrypsty -- bitcoins coming your way.
PyCrypsty was working great until an error occurred around line 222 in Cryptoswithcer caused by line 80 in PyCrypsty. Error "Unbound Local Error: local variable 'mkt_id' referenced before assignment.
This error causes a fatal error in Cryptoswitcher. After this fatal error occurs when you try to run Cryptoswitcher again, BTC-E Api returns "invalid noonce parameter". I think the error caused by PyCrypsty causes the Cryptoswitcher to exit without saving the incremented noonce value to the BTC-E key file.
I think there needs to be error handling in Cryptoswitcher around line 581 and 593 to prevent submodules from causing fatal errors in Cryptoswitcher.
Error Below:
Traceback (most recent call last):
File "F:\Users\CryptoSwitcher\cryptoSwitcher.py", line 593, in <module
>
sellCoinCryptsy(abbreviation)
File "F:\Users\CryptoSwitcher\cryptoSwitcher.py", line 222, in sellCoi
nCryptsy
acct.CreateSellOrder(coin, "BTC", bal, acct.GetBuyPrice(coin, "BTC")*tradeMu
ltiplier)
File "./PyCryptsy/PyCryptsy.py", line 84, in GetBuyPrice
r=self.Query("marketorders", {"marketid": self.GetMarketID(src, dest)})
File "./PyCryptsy/PyCryptsy.py", line 80, in GetMarketID
return mkt_id
UnboundLocalError: local variable 'mkt_id' referenced before assignment
Yeah, there's probably not as much exception handling as there should be. I'm looking into it. |
|
|
|
Salfter if I had coins to spare I'd donate, your software gives me piece of mind while I'm at work. One thing I'd like is to be able to specify different cgminer.confs to use for each coin. You can do that with the script (or batch file) you use to start the miner for each coin: cgminer --config=cgminer.conf.bitcoin ... |
|
|
|
I'm seeing only 84% efficiency with mine. What settings are you using? My miner name has +256 appended to it. A poster in the BFL forums is using /6000 and is getting results more like yours than mine. Given that share difficulty is only 1080 as I write this, though, wouldn't setting difficulty too high risk throwing out valid shares?
What would be a good input to have to guess how good these ASICs are would be people comparing what their efficiency was with low-latency mining devices (GPUs/Icarus/Cairnsmore1/Ztex/...) and what is their efficiency with their BFL ASIC without any p2pool node reconfiguration. If they have a mixed setup, knowing the total hashrate of the low-latency devices and the total hashrate of the BFL ASICs can do too. Warning: don't use different payout addresses on your node: it currently adds latency in the P2Pool process and would lower efficiency. Currently they don't seem horrible: 84% efficiency is the worst I'm aware of. It's bad but not far from what is good enough to make it almost as good as most pools (I consider the 90-95% range to be where P2Pool starts to be the best solution for mining). Try to tune your setup according to my guide to see if you can reach a better efficiency (see my sig). I've done that...average bitcoind latency seems to be hanging around 300 ms since the upgrade to 0.8.2. With 0.8.1, I was seeing multiple-second latencies. Over the weekend, efficiency went up slightly to around 86%. I've switched from +256 to /6000 to see if that makes any difference; it's only been running a few minutes, but the 204 rejected shares to 642 accepted shares so far isn't much different than what I was already getting. I double-checked my router QoS settings; p2pool traffic is running at a high priority. One thing: my P2Pool node is at home, but my Jalapeņos are at work. Ping times tend to run 30-50 ms; both LANs are connected through Cox. Would even this little bit of added latency be enough to throw my efficiency into the basement? By "don't use different payout addresses," are you suggesting that I should use an address from the bitcoind wallet, or only that I shouldn't use the "mine-to-the-address-in-the-username" feature (which I don't use)? In any case, it looks like I should see some benefit from the upcoming changes to P2Pool. I'd like to see the concept succeed, so I think I can stick with it at least a little while longer. |
|
|
|
Order #6535 (placed 29 Aug 12) shipped today according to email received from BFL. "Standard shipping" turned out to be Priority Mail, so I should have it Wednesday afternoon.
They ended up arriving in Las Vegas Wednesday morning (19 June). Working like a champ at 10.5-11 GH/s for the pair. One runs on 30 cores, while the other runs on 29. |
|
|
|
Been testing my upgraded Jally on p2pool after the reports that BFL asics seemed to be doing OK. After around 18 hours, I'm seeing this:  Efficiency seems OK? DOA is high though, should I be worried about that? Guess I will let it run a few more days and see how payouts go once we start actually solving some blocks. I'm seeing only 84% efficiency with mine. What settings are you using? My miner name has +256 appended to it. A poster in the BFL forums is using /6000 and is getting results more like yours than mine. Given that share difficulty is only 1080 as I write this, though, wouldn't setting difficulty too high risk throwing out valid shares? |
|
|
|
Salfter, mine is up and running on windows but the auto sell function doesnt seem to be working. I have PyCrptsy.py in the appropriate folder and have put my api keys in the config file and set the ones i want to sell to true, although it doesnt seem to be selling? Is there a certain amount of coins you need before it will sell? Or am i missing something.
Thanks!
I was able to get the auto switching working with LittleDigger's guide. But I never got the auto selling features to work on Windows. Has anyone else gotten that to work on Windows? I've not had it on altcoins long enough for it to kick in, though it just switched over to Terracoin a bit ago. We'll see what happens over the next several hours or so. |
|
|
|
Now that I have CryptoSwitcher running on Windows, I have it set up for altcoin mining with my Jalapeņos. Altcoin mining with ASICs is a bit more limited as not many of them use the same sha256d proof-of-work as Bitcoin, but I have CryptoSwitcher set up to switch between Bitcoin and Freicoin. Terracoin and PPCoin might also be worth setting up. I had my Jalapeņos aimed at Coinotron's FRC pool for an hour or so this morning for testing...kicked their hashrate up by 50% and found a block.  |
|
|
|
Anyone gotten this working under windows.
I get this error:
Traceback (most recent call last):
File "cryptoSwitcher.py", line 13, in <module>
from PyCryptsy import PyCryptsy
File "./PyCryptsy/PyCryptsy.py", line 25, in <module>
import pycurl
ImportError: No module named pycurl
I have tried to install pycurl, but I keep getting errors, is there anyone that has a curl (that pycurl works with) that will share ?
I usually work with Linux, but am working on getting Python on Windows to the point where it'll run CryptoSwitcher. In the meantime, you might give the PyCurl builds on this page a shot: http://www.lfd.uci.edu/~gohlke/pythonlibs/Edit: Confirmed working with the following configuration on Windows 7 Professional for AMD64: Python 2.7.5 (install with default options) http://www.python.org/download/releases/2.7.5/setuptools https://pypi.python.org/pypi/setuptools/0.7.4#windows open administrator command prompt, then install with pip, PyCurl, NumPy, simplejson http://www.lfd.uci.edu/~gohlke/pythonlibs/ Make sure c:\Python27 and c:\Python27\Scripts are in your PATH, then open an administrator command prompt and install beautifulsoup4: pip install beautifulsoup4 urllib2 appears to be part of the base Python install, so with everything above installed, CryptoSwitcher should fire up. |
|
|
|
<snip>
For now, it's on my work computer, which runs Windows. After a bit of work, I got the latest cgminer working within EasyMiner, and now have ~10.5 GH/s directed at BitMinter:
Eventually I'll take them home and plug them into my Gentoo mining rig. For now, though, this will work.
Not to be devils advocate... but if you got them running at work, why not leave them there..... Will anyone really notice? $$$ savings... They'd be more secure at home, and the power draw of two Jalapeņos is not much more than that of the 7750 in my mining rig. Besides, my work computer is getting long in the tooth (Athlon 64 3700+, though it is running Win7 now) and lately has been prone to bluescreening and/or freezing. The mining rig doesn't have these problems. |
|
|
|
Hi,
when i try to run cryptoswitcher i get this error:
<<< Round 1 >>>
time: 2013-06-17 14:57:24
getting data... done
comparing profitabilty...
------------------------------------
Bitcoin: 103 (fee: 0, src: cc)
FeatherCoin: 134 (fee: 2, src: cc)
DigitalCoin: 142 (fee: 2, src: cc)
TerraCoin: 119 (fee: 2, src: cc)
Devcoin: 0 (fee: 0, src: cc)
Litecoin: 117 (fee: 0, src: cc)
IXCoin: 0 (fee: 0, src: cc)
NameCoin: 2 (fee: 0, src: cc)
------------------------------------
=> Best: 140, mining DigitalCoin
=> Switching to DigitalCoin (running dgcoin.sh)
Traceback (most recent call last):
File "cryptoSwitcher.py", line 566, in <module>
subprocess.Popen(coins[bestcoin].command)
File "/usr/lib/python2.7/subprocess.py", line 679, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1259, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
Can someone help me?
Does dgcoin.sh exist? It doesn't ship with CryptoSwitcher; you'll have to create it yourself. Assuming that it does, you might want to enter it in cryptoSwitcher.config as ./dgcoin.sh, just to be safe. |
|
|
|
OP, please add Cryptsy to the auto sell option of CryptoSwitcher!
I've already done that. My changes were merged into this project's GitHub repo, so cd CryptoSwitcher && git pull should bring you up to date. Check cryptoSwitcher.config.sample for updated options. |
|
|
|
Received email this morning...my Jalapeņos are on the way. w00t!
"Standard shipping," at least for my smallish order, turned out to be Priority Mail. Odds are they'll arrive here Wednesday afternoon.
They arrived here this morning...our mail must get here earlier than I thought. Click any of the pix to embiggen. :-) They shipped in this box...  ...into which this box was a snug fit:  Two Jalapeņos tucked away inside (power supplies and USB cables are in the two small boxes on the right):  One had this note wrapped up with it:  Unboxed:  For now, it's on my work computer, which runs Windows. After a bit of work, I got the latest cgminer working within EasyMiner, and now have ~10.5 GH/s directed at BitMinter:   Ordered 29 Aug 12, arrived 19 Jun 13, order #6535. To get EasyMiner working with something other than EclipseMC or Eligius, use the "manual mining" option under the settings tab. Fill it with something like this: cgminer-nogpu -o stratum+tcp://mint.bitminter.com:3333 -u user_worker -p password Repeat the -o/-u/-p options for each additional pool you want to configure. It also wouldn't be a bad idea to replace the bundled cgminer (3.1.1) with the latest (3.2.2, as of this writing). cgminer 3.2.x uses a rewritten USB communication layer. Instead of the FTDI USB-to-RS232 driver, you'll want to use a tool called "zadig" to install the driver that cgminer will use: http://sourceforge.net/projects/libwdi/files/zadig/Reboot and your miners will show up. Eventually I'll take them home and plug them into my Gentoo mining rig. For now, though, this will work. |
|
|
|
I plan on doing both. I am going to be a fully licensed nano brewery.
Good that you addressed that...no use in getting the revenuers crawling up your six for selling alcohol without a license. |
|
|
|
Here's my first stab at it...waiting to build up enough coins for it to trigger: https://github.com/salfter/CryptoSwitcherPyCryptsy seems to have worked well enough for a couple of YAC-to-BTC exchanges earlier. Integration was fairly simple; I designed it to work similarly with the Vircurex integration that had been done earlier. This looks great, and I've merged it into CryptoSwitcher. I've also adjusted the TradeMultiplier to a default of 1.01, given the race-to-the-bottom nature of Cryptsy. To sell your altcoins for the highest price you can right now, return this to 1 in the config file. Looks like it's trading on Cryptsy...one LTC-to-BTC trade went through; another is pending. It would be nice if their API provided a way to cash out your BTC to your wallet. I'd rather keep my coin in a wallet under my control. |
|
|
|
There's only a fixed number of people who want to mine BTC, so interest has to slow down / stop at some point.
It also might be a matter of wanting to catch up on what you already have in the pipeline before buying more. I should have a couple of Jalapeņos arriving tomorrow. I have some Avalon ASICs on order from a couple of group buys (including #4 in this topic). Once the Jalapeņos have made some money and the chips are built into boards and making some more money, odds are good I'll be in the market for more mining equipment. Whether it's BFL or Avalon gear I'll be buying remains an open question. (Avalon will probably end up cheaper, while BFL will most likely be more power-efficient (if not by as much as they had predicted).) |
|
|
|
Here's my first stab at it...waiting to build up enough coins for it to trigger: https://github.com/salfter/CryptoSwitcherPyCryptsy seems to have worked well enough for a couple of YAC-to-BTC exchanges earlier. Integration was fairly simple; I designed it to work similarly with the Vircurex integration that had been done earlier. |
|
|
|
Received email this morning...my Jalapeņos are on the way. w00t!
"Standard shipping," at least for my smallish order, turned out to be Priority Mail. Odds are they'll arrive here Wednesday afternoon.
What date did you order on? 29 August 2012. Order number was 6535. |
|
|
|
|
Show Posts
