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

Hi Michael,

> I agree with Matt. The less said about the "Aw shucks Jeremy didn't know =
that CTV didn't have community consensus at the time" [0] and "it was the l=
ack of process that was the problem" the better.=20

The linked gist cannot be taken seriously and I am not sure why you keep sh=
aring it as some document to prove there was no technical consensus for BIP=
 119. Nadav has already mentioned this in the comments. If you care about c=
ommunity consensus, maybe feedback about the links in that gist should also=
 be respected. There was chaos, misinformation and lot of drama on twitter.=
 Some people that opposed CTV on twitter still have no clue what CTV actual=
ly does and a few were super enthusiastic because of the author for BIP 119=
.

> I'm not convinced by the name (bitcoin-inquisition, shedpaint, shedpaint,=
 let's park that for the moment) but I do like the idea of signet having so=
ft fork proposals enabled on it [1] whether that be CTV, APO etc and if tha=
t requires more of the signet code to be moved out of the Core repo so be i=
t.

Good to see some positivity, finally. Because tx introspection aka covenant=
s would help everyone involved in bitcoin. This idea of experimenting with =
soft forks on signet together with research and meetings suggested by Antoi=
ne should help in better evaluation phase with less drama, politics etc. an=
d more technical discussions to reach a goal.

> 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.=20

1)Nobody uses Liquid. Signet has more activity than Liquid.
2)Testing something on Liquid will be completely different as its a separat=
e blockchain with some similarities.

I have summarized a few other positives of testing soft forks on signet bas=
ed on AJ's email:

a)Better evaluation
b)PR implementing soft fork could be reviewed and merged outside core
c)Testing on signet with pre-existing signet infrastructure
d)Can deploy multiple consensus changes so easier to compare alternative ap=
proaches (eg CTV vs ANYPREVOUT vs OP_TXHASH vs OP_TX, etc)
e)Pre-baked ability to abandon the soft fork
f)No need to regularly rebase consensus changes against bitcoin core's mast=
er branch

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Saturday, September 17th, 2022 at 3:53 PM, Michael Folkson via bitcoin-d=
ev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> I agree with Matt. The less said about the "Aw shucks Jeremy didn't know =
that CTV didn't have community consensus at the time" [0] and "it was the l=
ack of process that was the problem" the better. If people don't care about=
 lack of community consensus there is no process in a permissionless, open =
source community that can stop them or direct them down a more patient, pro=
ductive path (I tried). I think it is a shame because I think (maybe I'm wr=
ong) at least in the technical community there is an understanding that lon=
g term Bitcoin is far from finished in exhausting its potential and we do n=
eed people who will work on changes that we'll need in the long term.
>=20
> There are a few interesting things in here though. I'm not convinced by t=
he name (bitcoin-inquisition, shedpaint, shedpaint, let's park that for the=
 moment) but I do like the idea of signet having soft fork proposals enable=
d on it [1] whether that be CTV, APO etc and if that requires more of the s=
ignet code to be moved out of the Core repo so be it. I'm surprised more is=
n'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 (an=
d/or Liquid/sidechains) seem an obvious stepping stone to me for convincing=
 the 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 u=
pgrade (Taproot certainly was a slog) but I think the vast majority of us t=
hink Taproot was worth that slog and Bitcoin would be poorer today without =
it.
>=20
> The Great Consensus Cleanup is an interesting example in that I get Matt =
doesn't have time to champion it or focus on it with his LDK commitments bu=
t I have no idea where it would rank on his long term priority list if he w=
asn't working on LDK. Similarly I have no idea what people who understand t=
his evolving system much better than I do are thinking with regards to say =
adding new opcodes, sighash flags versus say waiting on Simplicity and poss=
ibly adding new functionality within that potential upgrade. For people lik=
e me who are extremely unlikely to propose their own consensus change(s) ge=
tting some signal on what to spend time digging into would be useful rather=
 than second guessing what people are thinking. There is a danger that you =
flirt with perceived public roadmaps when possible authority figures stick =
their necks out and effectively say "I'm not in charge but in an imaginary =
world where I was this is my current thinking of the ordering in which we c=
ould improve this system
> long term. But this could change depending on x, y and z and possible upg=
rades 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 is in prime position t=
o improve Lightning channel state management with eltoo and if it enables s=
ome covenant schemes too that seems like an added bonus. On APO versus wait=
ing for APO like functionality in Simplicity I have no idea. Work on APO/el=
too and Simplicity both seem to be progressing in parallel so the APO versu=
s Simplicity discussion perhaps rests on whether people think certain coven=
ants should only really be enabled once we have the security guarantees of =
Simplicity [3] (if at all).
>=20
> Antoine's covenant R&D effort [4] seems really promising and I hope the s=
henanigans from earlier in the year don't put people off from engaging with=
 that. Hopefully we can see more exploration, development and research in c=
ovenants (e.g. this excellent research paper "Bitcoin Covenants: Three Ways=
 to Control the Future" [5]) and we can foster a community which has very h=
igh standards, is open to new ideas and new research but can avoid these mo=
nths long resisting chain split fights. I think the discussion would be muc=
h more interesting and much more productive if people didn't have to think =
"If I express a view now it will be used to attack me personally later" or =
worse "If I express a view now it will be used to justify an upcoming chain=
 split".
>=20
> [0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b=
718
> [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-=
supported-on-liquid-but-not-yet-on-bitcoin
> [3]: https://bitcoinops.org/en/topics/simplicity/
> [4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Septemb=
er/020912.html
> [5]: https://arxiv.org/pdf/2006.16714.pdf
>=20
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>=20
>=20
> ------- Original Message -------
> On Saturday, September 17th, 2022 at 09:39, Matt Corallo via bitcoin-dev =
bitcoin-dev@lists.linuxfoundation.org wrote:
>=20
>=20
>=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-de=
v 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 activatio=
n earlier
> > > > > in the year [0], the question of "how to successfully get soft fo=
rk
> > > > > ideas from concept to deployment" doesn't really have a good answ=
er 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 th=
e
> > > 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) maki=
ng
> > > it better, which would be worthwhile anyway?
> >=20
> > No, I think its at least a good chunk of the "statement of problem". Ye=
s, more testing is good, and
> > this project is a way to get that. Cool. But implying that lack of test=
 frameworks is in any
> > material way part of the lack of movement on forks in Bitcoin I think i=
s very wrong, so its worth
> > pointing out, whether the particular project is useful or not is separa=
te.
> >=20
> > > > 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 co=
mes up
> > > > with any major issues or can suggest better ideas which solve the s=
ame
> > > > use-cases in cleaner ways
> > > > (3) propose the concrete idea with a more well-defined strawman, so=
cialize
> > > > that, get some kind of rough consensus in the loosely-defined, subj=
ective,
> > > > "technical community" (ie just ask people and adapt to feedback unt=
il 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 bitcoiner=
s
> > > > (without which I highly doubt you'd ever see broader-community cons=
ensus).
> > >=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 th=
e
> > > past 3.5 years
> >=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 h=
as strong interest in doing
> > so, and that's totally fine. It means it hasn't made any progress, but =
that's an indication that no
> > one feels strongly enough about it that its risen to the top of their p=
ersonal 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 it=
s
> > > 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 coul=
d
> > > have taken it over in that timeframe.
> >=20
> > No? Its not up to the community to find a champion for someone who want=
s 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 impor=
tant 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) ab=
ove:
> > > certainly there's been an idea, it's been socialised through giving t=
alks,
> > > 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 alternativ=
e
> > > approaches have been suggested [3], none of them have even really mad=
e
> > > it to step (2), let alone step (3).
> >=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) h=
as 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
> > I think this is most of it, but its not that they're too hard, its that=
 people are too busy. There
> > seemed to be more positive feedback, for example, to Rusty's proposal, =
but being the champion for a
> > soft-fork is a full-time job for months on end, and last I checked Rust=
y has a lightning
> > implementation to maintain, which tends to be a more-than-full-time job=
 already.
> >=20
> > To my knowledge, no one but Jeremy has made any serious attempt at bein=
g the champion for a
> > soft-fork since Taproot, and before that Segwit (if someone reading thi=
s who contributes to Core
> > already wants to, and isn't sure how to, there's lots of people who wou=
ld 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
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev