This post is a follow up to my Bitcoin Mining 101 post where I covered mining basics. Here I’m going to talk about a few more topics related to mining, most of which have an impact on network centralization and scalability. Those of you who have no plans to start mining should still find this post relevant to the future of bitcoin.
In part one I talked about pooled mining and how it arose as a response to the extreme variance of solo mining. A potentially even more convenient solution is cloud mining. Instead of purchasing and maintaining the hardware yourself, you can essentially outsource that responsibility to a cloud mining company. These firms will purchase and maintain the hardware themselves, sometimes fabricating it themselves as well, and sell you a portion of the hash rate. For example, CloudHashing.com (seen to the right) is currently selling 250 Gh/s (gigahashs per second) for $1,000. If you purchase the Gh/s from them you are entitled to any bitcoins earned with those Gh/s. According to CloudHashing the $1,000 contract earned .29 BTC in June or about $170.
If you extrapolate $170/mo out for 12 months you get a ROI on that contract of about 100%. Unfortunately, it isn’t that easy. If you recall from part one, the total hash rate in the network is climbing rapidly.
What this means is that the return on your cloud mining contract is going to decline pretty sharply from month to month. So just like miners who operate their own hardware, you would need to forecast the network hashrate into the future to get an estimate of what kind of return you would get on your mining contract.
Pros and Cons
As I mentioned, a major benefit of going the cloud mining route is you don’t have to operate your own hardware. Not only does this mean that people who lack the technical skills can participate in mining but you don’t have to deal with the frustration and delays of trying to acquire hardware in a timely manner. Neither do you have to worry about permanent brain damage from heat stroke when you have your miners running in your bedroom in the summer (I’m half kidding).
Additionally, mining hardware isn’t very liquid. If you decide you want to get out of mining, you usually have to try to dump your used hardware on eBay or with a friend if you have any who are interested. Mining contracts, on the other hand, are typically easier to sell. Some cloud mining companies have set up their own markets for trading cloud mining contracts. That’s an extra benefit you don’t have if you operate the hardware yourself.
But, there are some downsides to cloud mining as well. In theory you should be able to earn more by operating the hardware yourself since a portion of your return isn’t going to pay a third party to operate the hardware for you. In practice, I don’t know if this is true. Typically, large mining firms find it easier to acquire hardware from suppliers in a timely manner compared to individuals with limited resources and connections. So, all other things equal, running the hardware yourself should be more profitable, but I’m not sure all other things are equal. Perhaps a good case study could shed some more light here.
Finally, cloud mining does create some concerns about network centralization. Remember, the primary security proposition of Bitcoin is that no one person or group should be able to control more than 50% of the network hashing power. If that happens, either by a single person/group acquiring that much processing power or by separate groups colluding with each other, they could prevent transactions from confirming, double spend bitcoins, crowd out all legitimate miners, etc. In other words, it would prevent the network from being useful and would undermine confidence in the currency.
In an ideal world there would be 50,000+ individual miners, each with only a tiny sliver of the total hashing power. The existence of cloud mining, however, introduces large firms with a sizable portion of the network hashrate. It has been reported, for example, that GHash.io owns about 10% of the hashing power in the network as a result of their cloud mining operation. Unlike pooled mining for which there are theoretical solutions to the problem of centralization, there really isn’t anything stopping cloud mining companies from amassing large amounts of hardware. If you get a few cloud mining companies the size of GHash.io, they could easily collude and take over the network.
I say all this to give you something to consider if you do get into cloud mining. It’s best to go with firms that don’t own a large share of the network hashrate.
Block Size Issues
I’m going to switch gears a little bit and talk about a hot topic of late ― block size and relay times. For a while now Gavin Andresen has been working on implementing floating transaction fees into the bitcoin protocol. As it stands, miners have discretion to decide which transactions they include in their blocks and which they don’t. This implies they can set their own policies regarding how low of a transaction fee they will accept. Up until this point, however, wallets have no idea what these miner policies are and just use a hard coded default transaction fee. What this floating fee code will do is scan the block chain see how long it’s taking transactions to make it into blocks at different fees and feed that information to the user who can than use that information to decide on a fee.
In theory, so long as the fee is higher than cost to process and store the transaction on disk, profit maximizing miners should always include it in their blocks. So transaction fees should basically be negligible. However, that isn’t what we are seeing. The following is a chart compiled by Gavin after running a node and recording estimates once per day:
Basically it shows that transaction fees are non-negligible. What’s going on is that miners are intentionally keeping the number transactions in their blocks below the total number of outstanding transaction, foregoing the transaction fees from those additional transactions. Why would they do this? Essentially, the problem stems from situations where two miners solve in block at approximately the same time. When this happens, which ever block propagates the network quicker and reaches more nodes is more likely to be accepted earning the miner the block reward (approximately $15,000 at the moment).
As it happens, blocks which contain a smaller number of transactions propagate quicker than blocks which contain more. Rather than risk losing $15,000 for an extra couple bits in transaction fees, miners just accept a small number of transactions with the largest fees and reject the rest. This creates artificial scarcity where none exists and drives up transactions fees, eliminating part of Bitcoin’s competitive advantage in the process.
So what’s the solution? There have been a lot of ideas floating around but most of them revolve around relaying a fixed size header instead of a full block of transactions and defining some other method for acquiring the transactions in the block. Gavin alluded to something along these lines in a tweet the other day:
Should be able to get constant-size newblock messages for arbitrarily large blocks using invertible bloom lookup tables.
— Gavin Andresen (@gavinandresen) August 8, 2014
All in all this is a fairly serious issue. Failure to fix it will ruin one of Bitcoin’s primary value propositions. But fixing is requires a pretty drastic change to the core protocol, something which has the potential to damaging if implemented incorrectly and which requires a near consensus to implement.
My hope is it gets fixed sooner rather than later.
Original content by Chris, copyleft, tips welcome // < ![CDATA[
// < ![CDATA[