On 30 September 2015 at 13:11, Mike Hearn via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: >> Have I missed a proposal to change BIP101 to be a real hardfork > > There's no such thing as a "real" hard fork - don't try and move the goal > posts. SPV clients do not need any changes to do the right thing with BIP > 101, they will follow the new chain automatically, so it needs no changes.
BIP101 is a hybrid: in some ways it is a hard-fork and in other ways it is a soft-fork. It is a hard-fork to full-nodes, but also a soft-fork to SPV clients, as by definition the SPV miners are having changes made whether they approve or not as they are not even aware of the change. > To repeat: CLTV does not have consensus at the moment. I think people are saying CLTV is long discussed and does have consensus. > Several people have asked several times now: given the very real and widely > acknowledged downsides that come with a soft fork, what is the specific > benefit to end users of doing them? > > Until that question is answered to my satisfaction I continue to object to > this BIP on the grounds that the deployment creates financial risk > unnecessarily. Let's not conflate CLTV with a discussion about future possible deployment methods. Forks are an interesting but different topic. Soft-forks have a lot of mileage on them at this point, hard-forks do not, and are anyway inherently higher riskier, even ignoring our lack of practical experience with planned hard-forks. With a soft-fork, while it's clear there is a temporary security model reduction for SPV nodes (and non-upgraded full nodes) in the period before they upgrade, this is preferable to the risks of a system-wide coordinated hard-fork upgrade. There is some limit if the complexity of soft-forking a feature is quite complicated (eg one could argue that with soft-fork extension-blocks vs hard-fork method of increasing block-size for example). So the balance, which I think is easily met with CLTV, is that soft-fork is simple-enough technically and the feature is entirely non-controversial and additive functionality improvement without downside or reason for dissent. To my view this is an answer to your question "what is the specific benefit to end users of doing [soft-forks]" -- it is a lower risk, and therefore faster way to deploy non-controversial (additive) changes. Given the CLTV is useful for improving lightning efficiency this is good for improving Bitcoin's scalability. Adam _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
