Bitcoin’s Hashrate Jumps as Price Turns – Trustnodes

Bitcoin’s Hashrate Jumps as Price Turns


Bitcoin hashrate jumps, March 2020

Bitcoin’s hashrate has suddenly spiked for unclear reasons with it up by some 4 times more than the entire hashrate of Bitcoin Cash.

On the 29th of February bitcoin’s hashrate was at 107 petahashes per second. Now it stands at 136 as pictured above.

Making this one of the biggest jump in hashrate with it unclear why it has suddenly spiked.

One potential reason might be perhaps the re-opening of at least one mine which was closed in China due to the new strand of flu.

China is now trying to get back to normality, with workers who were previously told to stay indoors now urged to get off to work as new cases of this strand keep falling there.

Another reason may be the continued advancement in asics speed. At least three such manufacturers are locked in a fierce competition in China, with the slightest gain by one risking the complete obliteration and bankruptcy of the others as bitcoin mining is a very zero sum game.

Yet another reason might be potentially state mining, especially Iran or Venezuela for example, which might not necessarily engage in business calculations of profits and losses to mine a coin more than on the need to have the crypto for international commerce.

The apparent entrance of these new actors might have an effect on price because business miners tend to sell to cover their costs, while trade miners might even overpay for bitcoin through the cost of mining simply because they need it for a function instead of just mechanically.

Overall if we had to guess we’d say this spike is probably primarily due to the apparent return of China to normality, but bitcoin’s hashrate has been on an uptrend for many, many months.

Ethereum’s Wavy Hashy

Ethereum’s hashrate on the other hand looks more wavy instead of a straight up line as in bitcoin:

Ethereum's hashrate, March 2020
Ethereum’s hashrate, March 2020

We can see here a clear correlation between price and hash, even to the dot in some periods, with miners in eth arguably suffering and quite a bit.

That’s because some of them should have gone bankrupt, and may have well done so, as mining needs a more long term approach and plan to weather the storms and to not get too exuberant when the sun is too shiny.

Some of them are however trying to get a bailout instead through ProgPoW even though the clear difference between bitcoin’s hashrate trajectory and that of eth is probably due to bitcoin having its own unique hardware, while eth is more kind of merged mined.

That’s because eth currently runs on GPUs which can mine any coin with ‘merged mined’ not quite being the right term because eth is the biggest, but it is kind of the same in an overall conceptual view in as far as eth miners don’t necessarily need to care about eth, while bitcoin miners depend fully on BTC and maybe to some extend the smaller forks of it.

Making BTC too semi merge mined nowadays, but the other coins are such a small fraction and arguably will remain so as long as they share the same hash as bitcoin.

Hash Complexity

For small amounts, say $1,000 or even $10 million, you might minisculely think about miners potentially double spending but you probably wouldn’t really fret about it.

If however you’re moving $100 million, let alone a billion, just how safely that would go through the network could be a consideration if it takes say just one rogue pool miner in BTC to send a bit of their hash to BCH to mess with your transaction.

Still they can only double spend their own coin or turn a confirmed transaction into an unconfirmed one, they can’t change the accounts themselves or ownership except by reversing confirmation of transaction between the two genuinely transacting parties.

So the endeavor would be a bit pointless unless it was a transaction fee they are fighting over. In that case who gets the block matters because they get the fee. But if it is the moving of value itself at most all they can do is cause confusion.

Thus theoretically the amount of hash doesn’t matter at a technical level except to lower the chances of denial of service with that here meaning the reliability of confirmed transactions and the time it takes for it.

Simplicitis Deceptas

That’s in simple bitcoin. In eth, there is defi and tokens and a whole universe which could potentially make things more complicated at hash security level.

How is a good question, and it’s a good question because we don’t know, and we don’t know because defi is a very new area that is rapidly developing with considerable complexity where there could potentially be even foreseeable shenanigans.

At the base however two things are useful to bear in mind. The most important one is that miners by themselves can not change account ownership, only protocol code can do that.

So in the case of the Slockit DAO where the ethereum network basically just deleted an event, miners can not get together and secretly plot to just delete x. Instead they’d have to launch new protocol code and they’d have to get others to recognize and accept it.

That’s what is meant by immutability, or non malleability, or unstoppable contracts or permissionless and so on.

Neither miners nor devs nor businesses, nor really any man or any group, can change any ownership without the consent of the owner unless everyone agrees through collective action after much deliberation to do so, and even then whoever disagrees can just reject this change by creating their own network.

This somewhat misunderstood basic premise, currently misunderstood in BCH especially where a new client claims they’ll follow the longest chain even though this client has completely different rules, is arguably the technical foundation of the stone like nature of bitcoin or eth or others like it.

The second thing to bear in mind is that miners can change ownership between transacting parties within a period of time based on what block they choose to build upon.

So you have code rules, which miners can’t change, but within the rules all miners run, they can decide which transaction went when and so they can effectively cause a denial of service and so corrupt the database but by only reversing ownership between rightful owners, rather than by changing ownership to send it to a third party like the miners themselves.

As there is no gain here in changing ownership where it concerns other people you don’t even know, while you do so at a considerable cost to yourself, the benefit of doing so in edge cases where maybe you know the person depends on the cost of doing so. And hence the higher the hashrate, the higher the cost, and so the lower the chances of such meddling even where it concerns a billion dollars.

Meaning hash does matter at this ‘negative’ end if we call it so, but it also matters at the ‘positive’ end whereby we meet some considerable and perhaps unappreciated complexity due to the reclusive loop of higher hash meaning safer in absolute terms to transfer higher value, and higher value transfers meaning higher hash.

More clearly said, price depends on demand and demand depends on utility with the utility here being the transfer of value. So if you have more value transferred then that suggest there is more demand and thus there is a higher price, ignoring other factors for now.

But mining is itself demand, as whether for mechanical business or for trading miners, they both are demanding bitcoin.

Hence the surface simplicity deceives considerably the complexity this mighty machine hides and reveals only in drips and perhaps intuitively, as a mere guess that can be wrong, with our guess being hash is maybe indicative of demand.

In sufficient time-frames that is. We were wrong in August last year maybe. Let’s see as time goes just how wrong we were, or if we were wrong at all, presuming of course no fakery because we’d know it anyway and so we’d account for it.


Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>