On mining transition to a zero subsidy world

Getting your Trinity Audio player ready...

This week there has been some active discussions about the mining infrastructure and ecosystem of BSV hashrate adjustments and how it pertains to projects that wish to deploy on BSV, and what they should expect.

First off, I feel it is necessary to re-state some of the obvious facts, because they are so often mis-represented in the world of crypto—(thanks to many participants in the industry who are just in it for the pump profits), namely that in the long run, all profits from mining (aka maintaining a network node which produces blocks) must be funded by transaction fees. Block subsidies are just temporary and will run out. This means that although Bitcoin is a decentralized system (in so far as there is no central coordination required for participation as a network node), it doesn’t mean that nodes need be anonymous, or even wish to be. This means, that some network nodes (miners) may actually find that being very open about their business policies could stand to benefit a lot by doing so. Conceivably due to the fact that being an open miner may illicit direct clients who wish to come directly to a particular miner with their transactions in order to gain some amount of certainty in the service that they can expect from the network, or perhaps to work out special fee pricing.

Going directly to a miner, is the better way of doing things, especially if you are launching a large project on BSV which will generate many transactions. At the end of the day, applications generally are concerned about whether or not their transactions will make it onto the blockchain within a certain amount of time, and that fees will be cheap (enough) and won’t fluctuate over time. Of those points, the latter is guaranteed basically by the nature of the fact that BSV has done away with the old BTC block size limit which was imposed reluctantly by Satoshi Nakamoto back in the beginning as a temporary measure to defend against denial of service attacks on the then fledging network. The former is the one that is hardest to have certainty in, and I will explain why.

Network confirmation times are a stochastic process but adjusted to happen on average every 10 minutes. The algorithm that is responsible for this adjustment, called the DAA or Difficulty Adjustment Algorithm, was originally calculated every 2016 blocks, and took into account the time taken to generate the last 2016 blocks.

The difficulty target, which is what determines how many (avg) hashes need to be generated before a solution is likely to be found, would then be changed such that the average block time would be reset to 10 minutes. That way, if hashpower were to increase, and blocks were found faster than 10m on average, the next difficulty adjustment period would adjust the difficulty target upwards, to ensure that blocks slowed down back to an average of 10m, and vice versa.

Now when the great Bitcoin split happened, and BCH was split from BTC in 2017, some developers at the time felt that there was enough hostility from the BTC mining companies that they may deliberately use their hashpower to ‘attack’ the new split off network, either by producing blocks which have no transactions in them, or by continually using their hashpower to re-organize blocks, effectively unwinding the blockchain perpetually. While maintaining such an attack would continually use hashpower (which has a high running cost) and capital, the attack may still succeed in deterring any new developers from using the network, if they could not be convinced that previously confirmed blocks are indeed final.

This fear, (which never came to pass) was enough for the developers of BCH at the time to change the DAA to not have a period of 2016 blocks, but instead adjust the difficulty at every block, which meant that large increases in hashpower that may jump on the network would ratchet up the difficulty very quickly, and thus would not be profitable for a miner from BTC to do so. It would also keep the block discovery rate more or less around an avg of 10m if taken on a daily basis. (Although hourly spikes and drops would still be possible). They called this new DAA the “emergency DAA.” This EDAA was also inherited from BCH when BSV split from that project in its attempt at returning to the original Bitcoin protocol, which was given up on by the BCH team shortly after their split from BTC.

The EDAA can be said to have worked, as after the BSV split there were some miners from BCH which mined on BSV only long enough to drive up the difficulty, then would leave. This resulted in times during the day when blocks would be mined very quickly, followed by several hours with very few blocks. If this was done under the original DAA, it would have been several days of a lot of blocks, followed by more than two weeks of few if any blocks. So the change was necessary, given the possibility of hostile hashpower willing to cause grief.

Does BSV still need the EDAA? That is the question at hand. The network has grown in size, and have some significant miners mining on it, including TAAL Distributed Information Technologies Inc. (CSE:TAAL | FWB:9SQ1 | OTC: TAALF), Mempool, and SBI Crypto. There are enough projects and apps using BSV that there is a constant fee volume on the network, in fact, there are often more transactions on BSV occurring than on the Ethereum network, which is truly a remarkable feat.

There is enough of an ‘ecosystem’ now that any such grief attacks by a hostile miner will likely be swiftly dealt with by the incumbent miners (by way of ignoring their blocks) or perhaps even having legal action taken against them by ecosystem parties, who may have legitimate reason to sue them on the basis of computer exploitation or Cybersecurity Act violations. It would not be possible to just casually attack BSV any longer. So is the EDAA still needed? I don’t believe so.

In fact, more and more, it is becoming an impediment for the network infrastructure providers, as it removes economic incentive for miners with hashpower from moving over from BTC to mine on BSV instead. Recently BSV has had some applications generating total block transaction fees that outweighed the block reward itself. If this flow can be sustained, there is a large incentive for hashpower coming over from BTC to ‘play nice’ and collect fee revenue, something that they can’t do as well on BTC, due to block size restrictions and low transaction volume.

The theory goes, if hashpower can be seen to significantly swing to BSV for a whole 2016 blocks (which would likely last more than a couple days), it would certainly show up on all sites which monitor hashpower. Because of this, there could be price action on BSV driven by sentiment as speculators take notice. That could start a positive feedback loop which would increase the profit of the miners switching over. It would be true that the miners would likely leave BSV again after the difficulty adjusts, but if the price of BSV would have experienced an upward swing because of it, then the next difficulty period may host the same miners coming back, this time deriving more dollar value profit from mining BSV, due to the increase in price.

As long as this strategy of on/off mining between difficulty periods results in a upward movement in BSV price that lasts the whole 2016 blocks, then a positive feedback loop forms which may likely see the rise of the BSV price above historical levels, in line with the percentage of ‘transient’ hashpower that migrates every other difficulty period to BSV. While this initially won’t seem very ideal (and would mimic the old intra-day fluctuations of hashpower following the BCH/BSV split) it actually won’t matter as much to ecosystem applications because many of them have been working on ways to decouple themselves from block confirm times. (Through the use of SPV channels, BIP270, and transaction processing contracts with known miners).

And in the grand scheme of things, a week of blocks arriving once every 5m, followed by four weeks of blocks arriving every 20m isn’t that horrible, especially when there is no practical limit on block sizes. The benefit is that this feedback loop would theoretically end up with hashpower increasing on BSV to the point of surpassing hashpower on BTC, as long as transaction volume can keep up. If not, then at least it may hit a new Nash equilibrium of hashpower around the new stable price of BSV, a price which factors in hashpower support of the network. (Currently BSV price loosely correlates with the amount of stable hashpower on the network).

So should the EDAA be reset? Yes. When should it be done? I can’t say for certain, but I believe we are getting close to the time where the ecosystem would be able to manage it. It would be a network wide upgrade that would be required, but it will be the last big upgrade needed before we can officially say that BSV is back to the original protocol, and that Bitcoin lives again.