Message-ID: <c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com>
Date: Thu, 21 Apr 2022 11:39:17 -0700
MIME-Version: 1.0
Content-Language: en-US
To: "David A. Harding" <dave@dtrt.org>
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
 <d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com>
 <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <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 4/21/22 11:06 AM, David A. Harding wrote:
> 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.

No, its unrelated to whether CTV or any other system gets usage. If we were just concerned with 
whether CTV would get usage over or under some other alternative proposal then I could see an 
argument for your proposal (though the nontrivial cost of any fork to Bitcoin would make me still 
strongly disagree with such a way forward in principle).

Rather, I'm instead concerned with us designing something that is going to be the most flexible and 
useful and hopefully private covenents design we can, because that doesn't just get users to use the 
change to Bitcoin we paid some nontrivial change-cost to incorporate into the Bitcoin's consensus 
rules, but gets the most bang-for-our-buck. There are at least three or four separate covenants 
designs that have been posted to this list, and I don't see why we're even remotely talking about a 
specific one as something to move forward with at this point.

We don't add things to Bitcoin just to find out whether we can. full stop.

We add things to Bitcoin because (a) there's some demonstrated use-cases and intent to use the 
change (which I think we definitely have for covenants, but which only barely, if at all, suggests 
favoring one covenant design over any other), (b) because its generally considered aligned with 
Bitcoin's design and goals, based on developer and more broad community response and (c) because the 
technical folks who have/are wiling to spend time working on the specific design space think the 
concrete proposal is the best design we have, and finally (d) because the implementation is 
well-reviewed and complete.

I do not see how we can make an argument for any specific covenant under (c) here. We could just as 
well be talking about TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use CTV can 
probably just as easily use those instead - ie this has nothing to do with "will people use it".

>> 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

That all seems fine, except that doing a fork on Bitcoin has very nontrivial cost, both in terms of 
ecosystem disruption and possibility that anything goes wrong, not to mention code maintenance 
(which we cannot remove the validation code for something ever, really - you still want to be able 
to validate the historical chain). Plus, really, I'd love to see "technical community consensus" 
somewhere in there - at least its been something that has very roughly appeared for most previous 
soft forks, at least among those who have time/willingness to work on the specific design being 
proposed.

[other comments snipped because my responses would mostly have been rehashing the first response above].

Matt