Or, you know, enter some discussions on what exactly are the issues that SPV clients face during soft forks and see if anything can be done (on all sides) to mitigate the risks. Crazy stuff, I know Š ;-) From: NotMike Hearn via bitcoin-dev Reply-To: NotMike Hearn Date: Friday, 2 October 2015 9:57 am To: Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev wrote: > There is no consensus on using a soft fork to deploy this feature. It will > result in the same problems as all the other soft forks - SPV wallets will > become less reliable during the rollout period. I am against that, as it's > entirely avoidable. > > Make it a hard fork and my objection will be dropped. > > Until then, as there is no consensus, you need to do one of two things: > > 1) Drop the "everyone must agree to make changes" idea that people here like > to peddle, and do it loudly, so everyone in the community is correctly > informed > > 2) Do nothing > > I agree with Mike Hearn that there is no consensus on using a soft fork to deploy this feature. Either everyone agrees that we should all agree on consensus or else there is arbitrary disagreement. You cannot have it both ways. It is very important that we reach consensus on consensus or, if you will, meta0consensus. I think we should Do nothing as that is clearly the choice that we have taken re: blocksize. If we use one set of rules for that decision we should use the same set of rules for all decisions and there is no middle ground. Thank you. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev