Mining brings both income and expenses. The income is obvious, and the expenses consist of the purchase price of the mining hardware (or contract) and operational costs (mainly power, but one might factor in time spent maintaining the setup as well). Lets focus solely on the income earned from mining and make an estimate of that. Since the income of a setup scales inversely with the difficulty, we have seen mining income go down steadily since the inception of Bitcoin as the network grows and mining hardware is increased both in quantity and in efficiency. One month from now, a miner will earn less than he does today and a year from the earnings will probably be a tiny fraction of what he earns today.

To predict how the earnings will change, one needs to predict how the network hashrate and consequently the difficulty of mining will grow. Over the last 6-9 months the difficulty has grown exponentially, that is, with a (relatively) constant percentage increase per unit of time. Exponential growth is unsustainable on the long term, but on shorter timescales, there is little indication that the growth is slowing down as both Bitcoins popularity as well as the hashpower of new mining hardware increases.

So without further ado, lets get to the calculations. The next section will contain some math for the derivation of the income estimate. If you want, you can skip right past the math to the conclusion (but why would you want to?).

**Warning: Math ahead!**

Lets start with the amount of coins mined per day right now and call it *X* and take the expected difficulty increase per adjustment and call it *D*^{1}.

The difficulty is adjusted every 2016 blocks. If blocks are found every 10 minutes on average, as is the goal, then it takes exactly 14 days to find 2016 blocks. However, if the network hashrate is increasing, blocks are found more rapidly and the difficulty is increased to compensate. More specifically, if blocks were found 10% too fast over the last 2016 blocks, the difficulty will be increased by 10%. So instead of 14 days, the time between difficulty adjustments becomes

days.

For example, if the difficulty is increasing by 25%, there are only 11.2 days between adjustments.

The amount mined during the first period is

During the second period, the difficulty is up by an amount *D*, so the mining profit has decreased by factor 1 + *D* and in the second period, total earnings are

Similarly, total earnings in the third period are

Adding up the total earnings for all these periods gives the following series

which can be rewritten as

We can use the sum notation for an infinite series to write this expression more eloquently:

What we have here is a geometric series, that is, a series in which the next term is obtained by multiplying the previous one with a fixed value. In this case, this fixed value is

The nice thing about geometric series is that if the multiplication factor is smaller than one, then the series adds up to finite number. For a multiplication factor *r* (with *r* less than 1) , the sum value can be computed as

Using this wisdom, we can express the summation part of our intermediate result as

and we can plug this result into our original calculation to obtain

The fractions cancel and we obtain …

**–MATH ENDS HERE– The result**

That doesn’t look too bad. Ok, so how does it work? Lets take the popular cloud mining service CEX.io as an example. Currently, you pay 11.4 mBTC (I will express values in mBTC for clarity) for 1 GHash/s of mining power on that website. We first need to calculate the daily income from that at the current difficulty. You can compute that with one of the many calculators available, just put all the things like power costs to zero and only focus on the amount of income per day. Anyway, the daily income of 1 GHash/s is 0.082 mBTC.

Next, we need to make an estimate of the rate of difficulty increase. A quick glance at recent difficulty increases (You can use this site for that) shows that 20% is a good ballpark estimate.

We plug in the numbers and find:

So this 1 GHash/s will not yield more than 5.74 mBTC in total if the difficulty keeps increasing by 20% every adjustment. That’s pretty much half the current purchase price. If you assume that the difficulty will only increase by 10% on average, you end up earning about as much as you paid.

**Limitations of this model**

Of course the model described above is incredibly simple and has some limitations. It is intended as a simple way to show that mining typically isn’t at all profitable. Consequently, costs like electricity, man-hours and repairs/replacements are not included. Typically only electricity is factored in by other calculators, but right now power costs of modern mining hardware are only a small fraction of their current income.

The main limitation of the model is that the difficulty won’t be going up exponentially forever. As many people have rightly pointed out on various forums, an exponential increase in difficulty means that in a few years we’d be using all of our planets energy production for mining. Clearly not realistic. Apart from that, technological limitations will also play a role in slowing down the growth of the difficulty.

