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