This answer will attempt to answer the question at multiple levels, as follows:
Section I explains the basics of how to calculate this yourself.
Section II provides updated calculations based on Section I.
Section III provides an abstracted way to determine this based only on the total network hashrate and the total number of coins in circulation.
The daily variance appears to be limited to about 10% of the hashrate. Two possible explanations:
A system administrator mines Monero at night when computers would otherwise be idle
A system administrator mines Monero during the day while having physical control of the computers.
Replace system administrator for anyone with control over a large group of ...
It looks like your hash-rate is calculated in the following code:
hashes_done = 0;
/* scan nonces for a proof-of-work hash */
rc = scanhash_cryptonight(thr_id, work.data, work.target, max_nonce, &hashes_done);
/* record scanhash elapsed time */
Currently the network hashrate is approximately 22.9 MH/s. There are about 30 blocks per hour and 720 blocks per day.
On average to find one block per day you would need 1/720 of the current network hashrate or approximately (22.9 MH/s)/(720) = 31.8 kH/s today. The relationship between MH and kH is found here
In addition to the (very likely) reasons given by Big Things, there is also the distinct possibility that something in the difficulty adjustment algorithm is causing this. It could be the way we're cutting off outliers, for instance. One of the MRL projects is to investigate the difficulty adjustment algorithm precisely for this reason:)
Right now Wolf's OpenCL XMR Miner for AMD GPUs (open source) and Claymore CryptoNote GPU Miner (proprietary) are probably the most efficient.
It is believed that Monero is still quite far away from ASIC mining largely because of the memory requirement and that CryptoNight takes advantage of the AES-NI instruction set on modern PCs. The relative advantage ...
Well, private spend keys are 64 character hex strings, see here:
That will give you around 1e77 possible private keys. If n is the number of possible private keys, and you only generated two private spend keys, the odds they would be the same is:
1 - (n-1)/n
Which Python tells me is 0.0 due to floating point arithmetic.
Assuming a current hashrate of 21.1 MH/s, an attacker would need a bit more than 21.1 MH/s to perform a 51% attack. This assumes that doubling the hashrate for a day doesn't drive miners out. According to Fluffypony's slides¹ from his presentation to a group of bankers at the Thales User Group², the rental price of 1 KH/s is approximately 13.11$. Thus, an ...
There are at least 13 pools but likely more due to private and unkown pools
Not yet, but there has been some interest in the idea
It does not exist for Monero but it would be a nice little project to create one.
The main reason people don't seem to go for it is higher overhead. You have to run a full node, and you have to run what is essentially a ...
According to https://www.cryptocompare.com/mining/calculator/xmr you need 2910 H/s at the moment to mine 1 XMR per day.
Here's a Google doc with a comparison of various hardware (CPU and GPU) for Monero mining: https://docs.google.com/spreadsheets/d/1E0GqJdLhMmeO5BW3RBcIpftMR_BJhnyUS464ZO_EYGQ/edit?pref=2&pli=1#gid=1
From that you can figure out how ...
Currently network hashrates are near historically high levels. How much further hash rate moves up in the future depends heavily on mining profitability based on current XMR prices and coinbase reward.
Similarly the following factors will have a large impact on the attractiveness of future FPGA and ASIC development for Monero.
The emission ...
This is kind of a subjective question. Currently the block reward is ~ 10.4 XMR per block or 5.2 XMR per minute. When the tail emission kicks in, the block reward will be 0.6 XMR per block (assuming 2 minute blocks) or 0.3 XMR per minute. If we further assume miners are currently mining at an equilibrium then the price should be approximately 17 times as ...
The Monero community almost unanimously voted against merged mining choosing instead to stand on its own and avoid indirectly supporting another CryptoNote coin, BCN that was 80% premined..
Actually voting is closed now as soon as nearly nobody wants merge mining in BMR
In hindsight measured by network hashrate, the Monero community made a wise decision. ...
I think on AWS the most economical way to mine is with is a g2.2xlarge which costs $0.2017 per hour at spot price right now. I believe you can get on average around 1 kH/s with the GPU and CPU combined on one of these.
In order to 51% attack from scratch, one would need 21.1 Mh/s, or 21,100 instances. So, that would be $4,256/hr and $102,141/day.
Keep in ...
The hash rate can only be estimated from the difficulty, which is itself adjusted up and down based on how fast blocks are found compared to the 120 second target. This estimation is the difficulty (currently 7462457559) divided by the target (currently 120 seconds), so currently about 62 MH/s.
You cannot compute a block's difficulty from its hash. The hash is a Keccak hash.
A different hash using Cryptonight is used for PoW purposes, but this isn't the block hash. It is often called the PoW hash, or just PoW. It uses a similar system to Bitcoin where the hash as an integer must be below some treshold based on difficulty. This hash is run on the "...
Pools do not know your hash rate, they can only estimate it based on the shares you submit. Since finding those shares is in inherently random process, you will sometimes have lucky breaks, and sometimes long dry spells. This will translate to a randomly changing hash rate being reported by the pool. Your miner knows the rate at which it is hashing, so ...
When Monero forked to v7, it changed its proof of work algorithm. While it previously used Cryptonight, it now uses a slight variant (technically, variant 1) of Cryptonight, which should be typically slightly slower to compute.
After the fork, miners would were not able to update their hash algorithm were left unable to mine Monero. While patches were made ...
I believe this refers to hashes - it does 39 hashes for you and 1 hash for the developer, regardless of whether the hashes are valid or not. As Claymore is closed source, we can't easily verify this, but from what I have seen running the miner it seems like the most likely explanation.
To answer the question for Zcash, spending keys are 252 bits (all of which are valid). There's no practical difference between 252 and 256 bits in terms of the probability of collision for a properly working RNG; both are close enough to zero for reasonable bounds on the number of keys that will ever be generated. For how to calculate this probability, see ...
The likelihood of a collision is theoretically 1 in 2^256 which is a number with 78 digits. It's the likelihood of winning the lottery 7 times in a row, or something along those lines. Unless, of course, the random number generator is broken somehow and the "rolls" could be predicted, which I don't believe is the case here. If you were concerned about the ...
Value of a coin and hash rate goes hand in hand.
If value of coin decrease, then miners will have less reward for their mining and will rather go mine some other more profitable coin.
So if a coin is used only by 2 people and have low value. The hash rate needed to run network is tiny, but network is still secure.
Motive behind doing a 51% attack is ...
The hashrate that is reported by the pool is an average over some time period - for example the original core pool implementation uses a window of 10 minutes (600 seconds) to compute the average.
Your miner probably reports the average hashrate over a shorter window.
That could be the reason why you may observe discrepancies at a particular moment in time (...
The log file is ~/.bitmonero/bitmonero.log. On Windows, it is somewhere else which someone who knows will edit here soon.
The status command reports your hash rate. If you're running a detached monerod:
You could use watch to run this at whatever interval you want, eg:
watch -n 60 monerod status >> /tmp/monerod.log
Or you could ...
You cannot compare hash-rates for SHA and CryptoNight as they have different characteristics. CryptoNight requires 2MB of processor cache per thread and if you don't have that, the hashing will be significantly slower than other algorithms.
Raspberry Pi 3 to my recollection only has 512KB L2 cache so it's always going to be slow hashing CryptoNight compared ...
Thanks to the tail emission, in order for miners to continue to be incentivized, Monero must merely have a price. It honestly doesn't matter what that price is.
The security of the network scales mostly linearly with the price of Monero, but so does the need for security. If Monero has a market cap of $1 thousand, there really isn't much need ...