path: root/45/3dfe39d89c6a1ac37ba38ba0b51c529360c389

Return-Path: <antoine.riard@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 48CF2C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Sep 2022 18:47:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 0463641986
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Sep 2022 18:47:54 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 0463641986
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=hooINM1D
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ZwieNWjb3p3n
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Sep 2022 18:47:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org DDC5941977
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com
 [IPv6:2607:f8b0:4864:20::d36])
 by smtp4.osuosl.org (Postfix) with ESMTPS id DDC5941977
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Sep 2022 18:47:50 +0000 (UTC)
Received: by mail-io1-xd36.google.com with SMTP id e205so17302434iof.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Sep 2022 11:47:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date;
 bh=OPqtjSjRraPewnK4ct8Z4f4wVmwpDwXX7t5LkmvIRTI=;
 b=hooINM1DJrV29xQlgw1wetyRWbmqDdDA0T3TxCfXV6dbd0CH7omGXP2qgwILhY5o07
 gIimp5Oal+NUpBsgCvQNWieSe79AUBTAcxMd2InBFp6RBA0VtLC5bI93tlimkZ6D412n
 6qwgleQUUMqA8EdBL7QQMStwUkmYbrsNz1faiDJOWHTzwR3Hjc0CziHvW0j25vXU+HuN
 KF5NEimaIlofvQOldybUuNZbX+hNMlKnnQLvQBWNa2fry3f/uMOf7toVOh1BuYkQ5YJC
 7+PoNFzuY8p8Kfwob4aLjHSeCIj8IZ1BOW7B0gmzWNcG4wSqZS+nf/jFpuah64yEs0Gp
 2J4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date;
 bh=OPqtjSjRraPewnK4ct8Z4f4wVmwpDwXX7t5LkmvIRTI=;
 b=n1nx2KxGrS6a6WhqxoaWKbslcJ1s+RIEGieVopvOqCxk0TZ4o7mnpNtQOdL8XcZJHu
 pB/9aJczpLpue4Rp8kYW0bea17Q01vp10huc8+xgNPYDx1buHDEsh42N6JEt8jmxViPm
 OQCcooHMRmXCRNjP4wFHKniV1dq6PK4sTZG6k0sYAh2SQMCC0LeC3QMDDicuPQcRI1fd
 QJi2OVLXTRs7ocNorAfhttdklSmSfFO6WMgR3drzT1frV2v4YefgFZAcyzc7/L+vJXrY
 Xk83lgj6VlzhwZr37me//vow3W5TMm24ToAywIG8K8OmSTVTXksFIBvFN9mJyFmo0BXd
 R6rQ==
X-Gm-Message-State: ACrzQf2c9rFjE/0rvkV579cqHjGuANlQE4m9EfcAto4uVPfzy+Rzwn98
 nYbNkn6uP4Dbq1yp2jxI7lLqZjZfVoQccKrCnNJ5+2im6SE=
X-Google-Smtp-Source: AMsMyM7vx/692+zv6XKLvKrwA+mNtjbbyjA0MXVWgx1lCGsPoen8hodT9gPQGOnT1Y1Kc0GZSWwtJwyydMdou5Y1WPM=
X-Received: by 2002:a05:6638:1315:b0:35a:7c96:9737 with SMTP id
 r21-20020a056638131500b0035a7c969737mr6554917jad.302.1663526869459; Sun, 18
 Sep 2022 11:47:49 -0700 (PDT)
MIME-Version: 1.0
References: <YyQioS3F942wu1HW@erisian.com.au>
In-Reply-To: <YyQioS3F942wu1HW@erisian.com.au>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sun, 18 Sep 2022 14:47:38 -0400
Message-ID: <CALZpt+HksJ8BFi-8jvKJQLskSiLnm5f-QR_zmFrsgLX19R630Q@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000020e79205e8f8084d"
X-Mailman-Approved-At: Mon, 19 Sep 2022 00:59:22 +0000
Subject: Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on
	signet
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Sep 2022 18:47:54 -0000

