MIME-Version: 1.0
Date: Thu, 21 Apr 2022 15:44:41 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Anthony Towns <aj@erisian.com.au>
In-Reply-To: <20220422002840.GB5616@erisian.com.au>
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
 <20220422002840.GB5616@erisian.com.au>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <c62c913ac4e36182f719ddb754a0f754@dtrt.org>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks,
 e.g. for CTV
Precedence: list

On 21.04.2022 14:28, Anthony Towns wrote:
> But, if [it's true that "many [...] use cases [...] to use CTV for
> are very long term in nature"], 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?

I fully acknowledge that a temporary test can't fully replicate a 
permanent condition.  That said, if people truly believe CTV vaults will 
significantly enhance their security, wouldn't it be worth using them 
for most of the deployment?  Users would receive both years of added 
security and the opportunity to convince other Bitcoiners to make CTV 
permanent by demonstrating real-world usage.

> 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();
>   }

Defining at the outset how we'll signal years later if we want to keep 
the rules seems intelligent to me.

Thanks!,

-Dave