📅 Original date posted:2022-03-10
📝 Original message:Thank you for explaining. I agree with luke then, I'm against speedy trial.
I explained why already, I think.
In summary: speedy trial kind of means is miners and not users who decide
the rules.
It gives users less opportunities to react and oppose a malevolent change
in case miners want to impose such change on them.
Why specially jeremy?
I personally distrust him more from experience, but that's subjective, and
kind of offtopic. Sorry, I should try to distrust all the other devs as
much as I distrust him in particular.
"Don't trust, verify", right?
On Wed, Mar 9, 2022, 14:42 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Jorge,
>
> > What is ST? If it may be a reason to oppose CTV, why not talk about it
> more explicitly so that others can understand the criticisms?
>
> ST is Speedy Trial.
> Basically, a short softfork attempt with `lockinontimeout=false` is first
> done.
> If this fails, then developers stop and think and decide whether to offer
> a UASF `lockinontimeout=true` version or not.
>
> Jeremy showed a state diagram of Speedy Trial on the IRC, which was
> complicated enough that I ***joked*** that it would be better to not
> implement `OP_CTV` and just use One OPCODE To Rule Them All, a.k.a.
> `OP_RING`.
>
> If you had actually read the IRC logs you would have understood it, I even
> explicitly asked "ST ?=" so that the IRC logs have it explicitly listed as
> "Speedy Trial".
>
>
> > It seems that criticism isn't really that welcomed and is just explained
> away.
>
> It seems that you are trying to grasp at any criticism and thus fell
> victim to a joke.
>
> > Perhaps it is just my subjective perception.
> > Sometimes it feels we're going from "don't trust, verify" to "just trust
> jeremy rubin", i hope this is really just my subjective perception. Because
> I think it would be really bad that we started to blindly trust people like
> that, and specially jeremy.
>
> Why "specially jeremy"?
> Any particular information you think is relevant?
>
> The IRC logs were linked, you know, you could have seen what was discussed.
>
> In particular, on the other thread you mention:
>
> > We should talk more about activation mechanisms and how users should be
> able to actively resist them more.
>
> Speedy Trial means that users with mining hashpower can block the initial
> Speedy Trial, and the failure to lock in ***should*** cause the developers
> to stop-and-listen.
> If the developers fail to stop-and-listen, then a counter-UASF can be
> written which *rejects* blocks signalling *for* the upgrade, which will
> chainsplit from a pro-UASF `lockinontimeout=true`, but clients using the
> initial Speedy Trial code will follow which one has better hashpower.
>
> If we assume that hashpower follows price, then users who want for /
> against a particular softfork will be able to resist the Speedy Trial, and
> if developers release a UASF `lockinontimeout=true` later, will have the
> choice to reject running the UASF and even running a counter-UASF.
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220310/5a3a82c6/attachment-0001.html>;
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 23:05:52
in reply to nevent1q…2thl
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 23:05:52Event JSON
{
"id": "72cf981137df2c756295e9c092b477fff56e4f225337b1e139a06de1d7681753",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686179152,
"kind": 1,
"tags": [
[
"e",
"83acd5370ccb9fe968098a1396b47a2e00f389e32ecf7150596370fd89c05c58",
"",
"root"
],
[
"e",
"648dde30822a79df2304e7697c56625a7364468fdb0b69df0a930c3822912c84",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2022-03-10\n📝 Original message:Thank you for explaining. I agree with luke then, I'm against speedy trial.\nI explained why already, I think.\nIn summary: speedy trial kind of means is miners and not users who decide\nthe rules.\nIt gives users less opportunities to react and oppose a malevolent change\nin case miners want to impose such change on them.\n\n\nWhy specially jeremy?\n\nI personally distrust him more from experience, but that's subjective, and\nkind of offtopic. Sorry, I should try to distrust all the other devs as\nmuch as I distrust him in particular.\n\"Don't trust, verify\", right?\n\n\nOn Wed, Mar 9, 2022, 14:42 ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning Jorge,\n\u003e\n\u003e \u003e What is ST? If it may be a reason to oppose CTV, why not talk about it\n\u003e more explicitly so that others can understand the criticisms?\n\u003e\n\u003e ST is Speedy Trial.\n\u003e Basically, a short softfork attempt with `lockinontimeout=false` is first\n\u003e done.\n\u003e If this fails, then developers stop and think and decide whether to offer\n\u003e a UASF `lockinontimeout=true` version or not.\n\u003e\n\u003e Jeremy showed a state diagram of Speedy Trial on the IRC, which was\n\u003e complicated enough that I ***joked*** that it would be better to not\n\u003e implement `OP_CTV` and just use One OPCODE To Rule Them All, a.k.a.\n\u003e `OP_RING`.\n\u003e\n\u003e If you had actually read the IRC logs you would have understood it, I even\n\u003e explicitly asked \"ST ?=\" so that the IRC logs have it explicitly listed as\n\u003e \"Speedy Trial\".\n\u003e\n\u003e\n\u003e \u003e It seems that criticism isn't really that welcomed and is just explained\n\u003e away.\n\u003e\n\u003e It seems that you are trying to grasp at any criticism and thus fell\n\u003e victim to a joke.\n\u003e\n\u003e \u003e Perhaps it is just my subjective perception.\n\u003e \u003e Sometimes it feels we're going from \"don't trust, verify\" to \"just trust\n\u003e jeremy rubin\", i hope this is really just my subjective perception. Because\n\u003e I think it would be really bad that we started to blindly trust people like\n\u003e that, and specially jeremy.\n\u003e\n\u003e Why \"specially jeremy\"?\n\u003e Any particular information you think is relevant?\n\u003e\n\u003e The IRC logs were linked, you know, you could have seen what was discussed.\n\u003e\n\u003e In particular, on the other thread you mention:\n\u003e\n\u003e \u003e We should talk more about activation mechanisms and how users should be\n\u003e able to actively resist them more.\n\u003e\n\u003e Speedy Trial means that users with mining hashpower can block the initial\n\u003e Speedy Trial, and the failure to lock in ***should*** cause the developers\n\u003e to stop-and-listen.\n\u003e If the developers fail to stop-and-listen, then a counter-UASF can be\n\u003e written which *rejects* blocks signalling *for* the upgrade, which will\n\u003e chainsplit from a pro-UASF `lockinontimeout=true`, but clients using the\n\u003e initial Speedy Trial code will follow which one has better hashpower.\n\u003e\n\u003e If we assume that hashpower follows price, then users who want for /\n\u003e against a particular softfork will be able to resist the Speedy Trial, and\n\u003e if developers release a UASF `lockinontimeout=true` later, will have the\n\u003e choice to reject running the UASF and even running a counter-UASF.\n\u003e\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220310/5a3a82c6/attachment-0001.html\u003e",
"sig": "5ce767e19b77bb3086d6ee283e2137971c3fff70a442d29ee84342f8494d35dc6e7f3d3f73c2a653a806bee1d004f8fac51146a23d05e97adb563cb84ee8b75b"
}