{"type":"rich","version":"1.0","author_name":"npub1yvcp7ayqy5xa3qgtz9hj9hdn5c9shp6tuvrxu3tw99qj6dveq2csqu4zp6","author_url":"https://nostr.ae/npub1yvcp7ayqy5xa3qgtz9hj9hdn5c9shp6tuvrxu3tw99qj6dveq2csqu4zp6","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-03-03\n📝 Original message:Since the root cause of what you are trying to address is the reward\nhaving, I'd suggest considering an adjustment to the having schedule.\nInstead of their being a large supply shock every four years, perhaps the\nreward could drop every 52,500 blocks (yearly), or even at each difficulty\nadjustment, in such a way that the inflation curve is smoothed out.  The\nexponential decay rate would be preserved, so overall economic philosophy\nwould be preserved.\n\nI'm guessing hesitance to this approach would lie in a reluctance to tinker\nwith Bitcoin's 'economic contract', and slippery slope concerns about might\nbe the next change (21M?).  However, I think it could actually increase\nconfidence in the system if the community is able to demonstrate a good\nprocess for making such decisions, and show that we can separate the\nmeaningful underlying principles, such as the coin limit and overall\ninflation rate, from what is more akin to an implementation detail, as I\nconsider the large-step reward reduction to be.\n\nI'm not too worried about the impact of the having as is, but adjusting the\neconomic parameter would be a safer and simpler way to address the concerns\nthan to tinker with the difficulty targeting mechanism, which is at the\nheart of Bitcoin's security\n\nOn Wed, Mar 2, 2016 at 6:56 AM, Luke Dashjr via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e We are coming up on the subsidy halving this July, and there have been some\n\u003e concerns raised that a non-trivial number of miners could potentially drop\n\u003e off\n\u003e the network. This would result in a significantly longer block interval,\n\u003e which\n\u003e also means a higher per-block transaction volume, which could cause the\n\u003e block\n\u003e size limit to legitimately be hit much sooner than expected. Furthermore,\n\u003e due\n\u003e to difficulty adjustment being measured exclusively in blocks, the time\n\u003e until\n\u003e it adjusts to compensate would be prolonged.\n\u003e\n\u003e For example, if 50% of miners dropped off the network, blocks would be\n\u003e every\n\u003e 20 minutes on average and contain double the transactions they presently\n\u003e do.\n\u003e Even double would be approximately 850-900k, which potentially bumps up\n\u003e against the hard limit when empty blocks are taken into consideration. This\n\u003e situation would continue for a full month if no changes are made. If more\n\u003e miners drop off the network, most of this becomes linearly worse, but due\n\u003e to\n\u003e hitting the block size limit, the backlog would grow indefinitely until the\n\u003e adjustment occurs.\n\u003e\n\u003e To alleviate this risk, it seems reasonable to propose a hardfork to the\n\u003e difficulty adjustment algorithm so it can adapt quicker to such a\n\u003e significant\n\u003e drop in mining rate. BtcDrak tells me he has well-tested code for this in\n\u003e his\n\u003e altcoin, which has seen some roller-coaster hashrates, so it may even be\n\u003e possible to have such a proposal ready in time to be deployed alongside\n\u003e SegWit\n\u003e to take effect in time for the upcoming subsidy halving. If this slips, I\n\u003e think it may be reasonable to push for at least code-readiness before July,\n\u003e and possibly roll it into any other hardfork proposed before or around that\n\u003e time.\n\u003e\n\u003e I am unaware of any reason this would be controversial, so if anyone has a\n\u003e problem with such a change, please speak up sooner rather than later. Other\n\u003e ideas or concerns are of course welcome as well.\n\u003e\n\u003e Thanks,\n\u003e\n\u003e Luke\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160303/89c572a7/attachment-0001.html\u003e"}