📅 Original date posted:2014-10-07
📝 Original message:>
> That is easy to change; I'll submit a pull request.
>
That's certainly a useful improvement. It won't help the existing userbase
though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major
release. If there's going to be an intermediate release (6 months?) which
lays the groundwork for future rule changes, it helps more.
It would be good if getblocktemplate was updated at the same time to serve
errors if the fork warning is active. I'd hope miners have some way to
automatically handle IBD/getting forked off the chain, but I guess some
(newer) pools might not, and refusing to serve work should be the safest
option that shuts them down.
I don't have any opinion on the hard- versus soft- fork debate. I think
> either can work.
>
P2SH was a soft fork and the sky did not fall, but miners did lose money
and waste electricity mining blocks on the wrong side of the chain:
https://bitcointalk.org/index.php?topic=75294.0
Presumably they didn't notice for longer because it looked like a run of
unusually bad orphaning luck. It seems safer to have a clean fork, with
alerts telling people during the lockin period before new rule enforcement
starts (and possibly automated termination if there's no upgrade by the
flag day?). Miners who ignore it would still risk losing money, but
merchants who wait for a block at least would not be at risk.
One open question is how can you actually trigger a hard fork? Coinbase
scriptSigs are not executed, so putting some ignored but failing opcode
sequence there wouldn't work. One possibility would be to have a special
invalid tx in the block that marks the start of new rule enforcement. New
nodes would know to ignore it. But this risks corrupting block explorers.
Alternatively the coinbase outpoint structure could have its hash set to 1
instead of 0.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141007/9f9292df/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:26:10
in reply to nevent1q…njxw
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:26:10Event JSON
{
"id": "18ca2f199a23299ae2860100a86e7d656d4d94a57e872b62768a90ea3dab5f37",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686151570,
"kind": 1,
"tags": [
[
"e",
"b0d4dbe43a898155b6750ed1dce6a700ce007fe7f2dce49b1bbfe7e2cca60c4c",
"",
"root"
],
[
"e",
"de41a213b73302982cad53ee77f5891cd37ea2ff2879d517869e4bf19e05da89",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2014-10-07\n📝 Original message:\u003e\n\u003e That is easy to change; I'll submit a pull request.\n\u003e\n\nThat's certainly a useful improvement. It won't help the existing userbase\nthough - assuming CHECKLOCKTIMEVERIFY is to go in to the next major\nrelease. If there's going to be an intermediate release (6 months?) which\nlays the groundwork for future rule changes, it helps more.\n\nIt would be good if getblocktemplate was updated at the same time to serve\nerrors if the fork warning is active. I'd hope miners have some way to\nautomatically handle IBD/getting forked off the chain, but I guess some\n(newer) pools might not, and refusing to serve work should be the safest\noption that shuts them down.\n\nI don't have any opinion on the hard- versus soft- fork debate. I think\n\u003e either can work.\n\u003e\n\nP2SH was a soft fork and the sky did not fall, but miners did lose money\nand waste electricity mining blocks on the wrong side of the chain:\n\nhttps://bitcointalk.org/index.php?topic=75294.0\n\nPresumably they didn't notice for longer because it looked like a run of\nunusually bad orphaning luck. It seems safer to have a clean fork, with\nalerts telling people during the lockin period before new rule enforcement\nstarts (and possibly automated termination if there's no upgrade by the\nflag day?). Miners who ignore it would still risk losing money, but\nmerchants who wait for a block at least would not be at risk.\n\nOne open question is how can you actually trigger a hard fork? Coinbase\nscriptSigs are not executed, so putting some ignored but failing opcode\nsequence there wouldn't work. One possibility would be to have a special\ninvalid tx in the block that marks the start of new rule enforcement. New\nnodes would know to ignore it. But this risks corrupting block explorers.\nAlternatively the coinbase outpoint structure could have its hash set to 1\ninstead of 0.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141007/9f9292df/attachment.html\u003e",
"sig": "5d440f4566ad719c7ec1c749e2b252a724c3faeea91ed08dd4daef665d727879b6b7553ace76fdfc94245c6bf8b8eb0356824d69048d2bc3559ba063d287207c"
}