馃搮 Original date posted:2022-04-24
馃摑 Original message:On Sun, Apr 24, 2022 at 2:14 PM Anthony Towns <aj at erisian.com.au> wrote:
> On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Tim贸n wrote:
> > You're not even considering user resistance in your cases.
>
> Of course I am. Again:
>
No, you're relying on miners to stop bad proposals.
> > > My claim is that for *any* bad (evil, flawed, whatever) softfork, then
> > > attempting activation via bip8 is *never* superior to speedy trial,
> > > and in some cases is worse.
> > >
> > > If I'm missing something, you only need to work through a single
> example
> > > to demonstrate I'm wrong, which seems like it ought to be easy... But
> > > just saying "I disagree" and "I don't want to talk about that" isn't
> > > going to convince anyone.
>
> The "some cases" where bip8 with lot=true is *worse* than speedy trial
> is when miners correctly see that a bad fork is bad.
>
> Under *any* other circumstance, when they're used to activate a bad soft
> fork, speedy trial and bip8 are the same. If a resistance method works
> against bip8, it works against speedy trial; if it fails against speedy
> trial, it fails against bip8.
>
You're wrong.
> > Sorry for the aggressive tone, but I when people ignore some of my points
> > repeteadly, I start to wonder if they do it on purpose.
>
> Perhaps examine the beam in your own eye.
>
Yeah, whether you do that yourself or not: sorry, it's over.
> Cheers,
> aj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220424/7340f4aa/attachment-0001.html>;
Jorge Tim贸n [ARCHIVE] /
npub1fx鈥l2d8
2023-06-07 23:07:05
in reply to nevent1q鈥zkz
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 23:07:05Event JSON
{
"id": "6e53de6379764cd090d31328e016f749f01ab0c6cbf8d29891cc907cd30ed081",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686179225,
"kind": 1,
"tags": [
[
"e",
"71fdbe6d124fd3a1fedf27070b6e15aea47bf689ee68bddf05a0d32ebbd5d875",
"",
"root"
],
[
"e",
"821c1b2cd4a814ac19635fbe05adc3134938d62d007f185d1a338751bf374f18",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "馃搮 Original date posted:2022-04-24\n馃摑 Original message:On Sun, Apr 24, 2022 at 2:14 PM Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\n\u003e On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Tim贸n wrote:\n\u003e \u003e You're not even considering user resistance in your cases.\n\u003e\n\u003e Of course I am. Again:\n\u003e\n\nNo, you're relying on miners to stop bad proposals.\n\n\n\u003e \u003e \u003e My claim is that for *any* bad (evil, flawed, whatever) softfork, then\n\u003e \u003e \u003e attempting activation via bip8 is *never* superior to speedy trial,\n\u003e \u003e \u003e and in some cases is worse.\n\u003e \u003e \u003e\n\u003e \u003e \u003e If I'm missing something, you only need to work through a single\n\u003e example\n\u003e \u003e \u003e to demonstrate I'm wrong, which seems like it ought to be easy... But\n\u003e \u003e \u003e just saying \"I disagree\" and \"I don't want to talk about that\" isn't\n\u003e \u003e \u003e going to convince anyone.\n\u003e\n\u003e The \"some cases\" where bip8 with lot=true is *worse* than speedy trial\n\u003e is when miners correctly see that a bad fork is bad.\n\u003e\n\u003e Under *any* other circumstance, when they're used to activate a bad soft\n\u003e fork, speedy trial and bip8 are the same. If a resistance method works\n\u003e against bip8, it works against speedy trial; if it fails against speedy\n\u003e trial, it fails against bip8.\n\u003e\n\nYou're wrong.\n\n\n\u003e \u003e Sorry for the aggressive tone, but I when people ignore some of my points\n\u003e \u003e repeteadly, I start to wonder if they do it on purpose.\n\u003e\n\u003e Perhaps examine the beam in your own eye.\n\u003e\n\nYeah, whether you do that yourself or not: sorry, it's over.\n\n\n\u003e Cheers,\n\u003e aj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220424/7340f4aa/attachment-0001.html\u003e",
"sig": "c7b595cd8334c33a282cc352dbaad700831b7cbeea4a0c5db8b4904f59b0c28ed8aedb947762921940560e8098365fd2ee805ba37f265bc845f095886504b375"
}