<oembed><type>rich</type><version>1.0</version><author_name>npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n</author_name><author_url>https://nostr.ae/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2016-03-02&#xA;📝 Original message:We are coming up on the subsidy halving this July, and there have been some &#xA;concerns raised that a non-trivial number of miners could potentially drop off &#xA;the network. This would result in a significantly longer block interval, which &#xA;also means a higher per-block transaction volume, which could cause the block &#xA;size limit to legitimately be hit much sooner than expected. Furthermore, due &#xA;to difficulty adjustment being measured exclusively in blocks, the time until &#xA;it adjusts to compensate would be prolonged.&#xA;&#xA;For example, if 50% of miners dropped off the network, blocks would be every &#xA;20 minutes on average and contain double the transactions they presently do. &#xA;Even double would be approximately 850-900k, which potentially bumps up &#xA;against the hard limit when empty blocks are taken into consideration. This &#xA;situation would continue for a full month if no changes are made. If more &#xA;miners drop off the network, most of this becomes linearly worse, but due to &#xA;hitting the block size limit, the backlog would grow indefinitely until the &#xA;adjustment occurs.&#xA;&#xA;To alleviate this risk, it seems reasonable to propose a hardfork to the &#xA;difficulty adjustment algorithm so it can adapt quicker to such a significant &#xA;drop in mining rate. BtcDrak tells me he has well-tested code for this in his &#xA;altcoin, which has seen some roller-coaster hashrates, so it may even be &#xA;possible to have such a proposal ready in time to be deployed alongside SegWit &#xA;to take effect in time for the upcoming subsidy halving. If this slips, I &#xA;think it may be reasonable to push for at least code-readiness before July, &#xA;and possibly roll it into any other hardfork proposed before or around that &#xA;time.&#xA;&#xA;I am unaware of any reason this would be controversial, so if anyone has a &#xA;problem with such a change, please speak up sooner rather than later. Other &#xA;ideas or concerns are of course welcome as well.&#xA;&#xA;Thanks,&#xA;&#xA;Luke</html></oembed>