But does that matter for the general conclusion? Probably not. Because while difficulty growth will slow down eventually, for now there are no signs of that happening any time soon. If the difficulty keeps going up by 20% for 6 months, then after those 6 months the income generated by a miner is only 3.5% of what it would be today. And at those levels, operational costs (primarily power) will start to play a significant role and the net profit will be close to or below zero, whereas operational costs are now negligible for up-to-date hardware.

So after these 6 months it hardly matters if the difficulty will keep going up as fast, if the growth slows down or even halts completely. The profits have gone down enough to make continued operation rather uneconomical.

**Conclusion**

Using basic arithmetic and some knowledge about geometric series, we have derived a nice expression that allows you to make a good first estimate of the upper limit of mining profits:

While the model is very simple, it is good enough to show that almost any mining operation (hardware or cloud mining service) is not profitable for the miner. Anyone considering the purchase of mining hardware or a mining contract should apply this formula and only if the calculated profits are considerably above the cost of the device or contract is it worthwhile to look at more advanced calculations that factor in finer details such as operational costs.

But I bet that that won’t be necessary.

*D*is the fractional difficulty increase, so a 10% difficulty increase corresponds to a value of 0.1 for*D*. ↩

**The problem: Double-spending**

One of the main problems with a decentralized currently that the blockchain concept of Bitcoin solves rather elegantly is the problem of double-spending. Person A sends coins to person B, but (almost) simultaneously sends the same coins to person C (or to himself). With Bitcoin, only one of these two transactions is included in a block and inclusion in a block is almost a guarantee that this transaction will no longer be reverted. And the more blocks that follow that one block that includes your transaction, the stronger the guarantee is.

In the situation where a person pays for a drink or his groceries with Bitcoin, a double-spend attack would involve the person broadcasting a second transaction that tries to spend the same funds he just used to pay for his coffee. This second transaction typically deposits the funds in another address of the attacker. The merchant sees the initial transaction and considers the payment completed, but if the second transaction makes it into a block at the expense of the first, the merchant ends up not receiving any payment.

**Why it’s actually not such a problem: Effort versus reward**

Bitcoin nodes typically reject a transaction that attempts to spend coins already spent ^{1}. So in order for the merchant to see and acknowledge the payment transaction, it should be broadcast first to ensure that the node of the merchant receives this transaction first. When the second transaction is broadcast afterwards, it should be broadcast to a set of nodes that haven’t seen the first transaction yet. Ideally, this means that the second transaction should be broadcast from a completely different location, across the globe if possible.

At this point it becomes a race to see which transaction has propagated to the miners the fastest. The transaction that first makes it to the miner that ends up finding the next block will probably win. Since the original transaction has a considerable head start, the probability of the double-spend transaction winning the race is very small. Unless the attacker works together with a large mining pool, that promises to include the double-spend transaction at the expense of the original transaction.

Either way, the effort required to make such an attack work is relatively large and even then the outcome is far from guaranteed. The reward, a chance at free coffee or groceries, is definitely not worth the effort. And for more valuable transactions, such as the purchase of electronics or a car, there is typically a delay between the purchase and the delivery of the product and this delay can be used to wait for the transaction to be confirmed.

**Additional measures: The payment provider**

Since almost all merchants and businesses that accept Bitcoin still pay their suppliers and personnel with the local fiat currency (Euro, Dollar, etc…), they will want to exchange their Bitcoins for fiat currency as they receive it. Because of this, a Bitcoin payment provider, such as BitPay, is typically used, which handles the Bitcoin transaction and pays out the merchant in fiat currency.

An added bonus of using such a payment provider is that they take up the risk of accepting a 0-conf transaction. In the very rare event that a double-spend does occur, the payment provider covers the loss. Of course, this risk is priced into the fee charged by the payment provider, but it does provide the merchant with a clear, risk-free picture of what to expect from each sale.

**And more: Transaction propagation, miner deals, etc…**

