{"type":"rich","version":"1.0","author_name":"npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9","author_url":"https://nostr.ae/npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-03-02\n📝 Original message:It is **essential** that emergency code be prepared. This code must be\nable to lower the difficulty by a large factor.\n\n---\n\nThis halving-difficulty-drop problem can, with some bad luck, get quite\ndisastrous, very quickly.\n\n( I did a micro-study of this problem here, for those who are unaware:\nhttp://www.truthcoin.info/blog/mining-heart-attack )\n\nFor example, it is theoretically possible that 100% of miners (not 50%\nor 10%) will shut off their hardware. This is because it is revenue\nwhich ~halves, not profit. If miners are all equal, difficulty causes\ntheir profit margin to narrow over time (for example, if BTC revenues\nare $100, and amortized fixed costs are $10, then difficulty adjustments\nwill cause total energy costs to rise to ~ $89, such that total\npre-halving profit is $1 for everyone...post-halving, profit is -$49 for\neveryone).\n\nSo, if miners are homogenous the result is disastrous. Fortunately,\nminers are probably still somewhat heterogenous. However, we don't know\nhow their power contracts (or their hardware turnover) are\nscheduled...many miners might (?) have already planned, in private, to\nclose down (or substantially reduce) operations after the halving.\n\nAs the coinbase rewards are currently orders of magnitude larger than\ntx-fees, fees are unlikely to be able to compensate for this. Users may\ndecide to simply hold-off on transacting until fees decrease.\n\nWorse, if the price crashes (possibly as a result of uncertainty\nsurrounding this episode), it will begin to affect miner-revenue.\n\nAs a result, miners may decide to temporarily halt mining until the\ndifficulty falls naturally.\n\nBut such a temporary halt is also (potentially) disastrous. Recall the\nsimple fact that difficulty adjustments are measured in blocks, not time\n(it appears that we have exactly 1015 blocks between the halving block\nand the next difficulty adjustment block). If excessive difficulty\nchokes the system, next difficulty adjustment may *never* arrive naturally.\n\nIn this worst-case (but somewhat plausible) scenario, we will be\n*forced* to lower the difficulty via hard fork, and we will be forced to\ndo so very very QUICKLY, as word will be spreading that the Bitcoin\nsystem has broken!\n\nIf a specific hard fork is not coded and tested for this, in advance,\nthe delay might be accompanied by endless [contentious] conversations\nabout what else should be included in this hard fork.\n\nWorse, since all users will need to upgrade, there will be uncertainty\nover contentious versions, malicious agents may try to tamper with\nversions (to steal Bitcoins), etc. We should consider pushing a version\nout for users to upgrade, in advance of the halving, as soon as possible.\n\n\n\nWhat a disaster! I certainly hope it does not happen, but if it does we\nshould have already agreed on what to do.\n\n\nOne choice is \"which number do we set the difficulty to?\". Half may be\ntoo much, or too little. However, allow me to suggest that, if this\ndisastrous scenario occurs, we shouldn't take any chances, and reduce\ndifficulty by a huge proportion...80% or so. The difficulty will then\nquickly begin to increase again...we can warn users of the increased\norphan risk, and that they should wait for many confirmations (which\nshould be happening faster).\n\nSo, \"Allow the alert key to reduce the difficulty by 80%, exactly once\non one of the 1015 blocks between halving and difficulty adjustment.\"\n\nAnd we should consider smoothing the rewards (as described in my post,\ncan be done via soft fork) to prevent this from happening again. In\nmicroeconomics literature, 'kinks' in incentive-systems are\nalmost-universally agreed to be very undesirable.\n\nPaul\n\n\nOn 3/2/2016 10:42 AM, Luke Dashjr via bitcoin-dev wrote:\n\u003e On Wednesday, March 02, 2016 2:56:14 PM Luke Dashjr via bitcoin-dev wrote:\n\u003e\u003e so it may even be possible to have such a proposal ready in time to be\n\u003e\u003e deployed alongside SegWit  to take effect in time for the upcoming subsidy\n\u003e\u003e halving.\n\u003e \n\u003e Lapse of thinking/clarity here. This probably isn't a practical timeframe for \n\u003e deployment, unless/until there's an emergency situation. So if the code were \n\u003e bundled with SegWit, it would need some way to avoid its early activation \n\u003e outside of such an emergency (which could possibly be detected in code, in \n\u003e this case).\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"}