Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet

[Anthony Towns <aj@erisian.com.au>]

On Fri, Sep 16, 2022 at 12:46:53PM -0400, Matt Corallo via bitcoin-dev wrote:
> On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote:
> > As we've seen from the attempt at a CHECKTEMPLATEVERIFY activation earlier
> > in the year [0], the question of "how to successfully get soft fork
> > ideas from concept to deployment" doesn't really have a good answer today.
> I strongly disagree with this.

Okay? "X is good" is obviously just a statement of opinion, so if you
want to disagree, that's obviously allowed. 

I also kind of feel like that's the *least* interesting paragraph in the
entire email to talk further about; if you think the current answer's
already good, then the rest of the mail's just about (hopefully) making
it better, which would be worthwhile anyway?

> Going back many, many years we've had many
> discussions about fork process, and the parts people (historically) agreed
> with tend to be:
> (1) come up with an idea
> (2) socialize the idea in the technical community, see if anyone comes up
> with any major issues or can suggest better ideas which solve the same
> use-cases in cleaner ways
> (3) propose the concrete idea with a more well-defined strawman, socialize
> that, get some kind of rough consensus in the loosely-defined, subjective,
> "technical community" (ie just ask people and adapt to feedback until you
> have found some kind of average of the opinions of people you, the
> fork-champion, think are reasonably well-informed!).
> (4) okay, admittedly beyond this is a bit less defined, but we can deal with it when we get there.
> Turns out, the issue today is a lack of champions following steps 1-3, we
> can debate what the correct answer is to step (4) once we actually have
> people who want to be champions who are willing to (humbly) push an idea
> forward towards rough agreement of the world of technical bitcoiners
> (without which I highly doubt you'd ever see broader-community consensus).

Personally, I think this is easily refuted by contradiction.

1) If we did have a good answer for how to progress a soft-fork, then
the great consensus cleanup [0] would have made more progress over the
past 3.5 years. Maybe not all of the ideas in it were unambiguously good
[1], but personally, I'm convinced at least some of them are, and I
don't think I'm alone in thinking that. Even if the excuse is that its
original champion wasn't humble enough, there's something wrong with
the process if there doesn't exist some other potential champion with
the right balance of humility, confidence, interest and time who could
have taken it over in that timeframe.

2) Many will argue that CTV has already done steps (1) through (3) above:
certainly there's been an idea, it's been socialised through giving talks,
having discussion forums, having research workshops [2], documenting use
cases use cases; there's been a concrete implementation for years now,
with a test network that supports the proposed feature, and new tools
that demonstrate some of the proposed use cases, and while alternative
approaches have been suggested [3], none of them have even really made
it to step (2), let alone step (3). So that leaves a few possibilities
to my mind:

 * CTV should be in step (4), and its lack of definition is a problem,
   and trying the "deal with it when we get there" approach is precisely
   what didn't work back in April.

 * The evaluation process is too inconclusive: it should either be
   saying "CTV is not good enough, fix these problems", or "CTV hasn't
   sufficiently demonstrated its value/cost, work on X next", but it
   isn't.

 * Parts (2) to (3) are too hard, and that's preventing alternatives
   from making progress, which in turn is preventing people from
   being able to decide whether CTV is the superior approach, or some
   alternative is.

But each of those possibilities indicates a significant problem with
our answer for developing soft forks.

I guess my belief is that it's mostly (2) and (3) being too hard (which
taproot overcame because many were excited about it, and CTV overcame
because Jeremy's put a lot of effort into it; but consensus cleanup,
APO, simplicity, TXHASH, etc have not similarly overcome at this point),
which leads to the evaluation process being inconclusive when plausible
alternatives exist. 

(In particular, I think having the process be massively difficult is
going to naturally cause any "humble" champion to decide that they're
not up to the task of following the process through to completion)

Anyway, that's some additional reasons why I believe what I said above,
in case that's interesting. But like I said at the start, if you still
disagree, that's fine of course.

Cheers,
aj

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016714.html
    https://github.com/bitcoin/bitcoin/pull/15481
    https://github.com/bitcoin/bitcoin/pull/15482

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016765.html
    https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016763.html
    https://github.com/bitcoin/bitcoin/pull/15482#issuecomment-469822630

[2] https://utxos.org/workshops/

[3] TXHASH https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
    TX https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020450.html
    Elements-style opcodes https://twitter.com/rusty_twit/status/1518007923896578048
      cf https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019851.html
    ANYPREVOUT? https://twitter.com/darosior/status/1474375301262151684
    Simplicity? https://twitter.com/Mario_Gibney/status/1403890965903859718
    Lisp? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020036.html