Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Mike Hearn <hearn@vinumeris.com>]

[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]

Hi Gregory,


> I'm surprised to see this response


Why? I have objected to the idea of soft forks many times. I wrote an
entire article about it in August. I also objected in April 2014, for
instance, where Pieter agreed with me that soft forks can result in ugly
hacks, and that they are "not nice philosophically because they reduce the
security model of former full nodes to SPV without their knowledge" (he
thought they were worth it anyway).

This is not a new debate. If you're surprised, it means only you weren't
paying attention to all the previous times people raised this issue.


> 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.

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. To repeat: *CLTV does not have consensus at the moment*.

BTW, in the April 2014 thread Pieter's argument was that hard forks are
more risky, which is at least an answer to my question. But he didn't
explain why he thought that. I disagree: the risk level seems lower with a
hard fork because it doesn't lower anyone's security level.

[-- Attachment #2: Type: text/html, Size: 2122 bytes --]