Beyond the protection offered by payment providers there are additional means through which a merchant can greatly reduce (thought not entirely eliminate) the already small risk of a double-spend. One such approach is to measure how much a transaction has propagated through the network. If a large number of nodes run a specific wallet client that reports to a server the transactions it has seen, then this information can be used to make an estimate of the fraction of the network that has seen a transaction. A merchant could then hook up to this server and look up the propagation-status of a payment. Under normal circumstances, the transaction should very quickly spread and in 15-30 seconds the merchant should have a very good idea whether the transaction has reached most nodes or whether it failed to propagate, either due to connectivity issues or due to a double-spend attack.

One could also imagine a large mining pool offering merchants a deal where in exchange for a small payment, the pool would guarantee to include any valid transactions that merchant submits in blocks found by the pool. In practice this would mean that after a customer makes a payment, the merchant submits the payment transaction to the pool and receives an OK from the pool. If this is done with several large pools, a merchant could get the security that the majority of the network is backing this transaction over any potential double-spend attempts. This further reduces the already very small chance of a double-spend succeeding and will also serve to discourage such attempts.

**Conclusion: 0-conf? (Almost) 0 problems.**

Being able to accept 0-conf transactions with relative safety is a necessity for the adoption of Bitcoin (or any Bitcoin-based crypto-currency) in brick-and-mortar stores and other points-of-sale. Fortunately, 0-conf transactions are already very hard to double-spend, to the point where it becomes uneconomical to do so for the type of transactions that would have to be accepted without confirmations. In addition, the use of a payment provider which takes over the double-spend risk, completely insures the merchant against double-spends, for a fee that is still much lower than conventional payment systems such as credit cards.

In the future, new developments may be deployed that allow a merchant without such an insurance to further reduce the probability of a double-spend being performed successfully. As with many other aspects of Bitcoin, it is simply more economical for people to play by the rules than to try and break them. And an economical incentive to play by the rules is all most people need.

- An exception to this is when a transaction that has insufficient fees included is replaced by a double-spend transaction that does include sufficient fees. Any merchant should therefore check (or have his software do this) that a payment transaction contained the right amount of fees. ↩

If I mine with two identical machines, I’ll be able to compute twice as many hash values and will therefore have two times as high a chance of finding a block. This simple logic scales up rather well and it means that it makes no difference if 1000 people mine on their own or if they all submit any valid block they find to a central operator who then broadcasts it to the network.

And herein lies the main idea behind mining in a pool. The mining software is reconfigured to communicate with a central operator (the pool) rather than with the Bitcoin network directly. The pool provides the miner with the ingredients for the block and the miner tries to find a correct nonce. The rewards for finding a block go to the pool, who then distributes it among the miners.

**Share the rewards**

The point of pool mining is that all miners receive part of the block reward, not just the lucky one who computed the winning hash. So how do we go about deciding who gets how much? Clearly the reward a miner gets should be in some relation to the amount of computing power he is contributing. Someone with twice the power should get twice the rewards. But how do we measure how much someone has contributed?

One solution is for the mining software to count the amount of hashes computed and report that to the pool. But this method relies on all miners playing by the rules and not using modified software that reports an inflated amount.

Recall that mining involves computing hash values until one is found that is below the target. This target value is related to the difficulty parameter in the sense that if the difficulty is doubled, the target is halved and the chance to find a hash value below the target is halved as well.

Suppose now that the target is 100, so a hash value less than 100 is needed to make a valid block. The pool now asks the miners to report back all block headers that have a hash value of less than 10000. Any time a miner sends in such a result, the pool can compute the hash value as well and check to see if it’s correct. If so, the miner is credited for the work. This credit is typically called a ‘share’.

Approximately once every 100 reports will have a hash value that is not only below 10000, but also below 100 and thus makes for a valid block. At this point, the pool reports the block to the network and distributes the reward. The miner who reported this will still only get a single share.

**Payday!**

Now that we have a cheat-proof way to measure how much work a miner has done, we need to determine how to distribute the reward. The most obvious solution is to simply distribute the reward between the miners proportionally to the amount of work they contributed. Since we measure work in number of shares, we can add up the number of shares that were submitted while searching for this block, divide the block reward by this total and then pay each miner that much for every share they submitted.

However, there are ways to exploit this payment method by switching pools in a certain way. This gives a pool-switching miner a higher income than a miner that sticks with a single pool. Further details about this problem and the solutions in the form of other payout algorithms I will save for a future article.

]]>

