rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2015-09-28 📝 Original message:On Mon, Sep 28, 2015 at 12:48:57PM +0200, Mike Hearn 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 Hmm? You didn't quote any of my email, so I'll remind you what I did say we had consensus about: 2) We have consensus on the semantics of the CLTV opcode and 3) We have consensus that Bitcoin should adopt CLTV The broad peer review and discussion that got #6124 merged is a clear sign that we expect CLTV to be eventually adopted. __The question isn't if CLTV should be added to the Bitcoin protocol, but rather when.__ (emphasis mine) Both those statements of consensus are *not* about how CLTV is to be deployed. I did discuss deployment later: 6) We have the __necessary consensus__ to deploy CLTV via IsSuperMajority() The various "nVersion bits" proposals - which I am a co-author of - have the primary advantage of being able to cleanly deal with the case where a soft-fork fails to get adopted. However, we do have broad consensus, including across all sides of the blocksize debate, that CLTV should be adopted. __The risk of CLTV failing to get miner adoption, and thus blocking other soft-forks, is very low.__ I probably could have worded this section a bit more clearly; when I say "necessary consensus" I'm referring to the consensus required for a soft-fork deployment. At minimum a simple majority of hashing power - your approval isn't required. For a safe soft-fork, we'd like a super majority of miners to be on board. For a IsSuperMajority() soft-fork - as opposed to nVersion bits - we also need the probability of the soft-fork being rejected to be very low. To achieve that, having consensus that CLTV is a good idea is the best situation to be in. But that's not to say that a few dissenting voices should be seen as a blocker to progress - rather is just makes the deployment a bit more risky, being a sign that the consensus may change in the future, with the soft-fork being later rejected. For example strong objections by a respected Bitcoin developer who has made significant contributions to the consensus codebase and protocol development would be a strong sign that a IsSuperMajority() soft-fork might fail, and deployment via nVersion bits is probably a better approach. Fortunately we're not in that situation. Hard-forks are a very different situation, with significantly more need for very broad consensus, but that's been well discussed elsewhere. I have three questions to you: 1) Do you agree that CLTV should be added to the Bitcoin protocol? Ignoring the question how exactly it is added, hard-fork or soft-fork. 2) Will you add a IsSuperMajority() CLTV soft-fork to Bitcoin XT if it is added to Bitcoin Core? If you refuse to do this the risk of the soft-fork is increased a bit, although miner support for XT has remained extremely low, and the 95% switch-over threshold has a significant margin for error. (there's a 75% threshold to consider as well, however as XT has adopted my pull-req #5000 - Discourage NOPs reserved for soft-fork upgrades - those miners will only produce valid blocks under CLTV rules) 3) Will you add soft-fork detection to bitcoinj, to allow SPV clients to detect advertised soft-forks and correctly handle them? Notably, if you do this your objections against soft-forks will be met, as the behavior of a SPV client with soft-fork detection during a soft-fork will be identical to that client during a hard-fork. In particular, the SPV client will correct reject invalid blocks, and continue to follow only the longest valid chain. (modulo unadvertised forks of course, an inherently unavoidable problem with the SPV security model) Secondly, that code should also detect forks it doesn't know about - as is done in Bitcoin Core already - and warn the user. -- 'peter'[:-1]@petertodd.org 00000000000000000d74f5def1087f3ec1571cb468e471e71f96063253988c78 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 650 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/8afec924/attachment-0001.sig>