Bitcoin mining today is dominated by mining pools. These mining pools arguably have a strong hold on the Bitcoin network, but also on their own participants. Since mining pools typically operate with little transparency, participants must issue a lot of trust in pool operators not to cheat them out of Bitcoin.
Czech Republic-basedSlush Pool – accounting for some4 percent of total hash power on the Bitcoin network – now believes it has solved this problem. Its “provably fair” mining should take away any mistrust – plus introduce some added benefits.
A Quick Recap on Mining
Miners are the entities on the Bitcoin network that confirm transactions and secure the network with hash power by finding Bitcoin blocks. These blocks include several types of data, most importantly transactions, but also the previous block header (linking blocks together), a timestamp and a random number called a “nonce.”
Using a mathematical trick called hashing, miners combine and scramble all of this data into an unpredictable random number called a hash, which is the “block header,” identifying the block. The same data will always result in the exact same block header, but if even a tiny alteration is made to any of the data, it will result into a completely new hash.
If a miner hashes data ten times, odds are that one of these hashes starts with a zero. If a miner does it a hundred times, odds are one of them starts with two zeros. The Bitcoin network requires a valid block header to start with a certain amount of zeros: the difficulty factor.
Miners essentially keep hashing potential blocks until they find a valid block, or one that meets the required difficulty.
A Quick Recap on Pools
Mining pools – the first of which was Slush Pool back in 2010 – divide the work required to find blocks among all participants. A pool operator constructs a block, minus the nonce, and sends this block to all participants, called “hashers.” (“Hashers” are sometimes simply referred to as “miners” – but they don’t do everything typical [solo] miners do.)
Hashers take the block as provided by the pool operator, and simply add a nonce to hash the bundle together. If any of the hashers finds a valid block, it sends this block to the pool operator, after which the pool redistributes the block reward among all connected hashers. (A hasher cannot keep the profit of the block for himself, as the coinbase transaction in the block is already attributed to the Bitcoin address controlled by the pool operator.)
The part of the block reward attributed to each hasher is based on his or her share of hash power contributed to the pool. This share, in turn, is calculated using “almost valid” blocks. If Bitcoin’s difficulty requires valid blocks to start with 10 zeros, an “almost valid” block might start with nine zeros, or eight, or seven. Since hashers find these “almost valid” blocks more often, pool operators have a good idea of how much hash power each hasher contributes.
(There is always a slight element of variance – luck – involved, as some hashers might randomly find a bit more almost-valid blocks than others. But as more almost-valid blocks are taken into account, this variance increasingly cancels out.)
The Problem: Pool Operator Control
The problem is that no one but the pool operator knows what percentage of hash power each hasher contributes. While hashers provide the pool operator with a certain amount of almost-valid blocks, they have no way of knowing how many “of the blocks all other hashers found. They have to trust the mining pool to tell them what their share is.
Well, almost. Hashers do know how much hash power they contributed to a pool, they can see how many blocks a pool found, and they can estimate how much total hash power is connected to the Bitcoin network based on how often blocks are found. As such, they can also estimate how much their mining pool contributes to the network, and therefore whether the pool is being honest.
But since pools – and smaller pools in particular – find only a certain number of blocks, it can take a long time to gather enough data to reliably draw a conclusion.
This uncertainty can be abused by dishonest pool operators. A pool operator could claim the total hash power is a bit higher than it really is, and that the pool is on an unlucky streak. He could then issue hashers too little share and skim some profit of the top for himself.
Likewise, if an honest pool operator really does have an unlucky streak, hashers might falsely conclude the total hash power of their mining pool is lower than it really is — and falsely conclude their share is bigger than the pool operator claims it is.
The Solution: Publish the Blocks
The solution as introduced by Slush Pool is straightforward. Rather than keeping the almost- valid blocks for themselves, Slush Pool will publish them for anyone to see.
Since it’s easy to check whether these almost-valid blocks are indeed almost valid (meaning they did require hash power to produce), and due to the much lower impact of variance, it’s impossible to fake the public list. And it becomes impossible for a pool operator to pretend the total hash power is more than it really is.
(If hashers keep track of the almost-valid blocks they submit, they could also check whether these are included in the public list – though this shouldn’t even be necessary.)
As an added benefit, this solution also offers more transparency, perhaps most interestingly regarding miner votes. With the introduction of Bitcoin XT, soon to be followed by Bitcoin Classic, Slush Pool was the only mining pool to allow individual hashers to vote on their preferred block size limit. But while hashers – and any other interested party – had to trust Slush Pool to actually attribute the right amount of hash power to the preference hashers desired, Slush Pool can now prove that it does.
The post Slush Pool Introduces Provably Fair Bitcoin Mining appeared first on Bitcoin Magazine .