Hmm, in the meantime they are completely offline. Another one bites the dust.

To add an amusing side glance on top of the well known facts (extremely low payouts; no proof of real mining whatsoever; listed in badbitcoin.org for quite a while; not answering questions regarding equipment, detailed statistics, maintenance fees etc. pp.): Not able to stand provable critics.

As you might know they've got there own forum — http://forum.cloudmining.website.

When you post any of the above within that forum, your post gets deleted within an hour by moderator 'Alec'. When you do so repeatedly, your account gets suspended. Medievalism, to put it mildly.

Hi,

it shouldn't matter whether I backup the whole bitchain onto another drive (which I currently do) or into an archive file.

Of course you may further investigate this, maybe others have made similar experiences.

Another possibility: My wallet contains some hidden error since some time. Don't know how this should even be possible. Anyhow with the backuped wallet I'm experiencing frequent crashes of bitcoin-qt.exe v10.2 lately. When looking into the debug.log  I see an error message that some *.ldb file in the \chainstate subdir »possibly contains some virus and thus the program couldn't proceed safely«. 

Just trying to rebuild everything from scratch with an empty wallet and later on reimport my keys.    I'll keep you posted.

@bitcoinmasterlord:

Hmm — I did manually back up the whole blockchain, of course after having shut down the BTC client.

The next day my computer crashed while bitcoin-qt.exe was running, thus corrupting the blockchain.

After restarting I kept the wallet (there had been a few transactions since the backup), but restored everything else (e.g. the whole blockchain including indices).

This procedure was working fine with client v9.x; it took a quarter of an hour to catch up on the latest blocks and everything was working again.

The same procedure (full backup and full restore except the wallet.dat) failed miserably after I upgraded to Bitcoin client v10.x. Unavoidably and strictly reproducibly the program told me of a corrupted index and started to re-index the whole blockchain, taking at least a quarter of a day to get up to date and being able to perform any transactions.

Putting that procedure into a kind of scheduled batch script ain't no problem, however I seriously doubt it solves the problem described. Looks like the wallet.dat (or the registry?) carries some time stamp of last block or so, and if that doesn't match with the time stamp of the last block (or index?) actually found on the HDD, in client v10.x the blockchain index is automatically considered corrupted, even if it is perfectly legit at the backup time.

With Bitcoin client v9.x it was possible to backup the complete blockchain. In state of a computer crash somehow corrupting the blockchain a simple restore of the whole backuped directory except the wallet.dat got everything right fast — the Bitcoin client only had to catch up on the last blocks since the backup and everything was fine again within a quarter of an hour.

With Bitcoin client v10.x this procedure doesn't work any more. Keeping the wallet.dat and restoring everything else inevitably and reproducably results in a complete re-indexing of the whole blockchain from scratch. And even though this re-indexing utilizes the blocks already available on the local HDD and not downloading the whole blockchain again, it takes hour by hour by hour with high CPU and near to 100% HDD load.

Of course I could try restoring the old wallet, too — and use the 'rescan' option to retrieve transactions missing in my wallet from the blockchain. But this also is a time-devouring process as it has to scan the whole blockchain.

Thus my question: Is there an easy and time-saving way to backup and restore the whole blockchain whilst keeping the latest version of the wallet.dat with Bitcoin client v10.x?
Of course the BTC client was NOT running when I did the backup and the restore. To no avail as described above.

I'm obliged for every working hint.

