tl;dr Nothing I have read here has changed my mind. There is still no consensus to deploy CLTV in this way.
> Yes, your article contained numerous factual and logical inaccuracies > which I corrected > I responded to your response several times. It was not convincing, and I do not think you corrected factual inaccuracies. I mean, you said yourself you once used the correct terminology of forwards compatibility but stopped only because the term "backwards compatibility" is more common. But that's not a good reason to use a term with the opposite meaning and is certainly not a factual correction! > Yes, because what 101 does is not a hard-fork from the perspective of > BitcoinJ clients. Please do not conflate BitcoinJ with all of SPV; I coined the term SPV so I know exactly what it means, and bitcoinj implements it, as does BreadWallet (the other big SPV implementation). Yes, SPV wallets will follow the mining hashpower instead of doing a hard reject for bigger blocks, because they deliberately check a subset of the rules: block size is not and never has been one of them. Indeed it's not even included in the protocol messages. Users have no expectation that SPV wallets would check that, as it's never been claimed they do. On the other hand, full nodes all claim they run scripts. Users expect that and may be relying on it. The unstated assumption here is that the nodes run them correctly. A soft fork breaks this assumption. I'm going to ignore the rest of the stuff you wrote about "design decisions to lack security" or "cheaply avoidable lack of validation". When you have sat down and written an SPV implementation by yourself, then shipped it to a couple of million users, you might have better insight into basic engineering costs. Until then, I find your criticisms of code you think was missing due to "stonewalling" and so on to be seriously lacking real world experience. Yes, a hypothetical full node could fork on the version bits. I would be quite happy with the version number in the header being an enforced consensus rule: it'd make hard forks easier to trigger. But it hasn't been done that way, and wishing away the behaviour of existing software in the field is no good. Luckily, for introducing a new opcode, the same effect can be achieved by using a non-allocated opcode number. > For many changes, including CLTV the actual soft fork change is by far > the most natural way of implementing the change itself. This is subjective. I'd say picking an entirely new opcode number is most natural. The rest of your argument boils down to "people don't have to upgrade if they don't want to", which is addressed in the article I wrote already, and multiple responses on this thread. Yes, they do, otherwise they aren't getting the security level they were before. > Could [P2SH] have been done as a hard-fork? Likely not: you would have > prevented it. What? This is nonsensical. P2SH was added to the full verification code quite quickly, but it didn't matter much because nobody uses bitcoinj for mining. The docs explicitly tell people, in fact, not to mine on top of bitcoinj: https://bitcoinj.github.io/full-verification So no, bitcoinj+P2SH was irrelevant from a fork type perspective. It just had no effect at all. This entire section of your message is completely wrong. The code that did take longer was for wallet support. And the reason it came later was resource prioritisation: there were more important issues to resolve. Like I said - write the amount of code I've written, unpaid in your evenings and weekends, and then you can criticise bitcoinj for lacking features. 75% is a fine activation threshold. By definition if support is at 75% then bigger blocks is "winning", but if support fell, then the SPV wallets would just reorg back onto the 1mb-blocks chain. Re: demonstrated track record. They "work" only if you ignore the actual problems that have resulted. P2SH-invalid blocks were being mined for weeks after the flag day. That's not good no matter how you slice it: even if you didn't hear about any fraud resulting, it is still risk that can be avoided.
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
