Looks like Cryptsy's trading API is now documented. A blob of PHP at the end is provided as an example. |
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
I got an email from these people to my forum email address this morning.
So they have clearly started spamming forum email addresses.
BEWARE!! This is just a scam.
Confirmed. If the OP thinks this is an acceptable marketing method, then let me be the first to invite him to die in a fire.  |
|
|
|
|
While checking my TMDA pending folder, I found a couple of messages from the aforementioned outfit. One had their name in the subject; the other was titled "Bitcoin Master." They purport to have a 30 GH/s miner at (IMHO) an uncompetitive price. Anyone else heard of them? I'm not inclined to give spammers the time of day. Besides, I have a couple of Jalapeņos that should leave BFL today, and some Avalon ASICs from a couple of group buys are a bit further out.
|
|
|
|
I've been mining for 12 hours and this is all i see on my CGMiner display for P2Pool ...
GPU: 0 10.75M/11.17Mh/s
Stratum from pool 0 requested work restart
[snipped]
I have no new litecoins in my wallet yet. Is this thing working correctly? Am I Mining?
That seems awfully high for scrypt mining on a single GPU. For comparison, my 6870 does about 310 kH/s; the rate you're quoting is nearly two orders of magnitude faster. Are you sure you're actually using scrypt, or are you attempting to use sha256d on Litecoin P2Pool? |
|
|
|
I have an app that pulls market data from Cryptsy; this functionality has worked pretty well. I'd like to take a stab at setting up CryptoSwitcher to auto-trade through Cryptsy, as the fees (especially BTC withdrawal fees) are much more reasonable than BTC-e or Vircurex, but this part of the API appears to be undocumented. Is it undocumented because it's a work-in-progress or unimplemented, or have you just not gotten around to it? |
|
|
|
|
Fixed a bug in which non-integer rewards caused an incorrect calculation, and added a Bitbar config. A new binary zipball is up on Dropbox; updated source is on GitHub. See the OP for links.
|
|
|
|
I went to switch back to Bitcoin mining yesterday on a box that had been mining altcoins with cgminer 3.2.1 (built on an amd64 Gentoo box with a source tarball pulled from https://github.com/ckolivas/cgminer/archive/v3.2.1.tar.gz. I have these pools configured in cgminer.conf: "pools" : [
{
"url" : "stratum+tcp://mint.bitminter.com:3333/",
"user" : "salfter_lanbox",
"pass" : "**redacted**"
},
{
"url" : "stratum+tcp://us.eclipsemc.com:3333/",
"user" : "salfter_lanbox",
"pass" : "**redacted**"
}
]
The config file was unchanged from when I last used it. cgminer 3.2.1 produces this error on startup: [2013-06-12 09:04:09] Started cgminer 3.2.1
[2013-06-12 09:04:09] Started cgminer 3.2.1
[2013-06-12 09:04:09] Loaded configuration file /home/salfter/.cgminer/cgminer.
conf
[2013-06-12 09:04:10] Probing for an alive pool
[2013-06-12 09:04:10] Failed to resolve (?wrong URL) us.eclipsemc.com:3333/
[2013-06-12 09:04:10] Failed to resolve (?wrong URL) mint.bitminter.com:3333/
When I downgraded to cgminer 3.1.0, it runs like a champ. I've used cgminer 3.2.1 to mine altcoins on stratum pools...but I just noticed that the URLs for those pools don't have trailing slashes, while the ones for the Bitcoin pools do: salfter@lanbox ~ $ grep stratum .cgminer/cgminer.conf.*
.cgminer/cgminer.conf.bitcoin: "url" : "stratum+tcp://mint.bitminter.com:3333/",
.cgminer/cgminer.conf.bitcoin: "url" : "stratum+tcp://us.eclipsemc.com:3333/",
.cgminer/cgminer.conf.digitalcoin: "url" : "stratum+tcp://dgcpool.com:3333",
.cgminer/cgminer.conf.digitalcoin: "url" : "stratum+tcp://pool.digicoinpool.com:3344",
.cgminer/cgminer.conf.feathercoin: "url" : "stratum+tcp://stratum.wemineftc.com:4444",
.cgminer/cgminer.conf.feathercoin: "url" : "stratum+tcp://pool.fcpool.com:3334",
.cgminer/cgminer.conf.feathercoin: "url" : "stratum+tcp://feathercoin.is-a-geek.com:3333",
.cgminer/cgminer.conf.litecoin: "url" : "stratum+tcp://us.wemineltc.com:80",
.cgminer/cgminer.conf.litecoin: "url" : "stratum+tcp://eu.wemineltc.com:3333",
.cgminer/cgminer.conf.worldcoin: "url" : "stratum+tcp://wdc-eu.epools.org:3334",
I think cgminer 3.2.1 might not like the trailing slash, while previous versions didn't care. |
|
|
|
|
Updated default config for more reliable operation, and added a Feathercoin config. A new binary zipball is up on Dropbox; updated source is on GitHub. See the OP for links.
|
|
|
|
...and for me, it just runs forever. Just tried it again with a 7750, then with a 6870 and even a Core 2 Duo E8400. What card and ATI driver version are you using? Leaving out the device-selection option causes it to exit with a list of available devices.
no ATI, a GTX580 does it spit out "Difficulty: *" or not? It does. I think I've figured out what's happening: oclvanitygen will only find keys wirh vanity addresses for non-Bitcoin address types. These commands work: ./oclvanitygen -D 0:0 -S 1
./oclvanitygen -D 0:0 -S -X 48 Lfoo
This doesn't: ./oclvanitygen -D 0:0 -S -X 48 L
The degenerate case where you just want an address appears to only work for Bitcoin. |
|
|
|
or just dont specify -d 0 at all  I do believe that it is necessary... I get an error if I don't ~/git/bitcoin-vanitygen$ ./oclvanitygen -X 48 LNoobs
Difficulty: 264104224
Pattern: LNoobs
Address: LNoobsbG3rDntp8rc86F368SoPVHkW9z8P
Privkey: 6uB3J78ffBB7Uz22y8VH42awwRKiUiX7eqqqS1KkcauWa1qyLjg j/k ...and for me, it just runs forever. Just tried it again with a 7750, then with a 6870 and even a Core 2 Duo E8400. What card and ATI driver version are you using? Leaving out the device-selection option causes it to exit with a list of available devices. |
|
|
|
./oclvanitygen -D 0:0 -S -X48 L Didn't make any difference...still grinds away forever without finding any keys. I think your device flag is wrong. Also, I'm assuming you don't have more than one GPU because of your flag structure. Try: ./oclvanitygen -d 0 -S -X48 L(prefix)
The capital D might be why it doesn't identify your GPU. It works fine for finding Bitcoin keys when I invoke it like this: ./oclvanitygen -D 0:0 -S 1 I have only one GPU, but note that the CPU is available as an OpenCL device as well (-D 0:1). Not that you'd use oclvanitygen with your CPU as vanitygen is faster, but you could. |
|
|
|
the NSA released SHA256 according to wikipedia. The NSA never endorses anything that they can't themselves decrypt, ever.
SHA-256 is a hashing algorithm, not an encryption algorithm. The most you can do to compromise a hash is to find a way to create a hash collision, as happened with MD5 a while back. While it's possible the NSA withheld such a method from release, that they released the algorithm as open source makes backdoors less feasible. |
|
|
|
./oclvanitygen -D 0:0 -S -X 48 L This should find a Litecoin key. Instead, it runs forever. Is this a known limitation of oclvanitygen? Use ./oclvanitygen -D 0:0 -S -X48 -i Light You cannot have a space after the -X flag. ./oclvanitygen -D 0:0 -S -X48 L Didn't make any difference...still grinds away forever without finding any keys. |
|
|
|
I never got oclvanitygen to work on my GPU (only CPU which gets 750kkeys/s) so I read here that I should downgrade to AMD Catalyst 12.8. So I did that, but still oclvanitygen does not work on my GPU: Compiling kernel, can take minutes...LLVM ERROR: Cannot select: 0x549e808: i8 = ... Anyone knows how to fix this? I was getting a similar error from my 7750 when I was running it with 13.1. It works fine with 12.10, though. I'd give that version a shot. |
|
|
|
If anyone is interested in generating compressed vanity addresses, see this Pull Request. salfter did the CPU side, and I commented with a link to my fork that includes his work and adds OpenCL support for the GPU side. Please be careful and verify that addresses you generate using my changes are correct before sending money to them. Just got a chance to try out your OpenCL changes. On my Ubuntu box, the new changes work like a champ. I'm still trying to get a 12.x driver on my Gentoo box, as 13.1 breaks oclvanitygen. I just brought x11-drivers/ati-drivers-12.10.ebuild back from the dead, updated with some patches that allow it to run with newer kernels. I have ATI driver 12.10 running on Linux 3.8.13, and with the 7750 in this box, the compressed-key oclvanitygen works with the -S flag (which it's always needed). I've integrated your oclvanitygen changes into my fork. BTW, those of you with Gentoo mining rigs might want to look at my overlay. In addition to the older ATI driver, I have a bunch of ebuilds for Bitcoin, Litecoin, and some other altcoins in there. (Haven't gotten around to a vanitygen ebuild yet, though...should probably fix that.) Edit: One thing I noticed is that your oclvanitygen only appears to find Bitcoin keys. The original appears to have the same behavior, so your changes didn't cause a regression. Try this: ./oclvanitygen -D 0:0 -S -X 48 L This should find a Litecoin key. Instead, it runs forever. Is this a known limitation of oclvanitygen? |
|
|
|
|
The latest version now uses Cryptsy's new API to retrieve exchange data. A new binary zipball is up on Dropbox; updated source is on GitHub. See the OP for links.
|
|
|
|
|
Show Posts
