When I try to build zcashd (./zcutil/build.sh -j4)
I get ‘automake is required, but wasn’t found on this system’
In Austin-Williams guide he forgot to add automake
sudo apt-get install build-essential pkg-config libgtest-dev libc6-dev m4 g+±multilib autoconf libtool ncurses-dev unzip git python zlib1g-dev wget bsdmainutils
This is the correct setup
sudo apt-get install
build-essential pkg-config libgtest-dev libc6-dev m4
g+±multilib autoconf libtool ncurses-dev unzip git python
zlib1g-dev wget bsdmainutils automake
Thank you. I’ve updated both guides and added the automake dependency.
Thanks, will be installing it.
what tariff on Amazon EC2 you can recommend to mining Zcash?
I got it working I think but get this error:
“version” : 110200,
“protocolversion” : 170002,
“walletversion” : 60000,
“balance” : 0.20000000,
“blocks” : 6771,
“timeoffset” : 0,
“connections” : 9,
“proxy” : “”,
“difficulty” : 157.21366993,
“testnet” : true,
“keypoololdest” : 1473152030,
“keypoolsize” : 29997,
“paytxfee” : 0.00000000,
“relayfee” : 0.00005000,
“errors” : “WARNING: check your network connection, 0 blocks received in the last 4 hours (96 expected)”
Hey @Austin-Williams, this is a phenomenal resource! Wish I had a few BTC to send your way!! ![]()
May I ask, does it matter whether your Linux instance has SSD storage, or is “EBS only” sufficient? If I understand correctly, the key factors (once install and everything already sorted) are: memory bandwidth (so more “motherboards” better than more cores); some minimal amount of memory (>1GB). But given that you can presumably SSH the wallet.dat off the EBS storage as easily as off a hard disk, does a hard disk matter. You start with an m4.large, which has an SSD, but is the SSD necessary, or better to have cheaper instances, e.g. t2.small.
Cheers! Tom
The answer is… It’s complicated. ;p
You’re right: SSD vs EBS doesn’t matter w.r.t. mining. It’s all about memory bandwidth.
m4.large is great for setting up because we need at least 8GB of RAM for the installation process. But after you have an image and are ready to start mining, you don’t need 8GB of RAM anymore. I believe 1GB will suffice for mining (at least according to my tests… that may change as the devs change the equihash parameters).
I’ve mined on instance types as small as the t2.small. ![]()
But here is where things get tricky. Not all AWS instance types are created equal. Some have much more efficient access to the ‘bare metal’ than others.
For example, solving equihash on a m1.small instance takes almost twice as long as solving the same on a c1.medium (at least last time I benchmarked… idk if the equihash parameters have changed since then).
So a good first step is to try to minimize the price per hash. This involves two things:
- Benchmarking the different instance types to get the number of Equihash solves per second for that instance type.
- Estimating the SPOT price of that instance type.
That’ll give you a good first approximation of what instance types you’ll want to use. It’s time consuming but I’ve found it enlightening.
Another thing to consider is this: because the Equihash solve time is so long (in the ballpark of a minute – give or take) and because the devs decided to have a 2.5 minute blocktime (instead of bitcoin’s 10min), going for low hashes/dollar is not enough. You also have to consider how many guesses your machine gets to make during one blocktime interval.
For example, suppose instance type A computes Equihash once every 4 minutes and cost just a penny per day to run. Suppose instance type B computes Equihash once every 0.8 minutes and costs $0.30 per hour.
Then instance type A costs $0.028 per 1,000 hashes.
While instance type B costs $4 per 1,000 hashes.
So you might think instance type A is the clear winner, and go out and start bidding up the SPOT price of instance type A.
But in fact, that’d leave you broke. Instance type A will almost never find a block, because it’s Equihash solve time is longer than the blocktime. It will almost never finish it’s first equihash solve before the block in question is solved by someone else on the network.
I haven’t had the time to model this (let alone simulate it) but my shooting-from-the-hip guess is that any instance type with an Equihash solve-time greater than about 15-30% of the blocktime should be considered to be at a disproportional disadvantage.
That’s not to say that you shouldn’t use an instance type with an Equihash solve time of, say, 70 seconds. But when computing the cost/hash you should factor in an additional penalty to compensate for the fact that such an instance type will get fewer guess than one with an Equihash solve time of 45 seconds.
How to estimate that penalty isn’t something I can tell you presently. I haven’t had time to model or simulate this because of stupid life responsibilities, and I doubt I will before Sprout is released.
Agreed for the most part, except for “A will almost never find a block”.
With a 2.5 minute average, a block taking 4 minutes is far from unusual;
the poisson distribution is quite spread out…
So the more than 100x cost advantage of A will easily compensate
for the smaller block winning frequency.
Excellent answer, many thanks! Yes, I was considering the impact of a blocktime “threshold” as I was lying in bed. Although, as @tromp suggests, due to the statistical distribution of this time, it may not be such a “hard” threshold as we feared.
As you suggest, my plan is to run some benchmarks on a few different systems, and try and balance dollar/hash and equihashtime/dollar. Have you tested out using AWS GPUs? Presumably zhashd should run on GPUs without any code modification? If that’s not true, my programming skills are probably (definitely) not up to the task of recoding, unfortunately! ![]()
Keep up the good work, and I’ll be sure to fire you some BTC/zcash when I’m a crypto-millionaire!
![]()
OK, sorry, it’s clear that GPU algorithms aren’t available/optimised yet. Ignore above. CPUs FTW! ![]()
How much avg coins per day we can get in the first month of mining start, for example, from m4.large? Just your prediction
Amazon doesn’t banned me for mining?
Amazon doesn’t banned me for mining?
No. They’re happy to sell you as much computational power as you want to buy.
To be honest, I expect EC2 mining to be a relatively expensive way to mine. I expect it to become unprofitable shortly after the initial ZEC price discovery. Indeed, once there is a liquid market for ZEC I would be inclined to purchase ZEC directly rather than mine it on EC2.
Immediately after launch, the SPOT price of zcash-friendly instance types is going raise to a price that makes EC2 mining worthwhile for only the most fevered speculators. I simply don’t see any other possible outcome if there exists at least two non-cooperating, deep-pocketed rational speculators (and believe me, there are).
I predict the price-per-coin for home miners (that are participating in a pool) will be much better than for the EC2 miners.
That said I’ll be mining on both EC2 and at home, because gold rush.
Dear Austin-Williams,
Regarding your EC2 Mining guide, I’ve one question, Since there were lots of changes and improvements in the code, and in order to prevent the miner from removing addresses from the keypool (I don’t know if the miner will keep on doing so in the zcash final release)
do I still have to remove this:
reservekey.KeepKey();
from /zcash/src/miner.cpp
it’s now in the line number 429 (instead of 419)
Yes. That behaviour hasn’t changed.
Dear Daira,
Thank you, So I guess, I still need to remove it since I’m going to use one Zcash address for mining with more than one PC’s.
Thanks again.
That’s correct. Be aware, though, that mining to a single address will result in a loss of privacy. Since all coins will be going to the same address, people will know both (a) how many coins you’ve mined and (b) approx. how much hashing power you have.
If you plan on investing a lot in mining power, you may want to avoid this as it could make you a target for thieves. Just something to be aware of.
Many Thanks for the advice brother, since Zcash was originated to enhance privacy the correct way, still your great guide will be a good point to start with.
cheers