--00000000000020e79205e8f8084d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi AJ,

Thanks to setup a new laboratory for consensus upgrades experiment! Idea
was exposed during the last LN Summit, glad to see there is a useful fork
now.

While I think one of the problem particular in the current stagnation about
consensus upgrades has been well scoped by your proposal, namely on
formalizing the thorough analysis process to which an upgrade proposal
should be subject too, there are more issues or bounds to wonder on, at
least from my perspective.

Laying out fine-grained stages of the development process (research,
development, evaluation, deployment) sounds compelling to bring clarity to
everyone. However, I doubt it captures well the more realistic, chaotic
process from which new Bitcoin ideas and techniques are emerging. In
practice, consensus upgrades, akin to the sustenance of new scientific
theories or engineering principles in the wider creative areas of life, are
following an uncertain path of hazardous steps: seminal half-baked
intuitions, whiteboard modeling, code or quantitative experiments, loose
set of ideas pollination, peers feedbacks integration, etc before to mature
in some solidified proposals.

Said succinctly, in the genesis of creative ideas, evaluation doesn't
happen at a single clear point but all along the idea lifetime, where this
evaluation is as much done by the original author than its peers and a
wider audience. Sometimes really formally, e.g in academics with PhD thesis
defense. For Bitcoin, rather than to "declare" on the when and where
upgrades evaluation should happen once for all, I think a more open
evaluation process we can carry on is gathering and maintaining the factual
material and reasoning frameworks around solidified proposals, on which
each community stakeholder individually can assign a grounded judgement.
Those judgments are likely sources of new refinement of the upgrades
themselves.

Under that perspective, I believe a functional upgrades experimentation
platform as proposed by bitcoin-inquisition is very valuable, as it should
allow upgrades "champions" (CTV, ANYPREVOUT, TLUV, "fraud proofs" ops
primitives, etc) to loop faster in the R&D cycles, raise earlier awareness
on their work existence and as it's all open to assemble team around their
proposals. (Effectively, covenants upgrades and their associated use-cases
offered so much complexity that it's becoming less and less a one-man
job...).

