Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-30 📝 Original message:tl;dr Nothing I have read ...
📅 Original date posted:2015-09-30
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/5774e38f/attachment.html>;
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/5774e38f/attachment.html>;