From: Luke Dashjr <luke@dashjr•org>
To: alicexbt <alicexbt@protonmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
Date: Thu, 21 Apr 2022 05:56:54 +0000 [thread overview]
Message-ID: <202204210556.54781.luke@dashjr.org> (raw)
In-Reply-To: <R95icCQeG6oNu4uNppxVTceaMmZzOQhUD40HhOXkuQCOzUY_P5uM1F1AGBejdydrSjl4RYE538VWiDHeGx3YcaS0S-z_q9v5UaCK_Y4b5TE=@protonmail.com>
On Thursday 21 April 2022 03:10:02 alicexbt wrote:
> @DavidHarding
>
> Interesting proposal to revert consensus changes. Is it possible to do this
> for soft forks that are already activated?
Generally, no. Reverting a softfork without a built-in expiry would be a
hardfork.
> Example: Some users are not okay with witness discount in segwit
> transactions
>
> https://nitter.net/giacomozucco/status/1513614380121927682
While reverting Segwit wouldn't be possible, it IS entirely possible to do an
additional softfork to either weigh witness data at the full 4 WU/Byte rate
(same as other data), or to reduce the total weight limit so as to extend the
witness discount to non-segwit transactions (so scriptSig is similarly
discounted).
> @LukeDashjr
>
> > The bigger issue with CTV is the miner-decision route. Either CTV has
> > community support, or it doesn't. If it does, miners shouldn't have the
> > ability to veto it. If it doesn't, miners shouldn't have the ability to
> > activate it (making it a 51% attack more than a softfork).
>
> Agree. UASF client compatible with this speedy trial release for BIP 119
> could be a better way to activate CTV. Users can decide if they prefer
> mining pools to make the decision for them or they want to enforce it
> irrespective of how many mining pools signal for it. I haven't seen any
> arguments against CTV from mining pools yet.
We had that for Taproot, and now certain people are trying to say Speedy Trial
activated Taproot rather than the BIP8 client, and otherwise creating
confusion and ambiguity.
Furthermore, the variant of Speedy Trial being used (AFAIK) is the BIP9
variant which has no purpose other than to try to sabotage parallel UASF
efforts.
At this point, it is probably better for any Speedy Trial attempts to be
rejected by the community and fail outright. Perhaps even preparing a real
counter-softfork to invalidate blocks signalling for it.
Luke
next prev parent reply other threads:[~2022-04-21 5:57 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-21 1:04 David A. Harding
2022-04-21 2:05 ` Luke Dashjr
2022-04-21 3:10 ` alicexbt
2022-04-21 5:56 ` Luke Dashjr [this message]
2022-04-21 6:20 ` Jeremy Rubin
2022-04-21 6:37 ` Luke Dashjr
2022-04-21 13:10 ` Jeremy Rubin
2022-04-24 15:22 ` Peter Todd
2022-04-21 14:58 ` Matt Corallo
2022-04-21 18:06 ` David A. Harding
2022-04-21 18:39 ` Matt Corallo
2022-04-21 22:28 ` David A. Harding
2022-04-21 23:02 ` Matt Corallo
2022-04-22 1:20 ` David A. Harding
2022-04-22 18:40 ` Matt Corallo
2022-04-22 18:49 ` Corey Haddad
2022-04-22 16:48 ` James O'Beirne
2022-04-22 17:06 ` James O'Beirne
2022-04-22 16:28 ` James O'Beirne
2022-04-22 17:25 ` [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks) Russell O'Connor
2022-04-23 4:56 ` Billy Tetrud
2022-04-23 14:02 ` Russell O'Connor
2022-04-23 18:24 ` Matt Corallo
2022-04-23 19:30 ` Russell O'Connor
2022-04-24 23:03 ` Billy Tetrud
2022-04-25 17:27 ` Nadav Ivgi
2022-04-25 22:27 ` Russell O'Connor
2022-04-27 1:52 ` Billy Tetrud
2022-04-28 23:14 ` Nadav Ivgi
2022-04-28 23:51 ` Billy Tetrud
2022-04-22 18:35 ` [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV Matt Corallo
2022-04-21 19:08 ` Jeremy Rubin
2022-04-22 0:28 ` Anthony Towns
2022-04-22 1:44 ` David A. Harding
2022-04-22 19:57 ` Antoine Riard
2022-04-25 5:12 ` ZmnSCPxj
2022-04-22 19:05 alicexbt
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=202204210556.54781.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=alicexbt@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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