From: Anthony Towns <aj@erisian•com.au>
To: Matt Corallo <lf-lists@mattcorallo•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet
Date: Sat, 17 Sep 2022 16:14:05 +1000 [thread overview]
Message-ID: <YyVlra0AMIFO9Xid@erisian.com.au> (raw)
In-Reply-To: <798e8c4a-78e2-b210-2202-4b358b95a581@mattcorallo.com>
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
next prev parent reply other threads:[~2022-09-17 6:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-16 7:15 Anthony Towns
2022-09-16 16:46 ` Matt Corallo
2022-09-17 6:14 ` Anthony Towns [this message]
2022-09-17 8:39 ` Matt Corallo
2022-09-17 15:53 ` Michael Folkson
2022-09-18 12:27 ` alicexbt
2022-09-18 18:44 ` Michael Folkson
2022-09-18 18:47 ` Antoine Riard
2022-09-19 10:05 ` Anthony Towns
2022-09-28 11:48 ` Michael Folkson
2022-09-28 20:01 ` alicexbt
2022-10-02 4:06 ` Anthony Towns
2022-10-02 6:12 ` Anthony Towns
2022-10-02 15:25 ` Michael Folkson
2022-10-03 22:54 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YyVlra0AMIFO9Xid@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lf-lists@mattcorallo$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox