MIME-Version: 1.0
Date: Thu, 21 Apr 2022 08:06:14 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com>
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
 <d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
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 04:58, Matt Corallo wrote:
> On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
>> The main criticisms I'm aware of against CTV seem to be along the 
>> following lines:
>> 
>> 1. Usage, either:
>>    a. It won't receive significant real-world usage, or
>>    b. It will be used but we'll end up using something better later
>> 2. An unused CTV will need to be supported forever, creating extra 
>> maintenance
>>     burden, increasing security surface, and making it harder to 
>> evaluate later
>>     consensus change proposals due to their interactions with CTV
> 
> Also "is this even the way we should be going about covenants?"

I consider this to be a version of point 1b above.  If we find a better 
way for going about covenants, then we'll activate that and let CTV 
automatically be retired at the end of its five years.

If you still think your point is separate from point 1b, I would 
appreciate you helping me understand.

> the Bitcoin technical community (or at least those interested in
> working on covenants) doesn't even remotely show any signs of
> consensus around any concrete proposal,

This is also my assessment: neither CTV nor any other proposal currently 
has enough support to warrant a permanent change to the consensus rules. 
  My question to the list was whether we could use a transitory soft fork 
as a method for collecting real-world usage data about proposals.  E.g., 
a consensus change proposal could proceed along the following idealized 
path:

- Idea (individual or small group)
- Publication (probably to this list)
- Draft specification and implementation
- Riskless testing (integration tests, signet(s), testnet, etc)
- Money-at-stake testing (availability on a pegged sidechain, an altcoin 
similar to Bitcoin, or in Bitcoin via a transitory soft fork)
- Permanent consensus change

> talking about a "way forward for CTV" or activating CTV or coming up
> with some way of shoving it into Bitcoin at this stage [...] sets 
> incredibly poor precedent for
> how we think about changes to Bitcoin and maintaining Bitcoin's
> culture of security and careful design.

How should we think about changes to Bitcoin and maintaining its culture 
of security and careful design?  My post suggested a generalized way we 
could evaluate proposed consensus changes for real-world demand, 
allowing us to settle what I see as the most contended part of the CTV 
proposal.  That feels to me like legitimate engineering and social 
consensus building.  What would be your preferred alternatives?

(For the record, my preferred alternative for years has been to add the 
technically trivial opcodes OP_CAT and OP_CHECKSIGFROMSTACK, see what 
covenant-y things people build with them, and then consider proposals to 
optimize the onchain usage of those covenant-y things.  Alas, this seems 
to fall afoul of the concerns held by some people about recursive 
covenants.)

> I'm gobsmacked that the conversation has reached this point, and am
> even more surprised that the response from the Bitcoin (technical)
> community hasn't been a more resounding and complete rejection of this
> narrative.

If the only choices are to support activation of BIP119 CTV at this time 
or to reject it, I would currently side with rejection.  But I would 
prefer over both of those options to find a third way that doesn't 
compromise safety or long-term maintainability and which gives us the 
data about CTV (or other covenant-related constructions) to see whether 
the concerns described above in 1a and 1b are actually non-issues.

I see one of those third ways as the testing on the CTV signet described 
in a contemporaneous thread on this list.[1]  Other third ways would be 
trying CTV on sidechains or altcoins, or perhaps allowing CTV to be 
temporarily used on Bitcoin as proposed in this thread.  Is there 
interest in working on those alternatives, or is the only path forward 
an argument over attempting activation of CTV?

Thanks,

-Dave

[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020234.html