Do not copy without authorization.
- the bitcoin paper:http://bitcoin.org/bitcoin.pdf
- the excellent but fast under the hood explanation of bitcoin (this explanation follows roughly the same structure, but spends more time on some points and less on others): http://www.imponderablethings.com/2013/07/how-bitcoin-works-under-hood.html
- the Primecoin paper: http://primecoin.org/static/primecoin-paper.pdf
- an explanation of the paper: http://www.reddit.com/r/primecoin/comments/1rp5vx/could_someone_explain_in_detail_the_algorithm/
A CryptoCurrency is actually simply a ledger/audit of transactions, maintained by a decentralized peer to peer network. Amazingly, this ledger is protected by the computing power of the peer-to-peer network, and unless an entity with malicious intentions gained control over more than 50% of the total network computing power, the ledger is safe and sound.
So the ledger simply contains transactions (here expressed in BTC/bitcoin):
Alice gave Bob 5 BTC
Bob gave Steve 1.5 BTC
Steve gave Frank 0.8 BTC
All transactions are sent to the whole peer-to-peer network: in other words all transactions are public, and as such anyone who can sum can find out which accounts have received the most money. However, it is difficult to map any given account to a given entity, as any entity can have many accounts.
It is actually difficult to express what is a single coin of a cryptocurrency, because coins only exists as parts of transactions, and have no real being of their own. In cryptocurrencies, the only elements that have being are transaction and transaction blocks (more on this later). Coins themselves are not modeled as part of the protocol.
This can lead to the question: how are coins created? There is a system in place (mining) that allows transactions to give coins to a recipient, without having any specific sender - thus coins are "created" via transactions from nowhere. This will be explained as part of the block mining paragraph.
Assume Alice wants to send Bob some coins.
How are we sure that Alice has enough Bitcoins or other cryptocurrencies to send to Bob?
To be sure that Alice has enough Bitcoins to send to Bob is easy: with each outgoing transaction, she needs to broadcast incoming transactions to show that she has enough money to send that money to Bob. So she will actually refer to transactions as below:
“I received 3 bitcoins on my wallet from Peter”
“I received 2 bitcoins on my wallet from Frodo”
“I can send 5 bitcoins to Bob’s wallet”
Once this is done, the referred transactions (also known as the inputs of a transaction) will be can be considered to have been flagged as “Spent”, meaning she can no longer use them as referrals to send money, avoiding double-spending money (otherwise, Alice could keep referring to the 3 bitcoins she received from Peter and spend again and again from that transaction). In reality, none of the transactions are flagged as spent ; it is simply easy to check all the transactions in the peer-to-peer-maintained transaction ledger to detect whether any transaction has been or is being double spent (actually there is an index of unspent transactions to make that task easy).
In effect, given a long list of transactions, it is computationally very difficult (and in many cases impossible) to find a set of previous transactions that show Alice received money for exactly the amount that she wants to send. This problem is well-known in mathematics, and commonly referred to as the knapsack problem.
To solve this issue, in effect with each outgoing transaction, Alice will simply refer ALL of her previous incoming transactions (which will be flagged as spent), and two transactions will be generated:
- one that goes to Bob, for 5 BTC
- one that goes back to Alice, for her remaining Balance
In other words, with this outgoing transaction, Alice flags all of her previous incoming transactions as spent, and replaces them by a single transaction that summarizes her remaining balance.
This solves the issue of knowing whether Alice has enough to cover the outgoing transaction.
An example is as below:
- Alice received 7 bitcoins from Peter (Transaction1)
- Alice received 10 bitcoins from Jason (Transaction2)
- Alice received 6 bitcoins from Steven (Transaction 3)
- Alice wants to send 15 bitcoins to Bob (Transaction4)
So what will happen is:
- Alice creates Transaction4, referring to Transaction1, 2, and 3 as inputs, and broadcasts it to the network
- Transactions 1,2,3 are therefore spent, and cannot be used as referral transactions to send money anymore
- A new transaction, Transaction5, is created that gives back 8 bitcoins to Alice. That transaction is still valid, and can be used by Alice to send bitcoins later on.
One of the problems faced by cryptocurrencies was: how are we sure that when looking at the transaction “Alice gave Bob 5 BTC” that it is really Alice that sent Bob 5 BTC? Could it be that Bob sent a fake message to the peer-to-peer network saying there was such a transaction, in order to steal 5 BTC from Alice? Or could Alice be trying to refer to other transactions that were not sent to her?
Proving that Alice is indeed the owner of the money is accomplished by signing the message using a public and private key system.
Basically, when receiving money from Peter and Frodo, each time Alice gave the sender a public key (her receiving public key, effectively an address that identifies an account), which is a 64-digits hexadecimal number. When she generated that public key, she also generated a private key, that she alone knows - it is critical to protect that private key.
For each incoming transaction (input) that Alice refers to when she wants to send money, Alice needs to prove that she is the owner of the Public key that this incoming transaction was sent to. To do so, she mathematically combines her transaction message “Alice sends 5 BTC to Bob” to the private key (linked to her incoming account public key) to generate a signature that is appended to her transaction message. This signature does not contain her private key, nor can her private key be inferred from that signature. However, it is possible to verify that a message was properly signed by the relevant private key by comparing the public key to that signature and the message.
Therefore, all nodes on the peer-to-peer network can do the following process for each transaction sent:
- check the referral transactions that prove the sender has enough coins to send (i.e. previous transactions that the sender received are enough to cover the message sending)
- get the public key (or public keys) that the referral transactions were sent to (this should be the sender’s receiving public key)
- check the signature of the send transaction against each public key and the send transaction message content.
- if the signature matches the public key, then it means that indeed the sender is the owner of the private key linked to the public key that the referral transactions were sent to. The sender is therefore entitled to send that money, and mark the referral transactions as spent, since they were sent to them.
This ingenious system makes it easy for anybody to check whether a sender owns the private key to a public key to which money was sent to, and therefore to check that the sender indeed was the recipient of enough money to be able to send money. All of this without knowing the sender’s private key!
What is also interesting is that each message being different, the signature generated by mixing the private key to that message is also always different, even though the private key itself doesn’t change. Therefore the signature not only serves to prove that the sender is the owner of a receiving account that has received enough money to cover the transaction, but also to protect the message against tampering: if anyone were to change the contents of the message (such as to which Public key the message is being sent to in order to maliciously receive it), the signature would not match the message it is attached to anymore, and the transaction would be rejected.
Generating new public keys and private keys is easy, and can be done without access to the Internet - it is almost impossible to have a collision with another user, because of the sheer number of possible public keys. Cryptocurrency clients will usually to that for you.
Terminology point: referral transactions are usually referred to as the “input” to a transaction, and the output of the transaction is the public key and amount to which money is being sent.
Of course, all of the referral transactions need to also be checked! This is achieved by looking at their inputs (their own referral transactions) and then checking their own referral transactions, all the way until the origin.
When downloading a cryptocurrency client (such as a Bitcoin client), the first thing the client does is actually download the whole history of transactions from nodes on the network, and validate each and everyone of the transactions and their inputs, and keeps doing so for any new transactions received from the network. Doing so, it also makes sure that no transaction has been referred to as input more than once, since that would indicate there was a double spend.
Thus a peer-to-peer security network, requiring no trust between nodes, is formed.
A cryptocurrency is just a list of transactions, which are protected against tampering and negative balances through a public/private key system.
In effect, any public key used on the network is an account, also referred to as a wallet. The only thing necessary to claim ownership of that Public key (and therefore to claim ownership of all the transactions that were sent to that public key) is the Private key linked to that Public key. That private key gives the power to send money to another Public key address.
In other words, a cryptocurrency account is a simple tuple of (public key, private key), which can be printed on paper. If you have that tuple, you own the account. All the records are kept in the peer-to-peer network, and it is therefore not necessary to keep track of anything else than your own public and private key tuples.
You can at any time know how much coin each of your public keys is entitled to spend by getting the most recent ledger from the peer-to-peer network, and adding up all unspent transactions that were sent to each public key until you get your balance.
All cryptocurrency transactions are irreversible. There is no customer support, no central entity to refund you. Transactions cannot be rolled back because there are already part of the public record across many nodes.
The ledger of transactions is protected by different mechanisms, but one of the main features used is a hash algorithm. The reason why will be discussed later. A hash algorithm is simply a function that maps any input of any length, into an output of a fixed length.
A very simple hash algorithm would for example be: “count the number of characters in the input, and pad with leading zeros until you have 10 digits”. For example, running “a word” through this algorithm would yield the result 0000000006. This algorithm would only work for inputs of less than 9999999999 characters, so in that sense is a limited hash function that only works from a specific domain.
Another essential feature is that each input will give a completely different hash, even for a very small difference. “MyHash” and “myHash” will give completely different outputs.
It is difficult to maintain an order of transactions, because new transactions being propagated across the network, it would be possible for the following scenario to happen:
- transaction 1 is done, and starts propagating through the network
- transaction 2 is done 10 seconds later and starts propagating through the network
- a peer-to-peer node much closer to the origin of transaction 2 receives transaction 2 first and transaction 1 later. For that node, the correct chronological order of transactions is transaction 2 -> transaction 1.
This is an issue, because it is critical to know the correct order of transactions to avoid transactions from being double-spent.
For example the following scenario can occur:
- a buyer pays for a product (transaction 1, referring to transaction A as input)
- seller ships the product
- the buyer sends a second transaction to themselves or a different public key they own (transaction 2, also referring to transaction A as input)
- because of speed of propagation of the transaction in the network, some nodes may receive transaction 2 before transaction 1, and therefore declare that transaction 1 is invalid because it double-spends transaction A.
- if the consensus becomes such, the seller of the product will not get paid because transaction 1 has been deemed invalid, and has shipped a product for free
This also shows that it is difficult to get consensus on the order of the transactions in the whole network.
The problem can only be solved if the entire network can agree on a transaction order.
The cryptocurrency answer to that has been to group transactions in blocks, which are chronologically ordered by their “height”. The first block of transaction has a height of 0, the second block has a height of 1, the third a height of 2, etc. All transactions in one block are marked as having taken place at exactly the same time.
Therefore, blocks provide a chronological order of transactions, and the chain of blocks, dynamically validated by the peer-to-peer network processing power is called the Block Chain. Transactions are worthless until they have been made part of a block, and are referred as unordered or unconfirmed transactions.
A Transaction that has been put into the latest block is said to have been confirmed once. A transaction that was put in the block directly before that is said to have been confirmed twice, etc. The reason for that is important, and will be explained in the block chain Security sections.
Of course there needs to be a system to agree on the order of the block chain, as well as to protect the block chain against any tampering (which would open the network to double-spend attacks).
The first way to avoid tampering is to make sure that each block doesn’t contain a block height, but simply a reference to the previous block. Therefore, with the exception of the very first block created, a block cannot be created without having a direct parent, the previous block, and explicitly referring that parent through that parent’s block hash (the output of the hash function applied to a block). Block heights are deduced from this ordered chain of blocks.
Any node on the network can build a block from unconfirmed transactions it is aware of and broadcast it as a suggestion of what the next block in the chain should be. Of course if every node in the network did that, this would give too many suggestions for new blocks.
One way to avoid getting many block suggestions is to make creating blocks difficult. As such, a very difficult task is required of every block builder. With Bitcoin, creating a block goes in the following way:
- A node creates a block by grouping transactions, and adding a reference to the previous block (the SHA256 hash of the previous block)
- A small random number (referred to as the nonce) is appended to the block
- The whole block along with the nonce is passed through a SHA256 hash function with the block hash as output.
- Bitcoin requires that the hexadecimal representation of the block hash be inferior to a certain value (which is a representation of the difficulty of solving a block), which leads to block hashes having a certain number of leading zeroes, such as 0000000000000003bd7d2916ffa0d112d0797ffa9eef32ba62a219d215e02b55
This kind of requirement is referred to as a proof-of-work requirement.
Because hashes are fully random, and generate completely different outputs with each different nonce, the only way to find a hash that satisfies the requirement of the network is to try nonce after nonce after nonce, until finally the hash of the block satisfies the requirement. This could take years and years for a standard desktop computer, depending on the difficulty chosen (linked to the number that the hashed value needs to be inferior to).
There is a reward system for a node that manages to create a block with the correct hash: the node is entitled to put a transaction to themselves for a pre-determined amount in the list of transactions that make up the block. Currently the reward for solving a block, and making it part of the block chain is 25 bitcoins, equivalent to 20,000 USD!
The very first bitcoin block contained a single transaction for the block author, which was the reward for creating that block (at the time 50 bitcoins).
This whole process of creating blocks, which is very computationally demanding by having to check the block hash for each nonce value until a hash that satisfies the requirements is found, is called mining. Mining has two purposes:
- It helps secure the block chain by guaranteeing that very few block candidates can be generated at any given time
- it mints new bitcoins by giving a reward to the node that successfully mined the block, and therefore puts more currency in circulation
The block mining process also further secures the block chain almost fully, but this will be explained after the next section, which describes how to deal with multiple block candidates, and introduces the concept of the longest chain.
Consider the following scenario (arrows indicate a child block that refers to its parent block):
[Block 10] <- [Block 11]
The latest block generated is block 11.
From this block 11, a miner can start working on submitting a candidate for block 12. For this, the miner gathers the unconfirmed transactions in his block, adds the block 11 hash in there, and starts checking nonce after nonce until he gets a hash output that satisfies the currency conditions.
Therefore, block 12 is created and added to the chain, assuming no other miner found a solution first:
[Block 10] <- [Block 11] <- [Block 12]
Now it so happens that at roughly the same time, two miners manage to create a candidate block 13 that satisfies the currency conditions. We have two chains that start getting broadcast around the network. This is referred to as a Block Chain Fork.
[Block 10] <- [Block 11] <- [Block 12] <- [Block 13A]
[Block 10] <- [Block 11] <- [Block 12] <- [Block 13B]
Depending on which block first arrived to them through the network, miners will try to find a child block to either Block 13A or Block 13B.
Assume that very quickly, a miner manages to find a child block to Block 13B, while no such child block has been found for 13A, we now have:
[Block 10] <- [Block 11] <- [Block 12] <- [Block 13A]
[Block 10] <- [Block 11] <- [Block 12] <- [Block 13B] <- [Block 14]
This chain that includes Block 14 is now the longest, and Block 14 refers back to Block 13B. Block 14 starts propagating throughout the network. Each node that receives it will understand that the longest chain available is now the one with Block 13B and Block 14, and will discard Block 13A as invalid. Therefore the block chain that includes Block 13B is now the official main chain.
Any transactions that were included in block 13A but not block 13B will go back to the pool of unconfirmed transactions. Block 13A didn’t make it in the chain, the miner of that block does not have any reward (because there is no record of the reward transaction in the main block chain), and therefore block 13A is referred to as an orphaned block.
This exposes a weakness in the system: a double spend attacker could send some currency to themselves via Transaction 1 (referring to input Transaction A), and at the same time send currency to a product seller via Transaction 2 (also referring to input Transaction A, therefore double-spending it).
If Transaction 2 is accepted in Block 13A, and therefore gets confirmed once, the seller may ship the product immediately. If at the same time Transaction 1 gets accepted into Block 13B, the following will happen:
- eventually Transaction 2 is put back into the pool of unconfirmed orders because Block 13A has been orphaned
- however at the same time Transaction 1 has been accepted as part of the main block chain. Because of this, Transaction A, which it refers to, is considered Spent.
- Once Block 15 starts being built, it will gather transactions. However, Transaction 2 cannot be included in the block, because it refers to Transaction A, which is already spent. Therefore the seller will have shipped a product for free.
As such, when a seller accepts bitcoins, they will want to wait until transactions have been confirmed multiple times (are older in the block chain), to make sure that they are not the victim of such a scenario.
In Bitcoin, each block takes on average 10 minutes to solve (and the difficulty is adjusted to maintain that). It is considered that waiting 6 blocks (6 confirmations) is a good way to ensure security, therefore making transactions take 1 hour before being fully validated. This is pointed out (and rightfully so) as one of the weaknesses of Bitcoin as a currency.
Other alternative coins have adopted shorter block times to fix that issue.
We have seen that there are mechanisms to ensure that there is only a single version of the block chain in the end, propagated across the network, by enforcing the longest-chain policy (in case of a fork, the chain that generates the next block the fastest wins).
In addition, it is extremely difficult to tamper with the block chain (by enabling double-spend attacks) because each block contains as part of its payload the hash of the previous block.
Looking at the following scenario:
[Block 10] <- [Block 11] <- [Block 12] <- [Block 13] <- [Block 14]
Say I want to change the official order of the transactions by having a transaction that was in Block 10 be put in Block 14, enabling me to effect a double-spend attach. I can try to create a fork at the level of Block 10. To create that fork, I need to:
- create an alternate version of Block 10, Block 10B, containing the transactions I want, and the hash of block 9.
- to do so, I need to very quickly find a nonce that makes the hash of my new block fit the conditions of the currency (difficulty)
- then I need to create block 11B, with the hash of Block 10B, finding the nonce.
- rinse and repeat until I create block 15B
IF I have managed that feat BEFORE the true Block 15 from the main chain has been created, then my new fork will become the longest chain, and therefore be accepted as the main chain.
However, this means I need a lot of computing power. At least 50% of the total computing power in the network, and more as the origin point of my intended fork gets older. Currently, even the best super-computer in the world cannot match 50% of the network, so we are effectively safe. Anyway, with that kind of computing power, it would probably be more profitable to just mine many coins rather than try to subvert the system.
Effectively a cryptocurrency has a few main parameters:
- the block difficulty, which determines, on average, how much time it will take for the network to solve/mine a block (the block solving time)
- the interval after which the block difficulty will be adjusted. This is necessary because as the network grows, the computing power grows, and therefore if the difficulty remains stable, the amount of time to mine a block will decrease from the target. For bitcoin, the interval is 2016 blocks.
- the reward for mining a block
- the interval after which the reward is revised (to ensure a limited supply of currency). The reward is revised for bitcoin every 210,000 blocks
- the requirement method to mine a block, typically just specified as the hashing algorithm used.
Note that cryptocurrencies typically have a target time for blocks. This target time for blocks is 10 minutes for bitcoins, 1 minute for Primecoin. An interesting corollary is that the more computing power is spent across the network mining a given coin, the faster the blocks will be solved, and thus the higher the difficulty becomes in order to keep the block solving time fixed!
Most cryptocurrencies are similar, and use two main hashing algorithms:
Some other currencies have more original method, such as Quarks (uses multiple hashing algorithms on top of one another) or Primecoin (uses the difficulty of finding prime number chains of certain types, whose mathematical origin satisfies certain criteria such as being a multiple of the hash of the block as the proof-of-work method)
We will go into details about what impact that choice has on mining lon in the next section.
Mining used to be done with CPUs only. It is now also done with GPUs (video cards, primarily AMD/OpenCL video cards), FPGA circuits (programmable chips), and ASICs (hard-coded chips designed to do one task only, such as SHA256 hashes). Each is faster and/or consumes less energy than the other.
Performance is usually measured in Hashes/second: the number of hashes a computer can try every second.
For SHA256-based currencies, currently mining is possible by all of the above methods. ASICs will be hundreds of time faster at mining than CPU mining, with current hardware providing over a Tera-Hash per second, versus a customer PC providing less than 1 Giga-Hash/s, and often less than 100 Mega-Hashes/s.
This makes barrier to entry in terms of hardware necessary very high for SHA256-based currencies, which favor miners with access to expensive and difficult-to-find ASICs. This is because the total computing capacity of the network is very high because of all the dedicated mining rigs and ASICs, and this in turn pushes the difficulty sky-high, making it difficult for entrants with consumer hardware to be successful at mining.
For Scrypt-based currencies, mining is possible on CPUs and AMD GPUs (the latter offering a 10x increase over CPUs). No FPGA or ASICs are available at the moment, although one company announced their plans to commercialize an ASIC by mid-2014. This makes buying AMD GPUs risky when thinking about entering the mining market on such coins.
Other currencies are currently only feasible on CPUs, such as Primecoin and Quarks. Primecoin GPU miners have been unsuccessfully attempted, not providing much improvement over CPU miners. Such coins give owners of “standard” hardware the ability to participate in mining without too much of a disadvantage.
There are two ways to mine crypto-currencies: on your own, or part of a pool with a revenue-sharing agreement.
When you are on your own, you ONLY get money if you mine a block AND manage to be kept in the main chain. You then earn the full block reward. You could get lucky and mine a bitcoin block in seconds and earn a cool 20kUSD. But on average, consumer hardware will take around 60-70 years to mine a single block at the current difficulty. Not many currencies are profitable in solo mining, the current difficulties need to be analyzed carefully.
When you are pool-mining, you are lending your computing power to a pool that gathers multiple miners at the same time. Typically, each mining computer is associated to a “worker” on the pool, which is just a login and a password.
When mining in a pool, you will receive a fractional reward for each block the that pool solves and that is maintained in the main block chain. The fraction of the reward depends on:
- how much computing power you have contributed to solving the block
- how much fees you are paying to the pool (typically 2%)
How the pool measures your contributed computing power depends on each pool. Typically, however, pool will define shares as a block solved with a lower difficulty than the true block difficulty (that share difficulty is defined with each pool). In other words, you are solving shares, which truly have no meaning to the cryptocurrency, but not the block itself (if you do solve the block, you would have been better off solo mining :) )
The more shares you have solved for a given block (as a proportion of the total number of shares solved by the pool for that block), the more you are rewarded. So if you have solved 10% of all the shares solved during a given round, you will get roughly 10% of the reward (minus fees and any additional reward attributed to the solver of the block).
Some pools have fixed values per share, and increasing weights for the difficulty of the share solved (a share of difficulty 8 will be counted more than a share of difficulty 7).
Note that the rules are different in each pool. Note that pools may also just run away with rewards. The cryptocurrency doesn’t require trust, but pools do!
One technique of exploiting a cryptocurrency is to create a new cryptocurrency, and pre-mine it. In other words, for a while, only the developers will be mining the currency, before actually giving access to a frontend and binary to the rest of the public. This means that the developers have effectively created a large reserve of coins before anybody else could.
The next step is to market the currency, so that its value soars vs Bitcoin or USD.
The last step is to sell back the coins earned during the pre-mine for a good profit, and very little risk (not much development is needed because all the hard work has been done by Bitcoin, and not much power or electricity is needed to premine).
Because of this, pre-mining is viewed as a disgrace by the community, and pre-mined currencies are typically avoided (although good marketing towards the less knowledgeable public may work).
As a workaround to this, some developers of new coin have resorted to simply have a difficulty adjustment that will favor people who mine during the first hours of the currency. Some coin developers make it worse by making sure no binary clients are available during that period, such that only individuals who can compile the code from source can participate in those early hours.
This is referred to as “Instamine”, and some of the most popular currencies have suffered to it to some extent, intentionally or not.
The cryptocurrency frontends are almost all based on the original Bitcoin client. When first launched, they will download the whole block chain and check all the transactions - for Bitcoin, this can take over 24 hours. Below is a Primecoin client getting the last 6 days of blocks:
It is possible to send and receive money through that simple to use client.
To receive coins, you need to create a receive address public/private key. The client can do this for you in the receive menu.
By default, the client hides the Private key, and only shows your Public key.
You can display the Private key by going to help, Debug Window, Console Tab, and typing “dumppriv key <public key>
(No, I am not really using this public/private key tuple it is empty and will stay that way!)
Because the network takes care of maintaining the history of all transactions, the ONLY thing you need to keep your wallet safe are your public and private key tuples.
Note that the client gives you the possibility to encrypt your wallet (and therefore all your public and private keys) under the Settings menu.
The client can do solo mining, however pool mining is advised, unless you have an insane amount of computing power in your hands. Doing pool mining may use a different method/client for each currency/pool, so follow the instructions!
This section describes an interesting Proof-of-Work used by Primecoin.
Some of the most common criticism of cryptocurrencies is that lots of computing power and electricity is lost doing hash after hash, for nothing useful but to maintain the ledger. Another criticism is the hardware mining requires, which makes it very risk to invest in such hardware not knowing how the difficulty it going to evolve.
Primecoin tries to avoid these pitfalls by having a proof-of-work that can currently only be mined on CPUs, and that helps the world of mathematics by finding Prime Number Chains.
Primecoin basically works in almost the same way as any other cryptocurrency, and its blocks still include a variable nonce and are also hashed using the SHA256 algorithm.
However the goal of the proof-of-work is more involved: it involves finding Cunningham Chains of prime numbers of the first or second kind, or a bi-twin chain. More on each can be found on wikipedia or the primecoin paper, but each of those chains have an origin, usually a very large number, that is not a prime. The requirement is that the origin of the prime chain be a multiple of the hash of the block.
The difficulty is adjusted by requiring that the prime chains be at least X numbers long. There is also a fractional difficulty which is linked to the non-prime number that is outside of the chain, but would have followed the last number of the chain.
A standard algorithm is therefore to first vary the nonce of the block to find a hash that is divisible by a few prime numbers, such as 2, 3, 5, 7, and 11 (although just iterating through this can take time), which increase the odds of finding a prime chain whose origin is a multiple of the hash/
Because the numbers being used are extremely big numbers, which are not easily supported by GPUs, the only way to mine right now is via CPUs. The mining performance is measured in primes/second or chains per unit of time.
Primecoin gives a strong incentive to find better/faster algorithms to find prime chains, as well as give data to mathematicians about getting a better picture of the distribution of these chains within the natural numbers.
So how much is a given cryptocurrency worth? It all is in the eyes of the beholder, like pretty much anything else that can be bought and sold, such as gold. If people think a coin has value, and are willing to pay for it, than that coin has value.
Bitcoin is currently traded at around 900 USD per bitcoin, a staggering increase from the fractions of a dollar it was worth three or four years ago. It is highly volatile, and a very dangerous investment. The people who earned the most from Bitcoin are the ones who were mining at first. It is estimated that the creator (or creators? it is a bit of a mystery) of Bitcoin has around 1 million bitcoins, which makes him/her/them almost a billionaire. Another popular study is that of a man having bought bitcoins for 27 USD a few years back, only to realize that today they are worth almost 1 million USD. And a third story is of a man who forgot the private key to his bitcoin address, having thrown the hard drive containing the wallet away. Too bad, because he had 7,500 bitcoins (around 7 million dollars!) which now have been lost...
Now each coin is different, and also depends on which markets it gets listed on. Because yes, there are markets for cryptocurrencies, such as Mt. Gox (a Japanese company) and Cryptsy (an American company). These exchanges typically only quote the major cryptocurrencies (Bitcoin, Litecoin) against the dollar. Then other currencies are quoted against the bitcoin and litecoin.
As I am writing these lines, a Primecoin is quoted at 0.0047 bitcoins, itself quoted at around 915 USD. So each of the Primecoins I own is worth (before transaction fees) roughly 4.3 USD.
After mining any cryptocurrency, a miner has two choices:
- hold the cryptocurrency in the hopes that its worth per unit will rise (it could fall!)
- immediately convert this cryptocurrency in USD
Of course one alternative is riskier than the other, but seems to be the one chosen by many miners, as they believe in the cryptocurrency - this can be cited as one of the reasons the coins are valued so much.
Mining is a relatively risk-free endeavor, although it can be frustratingly slow depending on your hardware. The only risk being taken is that the electricity and processing power that went into mining were for naught, in case the value of the cryptocurrency suddenly plummeted. It can therefore be “fun” to mine. Just see it as a hobby that has the potential to bring you some revenue, and not a true source of revenue, and certainly not a replacement to a salary.
There are online return on investment calculators such as Coinwarz, which will indicate the cryptocurrencies that currently would provide the best return on investment for a given hardware capacity. This tends to change a lot because of fluctuating cryptocurrency to bitcoin to USD charts!
But it can give you a good idea of what would be good to mine by looking at which coins stay on top for several days in a row.
If you enjoyed this document or found it useful, please feel free to donate a small (or big!) amount at: