ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-03-09 📝 Original message:Good morning Jorge, > What ...
📅 Original date posted:2022-03-09
📝 Original message: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
📝 Original message: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