In case there is no easy solution (as far as I got it there's a new approach to retrieving Blockchain and indices in BTC client v10) the above can be considered a feature request. It shouldn't be acceptable that each and every crash causes an 8-12 hours delay before you're able to use your wallet again.

Does anyone receive any payment from GRMining after April 20th, 2015?

Hmm — to begin with GRMining.com showed all flags of a possible PONZI scheme. Anonymous, ROI almost too good to be true, no pool address whatsoever to mine against, etc. pp.

Their prices for a 5 years contract increased from initially 0.135 BTC / 100 GH/sec to 0.3 BTC / 100 GH/sec within 4 months.

A few weeks ago they suddenly turned from daily to weekly payout. Technical reasons after said tech worked well for several months? Wow, what an explanation.

Practically simultaneously their payouts dropped to less than ½ of the amount shown in the contract table. Emails to support weren't answered any more.

Their FAQ section shows a sample calculation explaining maintenance and electricity costs (in BTC) are much higher now than 4 months ago. Due to the BTC exchange price drop (from ~ US$340 in November down to US$230 today) this holds true. Not implementing the newly calculated fees into their table calculation is an indicator of very poor website maintenance.

Their site is completely offline now for a day. Not even an attempted explanation like Hashprofit.com did.

Sorry to say, but it looks like a PONZI run out of new coins rolling in and now is shutting down. The 'technical reasons' obviously are an empty wallet (resp. empty enough for them to make a cut and take the rest).

A few days ago epay.info established 'secure accounts', meaning you can enter a password — and HAVE to enter your name and an eMail address.

Password protection is basically fine, but entering personal data sufficient to unambigously identify you?

The whole Crypto system is based on a completely open blockchain; everybody can see any transaction. However as long as these transactions aren't linked to a specific IP address, eMail, name etc. pp. it are just BTC addresses with nobody knowing who's behind them. Could be anyone anywhere in the world. If I only know a BTC address that tells me nothing than the business of that specific address. And honestly: Not even the IRS would be interested in you having 'earned' some thousand satoshis at a faucet. Remember that 1,000,000 (!) Satoshis is just US$2.50 currently.

ePay.info is a microwallet, meaning they are collecting micropayments (probably mainly from their 7 faucets) and forward it to the respective BTC addresses once a week.

Thus why they would need personal data? The only answer I can think of is for marketing reasons. Sell them to Google or whoever is interested in people interested in Bitcoin faucets. And I don't see any data privacy statement anywhere on their site. IMHO a devious way to elicit personal data from a person.

---------------------

Apart from that their login system isn't even working very well. Try using two different BTC addresses (e.g. changing it after some days or using different addresses for different faucets). You are urged to secure every single one of it with every navigational click on their site. You confirm their eMail (Hah! It's actually a valid address we can use!) and only the balance of one single BTC address is shown. The others are a pure guess and remain so till payout.

Facts seem to be:
• Nobody has received any payment.
• No sensible updates of any kind from site owners.
• No ProfitCoin blockchain updates since more than a month.

Thus yes, we quite probably may say »Bye«.

Uuups - that means the miner rewrites its whole system besides the config folder from scratch on every reboot, probably using the latest firmware image!? Holy BS ...
Just performed a reboot and you're right, the files are gone resp. the cron reset. Damn!

Sorry, I definitely wasn't aware of that. Then the only chance would be patching the firmware image before uploading it. Cocksure beyond my scope.

Sure!

The blowing one is a Noiseblocker NB-eLoop BP12.
The drawing one is a Noiseblocker NB-Multiframe M12-P.

Both you can find e.g. at:
http://www.blacknoise.com/site/en/products/noiseblocker-it-fans.php

The BGears B-Blaster 120mm or B-PWM 120 mm fans are even stronger
(~100 CFM) and a bit louder (~35-37dB). See:
http://bgears.com/b-pwm.html
However it seems a bit hard to purchase them in Europe, possibly an
overseas order is needed and would take two or more weeks to arrive.

Hash rate at 312.5 MHz is at about 1 TH/sec — both Antminer webinterface
and pool statistics agree about that.

The temperature of both chains is at about 60°C, which is stated as a kind
of limit for longevity at the very first page of this AMS5 thread.

Has anyone at all substantiated the 50°C for 'best hashing' mentioned at the same place?

Regarding hash rate dropping or one board going offline I've taken a little cron job that has originally been developed due to hash rate dropping issues with several firmwares on the Antminer S3(+) that checks every 5 minutes (or as you like) whether the average hash rate is still high enough. If not, it initiates an automatic reboot without any need to babysit the device. Here it is:


mingh is the minimal hash rate below which the miner should reboot.

cgminer-api delivers status infos on the momentarily state — what is shown in the web interface via Miner Status -> Summary. The output is searched for the average hash rate and cut in a way to only return the mere number. If smaller than the defined limit a reboot occurs. The double round brackets in the third to last line are inevitable to make clear we've got a math expression and not a text string.

