📅 Original date posted:2015-09-29
📝 Original message:Hi Jorge,
Yes, there is a difference. Assuming the hashrate majority upgrades, in the
> case of a softfork [snip] ...... In the case of a hardfork [snip]
>
Yes, I know what the difference between them is at a technical level. You
didn't explain why this would make any difference to how fast miners
upgrade. The amount of money they lose in both cases is identical: they are
equally incentivised to upgrade with both fork types.
Additionally, you say in a hard fork the other chain may "continue
forever". Why do you think this is not true for miners building invalid
blocks on top of the main chain? Why would that not continue forever?
There just isn't any difference between the two fork types in terms of how
fast miners would upgrade. Heck if anything, a hard fork should promote
faster upgrades, because if a miner isn't paying attention to their
debug.log they might miss the warnings. A soft fork would then look
identical to a run of really bad luck, which can legitimately happen from
time to time. A hard fork results in your node having a different height to
everyone else, which is easily detectable by just checking a block explorer.
> This discussion about the general desirability of softforks seems offtopic
> for the concrete cltv deployment discussion, which assumes softforks as
> deployment mechanism (just like bip66 assumed it).
>
Isn't that circular? This thread is about deployment of CLTV, but the BIP
assumes a particular mechanism, so pointing out problems with it is off
topic? Why have a thread at all?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/09aeae3b/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 17:41:36
in reply to nevent1q…vy0q
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 17:41:36Event JSON
{
"id": "fc5d1c5bf9b266bde9085a9ab65db1a923d40dadad086c21785fad944f7a9991",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686159696,
"kind": 1,
"tags": [
[
"e",
"f5bb1bf208994917ac3ec4154383520df2a8573df815c54d28bae4e41ef024c8",
"",
"root"
],
[
"e",
"3cf7c41e85be764169fd8335477283c8d3303545a68d8d50e83de952bf790595",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-09-29\n📝 Original message:Hi Jorge,\n\nYes, there is a difference. Assuming the hashrate majority upgrades, in the\n\u003e case of a softfork [snip] ...... In the case of a hardfork [snip]\n\u003e\nYes, I know what the difference between them is at a technical level. You\ndidn't explain why this would make any difference to how fast miners\nupgrade. The amount of money they lose in both cases is identical: they are\nequally incentivised to upgrade with both fork types.\n\nAdditionally, you say in a hard fork the other chain may \"continue\nforever\". Why do you think this is not true for miners building invalid\nblocks on top of the main chain? Why would that not continue forever?\n\nThere just isn't any difference between the two fork types in terms of how\nfast miners would upgrade. Heck if anything, a hard fork should promote\nfaster upgrades, because if a miner isn't paying attention to their\ndebug.log they might miss the warnings. A soft fork would then look\nidentical to a run of really bad luck, which can legitimately happen from\ntime to time. A hard fork results in your node having a different height to\neveryone else, which is easily detectable by just checking a block explorer.\n\n\u003e This discussion about the general desirability of softforks seems offtopic\n\u003e for the concrete cltv deployment discussion, which assumes softforks as\n\u003e deployment mechanism (just like bip66 assumed it).\n\u003e\nIsn't that circular? This thread is about deployment of CLTV, but the BIP\nassumes a particular mechanism, so pointing out problems with it is off\ntopic? Why have a thread at all?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/09aeae3b/attachment.html\u003e",
"sig": "1ce7c9dbaac87c41e2fa3f9a6b178cc0cfc0247354e43a04a938a53e4390bf4c835f7423e5b1c8554f2a8f1fd9dbe4212c901b122ec71eb310722694ac9d28a5"
}