Date: Fri, 22 Apr 2022 10:28:40 +1000
From: Anthony Towns <aj@erisian.com.au>
To: "David A. Harding" <dave@dtrt.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220422002840.GB5616@erisian.com.au>
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks,
 e.g. for CTV
Precedence: list

On Wed, Apr 20, 2022 at 03:04:53PM -1000, David A. Harding via bitcoin-dev wrote:
> The main criticisms I'm aware of against CTV seem to be along the following
> lines: [...]

> Could those concerns be mitigated by making CTV an automatically reverting
> consensus change with an option to renew?  [...]

Buck O Perley suggested that "Many of the use cases that people
are excited to use CTV for ([5], [6]) are very long term in nature
and targeted for long term store of value in contrast to medium of
exchange."

But, if true, that's presumably incompatible with any sort of sunset
that's less than many decades away, so doesn't seem much better than
just having it be available on a signet?

[5] https://github.com/kanzure/python-vaults/blob/master/vaults/bip119_ctv.py
[6] https://github.com/jamesob/simple-ctv-vault

If sunsetting were a good idea, one way to think about implementing it
might be to code it as:

  if (DeploymentActiveAfter(pindexPrev, params, FOO) &&
      !DeploymentActiveAfter(pindexPrev, params, FOO_SUNSET))
  {
      EnforceFoo();
  }

That is to have sunsetting the feature be its own soft-fork with
pre-declared parameters that are included in the original activation
proposal. That way you don't have to have a second process debate about
how to go about (not) sunsetting the rules, just one on the merits of
whether sunsetting is worth doing or not.

Cheers,
aj