I would still expose a concern to not downgrade in the pure empiricism in
matter of consensus upgrades. I.e, slowly emerging the norm of a working
prototype running on bitcoin-inquisition` as a determining factor of the
soundness of a proposal. E.g with "upgrading lightning to support eltoo", a
running e2e won't save us to think the thousands variants of pinnings, the
game-theory soundness of a eltoo as mechanism in face of congestions, the
evolvability of APO with more known upgrades proposals or the
implementation complexity of a fully fleshed-out state machine and more
questions.

That said, a e2e implementation, partial or complete, would at least make
the serious analysis process easier. Moreover, the benefit of having e2e
implems runnable by everyone on bitcoin-inquisition would likely lower the
bar to have independent consensus upgrade analysis, likely a source of new
relevant feedback.

I can only share the sentiment expressed that this alternative open
approach of consensus changes avoids the gradual establishment of a trusted
group, even informal. In the past, to the best of my knowledge, most of the
substance of the Taproot softfork daily development happened on
semi-offline communication channels and the strong design rational
decisions at CoreDev editions. While not discrediting the high-quality
feedback than one can gather during those types of in-person engineering
meetings, for neutrality and openness of the Bitcoin upgrades process it
could be great to only consider them as source of feedbacks and move
progressively the crux of the upgrades R&D process online, open to anyone
interested. Moreover, it would bind more adequately the reality of a
growing development ecosystem, where we have to deal with an increasing
diversity of technical, social and geographical community stakeholders. I
acknowledge there is a hard challenge to maintain high-signal, low-noise
online communication channels and spaces about context-rich issues like
upgrades, however that might be the type of challenge we have to solve if
we care about everyone using Bitcoin to truly be peers. At least my 2 sats.

About the risk of latent centralization of global default signets
miners/bitcoin-inquisition maintainers, I don't think I'm worried about it.
With time, I would guess we might have multiple experimental signets with
different series of patches, as some patches might invalidate the
observations of another upgrade. E,g if one implements the "weird" ideas
about changes in the block reward issuance schedule discussed during the
summer, another one might not want "noise" interferences with new
fee-bumping primitives as the miner incentives are modified. About the
bitcoin-inquisition fork maintainers themselves becoming gatekeepers of
consensus upgrades changes, best we can do is maintain high-quality
documentation and knowledge base to lower the forking cost of the platform
for any community stakeholder.

Anyway, I hold the belief that the more initiatives we see to modernize the
"consensus-upgrades" production factory in order to scale with the current
dimensions of the Bitcoin ecosystem, better we're. I hope the upcoming
Contracting Primitives WG will be able to document and discuss some of the
relevant experiments run on bitcoin-inquisition. Time and work will tell
how they fit all together, where they complement each other and synergies
that are nurtured.

Speaking for myself, looking forward to experimenting with CoinPool code
components on bitcoin-inquistion in the future!

Best,
Antoine

Le ven. 16 sept. 2022 =C3=A0 03:16, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> 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 earlie=
r
> 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=
.
>
> Obviously, a centralised solution to this problem exists: we could
> establish a trusted group, perhaps one containing devs, industry
> representatives, investors, etc, have them review proposals and their
> implementations, and follow their lead when they decide that a proposal
> has met their standards and should be widely deployed. Some might even
> say "sipa is precisely that group". The problem with having a group of
> that nature isn't one of effectiveness, but rather that they are then
> vulnerable to pressure and corruption, which isn't desirable if we want
> everyone using Bitcoin to truly be peers, and often isn't desirable for
> the prospective members of the group either. So that's not something we
> should want people to volunteer for, nor is it a duty we should thrust
> on people. Or at least, that's my opinion, anyway.
>
> I think any alternative approach to doing consensus changes (while
> avoiding a chain split) has to look something like this:
>
>  * propose an idea (research phase)
>  * implement the idea (development phase)
>  * demonstrate the idea is worthwhile (evaluation phase)
>  * once everyone is convinced, activate (deployment phase)
>
> Without an evaluation phase that is thorough enough to convince (almost)
> everyone, I think deployment becomes controversial and perhaps effectivel=
y
> impossible (at least without some trusted leadership group). But with an
> evaluation phase that demonstrates to everyone who's interested that the
> proposal has actual value, minimal cost and no risk, I think activation
> could be fairly easy and straightforward.
>
> I contend that the most significant problem we have is in the "evaluation
> phase". How do you convince enough people that a change is sufficiently
> beneficial to justify the risk of messing with their money? If you're
> only trying to convince a few experts, then perhaps you can do that with
> papers and talks; but limiting the evaluation to only a few experts is
> effectively just falling back to the centralised approach.
>
> So I think that means that part of the "evaluation phase" should involve
> implementing real systems on top of the proposed change, so that you
> can demonstrate real value from the change. It's easy to say that
> "CTV can enable vaults" or "CTV can make opening a lightning channel
> non-interactive" -- but it's harder to go from saying something
> is possible to actually making it happen, so, at least to me, it
> seems reasonable to be skeptical of people claiming benefits without
> demonstrating they're achievable in practice.
>
> I contend the easiest way we could make it easy to demonstrate a soft
> fork working as designed is to deploy it on the default global signet,
> essentially as soon as it has a fully specified proposal and a reasonably
> high-quality implementation.
>
> The problem with that idea is that creates a conundrum: you can't activat=
e
> a soft fork on the default signet without first merging the code into
> bitcoin core, you can't merge the code into bitcoin core until it's been
> fully evaluated, and the way you evaluate it is by activating it on the
> default signet?
>
> I think the weakest link in that loop is the first one: what if we did
> activate soft forks on the default signet prior to the code being merged
> into core? To that end, I'm proposing a fork of core that I'm calling
> "bitcoin-inquisition", with the idea that it branches from stable
> releases of core and adds support for proposed changes to consensus
> (CTV, ANYPREVOUT, TLUV, OP_CAT, etc...) and potentially also relay
> policy (relay changes are often implied by consensus changes, but also
> potentially things like package relay).
>
>   https://github.com/bitcoin-inquisition/bitcoin/wiki
>   https://github.com/bitcoin-inquisition/bitcoin/pulls
>
> The idea being that if you're trying to work on "upgrading lightning
> to support eltoo", you can iterate through changes needed to consensus
> (via bitcoin-inquisition) and client apps (cln, lnd, eclair etc), while
> testing them in public (on signet) and having any/all the pre-existing
> signet infrastructure available (faucets, explorers etc) without having
> to redeploy it yourself. Having multiple consensus changes deployed in
> one place also seems like it might make it easier to compare alternative
> approaches (eg CTV vs ANYPREVOUT vs OP_TXHASH vs OP_TX, etc).
>
> So that's the concept. For practical purposes, I haven't yet merged
> either CTV or APO support into the bitcoin-inquisition 23.0 branch yet,
> and before actually mining blocks I want to make the signet miner able
> to automatically detect/recover if the bitcoin-inquisition node either
> crashes or starts producing incompatible blocks.
>
> Anyway, I wanted to post the idea publicly, both to give folks an
> opportunity to poke holes in the idea, or to suggest any further
> improvements or otherwise do any review before the CTV and APO patches
> get merged.
>
> Some other details that may be of interest.
>
> The biggest challenge with soft forks and the idea of "iterating
> through changes" is that making improvements can create a hard fork,
> which then forces everyone running old software to update, which can be
> pretty inconvenient, especially if you don't actually care about that
> change. Since signet (and regtest) mining is effectively permissioned,
> we can avoid that problem by having all these proposed soft forks
> come with a pre-baked ability to abandon the soft fork (much as David
> Harding described in [1]). Once a soft fork is abandoned, it can either
> be ignored forever (and later versions of the software can not include
> the code to enforce it at all), or it can be replaced by a new version
> of the soft fork.
>
> Another benefit that comes from signet chains being permissioned is
> that miners can be expected to coordinate upgrading out of band, so
> there is no need for a 90% signalling threshold. Instead, activation
> (and abandonment) of a soft fork can be triggered by a single block
> signalling. That further means there is no need for any individual
> block to signal for multiple forks, and instead of having 29 different
> signals, we can instead easily have up to 2**29. I've chosen to make
> the standard signal have 16 bits for specifying a bip number (0-65535)
> and 8 bits for specifying a version of that bip, which seems like it
> should be more than enough at least for a while. More details at [2].
>
> I'm basing bitcoin-inquisition solely off stable releases. This is partly
> because it can be annoying to constantly rebase consensus changes aginst
> bitcoin core's master branch, but also I think it might help consensus
> changes be easily backported once they pass the "evaluation phase"
> and move into the "deployment phase".
>
> I'm not sure what level of code quality PRs should have before being
> merged into bitcoin-inquisition. I think CTV is plenty good enough,
> but I'm not sure about APO, particularly its test coverage. If you want
> to influence what becomes the tradition here, contributing a review,
> or posting patches against the upsteam branch might be a good start?
>
> Does this make the global default signet miners, or perhaps the
> bitcoin-inquisition maintainers the "trusted group" that we want to
> avoid? Hopefully not -- anyone can run their own fork or do their own
> fork of bitcoin core, so if the miners/maintainers start trying to
> arbitrarily block proposals they can be worked around without too much
> hassle. And since they're clearly separate from any of the actions that
> need to be taken for actual deployment once activation is complete,
> they shouldn't have any ability to unduly promote fork proposals that
> people aren't fully satisfied are ready for deployment.
>
> Cheers,
> aj
>
> [0]
> https://bitcoinops.org/en/newsletters/2022/04/27/#discussion-about-activa=
ting-ctv
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020242=
.html
>
> [2]
> https://github.com/bitcoin-inquisition/bitcoin/wiki/Heretical-Deployments
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--00000000000020e79205e8f8084d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi AJ,<br><br>Thanks to setup a new laboratory for consens=
us upgrades experiment! Idea was exposed during the last LN Summit, glad to=
 see there is a useful fork now.<br><br>While I think one of the problem pa=
rticular in the current stagnation about consensus upgrades has been well s=
coped by your proposal, namely on formalizing the thorough analysis process=
 to which an upgrade proposal should be subject too, there are more issues =
or bounds to wonder on, at least from my perspective.<br><br>Laying out fin=
e-grained stages of the development process (research, development, evaluat=
ion, deployment) sounds compelling to bring clarity to everyone. However, I=
 doubt it captures well the more realistic, chaotic process from which new =
Bitcoin ideas and techniques are emerging. In practice, consensus upgrades,=
 akin to the sustenance of new scientific theories or engineering principle=
s in the wider creative areas of life, are following an uncertain path of h=
azardous steps: seminal half-baked intuitions, whiteboard modeling, code or=
 quantitative experiments, loose set of ideas pollination, peers feedbacks =
integration, etc before to mature in some solidified proposals.<br><br>Said=
 succinctly, in the genesis of creative ideas, evaluation doesn&#39;t happe=
n at a single clear point but all along the idea lifetime, where this evalu=
ation is as much done by the original author than its peers and a wider aud=
ience. Sometimes really formally, e.g in academics with PhD thesis defense.=
 For Bitcoin, rather than to &quot;declare&quot; on the when and where upgr=
ades evaluation should happen once for all, I think a more open evaluation =
process we can carry on is gathering and maintaining the factual material a=
nd reasoning frameworks around solidified proposals, on which each communit=
y stakeholder individually can assign a grounded judgement. Those judgments=
 are likely sources of new refinement of the upgrades themselves.<br><br>Un=
der that perspective, I believe a functional upgrades experimentation platf=
orm as proposed by bitcoin-inquisition is very valuable, as it should allow=
 upgrades &quot;champions&quot; (CTV, ANYPREVOUT, TLUV, &quot;fraud proofs&=
quot; ops primitives, etc) to loop faster in the R&amp;D cycles, raise earl=
ier awareness on their work existence and as it&#39;s all open to assemble =
team around their proposals. (Effectively, covenants upgrades and their ass=
ociated use-cases offered so much complexity that it&#39;s becoming less an=
d less a one-man job...).<br><br>I would still expose a concern to not down=
grade in the pure empiricism in matter of consensus upgrades. I.e, slowly e=
merging the norm of a working prototype running on bitcoin-inquisition` as =
a determining factor of the soundness of a proposal. E.g with &quot;upgradi=
ng lightning to support eltoo&quot;, a running e2e won&#39;t save us to thi=
nk the thousands variants of pinnings, the game-theory soundness of a eltoo=
 as mechanism in face of congestions, the evolvability of APO with more kno=