**But first, hash functions!**

An important concept in understanding Bitcoin mining (and mining of most altcoins) is the concept of a hash function. A hash function is a mathematical function that takes any input data and returns a number of fixed maximum size. A very simple example of a hash function would be the function that takes any number and adds up its digits, repeating the process until a single digit number remains. The number 5618 would give 2 as result, for example.

A special subset of hash functions are the cryptographic hash functions. These have the property that a small change in the input data completely changes the output. In addition, given an output value, it should be impossible to find input data that would produce this specific output. My previous example is not a good cryptographic hash function, since a simple change like swapping the order of two digits doesn’t change the output at all. In addition, given an output value, say 6, it is easy to find not just one, but many inputs that would result in this output, for example 6, 15, 24, 123, etc…

Cryptographic hash functions have many applications. One such application is to verify that some piece of data was not tampered with. If I post a file online, I can compute it’s hash using a cryptographic hash function. Anyone downloading the file can do the same and compare the results. If they are the same, then they can be assured that the file was not altered by a third party. In a similar way, I can make a prediction about a future event, say a sports match, type it out, compute the hash of the text and share that with others. After the event, I can reveal the original text and the others can verify that I did not change my written prediction by computing the hash of the revealed text and comparing it with the hash I provided at the start.

**A recipe for a block**

Back to Bitcoin. As you know, transactions are bundled in blocks. The set of transactions in a block is described by a data structure called a ‘Merkle tree’. The details of this are not important, but the main aspect is that from this data structure a single value can be computed, the so-called ‘Merkle root’, which is computed from the set of transactions using a cryptographic hash function. So any change in one of the transactions causes the Merkle root to change.

While the transactions form the main body of a block, each block has a header which contains important metadata. The Merkle root discussed above is one element of the header, but the header also includes a timestamp, a reference to the previous block and some other variables. One particular element of the block header is interesting though. A 4 byte area that can have any value.

**The puzzle: How low can you go?**

If we put the block header into a cryptographic hash function, we get a number out. The computational problem that drives Bitcoin mining is to make sure that this number is below a certain target-value. So if the hash function would have a possible range of values between 0 and 100, we could demand that in order for a block to be valid, the hash of its header must be smaller than 20, for example.

The 4 byte area that can have any value mentioned above plays an important role here. In the process of mining, the miner will change the value of this variable, the so-called ‘nonce’, compute the hash of the block header and check if it’s below the target value. If not, change the nonce and try again. If the hash does fall below the target value, the miner broadcasts the block to the network.

**Difficulties**

It should be clear from the previous section that the speed at which we can find a valid block header depends on how fast we can compute the hash function. The amount of computing power used for mining today is much higher than it was in 2009, when Bitcoin was first launched. If the target value below which a hash should fall would be fixed, this would mean that blocks would be produced many times faster today than a few years ago.

To overcome this problem, the target value is updated regularly. This update aims to set the target in such a way that on average it takes the entire network 10 minutes to find a valid block. This update occurs after every 2016 blocks, which corresponds with a period of 2 weeks at a rate of 10 minutes per block. At this point, the total amount of time spent mining the last 2016 blocks is computed and from that, the target value is adjust.

Instead of the target value, miners talk about the difficulty value, which is inversely proportional to the target value. A higher difficulty means that the target value is lower and that is more difficulty to find a valid hash of the block header. Since the difficulty is proportional to the amount of computing power in the network, the change in difficulty can be seen as a measure for the growth of the network.

**Extra nonce – for when just the nonce isn’t enough**

Very attentive readers may have noticed an issue with the description of the block header I gave earlier. The issue relating to the nonce, the 4 byte field that can be filled with arbitrary values to in the mining process in order to find the right hash value. 4 byte is 32 bits and that means there are 2^{32} possible values for the nonce. This is roughly 4 billion. Nowadays, there are plenty of mining devices on the market that compute a multiple of that per second, because 4 billion computations per second corresponds with a hashing rate of 4 GHash/s.

