Date: Sat, 17 Sep 2022 15:53:48 +0000
To: Matt Corallo <lf-lists@mattcorallo.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <8cU3OEEtb7Q8CRBHqeWV6qe4JSRnOeMjh2PRdYj4rsnxF4DxzQd1Bo-1DAPMWGNxjXsZQuSuPrDK5TF4ez6tONZ5ACoLJ_FqV6Y1q7ybSwI=@protonmail.com>
In-Reply-To: <8e4dc33b-2992-0380-de2a-0b8afa3db5b7@mattcorallo.com>
References: <YyQioS3F942wu1HW@erisian.com.au>
 <798e8c4a-78e2-b210-2202-4b358b95a581@mattcorallo.com>
 <YyVlra0AMIFO9Xid@erisian.com.au>
 <8e4dc33b-2992-0380-de2a-0b8afa3db5b7@mattcorallo.com>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on
	signet
Precedence: list

I agree with Matt. The less said about the "Aw shucks Jeremy didn't know th=
at CTV didn't have community consensus at the time" [0] and "it was the lac=
k of process that was the problem" the better. If people don't care about l=
ack of community consensus there is no process in a permissionless, open so=
urce community that can stop them or direct them down a more patient, produ=
ctive path (I tried). I think it is a shame because I think (maybe I'm wron=
g) at least in the technical community there is an understanding that long =
term Bitcoin is far from finished in exhausting its potential and we do nee=
d people who will work on changes that we'll need in the long term.

There are a few interesting things in here though. I'm not convinced by the=
 name (bitcoin-inquisition, shedpaint, shedpaint, let's park that for the m=
oment) but I do like the idea of signet having soft fork proposals enabled =
on it [1] whether that be CTV, APO etc and if that requires more of the sig=
net code to be moved out of the Core repo so be it. I'm surprised more isn'=
t being done on Liquid already with what possible future functionality is (=
and could be) enabled [2] there but maybe there is more happening than I'm =
aware of. Protocols or use cases built out and demonstrated on signet (and/=
or Liquid/sidechains) seem an obvious stepping stone to me for convincing t=
he community that it is potentially worth taking the chain split risk for a=
 particular upgrade. It is a long slog to get community consensus on an upg=
rade (Taproot certainly was a slog) but I think the vast majority of us thi=
nk Taproot was worth that slog and Bitcoin would be poorer today without it=
.

The Great Consensus Cleanup is an interesting example in that I get Matt do=
esn't have time to champion it or focus on it with his LDK commitments but =
I have no idea where it would rank on his long term priority list if he was=
n't working on LDK. Similarly I have no idea what people who understand thi=
s evolving system much better than I do are thinking with regards to say ad=
ding new opcodes, sighash flags versus say waiting on Simplicity and possib=
ly adding new functionality within that potential upgrade. For people like =
me who are extremely unlikely to propose their own consensus change(s) gett=
ing some signal on what to spend time digging into would be useful rather t=
han second guessing what people are thinking. There is a danger that you fl=
irt with perceived public roadmaps when possible authority figures stick th=
eir necks out and effectively say "I'm not in charge but in an imaginary wo=
rld where I was this is my current thinking of the ordering in which we cou=
ld improve this system long term. But this could change depending on x, y a=
nd z and possible upgrades are only ready when they're ready and they have =
community consensus." There is no way people don't play these exercises in =
their minds. I do, I just have very few answers :) I personally think APO i=
s in prime position to improve Lightning channel state management with elto=
o and if it enables some covenant schemes too that seems like an added bonu=
s. On APO versus waiting for APO like functionality in Simplicity I have no=
 idea. Work on APO/eltoo and Simplicity both seem to be progressing in para=
llel so the APO versus Simplicity discussion perhaps rests on whether peopl=
e think certain covenants should only really be enabled once we have the se=
curity guarantees of Simplicity [3] (if at all).

Antoine's covenant R&D effort [4] seems really promising and I hope the she=
nanigans from earlier in the year don't put people off from engaging with t=
hat. Hopefully we can see more exploration, development and research in cov=
enants (e.g. this excellent research paper "Bitcoin Covenants: Three Ways t=
o Control the Future" [5]) and we can foster a community which has very hig=
h standards, is open to new ideas and new research but can avoid these mont=
hs long resisting chain split fights. I think the discussion would be much =
more interesting and much more productive if people didn't have to think "I=
f I express a view now it will be used to attack me personally later" or wo=
rse "If I express a view now it will be used to justify an upcoming chain s=
plit".=20

[0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b71=
8
[1]: https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on=
-signet-with-multiple-proposed-soft-forks-whilst-maintaining
[2]: https://bitcoin.stackexchange.com/questions/109764/what-opcodes-are-su=
pported-on-liquid-but-not-yet-on-bitcoin
[3]: https://bitcoinops.org/en/topics/simplicity/
[4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September=
/020912.html
[5]: https://arxiv.org/pdf/2006.16714.pdf

--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3


------- Original Message -------
On Saturday, September 17th, 2022 at 09:39, Matt Corallo via bitcoin-dev <b=
itcoin-dev@lists.linuxfoundation.org> wrote:


>=20
> On 9/17/22 2:14 AM, Anthony Towns wrote:
>=20
> > On Fri, Sep 16, 2022 at 12:46:53PM -0400, Matt Corallo via bitcoin-dev =
wrote:
> >=20
> > > On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote:
> > >=20
> > > > 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.
> >=20
> > Okay? "X is good" is obviously just a statement of opinion, so if you
> > want to disagree, that's obviously allowed.
> >=20
> > 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?
>=20
>=20
> No, I think its at least a good chunk of the "statement of problem". Yes,=
 more testing is good, and
> this project is a way to get that. Cool. But implying that lack of test f=
rameworks is in any
> material way part of the lack of movement on forks in Bitcoin I think is =
very wrong, so its worth
> pointing out, whether the particular project is useful or not is separate=
.
>=20
> > > Going back many, many years we've had many
> > > discussions about fork process, and the parts people (historically) a=
greed
> > > with tend to be:
> > > (1) come up with an idea
> > > (2) socialize the idea in the technical community, see if anyone come=
s up
> > > with any major issues or can suggest better ideas which solve the sam=
e
> > > use-cases in cleaner ways
> > > (3) propose the concrete idea with a more well-defined strawman, soci=
alize
> > > that, get some kind of rough consensus in the loosely-defined, subjec=
tive,
> > > "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 de=
al 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 ha=
ve
> > > people who want to be champions who are willing to (humbly) push an i=
dea
> > > forward towards rough agreement of the world of technical bitcoiners
> > > (without which I highly doubt you'd ever see broader-community consen=
sus).
> >=20
> > Personally, I think this is easily refuted by contradiction.
> >=20
> > 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
>=20
>=20
> No? Who is the champion for it? I haven't been. No one else is obliged to=
 take up the reins and run
> with it, that's not how open-source works. And no one has emerged who has=
 strong interest in doing
> so, and that's totally fine. It means it hasn't made any progress, but th=
at's an indication that no
> one feels strongly enough about it that its risen to the top of their per=
sonal priority list so
> clearly doesn't need to make progress.
>=20
> > 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.
>=20
>=20
> No? Its not up to the community to find a champion for someone who wants =
a fork to happen. Either
> someone thinks its a good enough idea that they step up, or no one does. =
If no one does, then so be
> it. If the original proper (me, in this case) thought it was that importa=
nt then its their
> responsibility to be the champion, no one else's.
>=20
> > 2) Many will argue that CTV has already done steps (1) through (3) abov=
e:
> > certainly there's been an idea, it's been socialised through giving tal=
ks,
> > having discussion forums, having research workshops [2], documenting us=
e
> > 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).
>=20
>=20
> I don't really see how you can make this argument seriously. Honestly, if=
 a soft-fork BIP only has
> one author on the list, then I'm not sure one can argue that step (3) has=
 really been completed, and
> maybe not even step (2).
>=20
> > So that leaves a few possibilities
> > to my mind:
>=20
> > * 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.
> >=20
> > * 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.
> >=20
> > * 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.
>=20
>=20
> I think this is most of it, but its not that they're too hard, its that p=
eople are too busy. There
> seemed to be more positive feedback, for example, to Rusty's proposal, bu=
t being the champion for a
> soft-fork is a full-time job for months on end, and last I checked Rusty =
has a lightning
> implementation to maintain, which tends to be a more-than-full-time job a=
lready.
>=20
> To my knowledge, no one but Jeremy has made any serious attempt at being =
the champion for a
> soft-fork since Taproot, and before that Segwit (if someone reading this =
who contributes to Core
> already wants to, and isn't sure how to, there's lots of people who would=
 happily mentor you! I'm
> sure you can figure out who to reach out to!).
>=20
> Matt
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev