{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-09-28\n📝 Original message:On Mon, Sep 28, 2015 at 12:48:57PM +0200, Mike Hearn wrote:\n\u003e There is *no* consensus on using a soft fork to deploy this feature. It\n\u003e will result in the same problems as all the other soft forks - SPV wallets\n\u003e will become less reliable during the rollout period. I am against that, as\n\u003e it's entirely avoidable.\n\u003e \n\u003e Make it a hard fork and my objection will be dropped.\n\u003e \n\u003e Until then, as there is no consensus, you need to do one of two things:\n\u003e \n\u003e 1) Drop the \"everyone must agree to make changes\" idea that people here\n\u003e like to peddle, and do it loudly, so everyone in the community is correctly\n\u003e informed\n\u003e \n\u003e 2) Do nothing\n\nHmm? You didn't quote any of my email, so I'll remind you what I did say\nwe had consensus about:\n\n    2) We have consensus on the semantics of the CLTV opcode\n\nand\n\n    3) We have consensus that Bitcoin should adopt CLTV\n\n    The broad peer review and discussion that got #6124 merged is a clear\n    sign that we expect CLTV to be eventually adopted.  __The question isn't\n    if CLTV should be added to the Bitcoin protocol, but rather when.__\n\n(emphasis mine)\n\nBoth those statements of consensus are *not* about how CLTV is to be\ndeployed. I did discuss deployment later:\n\n    6) We have the __necessary consensus__ to deploy CLTV via IsSuperMajority()\n\n    The various \"nVersion bits\" proposals - which I am a co-author of - have\n    the primary advantage of being able to cleanly deal with the case where\n    a soft-fork fails to get adopted. However, we do have broad consensus,\n    including across all sides of the blocksize debate, that CLTV should be\n    adopted. __The risk of CLTV failing to get miner adoption, and thus\n    blocking other soft-forks, is very low.__\n\nI probably could have worded this section a bit more clearly; when I say\n\"necessary consensus\" I'm referring to the consensus required for a\nsoft-fork deployment. At minimum a simple majority of hashing power -\nyour approval isn't required.\n\nFor a safe soft-fork, we'd like a super majority of miners to be on\nboard. For a IsSuperMajority() soft-fork - as opposed to nVersion bits -\nwe also need the probability of the soft-fork being rejected to be very\nlow. To achieve that, having consensus that CLTV is a good idea is the\nbest situation to be in. But that's not to say that a few dissenting\nvoices should be seen as a blocker to progress - rather is just makes\nthe deployment a bit more risky, being a sign that the consensus may\nchange in the future, with the soft-fork being later rejected. For\nexample strong objections by a respected Bitcoin developer who has made\nsignificant contributions to the consensus codebase and protocol\ndevelopment would be a strong sign that a IsSuperMajority() soft-fork\nmight fail, and deployment via nVersion bits is probably a better\napproach. Fortunately we're not in that situation.\n\nHard-forks are a very different situation, with significantly more need\nfor very broad consensus, but that's been well discussed elsewhere.\n\n\nI have three questions to you:\n\n1) Do you agree that CLTV should be added to the Bitcoin protocol?\n\nIgnoring the question how exactly it is added, hard-fork or soft-fork.\n\n\n2) Will you add a IsSuperMajority() CLTV soft-fork to Bitcoin XT if it\n   is added to Bitcoin Core?\n\nIf you refuse to do this the risk of the soft-fork is increased a bit,\nalthough miner support for XT has remained extremely low, and the 95%\nswitch-over threshold has a significant margin for error. (there's a 75%\nthreshold to consider as well, however as XT has adopted my pull-req\n#5000 - Discourage NOPs reserved for soft-fork upgrades - those miners\nwill only produce valid blocks under CLTV rules)\n\n\n3) Will you add soft-fork detection to bitcoinj, to allow SPV clients to\n   detect advertised soft-forks and correctly handle them?\n\nNotably, if you do this your objections against soft-forks will be met,\nas the behavior of a SPV client with soft-fork detection during a\nsoft-fork will be identical to that client during a hard-fork. In\nparticular, the SPV client will correct reject invalid blocks, and\ncontinue to follow only the longest valid chain. (modulo unadvertised\nforks of course, an inherently unavoidable problem with the SPV security\nmodel) Secondly, that code should also detect forks it doesn't know\nabout - as is done in Bitcoin Core already - and warn the user.\n\n-- \n'peter'[:-1]@petertodd.org\n00000000000000000d74f5def1087f3ec1571cb468e471e71f96063253988c78\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/8afec924/attachment-0001.sig\u003e"}