wn upgrades proposals or the implementation complexity of a fully fleshed-o=
ut state machine and more questions.<br><br>That said, a e2e implementation=
, partial or complete, would at least make the serious analysis process eas=
ier. Moreover, the benefit of having e2e implems runnable by everyone on bi=
tcoin-inquisition would likely lower the bar to have independent consensus =
upgrade analysis, likely a source of new relevant feedback.<br><br>I can on=
ly share the sentiment expressed that this alternative open approach of con=
sensus changes avoids the gradual establishment of a trusted group, even in=
formal. In the past, to the best of my knowledge, most of the substance of =
the Taproot softfork daily development happened on semi-offline communicati=
on channels and the strong design rational decisions at CoreDev editions. W=
hile not discrediting the high-quality feedback than one can gather during =
those types of in-person engineering meetings, for neutrality and openness =
of the Bitcoin upgrades process it could be great to only consider them as =
source of feedbacks and move progressively the crux of the upgrades R&amp;D=
 process online, open to anyone interested. Moreover, it would bind more ad=
equately the reality of a growing development ecosystem, where we have to d=
eal with an increasing diversity of technical, social and geographical comm=
unity stakeholders. I acknowledge there is a hard challenge to maintain hig=
h-signal, low-noise online communication channels and spaces about context-=
rich issues like upgrades, however that might be the type of challenge we h=
ave to solve if we care about everyone using Bitcoin to truly be peers. At =
least my 2 sats.<br><br>About the risk of latent centralization of global d=
efault signets miners/bitcoin-inquisition maintainers, I don&#39;t think I&=
#39;m worried about it. With time, I would guess we might have multiple exp=
erimental signets with different series of patches, as some patches might i=
nvalidate the observations of another upgrade. E,g if one implements the &q=
uot;weird&quot; ideas about changes in the block reward issuance schedule d=
iscussed during the summer, another one might not want &quot;noise&quot; in=
terferences with new fee-bumping primitives as the miner incentives are mod=
ified. About the bitcoin-inquisition fork maintainers themselves becoming g=
atekeepers of consensus upgrades changes, best we can do is maintain high-q=
uality documentation and knowledge base to lower the forking cost of the pl=
atform for any community stakeholder.<br><br>Anyway, I hold the belief that=
 the more initiatives we see to modernize the &quot;consensus-upgrades&quot=