While there is a timestamp field in the block header, this field only has a granularity of a second. So if more than 4 billion values for the nonce are computed within a second, the miner runs out of new possibilities to try. And these days the mining difficulty is high enough that there’s a very large chance that more than 4 billion attempts are needed to find a valid block.

To overcome this problem, some additional space was added where miners can add random data in order to try additional possibilities. This additional space is located in the special transaction that rewards the miner with the reward for finding the block (this transaction is called the coinbase-transaction). Recall that a change in any of the transactions in a block changes the Merkle root in the block header. So after all 4 billion nonce values have been tried, a miner can change the value of the extra nonce field in the coinbase-transaction, which causes the Merkle root to change, after which the miner can restart trying changing the regular nonce values again.

**Conclusions and a note on the specific functions used**

The calculations done by miners don’t serve a particular purpose. The only point is that they take time and computational effort to do. By changing the nonce and extra nonce values until the resulting hash of the block header falls below the target value, mining essentially becomes a lottery, where a miner with more computing power has better odds.

In this article, I have not given any details about the hash function used, because they don’t matter. As long as it is a proper cryptographic hash function, it can be used. In fact, many applications of these cryptographic hash functions have more stringent demands than Bitcoin mining, so even functions that are no longer suitable for other tasks because weaknesses were found, would still make for a perfectly safe function for mining.

Many alternative cryptocurrencies use different hash functions than Bitcoin. This is not for security reasons (although some altcoin creators do claim just that), but rather to prevent the dedicated hardware created specifically for Bitcoin mining (the so-called ASIC hardware) from being used to mine the alternative currency, thereby giving users that haven’t made an investment in mining hardware a chance to provide a non-trivial contribution.

**In a followup article, I will discuss the mechanics of pooled mining, where many users can work together to find a block and share the rewards.**

In reality, the flaw isn’t so much in Bitcoin as it is in exchange-systems and their bookkeeping methods. Many exchanges use the transaction-id (the tx-id) to uniquely identify transactions. The tx-id is a hash of part of the transaction content and as it turns out, an attacker can change the tx-id without changing the actual transaction (that is, the senders, recipients and amounts), rebroadcast the changed transaction (effectively creating a double-spend) and if his altered transaction gets accepted into a block instead of the legit transaction, the attacker receives his coins and can complain with the exchange that he didn’t. The exchange will then check their database, fetch the tx-id from it, look it up in the blockchain and not find it. So they could conclude that the transaction indeed failed and credit the account with the coins.

A simple workaround is to not use the tx-id to identify transactions on the exchange side, but the set of (amount, address, timestamp) instead. If a user complains about not receiving their withdrawal, support can look it up using these 3 variables. It takes a little bit more work from support, but it prevents this attack from succeeding.

While it’d be nice if the tx-id isn’t malleable, blaming this problem on a flaw in the protocol is quite a stretch. In fact, it is the custom software that MtGox uses that doesn’t properly account for transaction malleability. The reference-client, Bitcoin-qt and the associated backend, bitcoind, do not exhibit this problem.

Transaction malleability isn’t new. It’s been known for quite some time and most software can deal with it just fine. It is disappointing that MtGox blames the protocol for its own problems and in doing so causes a sharp drop in the Bitcoin-price and negative press for the currency.

For more information, you can read the article on transaction malleability on the Bitcoin wiki, an interview with Bitcoin-developer Greg Maxwell immediately following the MtGox press release or a Bitcointalk post explaining the situation in very basic terms “for a five year old”.

]]>

**Consensus in a decentralized network with untrustworthy agents**

That’s quite a mouthful. Lets break it down into more comprehensible parts. As you probably know, Bitcoin is a decentralized system in the sense that there is no central authority that determines who has how many coins and which transactions are valid. Nevertheless, we do need some method to differentiate between valid and invalid transactions and ensure that people don’t cheat the system.

One important way to cheat the system is the so-called “doublespend”, which means exactly what you think it does: The offender tries to spend the same coins twice. To prevent this, the network needs to have some way to decide which of the two transactions it accepts. A naive approach is to simply accept the transaction that was broadcast first. However, this approach comes with its own issues, because even with the best of intentions, clocks on different computers are often not synced. Add in the possibility for an attacker to change timestamps and this simple timing-based decision method becomes invalid.

What we need is a system that uniquely determines which transactions are valid and is not reliant on a central authority, synchronized clocks and it should not be affected by the presence of some hostile agents, that try to cheat the system.

**Enter the Blockchain
**

The solution to the problem described above was created by Bitcoin-inventor(s) Satoshi Nakamoto. The idea is to periodically collect new transactions and wrap them into a so-called block. Besides the transactions, each block contains some additional data, most importantly a reference to the previous block, which makes each block a link in a long chain of blocks, the blockchain.

All transactions included in a valid block are considered to be valid. However, this system doesn’t yet solve the problem, it merely moves it. Because who decides what transactions make it into a block? And how do we ensure that a hostile agent doesn’t transmit his own version of the blockchain, containing his fraudulent transactions?

An elegant approach is to use a voting system. Different agents create and publish their blocks to the network and the network votes on which block is accepted as the next in the chain. This sounds good on the surface, but again raises questions: How do we register the votes? And more importantly: How do we prevent people from voting many times? After all, things like IP addresses are relatively easy to fake and if there is some authority that handles voter registration, then the decentralized nature of the network is lost.

**Proof of work**

The solution to the voting problem is to not associate votes with individual people or individual computers, but rather with computing power. In addition, instead of a regular voting system, which are deterministic and the majority always wins, we use a system where each vote offers a probability to completely decide the outcome. Compare this with your national elections: One voter gets randomly picked and can decide which party wins the election. This is not a very suitable method for elections, but it’s okay for cryptocurrencies.

So what happens in Bitcoin is that many people use their computer to collect transactions into a block and then try to solve a computationally difficult problem. Here both the problem and the solution are unique to the block, so someone trying to create a different block can’t use a solution that I computed.

Once a solution has been found, it is bundled with the block and broadcast to the network. Other nodes in the network now check that all transactions in the block are valid and that the solution is correct for the puzzle that is associated with that block.

Whoever finds the solution first is a matter of chance, but the probability of finding the solution first depends on the amount of available computer power. Since the problem is such that it can only be solved by brute force, the user with the more powerful computer has better odds.

**How does this prevent cheating?**

People accepting Bitcoin transactions can now choose to wait until a transaction has been included in a block before they consider it final. If someone wanted to change the contents of a block after it has been published to the network, they would have to redo the work to solve the associated puzzle since any change to the contents of a block changes the puzzle and its solution.

But in the meantime, the legitimate users of the network are working to create new blocks to be added to the chain. Therefore, any attacker has to race against the entire network to produce fraudulent blocks. In practice this means that as long as more than half the computing power in the network is controlled by people that don’t have bad intentions, then the network is secure.

**So who are the miners then?**

The miners are the people and/or computers that work to solve these problems and publish new blocks. If the term ‘miner’ doesn’t make much sense to you in this way, then that’s totally normal. Instead of a miner, it is more accurate to refer to these people as a combination between an accountant and a bank security guard.

So where does the term ‘miner’ come from? It is connected with the reward that the miner receives. Since computer power isn’t free, it is not sufficient to rely on altruistic motives. As a reward for their efforts, the miner that manages to be the first to publish a new block, may include in this block a transaction that transfers coins to an address of his choosing. These coins have no origin and are considered to be newly created.

This reward, called the ‘block reward’, is the only source of new coins in Bitcoin (and most other cryptocurrencies). By design, this reward becomes smaller with time and in his original paper, Satoshi Nakamoto drew parallels with the mining of gold or other precious metals, where the veins are slowly depleted and gains diminish. This is where the term miner finds its origins.

**Conclusion**

The process of mining has very little to do with finding new coins. The coins are not hidden and don’t require people to find them. They are simply created out of nothing as a reward for creating and publishing a valid block of transactions.

This transaction-block gives transactions a sort of permanency, making it increasingly difficulty for attackers to undo past transactions. In addition, the publishing of a block serves as a ruling in the case of an attempted double spend of coins as only one transaction is included and the other is dropped.

The actual validation of transactions is not just done by the miners. Every node in the network, whether they’re mining or not, will only pass on transactions that it considers valid.

**More on mining and how it works in followup articles.**