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
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.
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 effectively
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 activate
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-activating-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