Save it as hashcheck and upload it in text mode (Yep, that's important!) to
/user/bin
If you're a wizard in vi you can create it directly on the Antminer, too. Not my choice, to be honest.

Make it executable for everyone:
chmod 755 /user/bin/hashcheck
(or in WinSCP right click -> Properties)

Add one line to the file:
/var/spool/cron/root
namely:
5 * * * * /usr/bin/hashcheck

It should now contain 2 lines if you haven't conducted further modifications.

If you edited it locally take care using text mode for re-upping it to the Antminer.

Done.

Hmm, Bitmain has removed several items from the web interface I considered quite useful with the Antminer S3:

(a) Cronjobs are only available via SSH or SCP. The file is located in:
/var/spool/cron/root
If you edit it locally — i.e download it to your computer and edit it there with a text editor of your choice as vi probably isn't everybody's darling — make sure you transfer in text modus both directions.

(b) Voltage adjustment isn't public any more.
The corresponding file for the most important cgminer settings is:
/config/cgminer.conf
It's basically a JSON file now containing pools and other data as we well know it from other miners, too ... however:
The last two relevant lines in this config file read:

"bitmain-freq" : "4:312.5:0c02",
"bitmain-voltage" : ""

Due to noise issues I've taken two very silent (< 30dB) Noiseblocker fans at both ends, one drawing, one blowing (as with the Antminer S3) and underclocked the device to 312.5 MH/sec to keep temperatures at ca. 60 °C.
Okay, 4 separate units at 312.5 MH/sec — but what the heck does '0c02' mean?
And in which format should I enter the voltage — probably could be a bit below the standard 0.75V due to underclocking. But how to tell my Antminer without unwittingly bricking it?

Thanks in advance for any hints!

Well, let's try to figure out how to insert an image here.

Bitcoin address: 1GVZiKxtoegitgmhCXtBP1zBw1gzGzhebk

Ich z.B. (Therese)

Gibt's eine Möglichkeit, mit Dir in Kontakt zu treten, ohne meine ganzen Kontaktdaten hier öffentlich posten zu müssen?

Bin auch etwas durcheinander. Wenn ich mich nicht völlig verzählt habe, sind das im Thread oben
Interessenten an 8 Geräten ...


Von daher an Daniel noch einmal die Bitte um exakte Infos:

• Für wen genau sind wie viele Miner geplant?
• Wie erfolgt die Abwicklung, wenn die guten Teile in Deutschland angekommen sind?

Danke!

TT

Bei dem Holiday-Angebot bin ich auch sofort dabei!

Gruß,

Therese

The standard Antminer S3(+) fans (JDH1238B) do their job of cooling, but their noise level is evocative of a turbine rather than a high tech electronic device.

There is a fine replacement for them:

NOISEBLOCKER NB-eLoop B12-P

Just google it to find a nearby reseller.

It's much smaller (height 25mm instead of 37mm) but delivers nearly the same airflow — up to 132,4 m³/h.

The manufacturer states a life span of 120,000 hours and grants a 6 year (!) warranty, which completely backs up the relatively high price (about 20 bucks per fan).

Current measurements after 3 hours of full load hashing (Firmware from 2014-08-26, no shutdowns):

Fan Frequency    Temp   
1740 Hz             40 °C
1560 Hz             47 °C

Noise level: Barely hearable, per manufacturer well below 30dB. No comparison to the approximately 55+db fo the originals fans at full load.

No, I'm not an employee of Noiseblocker. I simply wanted to share my experiences with a fine peace of hardware that finally renders the Antminer into an equipment fitting any location, even a parlor.

Hi,

in the meantime one slowdown occured, hashcheck script run, no reboot. As I'm not overclocking my device mingh is 405 in my case.

I also adjusted the voltage to the suggested 0.725 V (a bit below standard, right?).

I'm not very good in Unix / Linux bash commands, thus I played a bit around in a putty terminal session (using half a dozen of example and help URLs) and reworked the var=$ ...  line till the output matched exactly the average GH/s — basically just taking the end of the line containing [GHSavg].


When I try to run the script in the putty box it gives me:
-ash: hashcheck: Permission denied
In the system log no error is mentioned, thus I assume it's just my missing knowledge of how get elevated rights in a terminal session.

Edit: No reboot after next slowdown.

Looks like I should revert to the August firmware, too — see next post.

Thanks a lot for the fast reply!

Just uploaded it and will report about success or failure the next time my Antminer bothers itself down to bog down at 10%.