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 <zmnsc...@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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
