public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo•com>
To: Anthony Towns <aj@erisian•com.au>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet
Date: Fri, 16 Sep 2022 12:46:53 -0400	[thread overview]
Message-ID: <798e8c4a-78e2-b210-2202-4b358b95a581@mattcorallo.com> (raw)
In-Reply-To: <YyQioS3F942wu1HW@erisian.com.au>

Apologies for any typos, somewhat jet-lagged atm.

On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote:
> Subhead: "Nobody expects a Bitcoin Inquistion? C'mon man, *everyone*
> expects a Bitcoin Inquisition."
> 
> 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. 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).

Matt


  reply	other threads:[~2022-09-16 17:06 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 [this message]
2022-09-17  6:14   ` Anthony Towns
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=798e8c4a-78e2-b210-2202-4b358b95a581@mattcorallo.com \
    --to=lf-lists@mattcorallo$(echo .)com \
    --cc=aj@erisian$(echo .)com.au \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /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