; production factory in order to scale with the current dimensions of the B=
itcoin ecosystem, better we&#39;re. I hope the upcoming Contracting Primiti=
ves WG will be able to document and discuss some of the relevant experiment=
s run on bitcoin-inquisition. Time and work will tell how they fit all toge=
ther, where they complement each other and synergies that are nurtured.<br>=
<br>Speaking for myself, looking forward to experimenting with CoinPool cod=
e components on bitcoin-inquistion in the future!<br><br>Best,<br>Antoine<b=
r></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">Le=C2=A0ven. 16 sept. 2022 =C3=A0=C2=A003:16, Anthony Towns via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">Subhead: &quot;Nobody expects a Bitc=
oin Inquistion? C&#39;mon man, *everyone*<br>
expects a Bitcoin Inquisition.&quot;<br>
<br>
As we&#39;ve seen from the attempt at a CHECKTEMPLATEVERIFY activation earl=
ier<br>
in the year [0], the question of &quot;how to successfully get soft fork<br=
>
ideas from concept to deployment&quot; doesn&#39;t really have a good answe=
r today.<br>
<br>
Obviously, a centralised solution to this problem exists: we could<br>
establish a trusted group, perhaps one containing devs, industry<br>
representatives, investors, etc, have them review proposals and their<br>
implementations, and follow their lead when they decide that a proposal<br>
has met their standards and should be widely deployed. Some might even<br>
say &quot;sipa is precisely that group&quot;. The problem with having a gro=
up of<br>
that nature isn&#39;t one of effectiveness, but rather that they are then<b=
r>
vulnerable to pressure and corruption, which isn&#39;t desirable if we want=
<br>
everyone using Bitcoin to truly be peers, and often isn&#39;t desirable for=
<br>
the prospective members of the group either. So that&#39;s not something we=
<br>
should want people to volunteer for, nor is it a duty we should thrust<br>
on people. Or at least, that&#39;s my opinion, anyway.<br>
<br>
I think any alternative approach to doing consensus changes (while<br>
avoiding a chain split) has to look something like this:<br>
<br>
=C2=A0* propose an idea (research phase)<br>
=C2=A0* implement the idea (development phase)<br>
=C2=A0* demonstrate the idea is worthwhile (evaluation phase)<br>
=C2=A0* once everyone is convinced, activate (deployment phase)<br>
<br>
Without an evaluation phase that is thorough enough to convince (almost)<br=
>
everyone, I think deployment becomes controversial and perhaps effectively<=
br>
impossible (at least without some trusted leadership group). But with an<br=
>
evaluation phase that demonstrates to everyone who&#39;s interested that th=
e<br>
proposal has actual value, minimal cost and no risk, I think activation<br>
could be fairly easy and straightforward.<br>
<br>
I contend that the most significant problem we have is in the &quot;evaluat=
ion<br>
phase&quot;. How do you convince enough people that a change is sufficientl=
y<br>
beneficial to justify the risk of messing with their money? If you&#39;re<b=
r>
only trying to convince a few experts, then perhaps you can do that with<br=
>
papers and talks; but limiting the evaluation to only a few experts is<br>
effectively just falling back to the centralised approach.<br>
<br>
So I think that means that part of the &quot;evaluation phase&quot; should =
involve<br>
implementing real systems on top of the proposed change, so that you<br>
can demonstrate real value from the change. It&#39;s easy to say that<br>
&quot;CTV can enable vaults&quot; or &quot;CTV can make opening a lightning=
 channel<br>
