📅 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>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 17:41:42
in reply to nevent1q…jrgy
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 17:41:42Event JSON
{
"id": "551ad9c3dcae91fddae2d1571ca6226ef4601cd0345f92041fae896a1f765dd7",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686159702,
"kind": 1,
"tags": [
[
"e",
"f5bb1bf208994917ac3ec4154383520df2a8573df815c54d28bae4e41ef024c8",
"",
"root"
],
[
"e",
"ed8673726546af74e16da19dcb73ca1cedfb9e69acc105c2f5b2ba878e21bdb7",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2015-09-30\n📝 Original message:tl;dr Nothing I have read here has changed my mind. There is still no\nconsensus to deploy CLTV in this way.\n\n\n\u003e Yes, your article contained numerous factual and logical inaccuracies\n\u003e which I corrected\n\u003e\n\nI responded to your response several times. It was not convincing, and I do\nnot think you corrected factual inaccuracies. I mean, you said yourself you\nonce used the correct terminology of forwards compatibility but stopped\nonly because the term \"backwards compatibility\" is more common. But that's\nnot a good reason to use a term with the opposite meaning and is certainly\nnot a factual correction!\n\n\n\u003e Yes, because what 101 does is not a hard-fork from the perspective of\n\u003e BitcoinJ clients. Please do not conflate BitcoinJ with all of SPV;\n\n\nI coined the term SPV so I know exactly what it means, and bitcoinj\nimplements it, as does BreadWallet (the other big SPV implementation).\n\nYes, SPV wallets will follow the mining hashpower instead of doing a hard\nreject for bigger blocks, because they deliberately check a subset of the\nrules: block size is not and never has been one of them. Indeed it's not\neven included in the protocol messages. Users have no expectation that SPV\nwallets would check that, as it's never been claimed they do.\n\nOn the other hand, full nodes all claim they run scripts. Users expect that\nand may be relying on it. The unstated assumption here is that the nodes\nrun them correctly. A soft fork breaks this assumption.\n\nI'm going to ignore the rest of the stuff you wrote about \"design decisions\nto lack security\" or \"cheaply avoidable lack of validation\". When you have\nsat down and written an SPV implementation by yourself, then shipped it to\na couple of million users, you might have better insight into basic\nengineering costs. Until then, I find your criticisms of code you think was\nmissing due to \"stonewalling\" and so on to be seriously lacking real world\nexperience.\n\nYes, a hypothetical full node could fork on the version bits. I would be\nquite happy with the version number in the header being an enforced\nconsensus rule: it'd make hard forks easier to trigger. But it hasn't been\ndone that way, and wishing away the behaviour of existing software in the\nfield is no good. Luckily, for introducing a new opcode, the same effect\ncan be achieved by using a non-allocated opcode number.\n\n\n\u003e For many changes, including CLTV the actual soft fork change is by far\n\u003e the most natural way of implementing the change itself.\n\n\nThis is subjective. I'd say picking an entirely new opcode number is most\nnatural.\n\nThe rest of your argument boils down to \"people don't have to upgrade if\nthey don't want to\", which is addressed in the article I wrote already, and\nmultiple responses on this thread. Yes, they do, otherwise they aren't\ngetting the security level they were before.\n\n\n\u003e Could [P2SH] have been done as a hard-fork? Likely not: you would have\n\u003e prevented it.\n\n\nWhat? This is nonsensical. P2SH was added to the full verification code\nquite quickly, but it didn't matter much because nobody uses bitcoinj for\nmining. The docs explicitly tell people, in fact, not to mine on top of\nbitcoinj:\n\nhttps://bitcoinj.github.io/full-verification\n\nSo no, bitcoinj+P2SH was irrelevant from a fork type perspective. It just\nhad no effect at all. This entire section of your message is completely\nwrong.\n\nThe code that did take longer was for wallet support. And the reason it\ncame later was resource prioritisation: there were more important issues to\nresolve. Like I said - write the amount of code I've written, unpaid in\nyour evenings and weekends, and then you can criticise bitcoinj for lacking\nfeatures.\n\n75% is a fine activation threshold. By definition if support is at 75% then\nbigger blocks is \"winning\", but if support fell, then the SPV wallets would\njust reorg back onto the 1mb-blocks chain.\n\nRe: demonstrated track record. They \"work\" only if you ignore the actual\nproblems that have resulted. P2SH-invalid blocks were being mined for weeks\nafter the flag day. That's not good no matter how you slice it: even if you\ndidn't hear about any fraud resulting, it is still risk that can be avoided.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/5774e38f/attachment.html\u003e",
"sig": "a95c4f6de47e31898c90604826a01915dc8a2b13f2611a696fe1bc53bdc62aae1fbb8d470096f7367ab86edfd533be40f0224bec1aa8a05d94b7af63a7531326"
}