Oh that's one of those Cougar fans, I just bought 2 of them for my case since the stock ones died after 4 years of continuous use. They're really nice and quiet with the rubber mounts.
they really are. I am strongly considering replacing the other stock PWM fan with one. They look AWESOME and are very quiet, but unfortunately have lower airflow. (box says around 75CFM, while the stock fans must push over 100CFM). BTW: anyone have good liquid cooling ideas or methods? It would be pretty sweet if the antminer boards could be placed into immersion cooling, but i know that they would require a radiator capable of >400W for each antminer which i imagine is costly and semi-complex to install AFAIK liquid cooling (waterblocks) are not really ideal for ~200W (per blade) spread over a large area. The blocks would tend to be expensive. They are usually made for higher densities. For an ant you would likely need to get slabs custom built... then mount the blades onto it. I did see some early avalon threads where someone got custom waterblocks made... and used a chiller to cool the water. Immersion cooling could work, just need to figure out how to keep the solution cool... I think liquid cooling is waste of money... unless you can overclock it to the point of justifying your investment. edit: found the thread https://bitcointalk.org/index.php?topic=211825.0 |
|
|
|
Don't get tied up in that whole roi thing when you think cex.io. Your not buying hardware, your just parking some BTC in a vehicle that pays a return. You can get that BTC back at any time. Depending on the GH/s market fluctuation you may get more BTC back or you may get less. I would rather have a few BTC in cex.io earning a small return than sitting in my wallet earning nothing. Bit like real cash sitting in a bank earning interest versus sitting in your real life wallet earning nothing.
Translation: Buy GH/s for more than itll ever make, resell it to someone who will buy GH/s for more than itll ever make. Ignore the depreciation due to difficulty. |
|
|
|
Pywallet works fine on a new wallet, but fails on the corrupted wallet. I'm getting the following error:
Traceback (most recent call last):
File "C:\Users\Jaap\Desktop\pywallet.py", line 2059, in parse_wallet
d['txIn'].append(parse_TxIn(vds))
File "C:\Users\Jaap\Desktop\pywallet.py", line 2028, in parse_TxIn
d['sequence'] = vds.read_uint32()
File "C:\Users\Jaap\Desktop\pywallet.py", line 1942, in read_uint32
def read_uint32(self): return self._read_num('<I')
File "C:\Users\Jaap\Desktop\pywallet.py", line 1981, in _read_num
(i,) = struct.unpack_from(format, self.input, self.read_cursor)
error: unpack_from requires a buffer of at least 4 bytes
I get the same error on mine as well but client runs fine. I probably have an ancient version of the client... havent update or launched it in months, just opened today and has a huge blockchain backlog so closed it. This is on linux btw Yeah, this wallet is quite old, so it was made with an old version try running it on an old build... and then make a tx to a fresh address on the new wallet... If you know how to build on windows try checking out upto a very early commit. probably mid may, or earlier... or use linux. I can give it a go on my old client if u send me the wallet and passphrase... but then i wouldnt trust me if i were you. Still had an old version on my of my mining PCs, but it's crashing with the same error as the one in my first post  Did you try clearing everything, leaving only the wallet in there and let the blockchain sync as usual? |
|
|
|
I guess typo... for 02/15/2013 auction i would have bidded 100s of BTC... |
|
|
|
cex.io?
0.07709201 BTC per GH/s is never gonna make ur money back. |
|
|
|
|
0.5 BTC
Only if u accept escrow. I pay fee.
|
|
|
|
1 green flashing, 1 red, 1 green at ethernet
just tried again, got this
The server at 192.168.2.041 is taking too long to respond
try 192.168.2.41 |
|
|
|
Pywallet works fine on a new wallet, but fails on the corrupted wallet. I'm getting the following error:
Traceback (most recent call last):
File "C:\Users\Jaap\Desktop\pywallet.py", line 2059, in parse_wallet
d['txIn'].append(parse_TxIn(vds))
File "C:\Users\Jaap\Desktop\pywallet.py", line 2028, in parse_TxIn
d['sequence'] = vds.read_uint32()
File "C:\Users\Jaap\Desktop\pywallet.py", line 1942, in read_uint32
def read_uint32(self): return self._read_num('<I')
File "C:\Users\Jaap\Desktop\pywallet.py", line 1981, in _read_num
(i,) = struct.unpack_from(format, self.input, self.read_cursor)
error: unpack_from requires a buffer of at least 4 bytes
I get the same error on mine as well but client runs fine. I probably have an ancient version of the client... havent update or launched it in months, just opened today and has a huge blockchain backlog so closed it. This is on linux btw Yeah, this wallet is quite old, so it was made with an old version try running it on an old build... and then make a tx to a fresh address on the new wallet... If you know how to build on windows try checking out upto a very early commit. probably mid may, or earlier... or use linux. I can give it a go on my old client if u send me the wallet and passphrase... but then i wouldnt trust me if i were you. |
|
|
|
Pywallet works fine on a new wallet, but fails on the corrupted wallet. I'm getting the following error:
Traceback (most recent call last):
File "C:\Users\Jaap\Desktop\pywallet.py", line 2059, in parse_wallet
d['txIn'].append(parse_TxIn(vds))
File "C:\Users\Jaap\Desktop\pywallet.py", line 2028, in parse_TxIn
d['sequence'] = vds.read_uint32()
File "C:\Users\Jaap\Desktop\pywallet.py", line 1942, in read_uint32
def read_uint32(self): return self._read_num('<I')
File "C:\Users\Jaap\Desktop\pywallet.py", line 1981, in _read_num
(i,) = struct.unpack_from(format, self.input, self.read_cursor)
error: unpack_from requires a buffer of at least 4 bytes
I get the same error on mine as well but client runs fine. I probably have an ancient version of the client... havent update or launched it in months, just opened today and has a huge blockchain backlog so closed it. This is on linux btw |
|
|
|
Okay, so I'm looking through the wallet.dat with a hex editor, and I've managed to find the Yacoin public address that contains my Yacoin in plaintext. Where exactly is the private key stored? And how would I decrypt it manually? Edit: Trying to use pywallet now to salvage the private key. What value should I pass to the --otherversion= switch so it looks for Yacoin addresses rather than Bitcoin? Edit2: Since addresses are base58 encoded and since Yacoin addresses start with an Y, that would be 31, correct? Let's see if this works  was trying pywallet but no luck. https://github.com/yacoin/yacoin/blob/master/src/base58.h#L279the otherversion should be 77 based on that but pywallet is still fussing about. It does dump address and key in some sort of hex but i dunno how to get it into importable format. |
|
|
|
What are we missing? Anybody have something specific they were wishing someone would get around to building?
A quantum processor for mining bitcoins  |
|
|
|
I see the forum uses HSTS Strict-Transport-Security: max-age=3000000 If im not mistaken, there are some certificate pinning features available which tells the (modern) browsers to trust only the current certificate(or public key) for a predefined time... If thats implemented, trying to pull off a similar MiTM would probably result in some sort of warning... Not sure the status of this extension.. |
|
|
|
One of my units perform lower than expected.  Onboarded my last unit today, and it underperformes significantly. It was doing ~140 GH/s . Chain 1 having some x , chain 2 many x after several hours of running. I forgot to take a screenshot then. Thinking this could be a PSU issue, i swapped PSU from a fully functional unit, and still see some x. not as low as earlier, but im sure after couple of hours it will get the many x in chain 2... Will update with fresh screenshot if i spot it again... My ambient : 20 to 30C (may get higher during mid-day and if AC is off). Any ideas? Anything I can do to see some debug logs? Is cgminer logs saved anywhere? Im very comfortable with linux, ssh and command line... Is this unit broked? |
|
|
|
Any chance of posting the source code for the firmware images on the devices?
The current firmware is based off an old copy of cgminer which has poor performance for large blocks or large coinbase transactions. As a result I'm seeing 100% cpu usage and a stale rate several times higher than my avalons. This could easily be fixed by porting the driver to bfgminer or a current cgminer (or backporting some of the work generation improvements from newer cgminer), and I'm willing to give it a shot at doing it myself— but I need the source.
https://github.com/bitmaintech/cgminerThat appears to be bitmains fork of cgminer. I think you dont need full firmware source to modify cgminer... just simple cross compile and replacing the binary should be sufficient.... Just guessing no past experience with openwrt/mips |
|
|
|
So the miner fan and the PSU fan are working against each other ?! I presume the PSU is pulling air. So they r working with each other... I added a small fan on other end to pull as well. |
|
|
|
The unit has to work hard, after login in with ssh, top showed 90%-100% cpu for cgminer most of the time. I was running the unit over wifi, but doubt if this has anything to do with it.
The cgminer version on this unit is 3.4.3, the command running is cgminer —-lowmem —bitmain-options 115200:32:8:40:350:4d81 -G -o stratum+tcp://eu-stratum.btcguild.com:3333 …
Since the unit has 64Gb of ram, of which less than 50% is used, I removed the —lowmem, and at a first glance this seems to make it run a bit smoother(CPU: usr 60%, sys 40% versus usr 40%, sys 60%) and a higher hash rate(5+ GH/s, but again by running for a few minutes). This has to be tested better than just for a few minutes. There certainly is room for improvement here, given the amount of free memory.
Interesting... i noticed the 90 - 100% cpu usage even on wired LAN... Not using wifi at all. Will remove the lowmem option tomorrow. |
|
|
|
Is this the bitfury chip version that they released before they are using the new 28NM chips?
By my math each chip is doing 2.8125 GH/s the mask is their own... this is no way a 28nm design based on hashrate/power  |
|
|
|
|
Show Posts
