{"type":"rich","version":"1.0","author_name":"npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","author_url":"https://nostr.ae/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-03-28\n📝 Original message:On Tuesday, March 28, 2017 5:34:23 PM Johnson Lau via bitcoin-dev wrote:\n\u003e You are probably not the first one nor last one with such idea. Actually,\n\u003e Luke wrote up a BIP with similar idea in mind:\n\u003e \n\u003e https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki\n\u003e \u003chttps://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki\u003e\n\u003e \n\u003e Instead of just lifting the block size limit, he also suggested to remove\n\u003e many other rules. I think he has given up this idea because it’s just too\n\u003e complicated.\n\u003e ...\n\u003e So if we really want to get prepared for a potential HF with unknown\n\u003e parameters, I’d suggest to set a time bomb in the client, which will stop\n\u003e processing of transactions with big warning in GUI. The user may still\n\u003e have an option to continue with old rules at their own risks.\n\nIndeed, actually implementing hfprep proved to be overly complicated.\n\nI like the idea of a time bomb that just shuts down the client after it \ndetermine it's stale and refuses to start without an explicit override.\nThat should work no matter what the hardfork is, and gives us a good \nexpectation for hardfork timeframes.\n\n\u003e Or, instead of increasing the block size, we make a softfork to decrease\n\u003e the block size to 1kB and block reward to 0, activating far in the future.\n\u003e This is similar to the difficulty bomb in ETH, which will freeze the\n\u003e network.\n\nI don't like this idea. It leaves the node open to attack from blocks actually \nmeeting the criteria. Maybe the absolute minimum as Jeremy suggested.\n\nLuke"}