From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: "Jorge Timón" <jtimon@jtimon•cc>,
"Bitcoin Protocol Discussion"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5
Date: Wed, 09 Mar 2022 14:42:36 +0000 [thread overview]
Message-ID: <CCrU07T0pDYBkAwCnUK3QZ3SFCtH1jSlH9ec6fUz5QxiNh7HT8lEx_2i6uR0Xedb6fdU94RZ4UXag9_Kchf6uELNjwSAxvyY4XgZ64aL-xI=@protonmail.com> (raw)
In-Reply-To: <CABm2gDqMcgcyYErNgMe9shXUxX5E85n+VqheDf1_E1mPq3ijLg@mail.gmail.com>
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 prev parent reply other threads:[~2022-03-09 14:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 0:36 Jeremy Rubin
2022-03-09 11:08 ` Jorge Timón
2022-03-09 14:42 ` ZmnSCPxj [this message]
2022-03-10 11:28 ` Jorge Timón
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CCrU07T0pDYBkAwCnUK3QZ3SFCtH1jSlH9ec6fUz5QxiNh7HT8lEx_2i6uR0Xedb6fdU94RZ4UXag9_Kchf6uELNjwSAxvyY4XgZ64aL-xI=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jtimon@jtimon$(echo .)cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox