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 à 03:16, Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > 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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