non-interactive&quot; -- but it&#39;s harder to go from saying something<br=
>
is possible to actually making it happen, so, at least to me, it<br>
seems reasonable to be skeptical of people claiming benefits without<br>
demonstrating they&#39;re achievable in practice.<br>
<br>
I contend the easiest way we could make it easy to demonstrate a soft<br>
fork working as designed is to deploy it on the default global signet,<br>
essentially as soon as it has a fully specified proposal and a reasonably<b=
r>
high-quality implementation.<br>
<br>
The problem with that idea is that creates a conundrum: you can&#39;t activ=
ate<br>
a soft fork on the default signet without first merging the code into<br>
bitcoin core, you can&#39;t merge the code into bitcoin core until it&#39;s=
 been<br>
fully evaluated, and the way you evaluate it is by activating it on the<br>
default signet?<br>
<br>
I think the weakest link in that loop is the first one: what if we did<br>
activate soft forks on the default signet prior to the code being merged<br=
>
into core? To that end, I&#39;m proposing a fork of core that I&#39;m calli=
ng<br>
&quot;bitcoin-inquisition&quot;, with the idea that it branches from stable=
<br>
releases of core and adds support for proposed changes to consensus<br>
(CTV, ANYPREVOUT, TLUV, OP_CAT, etc...) and potentially also relay<br>
policy (relay changes are often implied by consensus changes, but also<br>
potentially things like package relay).<br>
<br>
=C2=A0 <a href=3D"https://github.com/bitcoin-inquisition/bitcoin/wiki" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin-inquisition/bi=
tcoin/wiki</a><br>
=C2=A0 <a href=3D"https://github.com/bitcoin-inquisition/bitcoin/pulls" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin-inquisition/bi=
tcoin/pulls</a><br>
<br>
The idea being that if you&#39;re trying to work on &quot;upgrading lightni=
ng<br>
to support eltoo&quot;, you can iterate through changes needed to consensus=
<br>
(via bitcoin-inquisition) and client apps (cln, lnd, eclair etc), while<br>
testing them in public (on signet) and having any/all the pre-existing<br>
signet infrastructure available (faucets, explorers etc) without having<br>
to redeploy it yourself. Having multiple consensus changes deployed in<br>
one place also seems like it might make it easier to compare alternative<br=
>
approaches (eg CTV vs ANYPREVOUT vs OP_TXHASH vs OP_TX, etc).<br>
<br>
So that&#39;s the concept. For practical purposes, I haven&#39;t yet merged=
<br>
either CTV or APO support into the bitcoin-inquisition 23.0 branch yet,<br>
and before actually mining blocks I want to make the signet miner able<br>
to automatically detect/recover if the bitcoin-inquisition node either<br>
crashes or starts producing incompatible blocks.<br>
<br>
Anyway, I wanted to post the idea publicly, both to give folks an<br>
opportunity to poke holes in the idea, or to suggest any further<br>
improvements or otherwise do any review before the CTV and APO patches<br>
get merged.<br>
<br>
Some other details that may be of interest.<br>
<br>
The biggest challenge with soft forks and the idea of &quot;iterating<br>
through changes&quot; is that making improvements can create a hard fork,<b=
r>
which then forces everyone running old software to update, which can be<br>
pretty inconvenient, especially if you don&#39;t actually care about that<b=
r>
change. Since signet (and regtest) mining is effectively permissioned,<br>
we can avoid that problem by having all these proposed soft forks<br>
come with a pre-baked ability to abandon the soft fork (much as David<br>
Harding described in [1]). Once a soft fork is abandoned, it can either<br>
be ignored forever (and later versions of the software can not include<br>
the code to enforce it at all), or it can be replaced by a new version<br>
of the soft fork.<br>
<br>
Another benefit that comes from signet chains being permissioned is<br>
that miners can be expected to coordinate upgrading out of band, so<br>
there is no need for a 90% signalling threshold. Instead, activation<br>
(and abandonment) of a soft fork can be triggered by a single block<br>
signalling. That further means there is no need for any individual<br>
block to signal for multiple forks, and instead of having 29 different<br>
signals, we can instead easily have up to 2**29. I&#39;ve chosen to make<br=
>
the standard signal have 16 bits for specifying a bip number (0-65535)<br>
and 8 bits for specifying a version of that bip, which seems like it<br>
should be more than enough at least for a while. More details at [2].<br>
<br>
I&#39;m basing bitcoin-inquisition solely off stable releases. This is part=
ly<br>
because it can be annoying to constantly rebase consensus changes aginst<br=
>
bitcoin core&#39;s master branch, but also I think it might help consensus<=
br>
changes be easily backported once they pass the &quot;evaluation phase&quot=
;<br>
and move into the &quot;deployment phase&quot;.<br>
<br>
I&#39;m not sure what level of code quality PRs should have before being<br=
>
merged into bitcoin-inquisition. I think CTV is plenty good enough,<br>
but I&#39;m not sure about APO, particularly its test coverage. If you want=
<br>
to influence what becomes the tradition here, contributing a review,<br>
or posting patches against the upsteam branch might be a good start?<br>
<br>
Does this make the global default signet miners, or perhaps the<br>
bitcoin-inquisition maintainers the &quot;trusted group&quot; that we want =
to<br>
avoid? Hopefully not -- anyone can run their own fork or do their own<br>
fork of bitcoin core, so if the miners/maintainers start trying to<br>
arbitrarily block proposals they can be worked around without too much<br>
hassle. And since they&#39;re clearly separate from any of the actions that=
<br>
need to be taken for actual deployment once activation is complete,<br>
they shouldn&#39;t have any ability to unduly promote fork proposals that<b=
r>
people aren&#39;t fully satisfied are ready for deployment.<br>
<br>
Cheers,<br>
aj<br>
<br>
[0] <a href=3D"https://bitcoinops.org/en/newsletters/2022/04/27/#discussion=
-about-activating-ctv" rel=3D"noreferrer" target=3D"_blank">https://bitcoin=
ops.org/en/newsletters/2022/04/27/#discussion-about-activating-ctv</a><br>
<br>
[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022=
-April/020242.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linu=
xfoundation.org/pipermail/bitcoin-dev/2022-April/020242.html</a><br>
<br>
[2] <a href=3D"https://github.com/bitcoin-inquisition/bitcoin/wiki/Heretica=
l-Deployments" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitc=
oin-inquisition/bitcoin/wiki/Heretical-Deployments</a><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000020e79205e8f8084d--